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

[Rick Harding]

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 <ian.booth at canonical.com> 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 <ian.booth at canonical.com>
> 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 <
> >> martin.packman at canonical.com>
> >>>> wrote:
> >>>>
> >>>>> On 05/03/2016, Ian Booth <ian.booth at canonical.com> 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
> >>>>> Juju-dev at lists.ubuntu.com
> >>>>> Modify settings or unsubscribe at:
> >>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>>>>
> >>>>
> >>>>
> >>>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160310/f3ef85c4/attachment-0001.html>