On Monday, March 28, 2016, Ian Booth <<a href="mailto:ian.booth@canonical.com">ian.booth@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote><div> </div><div>Completely understood. I'll retest with Beta 4. Thanks for the update.</div><div> </div><div>-Antonio</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <<a href="javascript:;" onclick="_e(event, 'cvml', 'ian.booth@canonical.com')">ian.booth@canonical.com</a>> 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: > <a href="http://paste.ubuntu.com/15547725/" target="_blank">http://paste.ubuntu.com/15547725/</a> > 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. <a href="http://jujucharms.com/mysql" target="_blank">jujucharms.com/mysql</a> 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 <<a href="javascript:;" onclick="_e(event, 'cvml', 'ian.booth@canonical.com')">ian.booth@canonical.com</a>> 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 <<a href="javascript:;" onclick="_e(event, 'cvml', 'rick.harding@canonical.com')">rick.harding@canonical.com</a>> >>>>>> 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 <<a href="javascript:;" onclick="_e(event, 'cvml', 'ian.booth@canonical.com')">ian.booth@canonical.com</a>> >>>> 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 <<a href="javascript:;" onclick="_e(event, 'cvml', 'ian.booth@canonical.com')">ian.booth@canonical.com</a>> >>>>>>>> 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 < >>>>>>>>>> <a href="javascript:;" onclick="_e(event, 'cvml', 'martin.packman@canonical.com')">martin.packman@canonical.com</a>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 05/03/2016, Ian Booth <<a href="javascript:;" onclick="_e(event, 'cvml', 'ian.booth@canonical.com')">ian.booth@canonical.com</a>> 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 >>>>>>>>>>>>> <a href="javascript:;" onclick="_e(event, 'cvml', 'Juju-dev@lists.ubuntu.com')">Juju-dev@lists.ubuntu.com</a> >>>>>>>>>>>>> Modify settings or unsubscribe at: >>>>>>>>>>>>> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> -- >> Juju-dev mailing list >> <a href="javascript:;" onclick="_e(event, 'cvml', 'Juju-dev@lists.ubuntu.com')">Juju-dev@lists.ubuntu.com</a> >> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> > > > </blockquote> -- -Thanks Antonio