We should as soon as I have it landed in the 2.1 branch and CI starts to run we can use it's deb.
John =:-> On Mar 9, 2017 09:48, "Patrizio Bassi" <patrizio.ba...@gmail.com> wrote: > Fantastic job John! > > do you have a .deb i can already test on my environment? > > Patrizio > > 2017-03-09 16:24 GMT+01:00 John Meinel <j...@arbash-meinel.com>: > >> I do have a fix up for review: >> https://github.com/juju/juju/pull/7081 >> And I have tested it live against a local maas, though my maas doesn't >> have multiple interfaces, I can see the bindings get requested >> appropriately and not fail with the "empty binding name" failure. >> >> I'm pushing to get a 2.1.2 out to include this fix once it lands for >> review and CI, etc. If it all goes well then 2.1.2 will be out later this >> week. >> >> John >> =:-> >> >> >> On Thu, Mar 9, 2017 at 8:40 AM, Patrizio Bassi <patrizio.ba...@gmail.com> >> wrote: >> >>> @John >>> great. i'm using juju 2.1.1 and maas 2.1.3. >>> >>> Regarding the workaround...it's not a matter of a particular charm, it's >>> a matter of all (i will deploy openstack-telemetry charm with some >>> modifications), because when we allocate a machine with juju i would like >>> it to pick a public (dns) name, the one on the --bind <space>, no matter >>> which extra binding is declared in the charm, if any. >>> >>> Plus: i would even add another option, such as bind to a particular net >>> interface as a machine may have 2 subnet belonging to the same space >>> address (ok, we may model this in maas by designing 1-to-1 subnet-to-space). >>> >>> Again: some charms may use the juju network spaces, but it would be >>> great juju to be charm agnostic when asking resources to maas (with bind >>> constraint of course). >>> >>> I'm ready to test if you have a fix. >>> >>> Patrizio >>> >>> >>> 2017-03-09 15:05 GMT+01:00 Sandor Zeestraten <zando...@gmail.com>: >>> >>>> Where do we find which bindings a charm has so they can be specified >>>> directly? >>>> According to the docs on the metadata (https://jujucharms.com/docs/s >>>> table/authors-charm-metadata) there's a section called extra-bindings >>>> but that only seems to be used in some charms. >>>> >>>> -- >>>> Sandor Zeestraten >>>> >>>> On Thu, Mar 9, 2017 at 2:34 PM, John Meinel <j...@arbash-meinel.com> >>>> wrote: >>>> >>>>> In the meantime, you can work around it by specifying the bindings >>>>> directly: so in the case of mysql that would be: >>>>> juju deploy mysql --bind "db=db-space monitors=db-space ha=db-space >>>>> ..." >>>>> >>>>> John >>>>> =:-> >>>>> >>>>> >>>>> On Thu, Mar 9, 2017 at 7:25 AM, John Meinel <j...@arbash-meinel.com> >>>>> wrote: >>>>> >>>>>> "juju deploy mysql --bind db-space" is exactly the syntax that should >>>>>> be working, and I'm seeing it failing now. I will work to fix that and >>>>>> make >>>>>> sure we don't regress here. We certainly should have caught that before >>>>>> release. >>>>>> >>>>>> John >>>>>> =:-> >>>>>> >>>>>> >>>>>> On Thu, Mar 9, 2017 at 1:47 AM, Patrizio Bassi < >>>>>> patrizio.ba...@gmail.com> wrote: >>>>>> >>>>>>> Hi Ante, >>>>>>> >>>>>>> no that is not working, but i think it's by design. >>>>>>> That constraint means: pick up a machine that has a leg in the >>>>>>> db-space leg. >>>>>>> >>>>>>> So my machine with 2 eth ports in two different spaces satisfy that >>>>>>> constraint, >>>>>>> it is picked, but the IP is wrong. >>>>>>> >>>>>>> Another option i tried is: >>>>>>> >>>>>>> juju deploy mysql --constraints spaces=db-space,^space_i_dont_want >>>>>>> >>>>>>> in that case the machine is filtered out, because, as i said before, >>>>>>> it means "a machine that is in db-space space but not in >>>>>>> space_i_dont_want >>>>>>> space". >>>>>>> >>>>>>> i just want it to pick the right ip! >>>>>>> >>>>>>> I checked the json coming from maas: it seems sorting ipv4 addresses >>>>>>> from "smallest" to biggest and juju just picks the first one. in juju >>>>>>> status i continue to see "dns-name" set to the wrong ip address, which >>>>>>> doesn't resolve too. >>>>>>> >>>>>>> even using --to fqdn it doesn't get the right ip >>>>>>> >>>>>>> So i think there are two bugs: >>>>>>> 1) juju deploy --bind cannot find space name reporting "empty names" >>>>>>> error msg >>>>>>> 2) juju doesn't try to resolve ips/hostname to check what's the >>>>>>> machine name >>>>>>> >>>>>>> can you reproduce it? >>>>>>> >>>>>>> Patrizio >>>>>>> >>>>>>> >>>>>>> 2017-03-09 8:39 GMT+01:00 Ante Karamatić < >>>>>>> ante.karama...@canonical.com>: >>>>>>> >>>>>>>> Hi Patrizio, >>>>>>>> >>>>>>>> this is exactly what I saw yesterday too, unrelated to this thread. >>>>>>>> What you could do is: >>>>>>>> >>>>>>>> juju deploy mysql --constraints spaces=db-space >>>>>>>> >>>>>>>> Let me know if the constraints workaround works for you. >>>>>>>> >>>>>>>> On Thu, Mar 9, 2017 at 8:28 AM Patrizio Bassi < >>>>>>>> patrizio.ba...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi John, >>>>>>>>> >>>>>>>>> i simply would like to do what's written in >>>>>>>>> https://jujucharms.com/docs/2.1/charms-deploying >>>>>>>>> >>>>>>>>> "When deploying an application to a target with multiple spaces, >>>>>>>>> the operator must specify which space to use because ambiguous >>>>>>>>> bindings >>>>>>>>> will result in a provisioning failure." >>>>>>>>> >>>>>>>>> This is exactly my case: a machine with 2 eth ports, two different >>>>>>>>> subnets in two different spaces. >>>>>>>>> >>>>>>>>> the doc says i may do (c/p): $ juju deploy mysql --bind db-space >>>>>>>>> >>>>>>>>> and so bind a maas space for all the application. Unfortunately it >>>>>>>>> seems not working (i get the "empty names" error). >>>>>>>>> >>>>>>>>> Patrizio >>>>>>>>> >>>>>>>>> 2017-03-08 20:40 GMT+01:00 John Meinel <j...@arbash-meinel.com>: >>>>>>>>> >>>>>>>>> So without bindings, I would expect the behavior, the question is >>>>>>>>> why you would be seeing: >>>>>>>>> "cannot run instances: cannot run instance: interface bindings >>>>>>>>> cannot have empty names" >>>>>>>>> >>>>>>>>> Can you open a bug on https://bugs.launchpad.net/juju/+filebug >>>>>>>>> and include some more information like the logs from the controller >>>>>>>>> machine? >>>>>>>>> >>>>>>>>> I'm not quite sure I understand what you mean by "my binding >>>>>>>>> should be global for a local bundle charm". >>>>>>>>> >>>>>>>>> John >>>>>>>>> =:-> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 8, 2017 at 9:36 AM, Patrizio Bassi < >>>>>>>>> patrizio.ba...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> i just upgraded to 2.1.1-xenial-amd64, same behaviour >>>>>>>>> unfortunately. >>>>>>>>> >>>>>>>>> As i'm going to deploy openstack services (now i'm using ceph-osd >>>>>>>>> just to test, than my binding should be global for a local bundle >>>>>>>>> charm) i >>>>>>>>> would like to say: all juju endpoint (bare metal/lxd containers) just >>>>>>>>> get a >>>>>>>>> 10.xxx address, not 192.xxx. >>>>>>>>> >>>>>>>>> Patrizio >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-03-08 16:27 GMT+01:00 John Meinel <j...@arbash-meinel.com>: >>>>>>>>> >>>>>>>>> Is it possible for you to test with Juju 2.1? I haven't seen that >>>>>>>>> particular bug with binding, but I have done a lot more testing with >>>>>>>>> 2.1. I >>>>>>>>> didn't think we changed the particular "empty space" differences. >>>>>>>>> >>>>>>>>> The other possibility is to try and explicitly list the endpoints: >>>>>>>>> >>>>>>>>> juju deploy ceph-osd --bind "public=XXX cluster=YYY" >>>>>>>>> >>>>>>>>> I would have thought you would want something more like: >>>>>>>>> >>>>>>>>> juju deploy ceph-osd --bind "management public=PUBLIC" >>>>>>>>> >>>>>>>>> John >>>>>>>>> =:-> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 8, 2017 at 9:22 AM, Patrizio Bassi < >>>>>>>>> patrizio.ba...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> It looks like it's not working >>>>>>>>> >>>>>>>>> $ juju deploy ceph-osd --bind "management" >>>>>>>>> >>>>>>>>> $ juju show-machine 0 shows >>>>>>>>> "message: 'failed to start instance (cannot run instances: cannot >>>>>>>>> run instance: interface bindings cannot have empty names), retrying >>>>>>>>> in 10s >>>>>>>>> (3 more attempts)' >>>>>>>>> >>>>>>>>> ...than after some seconds it fails. juju spaces sees the spaces >>>>>>>>> from MaaS without issues. >>>>>>>>> >>>>>>>>> without forcing bindings >>>>>>>>> >>>>>>>>> $ juju show-machine 0 >>>>>>>>> model: openstack >>>>>>>>> machines: >>>>>>>>> "0": >>>>>>>>> juju-status: >>>>>>>>> current: pending >>>>>>>>> since: 08 Mar 2017 15:14:55Z >>>>>>>>> dns-name: 192.168.0.2 >>>>>>>>> ip-addresses: >>>>>>>>> - 192.168.0.2 >>>>>>>>> - 10.0.8.12 >>>>>>>>> instance-id: abkgqx >>>>>>>>> machine-status: >>>>>>>>> current: allocating >>>>>>>>> message: Deploying >>>>>>>>> since: 08 Mar 2017 15:15:09Z >>>>>>>>> series: xenial >>>>>>>>> hardware: arch=amd64 cores=4 mem=8192M tags=virtual >>>>>>>>> availability-zone=primary >>>>>>>>> >>>>>>>>> it looks a bug, or better, the bug: dns-name is 192.x.x.x but it's >>>>>>>>> not true, 10.0.8.12 is the real hostname provided by external dns. >>>>>>>>> >>>>>>>>> Patrizio >>>>>>>>> >>>>>>>>> 2017-03-08 14:57 GMT+01:00 John Meinel <j...@arbash-meinel.com>: >>>>>>>>> >>>>>>>>> You should be using "juju deploy application --bind space" to >>>>>>>>> declare which set of addresses you want the applications to use. >>>>>>>>> Does that >>>>>>>>> not work? >>>>>>>>> >>>>>>>>> John >>>>>>>>> =:-> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 8, 2017 at 4:44 AM, Patrizio Bassi < >>>>>>>>> patrizio.ba...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I'm quite new the juju and it's charms. On ubuntu 16.04 LTS I have >>>>>>>>> juju 2.0.2 using maas (2.1.3) cloud as provider. >>>>>>>>> >>>>>>>>> In maas I have configured (ready status) some machines, each one >>>>>>>>> has 2 eth ports, one with a public ip (same as juju client/controller >>>>>>>>> 10.x.x.x) which resolves to machine hostname and the other meant to be >>>>>>>>> private (192.x.x.x) and without a public gateway for instance. >>>>>>>>> >>>>>>>>> When deploying any application juju gets the machine from maas and >>>>>>>>> starts using as public ip the 192.x.x.x one. >>>>>>>>> >>>>>>>>> I could not find any way to deploy using the 10.x.x.x, the guide >>>>>>>>> in https://jujucharms.com/docs/2.0/network-spaces seems not >>>>>>>>> appliable to my case (spaces/network are already correctly provided by >>>>>>>>> maas). >>>>>>>>> >>>>>>>>> Can you please address me? Unfortunately I'm stuck with deploy >>>>>>>>> Thank you >>>>>>>>> >>>>>>>>> Patrizio >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Juju mailing list >>>>>>>>> Juju@lists.ubuntu.com >>>>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>>>>>> an/listinfo/juju >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Patrizio Bassi >>>>>>>>> www.patriziobassi.it >>>>>>>>> http://piazzadelpopolo.patriziobassi.it >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Patrizio Bassi >>>>>>>>> www.patriziobassi.it >>>>>>>>> http://piazzadelpopolo.patriziobassi.it >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Patrizio Bassi >>>>>>>>> www.patriziobassi.it >>>>>>>>> http://piazzadelpopolo.patriziobassi.it >>>>>>>>> -- >>>>>>>>> Juju mailing list >>>>>>>>> Juju@lists.ubuntu.com >>>>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>>>>>> an/listinfo/juju >>>>>>>>> >>>>>>>> -- >>>>>>>> Ante Karamatić >>>>>>>> ante.karama...@canonical.com >>>>>>>> Canonical >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Patrizio Bassi >>>>>>> www.patriziobassi.it >>>>>>> http://piazzadelpopolo.patriziobassi.it >>>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Juju mailing list >>>>> Juju@lists.ubuntu.com >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/juju >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> Patrizio Bassi >>> www.patriziobassi.it >>> http://piazzadelpopolo.patriziobassi.it >>> >> >> > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju