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 <[email protected]> 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: > > nova-compute: > > charm: ./nova-compute > > num_units: 2 > > > > This one deploys a charm store charm: > > > > series: trusty > > services: > > nova-compute: > > charm: nova-compute > > num_units: 2 > > > > > > > > On 09/03/16 03:59, Rick Harding wrote: > >> 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 get those bits to line up. > >> > >> I don't think we want to be doing the file based urls, but to build a > >> pattern that's reusable and makes sense across systems. Creating a > standard > >> pattern I think is the best path forward. > >> > >> On Tue, Mar 8, 2016 at 12:26 PM Martin Packman < > [email protected]> > >> wrote: > >> > >>> On 05/03/2016, Ian Booth <[email protected]> wrote: > >>>>> > >>>>> 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 > >>>>> ``` > >>>>> > >>>> > >>>> The above will work but not until a tweak is made to bundle > deployment to > >>>> interpret a path on disk rather than a url. It's a small change. This > >>> would > >>>> be done as part of the work to remove the local repo support. > >>> > >>> Can we keep interpreting the the reference in the bundle as a url, but > >>> start supporting file urls? That seems neater than treating the cs: > >>> prefix as magic not-a-filename. > >>> > >>> The catch is that there's no sane way of referencing locations outside > >>> a base url. > >>> > >>> charm: file:nova-compute > >>> > >>> Works as a reference to a dir inside the base location, but: > >>> > >>> charm: file:../nova-compute > >>> > >>> Will not work as a reference to a sibling directory. And absolute file > >>> paths are pretty useless across machines. > >>> > >>> Martin > >>> > >>> -- > >>> Juju-dev mailing list > >>> [email protected] > >>> Modify settings or unsubscribe at: > >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev > >>> > >> > >> > >> >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
