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 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
