juju 2.0.2 picking a random ip address from maas

John Meinel john at arbash-meinel.com
Fri Mar 10 13:35:25 UTC 2017 

The Address reported for the Machine is not necessarily the address that is
given to the applications themselves. You can run more than just 1
application on a machine, so they aren't strictly correlated. The question
is whether when relating that application to another application what
addresses it will share. And I'm pretty sure that is actually accurate.

John
=:->


On Fri, Mar 10, 2017 at 2:41 AM, Patrizio Bassi <patrizio.bassi at gmail.com>
wrote:

> Good morning John,
>
> I tested it, i destroyed the controller and rebuilt from scratch.
>
> after juju bootstrap i got "No packaged binary found, preparing local Juju
> agent binary" because it could not find 2.1.2 version in the repos, which
> is great.
>
> with
> $ juju deploy ceph-osd --bind <space>
>
> The unit deployed but $ juju status and $ juju show-machine 0 both show
> the secondary ip address as public address and not the one should come from
> subnet forced by --bind <space>
>
> So i tried without --bind
> $ juju deploy ceph-osd
>
> and it worked (deployed) as well, exactly as first attempt with bind. So i
> suspect the patch is just working for the cmd line parser but not affecting
> the interface/space selection, and my issue got fixed somehow while
> rebuilding the controller from scratch.
>
> $ juju show-machine 0 continues to show dns-name to an ip address and not
> the hostname in the dns (in the <space>) for instance.
>
> So it's not complete for me, sorry.
>
> Patrizio
>
>
> 2017-03-09 20:28 GMT+01:00 John Meinel <john at arbash-meinel.com>:
>
>> The build for trusty is the same as Xenial, it is just called trusty for
>> historical reasons.
>>
>> John
>> =:->
>>
>>
>> On Thu, Mar 9, 2017 at 12:32 PM, Patrizio Bassi <patrizio.bassi at gmail.com
>> > wrote:
>>
>>> Ok! I'll test tomorrow, but i need a xenial build as i'm on 16.04 release
>>>
>>> Patrizio
>>>
>>> Il 09/mar/2017 07:29 PM, "John Meinel" <john at arbash-meinel.com> ha
>>> scritto:
>>>
>>>> http://data.vapour.ws/juju-ci/products/version-4977/build-bi
>>>> nary-trusty-amd64/build-2159/juju-core_2.1.2-0ubuntu1~14.04.
>>>> 1~juju1_amd64.deb
>>>>
>>>> Should have the fix for empty binding names.
>>>>
>>>> John
>>>> =:->
>>>>
>>>>
>>>> On Thu, Mar 9, 2017 at 11:43 AM, Ante Karamatić <
>>>> ante.karamatic at canonical.com> wrote:
>>>>
>>>>> My snap is pending review. In the meantime you can try with:
>>>>>
>>>>> https://launchpad.net/~ivoks/+archive/ubuntu/ppa
>>>>>
>>>>> On Thu, Mar 9, 2017 at 6:38 PM John Meinel <john at arbash-meinel.com>
>>>>> wrote:
>>>>>
>>>>>> 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.bassi at 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 <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>
>>>>>>
>>>>>> ...
>>
>> [Messaggio troncato]
>
>
>
>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.it
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170310/12ba2b69/attachment.html>

More information about the Juju mailing list