On Thu, Mar 10, 2016 at 10:28 PM Ian Booth <[email protected]> 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. > We use switch a lot, and customers use this as well. The primary use case is "I have a bug in production charm that is not available upstream yet". I expect future 2.0 uses to look like this: charm pull <charm> <hack on code> juju upgrade-charm --switch ./<charm> <service> Another example, esp because of how the charmstore is structured now juju deploy trusty/wordpress # hackity hack juju deploy --switch cs:~marcoceppi/trusty/wordpress wordpress > > What would folks lose if --switch were to be dropped for 2.0? Any > objections to > doing this? I object. Switch should be updated to support ./local/directory/charm instead of local: Marco
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
