juju 2.0.2 picking a random ip address from maas
Patrizio Bassi
patrizio.bassi at gmail.com
Thu Apr 27 15:45:23 UTC 2017
Hi John,
i'm writing you again after long time i didn't check juju deploys for a
while.
Basically the dns-name (what juju status shows in Public address column) is
still wrong
juju show-machine 0
model: openstack
machines:
"0":
juju-status:
current: started
since: 27 Apr 2017 14:06:02Z
version: 2.1.2
* dns-name: 10.1.12.63*
ip-addresses:
- 10.1.12.63
- 10.1.4.63
- 10.1.8.63
instance-id: ne3nqh
machine-status:
current: running
message: Deployed
if i do a reverse lookup of dns name is get
Host 63.12.1.10.in-addr.arpa. not found: 3(NXDOMAIN)
while 10.1.8.63 (the only IP on the space i bind) correctly resolves.
I do think this is a bug.
Juju should
1) validate the ip from maas
"links": [
{
"id": 513753,
"mode": "static",
* "ip_address": "10.1.8.63",*
"subnet": {
* "space": "space-management",*
"id": 10,
"rdns_mode": 2,
"allow_proxy": true,
....
]
while it picks up IPs from other network spaces
2) in case more than 1 ip is found on the same space it should try to do a
reverse dns lookup and pick the one registered. If all resolve, just pick
one.
For containers hosted on the same machine instead i get the right ip
bindings.
Patrizio
2017-03-10 16:55 GMT+01:00 John Meinel <john at arbash-meinel.com>:
> Bindings can be set explicitly in bundles because each piece of the bundle
> takes different bindings.
>
> mysql:
> ...
> bindings:
> "": space
> telemetry:
> ...
> bindings:
> "": space
>
> You can't specify deploy bundle with binding because each application is
> likely to be bound differently.
>
> John
> =:->
>
> On Fri, Mar 10, 2017 at 8:28 AM, Patrizio Bassi <patrizio.bassi at gmail.com>
> wrote:
>
>> 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/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 <
>>>>>>>>> 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"
>>>>>>>>>
>>>>>>>>> ...
>>
>> [Message clipped]
>
>
>
--
Patrizio Bassi
www.patriziobassi.it
http://piazzadelpopolo.patriziobassi.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170427/29948d38/attachment.html>
More information about the Juju
mailing list