@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/ > stable/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
