Juju feedback from the Launchpad Yellow Squad

[Gustavo Niemeyer]

> 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.


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.

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


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.


(...)
> 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.


> 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.


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

-- I'm not absolutely sure of anything.