juju 2.0.2 picking a random ip address from maas

Patrizio Bassi patrizio.bassi at gmail.com
Thu Mar 9 15:47:43 UTC 2017 

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 <john at 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.bassi at 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 <zandor.z at 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 <john at 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 <john at 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.bassi at 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.karamatic at 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.bassi at 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 <john at 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.bassi at 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 <john at 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.bassi at 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 <john at 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.bassi at 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 at 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 at lists.ubuntu.com
>>>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>>>>> an/listinfo/juju
>>>>>>>>
>>>>>>> --
>>>>>>> Ante Karamatić
>>>>>>> ante.karamatic at canonical.com
>>>>>>> Canonical
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Patrizio Bassi
>>>>>> www.patriziobassi.it
>>>>>> http://piazzadelpopolo.patriziobassi.it
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170309/898e2e76/attachment-0001.html>

More information about the Juju mailing list