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

Re: Juju 2.0 and local charm deployment

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

Re: Juju 2.0 and local charm deployment

Long term we want to have a pattern when the bundle is a directory with local charms in a directory next to the bundles.yaml file. We could not do this cleanly before the multi-series charms that are just getting out the door. I think that bundles with local charms will be suboptimal until we can

Re: Juju 2.0 and local charm deployment

> > Does this mean it won't be possible to deploy old single-series > charms with Juju without modifying metadata.yaml to add the supported > series? > You can use the --series argument $ juju deploy ./trusty/mysql --series trusty We could look at pulling the series out of the path if it's an

Re: Juju 2.0 and local charm deployment

Hey Marco > > I'm a +1 > > How will bundles work which reference local charms? Will this work as > expected where nova-compute is a directory at the same level as a bundle > file? > > ``` > series: trusty > services: > nova-compute: > charm: ./nova-compute > num_units: 2 > ``` >

Re: Juju 2.0 and local charm deployment

Hi Marco, What happens if I have a multi series/OS bundle: ``` series: trusty services: nova-compute: charm: ./nova-compute num_units: 2 nova-hyperv: series: win2012hvr2 # is there a series override per charm ? charm: ./nova-hyperv # this can run on

Re: Juju 2.0 and local charm deployment

No, right now charms can be multiple series but must be of the same OS. If there is truly portable code they can be wrapped as Layers to be shared among the charms, but in practice, it turns into to much ifdef style development that's difficult to debug and things like resources that are vastly

Re: Juju 2.0 and local charm deployment

2016-03-04 8:55 GMT+03:00 Ian Booth : > Hopefully everyone is aware that Juju 2.0 and the charm store will support > multi-series charms. To recap, a multi-series charm is one which can declare > that it supports more than just the one series; you no longer need to have a

Re: Juju 2.0 and local charm deployment

On 4 March 2016 at 05:55, Ian Booth wrote: > Hi folks > > TL;DR we want to remove support for old style local charm repositories in > Juju 2.0 > > Hopefully everyone is aware that Juju 2.0 and the charm store will support > multi-series charms. To recap, a multi-series

Juju 2.0 and local charm deployment

Hi folks TL;DR we want to remove support for old style local charm repositories in Juju 2.0 Hopefully everyone is aware that Juju 2.0 and the charm store will support multi-series charms. To recap, a multi-series charm is one which can declare that it supports more than just the one series; you