Do we still need juju upgrade-charm --switch ... ?

Rick Harding rick.harding at canonical.com
Fri Mar 11 03:43:44 UTC 2016


The one use case that came up just this week is the ability to crosscrade
from different channels of charms in the new charm publishing world. You
deploy the charm from the stable path.

You find a bug, and the charm author tests a fix and publishes it to the
development channel. The author then reaches out to you to test the fix.
You could use upgrade-charm to switch tracking the stable channel to the
development channel and back.

I think it's typically used to move a running deployment to a fork of a
charm that is either maintained, has a bugfix you want, or other such
reasons.

I think we want to keep it. Can we make it safer? Provider better docs? I
think so, but I don't think we can remove it.

On Thu, Mar 10, 2016 at 10:28 PM Ian Booth <ian.booth at canonical.com> wrote:

> So we have a feature of upgrade-charm which allows you to crossgrade to a
> different charm than the one originally deployed.
>
> From the upgrade-charm help docs:
>
> The new charm's URL and revision are inferred as they would be when
> running a
> deploy command.
> Please note that --switch is dangerous, because juju only has limited
> information with which to determine compatibility; the operation will
> succeed,
> regardless of potential havoc.
>
> What is the use case for this functionality? I seemed to get the
> impression it
> was used mainly with local repos? But given local repos are going away in
> 2.0,
> do we still need it? And given the potential for users getting things
> wrong, do
> we even want to keep it regardless? Note also --switch is not allowed with
> --path which is how local charms are upgraded.
>
> What would folks lose if --switch were to be dropped for 2.0? Any
> objections to
> doing this?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160311/6d172470/attachment.html>


More information about the Juju-dev mailing list