juju 2.0.2 picking a random ip address from maas
Patrizio Bassi
patrizio.bassi at gmail.com
Fri Mar 10 14:28:42 UTC 2017
Hi John,
i do agree about ip addresses may be changing from application to
application but the ip addresses showed should be the ip juju
controller/client may reach the vm/container/bare metal. It should be, if
possibile, the machine hostname or the reverse lookup in the dns server, if
any.
For instance in my case i just have 2 ethernet interfaces, quite simple
design: eth0 is the public one, with its hostname in the dns, eth1 is other
net with a private one. Why should juju show the private one? Infact it's
not working (question is, how do you deploy openstack with juju with more
than 1 eth ports?).
I tried with a openstack telemetry bundle. --bind cannot be passed to a
bundle so i tried just to add a
constraints: spaces=management
for all machines described in the bundle, but, as design, it just select a
machine that has access to that space, doesn't bind anything
Basically all containers fail because of networking.
0/lxd/3:
juju-status:
current: pending
since: 10 Mar 2017 10:53:59Z
instance-id: pending
machine-status:
current: allocating
message: 'failed to start instance (unable to setup network: no
obvious
space for container "0/lxd/3", host machine has spaces:
"management",
"private"), retrying in 10s (3 more attempts)'
This is blocking everything for me.
Patrizio
2017-03-10 14:35 GMT+01:00 John Meinel <john at arbash-meinel.com>:
> 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
>>
>
>
--
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/a9e24656/attachment.html>
More information about the Juju
mailing list