Re: Do we still need juju upgrade-charm --switch ... ?
On 11/03/16 13:43, Rick Harding wrote: > 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. > Ok, thanks for clarifying. The help text was a little confusing because it mentioned switch in the same breath as local repos. The command does check that the new charm declares the same relations and has the same config schema etc. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Do we still need juju upgrade-charm --switch ... ?
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 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? > > > > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Do we still need juju upgrade-charm --switch ... ?
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? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)
Thanks Rick. Trivial change to make. This work should be in beta3 due next week. The work includes dropping support for local repositories in favour of path based local charm and bundle deployment. On 10/03/16 23:37, Rick Harding wrote: > Thanks Ian, after thinking about it I think what we want to do is really > #2. The reasoning I think is: > > 1) we want to make things consistent. The CLI experience is present a charm > and override series with --series= > 2) more consistent, if you do it with local charms you can always do it > 3) we want to encourage folks to drop series from the charmstore urls and > worry less about series over time. Just deploy X and let the charm author > pick the default best series. I think we should encourage this in the error > message for #2. "Please remove the series section of the charm url" or the > like when we error on the conflict, pushing users to use the series > override. > > Uros, Francesco, this brings up a point that I think for multi-series > charms we want the deploy cli snippets to start to drop the series part of > the url as often as we can. If the url doesn't have the series specified, > e.g. jujucharms.com/mysql then the cli command should not either. Right now > I know we add the series/revision info and such. Over time we want to try > to get to as simple a command as possible. > > On Thu, Mar 10, 2016 at 7:23 AM Ian Booth wrote: > >> I've implemented option 1: >> >> error if Series attribute is used at all with a store charm URL >> >> Trivial to change if needed. >> >> On 10/03/16 12:58, Ian Booth wrote: >>> Yeah, agreed having 2 ways to specify store series can be suboptimal. >>> So we have 2 choices: >>> >>> 1. error if Series attribute is used at all with a store charm URL >>> 2. error if the Series attribute is used and conflicts >>> >>> Case 1 >>> -- >>> >>> Errors: >>> >>> Series: trusty >>> Charm: cs:mysql >>> >>> Series: trusty >>> Charm: cs:trusty/mysql >>> >>> Ok: >>> >>> Series: trusty >>> Charm: ./mysql >>> >>> >>> Case 2 >>> -- >>> >>> Ok: >>> >>> Series: trusty >>> Charm: cs:mysql >>> >>> Series: trusty >>> Charm: cs:trusty/mysql >>> >>> Series: trusty >>> Charm: ./mysql >>> >>> Errors: >>> >>> Series: xenial >>> Charm: cs:trusty/mysql >>> >>> >>> On 10/03/16 12:51, Rick Harding wrote: Bah maybe you're right. I want to sleep on it. It's kind of ugh either >> way. On Wed, Mar 9, 2016, 9:50 PM Rick Harding wrote: > I think there's already rules for charmstore charms. it uses the >> default > if not specified. I totally agree that for local charms we have to have > this. For remote charms though this is providing the user two ways to >> do > the same thing > > On Wed, Mar 9, 2016, 9:46 PM Ian Booth >> wrote: > >> If the charm store charm defines a series in the URL, then we will >> consider it >> an error to specify a different series using the attribute. But charm >> store URLs >> are not required to have a series, so we can use the attribute in that >> case. It >> also allows users to easily switch between store and local charms >> during >> development just by replacing "./" with "cs:" >> >> nova-compute: >>series: xenial >>charm: ./nova-compute >> >> nova-compute: >>series: xenial >>charm: cs:nova-compute >> >> >> On 10/03/16 12:21, Rick Harding wrote: >>> I'm not sure we want to make this attribute apply to charmstore >> charms. >>> We've an established practice of the charmstore url being the series >>> information. It gives the user a chance to have conflicting >> information >> if >>> the charmstore url is cs:trusty/nova-compute and the series >> attribute is >>> set to xenial. I think we should toss an error to a bundle that has >> series: >>> specified for a charmstore based charm value (or non-local value >> whichever >>> way you want to think about it) >>> >>> On Wed, Mar 9, 2016 at 6:29 PM Ian Booth >> wrote: >>> One additional enhancement we need for bundles concerns specifying >> series for multi-series charms, in particular local charms now that the local >> repo will be going away. Consider: A new multi-series charm may have a URL which does not specify the >> series. In that case, the series used will be the default specified in the >> charm metadata or the latest LTS. But we want to allow people to choose their own >> series also. So we need a new (optional) Series attribute in the bundle metadata. bundle.yaml series: trusty services: nova-compute: series: xenial <-- new charm: ./nova-compute num_units: 2 or with a
Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)
Thanks Ian, after thinking about it I think what we want to do is really #2. The reasoning I think is: 1) we want to make things consistent. The CLI experience is present a charm and override series with --series= 2) more consistent, if you do it with local charms you can always do it 3) we want to encourage folks to drop series from the charmstore urls and worry less about series over time. Just deploy X and let the charm author pick the default best series. I think we should encourage this in the error message for #2. "Please remove the series section of the charm url" or the like when we error on the conflict, pushing users to use the series override. Uros, Francesco, this brings up a point that I think for multi-series charms we want the deploy cli snippets to start to drop the series part of the url as often as we can. If the url doesn't have the series specified, e.g. jujucharms.com/mysql then the cli command should not either. Right now I know we add the series/revision info and such. Over time we want to try to get to as simple a command as possible. On Thu, Mar 10, 2016 at 7:23 AM Ian Booth wrote: > I've implemented option 1: > > error if Series attribute is used at all with a store charm URL > > Trivial to change if needed. > > On 10/03/16 12:58, Ian Booth wrote: > > Yeah, agreed having 2 ways to specify store series can be suboptimal. > > So we have 2 choices: > > > > 1. error if Series attribute is used at all with a store charm URL > > 2. error if the Series attribute is used and conflicts > > > > Case 1 > > -- > > > > Errors: > > > > Series: trusty > > Charm: cs:mysql > > > > Series: trusty > > Charm: cs:trusty/mysql > > > > Ok: > > > > Series: trusty > > Charm: ./mysql > > > > > > Case 2 > > -- > > > > Ok: > > > > Series: trusty > > Charm: cs:mysql > > > > Series: trusty > > Charm: cs:trusty/mysql > > > > Series: trusty > > Charm: ./mysql > > > > Errors: > > > > Series: xenial > > Charm: cs:trusty/mysql > > > > > > On 10/03/16 12:51, Rick Harding wrote: > >> Bah maybe you're right. I want to sleep on it. It's kind of ugh either > way. > >> > >> On Wed, Mar 9, 2016, 9:50 PM Rick Harding > >> wrote: > >> > >>> I think there's already rules for charmstore charms. it uses the > default > >>> if not specified. I totally agree that for local charms we have to have > >>> this. For remote charms though this is providing the user two ways to > do > >>> the same thing > >>> > >>> On Wed, Mar 9, 2016, 9:46 PM Ian Booth > wrote: > >>> > If the charm store charm defines a series in the URL, then we will > consider it > an error to specify a different series using the attribute. But charm > store URLs > are not required to have a series, so we can use the attribute in that > case. It > also allows users to easily switch between store and local charms > during > development just by replacing "./" with "cs:" > > nova-compute: > series: xenial > charm: ./nova-compute > > nova-compute: > series: xenial > charm: cs:nova-compute > > > On 10/03/16 12:21, Rick Harding wrote: > > I'm not sure we want to make this attribute apply to charmstore > charms. > > We've an established practice of the charmstore url being the series > > information. It gives the user a chance to have conflicting > information > if > > the charmstore url is cs:trusty/nova-compute and the series > attribute is > > set to xenial. I think we should toss an error to a bundle that has > series: > > specified for a charmstore based charm value (or non-local value > whichever > > way you want to think about it) > > > > On Wed, Mar 9, 2016 at 6:29 PM Ian Booth > wrote: > > > >> One additional enhancement we need for bundles concerns specifying > series > >> for > >> multi-series charms, in particular local charms now that the local > repo > >> will be > >> going away. > >> > >> Consider: > >> > >> A new multi-series charm may have a URL which does not specify the > series. > >> In > >> that case, the series used will be the default specified in the > charm > >> metadata > >> or the latest LTS. But we want to allow people to choose their own > series > >> also. > >> > >> So we need a new (optional) Series attribute in the bundle metadata. > >> > >> bundle.yaml > >> series: trusty > >> services: > >> nova-compute: > >> series: xenial <-- new > >> charm: ./nova-compute > >> num_units: 2 > >> > >> or with a charm store charm > >> > >> bundle.yaml > >> series: trusty > >> services: > >> nova-compute: > >> series: xenial<-- new > >> charm: cs:nova-compute > >> num_units: 2 > >> > >> > >> Note: the global series in the bundle
Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)
I've implemented option 1: error if Series attribute is used at all with a store charm URL Trivial to change if needed. On 10/03/16 12:58, Ian Booth wrote: > Yeah, agreed having 2 ways to specify store series can be suboptimal. > So we have 2 choices: > > 1. error if Series attribute is used at all with a store charm URL > 2. error if the Series attribute is used and conflicts > > Case 1 > -- > > Errors: > > Series: trusty > Charm: cs:mysql > > Series: trusty > Charm: cs:trusty/mysql > > Ok: > > Series: trusty > Charm: ./mysql > > > Case 2 > -- > > Ok: > > Series: trusty > Charm: cs:mysql > > Series: trusty > Charm: cs:trusty/mysql > > Series: trusty > Charm: ./mysql > > Errors: > > Series: xenial > Charm: cs:trusty/mysql > > > On 10/03/16 12:51, Rick Harding wrote: >> Bah maybe you're right. I want to sleep on it. It's kind of ugh either way. >> >> On Wed, Mar 9, 2016, 9:50 PM Rick Harding >> wrote: >> >>> I think there's already rules for charmstore charms. it uses the default >>> if not specified. I totally agree that for local charms we have to have >>> this. For remote charms though this is providing the user two ways to do >>> the same thing >>> >>> On Wed, Mar 9, 2016, 9:46 PM Ian Booth wrote: >>> If the charm store charm defines a series in the URL, then we will consider it an error to specify a different series using the attribute. But charm store URLs are not required to have a series, so we can use the attribute in that case. It also allows users to easily switch between store and local charms during development just by replacing "./" with "cs:" nova-compute: series: xenial charm: ./nova-compute nova-compute: series: xenial charm: cs:nova-compute On 10/03/16 12:21, Rick Harding wrote: > I'm not sure we want to make this attribute apply to charmstore charms. > We've an established practice of the charmstore url being the series > information. It gives the user a chance to have conflicting information if > the charmstore url is cs:trusty/nova-compute and the series attribute is > set to xenial. I think we should toss an error to a bundle that has series: > specified for a charmstore based charm value (or non-local value whichever > way you want to think about it) > > On Wed, Mar 9, 2016 at 6:29 PM Ian Booth wrote: > >> One additional enhancement we need for bundles concerns specifying series >> for >> multi-series charms, in particular local charms now that the local repo >> will be >> going away. >> >> Consider: >> >> A new multi-series charm may have a URL which does not specify the series. >> In >> that case, the series used will be the default specified in the charm >> metadata >> or the latest LTS. But we want to allow people to choose their own series >> also. >> >> So we need a new (optional) Series attribute in the bundle metadata. >> >> bundle.yaml >> series: trusty >> services: >> nova-compute: >> series: xenial <-- new >> charm: ./nova-compute >> num_units: 2 >> >> or with a charm store charm >> >> bundle.yaml >> series: trusty >> services: >> nova-compute: >> series: xenial<-- new >> charm: cs:nova-compute >> num_units: 2 >> >> >> Note: the global series in the bundle still applies if series is not >> otherwise >> known. >> The new series attribute is per charm. >> >> So in the case above, cs:nova-compute may ordinarily be deployed on trusty >> (the >> default series in that charm's metadata). But the bundle requires the >> xenial >> version. With the charm store URL, we can currently use >> cs:xenial/nova-compute >> but that's not the case for local charms deployed out of a directory. We >> need a >> way to allow the series to be specified in that latter case. >> >> We'll look to make the changes in core initially and can followup later >> with the >> GUI etc. The attribute is optional and only really affects bundles with >> local >> charms. >> >> >> >> On 09/03/16 09:53, Ian Booth wrote: >>> So to clarify what we'll do. We'll support the same syntax in bundle >> files as we >>> do for deploy. >>> >>> Deploys charm store charms: >>> >>> $ juju deploy cs:wordpress >>> $ juju deploy wordpress >>> >>> Deploys a local charm from a directory: >>> >>> $ juju deploy ./charms/wordpress >>> $ juju deploy ./wordpress >>> >>> So below deploys a local nova-compute charm in a directory co-located >> with the >>> bundle.yaml file. >>> >>> series: trusty >>> services: >>>
