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

[Clint Byrum]

Excerpts from Kapil Thangavelu's message of Wed Nov 09 18:29:49 -0800 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'
> 

Kapil, I know your reply was a long time ago, so I've left the whole
thing quoted.

The sentence above is a problem, we need a 'switch-charm' command.

The reason being, as a user of juju in production, I can't wait for
*charmers* to fix the charm. If I were using Ubuntu and I had an *urgent*
patch to mysql, I would follow this workflow:

apt-get source mysql
<fix the bug>
debuild binary
<push debs to my servers>

After that, if the fix worked, and I feel its useful for other users,
I *MIGHT* have time to send the fix back to Ubuntu.

With juju, we need something similar, if I have done:

juju deploy cs:mysql mydb

And then the mysql charm is *breaking* my environment, or doesn't have
some config option I need, I need to be able to do

juju download-charm --repository=localcharms mydb
<fix the bug in localcharms/mysql>
juju switch-charm --repository=localcharms mydb local:mydb
juju upgrade-charm --repository=localcharms mydb

Yes, we want that fix to be contributed back, but that is completely
secondary to juju being useful for lifecycle management of services.

> 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).
> 
> cheers,
> 
> Kapil