Juju feedback from the Launchpad Yellow Squad

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of Thu Feb 16 07:20:12 -0800 2012:
> > Right, upgrade-charm requires a service name for a reason.. you are
> > explicitly asking for that service to have the newest version of the
> > charm.
> >
> > Deploy creates services.. and whats *VERY* confusing, is that this
> > command does not in fact deploy the charm on disk, it deploys the latest
> > one that juju has been told about explicitly.
> >
> > juju deploy --repository ~/charms local:mysql
> 
> You're right, this is very confusing, and there's no other way to read
> it besides the way you're reading. I've just had a conversation with
> Kapil on the subject, and there are three different angles of the
> problem to solve:
> 
> 
> 1) The "local:" scheme is misnamed
> 
> The command line above has a very strong cue for "use what I have in
> my disk" which is not intended. The real meaning for this scheme is
> that this is a standalone charm, that didn't come from a well known
> repository.
> 
> To solve this problem, I propose we rename the "local:" scheme to
> "adhoc:", as that matches the intended meaning much better and avoids
> the misleading connotation. We should update Oneiric to support the
> new name, and preserve the support for the old one for compatibility's
> sake.
> 

Ugh. At least the local: scheme tells me where the revision is coming
from. I'd much rather be informed about what juju thinks the revision
is than have some ambiguous thing like 'adhoc' in its place. This tells
me less about what is going on, not more.

If juju simply said "Uploading your new charm" or "Using existing revno=X"
that would solve the ambiguity of what 'local' means, without need for
a new scheme.

As an aside, Oneiric cannot be updated until this bug is addressed
(this is a *MUST* fix for precise as well):

https://bugs.launchpad.net/juju/+bug/926550

> 
> 2) It must be possible to deploy the new version of a charm
> 
> There are good arguments for having deploy upgrading the charm as
> well, and we should support that in a very convenient way. That said,
> this command should not change the version of mongodb if it was
> previously deployed:
> 
>     juju deploy adhoc:mongodb
> 
> This command shouldn't change it either, because it's saying exactly
> the same thing as the first one, but informing juju that there's a
> repository available:
> 
>     juju deploy --repository ~/charms adhoc:mongodb
> 
> If the latter one sounds surprising, keep in mind that --repository
> can (and probably will) become an option in the configuration file
> permanently, which means the second one will in fact look like the
> first one, so it's clear that they must have the same behavior.
> 

+1 for deploy always doing the same thing given the same set of
repositories.

> So, to solve this part of the problem, I propose we introduce a
> -u/--upgrade flag to the deploy command that will cause juju to look
> at the latest version of the charm and upload it into the environment,
> before deploying. This means the two command lines will look like:
> 
>     juju deploy -u adhoc:mongodb
>     juju deploy -u --repository ~/charms adhoc:mongodb
> 
> 

*that* is a fantastic idea. This flag will do the same thing as
upgrade-charm I presume (bump the revno) before deploying, right? The
mere presence of it will likely lead to people over-using it while
developing charms, but I think that is far less of a concern than people
being confused.

> 3) Upgrading of charms in a bad state
> 
> The last bit of the problem, which only became more clear after Kapil
> explained, is to make upgrading of charms more comfortable in
> scenarios when people are quickly iterating over versions of a hook to
> fix its problems. For that, we agreed to introduce the --force flag:
> 
>     juju upgrade-charm --force adhoc:mongodb
> 
> This would ignore any error states, and forcefully deploy the new
> charm onto every running unit.
> 

+1 for that as well!

> 
> (...)
> > Sure, we can keep our little experiments out of metadata.yaml. Though
> 
> Thanks.
> 
> > I'd think at some point some of these intentions will be useful as
> > metadata for the charm store, and so, it bight be good to gather them
> > all in one place.
> 
> That's certainly fine, and we should indeed improve what goes into
> metadata.yaml over time. We should just do so carefully, since this
> file contains settings that we'll be making a stronger promise about.
> 

Yeah, perhaps we could have an 'extended-metadata.yaml' while features
are still unspecified in juju.

> > As this ocurred, the things that people tended to do over and over
> > started collecting into debhelper. It became painfully obvious that having
> > declarative lists of files was far more adaptive than having code, so
> 
> All I'm suggesting is that we take what is painfully obvious and put
> that into juju proper so that people can have the nicest possible
> experience. If you want declarative packages and repositories, let's
> have that.
> 

If we tried to put all of debhelper into dpkg, debhelper 7 with its
magical minimal rules file would never have happened. CDBS would be
the only implementation, because it would have been the first one to
implement a highly declarative format, and the effort to put it in dpkg
would have been far too high to allow for the set based approach that
resulted in the best solution (dh).

dpkg, like juju, is extremely conservative in its development, and
rightfully so. Things that *must* be done in dpkg are, but everything
else is done in debhelper because debhelper can iterate and expand the
capabilities of packaging far faster, without universally locking all
users into a proposed solution.

With all of the features and bugs needed to be addressed in juju core,
this one is not really a priority, especially since it can be addressed
outside juju core while we figure out what will work better. If we get
to a place of zen perfection like debhelper has, then we could consider
moving it in to juju. But until then, I think it would *hurt* the idea
to lock it into juju.