On Monday, March 28, 2016, Ian Booth <ian.bo...@canonical.com> wrote:
> Hey Antonio > > I must apologise - the changes didn't make beta3 due to all the work > needed to > migrate the CI scripts to test the new hosted model functionality; we ran > out of > time to be able to QA the local bundle changes. > > I expect this work will be done for beta4. Completely understood. I'll retest with Beta 4. Thanks for the update. -Antonio > > > On 29/03/16 11:04, Antonio Rosales wrote: > > + Juju list for others awareness > > > > > > On Thu, Mar 10, 2016 at 1:53 PM, Ian Booth <ian.bo...@canonical.com > <javascript:;>> wrote: > >> Thanks Rick. Trivial change to make. This work should be in beta3 due > next week. > >> The work includes dropping support for local repositories in favour of > path > >> based local charm and bundle deployment. > > > > Ian, > > First thanks for working on this feature. Second, I tried this for a > > local ppc64el deploy which is behind a firewall, and thus local charms > > are good way forward. I may have got the syntax incorrect and thus > > wanted to confirm here. What I did was is at: > > http://paste.ubuntu.com/15547725/ > > Specifically, I set the the charm path to something like: > > charm: /home/ubuntu/charms/trusty/apache-hadoop-compute-slave > > However, I got the following error: > > ERROR cannot deploy bundle: cannot resolve URL > > "/home/ubuntu/charms/trusty/apache-hadoop-compute-slave": charm or > > bundle URL has invalid form: > > "/home/ubuntu/charms/trusty/apache-hadoop-compute-slave" > > > > This is on the latest beta3: > > 2.0-beta3-xenial-ppc64el > > > > Any suggestions? > > > > -thanks, > > Antonio > > > > > >> > >> On 10/03/16 23:37, Rick Harding wrote: > >>> Thanks Ian, after thinking about it I think what we want to do is > really > >>> #2. The reasoning I think is: > >>> > >>> 1) we want to make things consistent. The CLI experience is present a > charm > >>> and override series with --series= > >>> 2) more consistent, if you do it with local charms you can always do it > >>> 3) we want to encourage folks to drop series from the charmstore urls > and > >>> worry less about series over time. Just deploy X and let the charm > author > >>> pick the default best series. I think we should encourage this in the > error > >>> message for #2. "Please remove the series section of the charm url" or > the > >>> like when we error on the conflict, pushing users to use the series > >>> override. > >>> > >>> Uros, Francesco, this brings up a point that I think for multi-series > >>> charms we want the deploy cli snippets to start to drop the series > part of > >>> the url as often as we can. If the url doesn't have the series > specified, > >>> e.g. jujucharms.com/mysql then the cli command should not either. > Right now > >>> I know we add the series/revision info and such. Over time we want to > try > >>> to get to as simple a command as possible. > >>> > >>> On Thu, Mar 10, 2016 at 7:23 AM Ian Booth <ian.bo...@canonical.com > <javascript:;>> wrote: > >>> > >>>> 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 <javascript:;>> > >>>>>> 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 > <javascript:;>> > >>>> 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 <javascript:;>> > >>>>>>>> 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 <javascript:;>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> On 05/03/2016, Ian Booth <ian.bo...@canonical.com > <javascript:;>> 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 <javascript:;> > >>>>>>>>>>>>> Modify settings or unsubscribe at: > >>>>>>>>>>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> -- > >> Juju-dev mailing list > >> Juju-dev@lists.ubuntu.com <javascript:;> > >> Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > > > > -- -Thanks Antonio
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
