Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

Older URL format is what is needed until the change lands (targeted for beta4). The URL based format for bundle charms is all that is supported by the original local bundles work. The upcoming feature drop fixes that, as well as removing the support for local charm URLs - all local charms, whether

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

On Monday, March 28, 2016, Ian Booth wrote: > Hey Antonio > > I must apologise - the changes didn't make beta3 due to all the work > needed to > migrate the CI scripts to test the new hosted model functionality; we ran > out of > time to be able to QA the local bundle

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

Hey Antonio I must apologise - the changes didn't make beta3 due to all the work needed to migrate the CI scripts to test the new hosted model functionality; we ran out of time to be able to QA the local bundle changes. I expect this work will be done for beta4. On 29/03/16 11:04, Antonio

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

+ Juju list for others awareness On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth wrote: > 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

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

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

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

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

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:

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

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

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

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

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

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

Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

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