Juju feedback from the Launchpad Yellow Squad

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Thu Feb 16 02:09:38 UTC 2012


> Uhh, uhh, wait!!!
>
> Stop is not supposed to delete stuff!

Indeed!

>> Maybe our collective memory is wrong that juju (the zookeeper box?) has
>> the old charm cached and does not automatically refresh on an attempt to
>> redeploy, but that's our impression, and that's what this is about.

That's an interesting situation indeed. We have to fix this.

> This has also been a source of frustration for me since my very first
> charm writing experience.
>
> The way it works is that there is a 'revision' file in the charm's root,
> and that is the only way that juju knows whether or not the charm has
> changed. The fact that you want to use upgrade-charm is testament to
> the fact that upgrade-charm was modified to *increment* this revision
> every time it is run. Thats a nice feature, but only halfway done.
>
> IMO, this revision is a blight on the charm format, and should be
> rethought entirely. To me, we know if any files have changed, and if
> they have, subsequent deploys should deploy what is in the charm now.

I'm not sure I understand what you're suggesting. Are you saying that,
for example, I have a production environment running, and then I hack
on some files on disk, and then I ask my production environment to
deploy a service again, and then the files on disk are used rather
than what is already in the production environment? We really can't
allow for something like that to happen without explicit
acknowledgement from the admin. Upgrading a running charm will always
be an explicit action.

That said, the revision isn't really an oversight, and rather works
pretty much like you describe already. The revision is important
metadata for human consumption, though. Please read those two
sentences:

"I was using revision ab5766f765 of cs:oneiric/mongodb and I'm now
using 7efa7fba878a. I've heard revision 15fa87fa8ac is broken."

"I was using revision 10 of cs:oneiric/mongodb and I'm now using 14.
I've heard revision 12 is broken."

We may actually introduce a unique digest for charms at some point to
handle some scenarios, but revision numbers aren't going away.

> I actually just added some code to the juju-jitsu deploy wrapper that
> just sets the charm's revision to the result of int(time.time()) every
> time you deploy.  Yes this means every time you deploy you will get

Ugh.. that sounds nasty. What's the problem with current+1? The plan
is already to handle local updating of revisions automatically with
something like that. Whenever you say "upgrade-charm" to a local
charm, it should bump the revision and send the current content.

> I think we should probably see how the experience changes with a backend
> charm store available. That may end up making this frustration moot,
> tho I don't know how, since conceivably, charms will be developed locally
> and tested using local: before being pushed into cs:... branches.

Agreed. The local case must/will be fixed too. It's trivial really.

> I think this is just a product of the fact that before the 'private-*'
> settings, the relation namespace was considered somewhat sacred, and
> so everything that was not specifically relationship data set by charms
> was placed in the environment. That is of course, not the case anymore.
>
> +1 for adding more private-* fields.

It's not about the "private-" namespace. Both private-address and
public-address are set by the system, and those names simply reflect
what those settings mean.

The reason why those are relation settings rather than environment
variables is that they are meant for consumption by the other side,
and they actually may be overwritten if the charm decides to. The role
of relation-get and relation-set is to communicate.

The data we have in environment variables is context set by the unit
agent both for the benefit of the hook and for the charm tools to run.
relation-get and relation-set make use of them.

> We have thought about adding this into charm-tools as a charm-helper
> that would inspect a declarative section in metadata.yaml.

Please don't do that. We may even start blocking charms with random
content in metadata.yaml at some point to prevent breaking things
arbitrarily and unintendedly. metadata.yaml is for content that is
part of the specification only.

> So it would look something like
>
> apt-packaging:
>  add-repos: [ 'ppa:charmers/charm-helpers', 'ppa:ubuntu-server-edgers/php' ]
>  install-packages: ['php5-fpm','nginx','wordpress']

I don't understand. How's that any better than adding this to the install hook:

    add-apt-repository ppa:charmers/charm-helpers
    add-apt-repository ppa:ubuntu-server-edgers/php
    apt-get install php5-fpm nginx wordpress

This seems clear, cleaner, and expected.

> Then potentially your install hook would just be:
>
> # code to install charm-helpers
> ch_apt_add_repos
> ch_apt_install_packages

This is adding more layers of abstraction, more dependencies, more
code to break, more complexity for the user to understand. What is it
buying us in exchange?

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.



More information about the Juju mailing list