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 <rick.hard...@canonical.com> > 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 <ian.bo...@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.bo...@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.pack...@canonical.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On 05/03/2016, Ian Booth <ian.bo...@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@lists.ubuntu.com >>>>>>>> Modify settings or unsubscribe at: >>>>>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
