Going from a remote charm to a local fork of it...
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
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
More information about the Juju