Going from a remote charm to a local fork of it...

Kapil Thangavelu kapil.thangavelu at canonical.com
Thu Nov 10 02:29:49 UTC 2011

Excerpts from Clint Byrum's message of Wed Nov 09 09:16:11 -0500 2011:
> Since I expect we'll have the charm store soon enough, I wanted to start
> thinking about how it might end up being used in production. One thing
> that crossed my mind is how will people fork the remote charms?

The remote charm store client integration does cache the charm locally on the 
client (~/.juju/cache/downloads). We can add an explicit download-charm command 
to facilitate as well. 

Its not clear if the charms as bundled by the store would include the version 
control information. Even though the charms are packaged against a bzr repo, an 
explicit goal has to been allow for charm authors to utilize whatever version 
mechanism they are most comfortable with, and deferring to an upload command 
for bzr/lp/store integration. 
> If the mysql charm doesn't do something that I need, I'll need to fork
> it before I can propose any change for the masses. So, do we support
> that somehow?

The goal is that they could push it back to the charm store, it will 
automatically be put up as a ppa style charm there. Right now pushing to the 
store is a manual process as described in the juju wiki charm page (effectively 
get it to lp under the right distro and series). Getting upload functionality 
integrated into the client should help this process. 

In terms of getting a meaningful merge proposal back to the distro charm, it 
would be nice if the download component could take a --fork/branch flag, which 
would branch the distro charm into a ppa at download, so the charm upload 
be a commit on top of the ppa branch, and would preserve vcs context for an lp 
merge request to the distro charm.

> Seems like once we've deployed.. we can only upgrade-charm from the
> same place, since the namespace is kept along with the charm at that
> point.

Its really a matter of taste, we could support it.

Right now charm repository namespace support is limited to local or charm store, 
with further explicit division of the repo into series, and ppa|distro. 

The upgrade-charm implementation atm will only consider a newer version of the 
deployed charm matching its 'namespace:[ppa]series/charm'

So upgrade switching between a ppa and the distro charm isn't supported atm. 
We can change the implementation but need to define the use cases.

 - upgrade a deployed distro charm to one from the ppa.
 - upgrade a deployed ppa charm to one from the distro.
 - upgrade a local charm to one from the store.
 - upgrade a store charm to a local one.

One caveat, charm names are only loosely coupled across namespaces and may lack 
vc revision ancestry  (ie. cs:~fewbar/oneiric/superdb may have nothing in common 
with cs:oneiric/superdb).



More information about the Juju mailing list