So this means the older format should work? Antonio, have you poked through that thread at the original working setup for local charms?
On Mon, Mar 28, 2016 at 9:45 PM Antonio Rosales < [email protected]> wrote: > > > On Monday, March 28, 2016, Ian Booth <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 < >> [email protected]> >> >>>>>> 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 <[email protected]> >> >>>> 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 < >> [email protected]> >> >>>>>>>> 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 < >> >>>>>>>>>> [email protected]> >> >>>>>>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> On 05/03/2016, Ian Booth <[email protected]> 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 >> >>>>>>>>>>>>> [email protected] >> >>>>>>>>>>>>> Modify settings or unsubscribe at: >> >>>>>>>>>>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> -- >> >> Juju-dev mailing list >> >> [email protected] >> >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > >> > >> > >> > > > -- > -Thanks > Antonio > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
