Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)
Ian Booth
ian.booth at canonical.com
Thu Mar 10 02:58:02 UTC 2016
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.harding at 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.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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the Juju-dev
mailing list