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/mailman/listinfo/juju
