You might want to track https://bugs.launchpad.net/juju/+bug/1680100
On Thu, Apr 27, 2017 at 11:45 AM Patrizio Bassi <patrizio.ba...@gmail.com>
wrote:
> 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 <j...@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.ba...@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 <j...@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.ba...@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 <j...@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.ba...@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" <j...@arbash-meinel.com> ha
>>>>>>> scritto:
>>>>>>>
>>>>>>>>
>>>>>>>> http://data.vapour.ws/juju-ci/products/version-4977/build-binary-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.karama...@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 <j...@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.ba...@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 <j...@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.ba...@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 <zando...@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 <
>>>>>>>>>> j...@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 <
>>>>>>>>>> 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:
>>>>>>>>>>
>>>>>>>>>> --
Ante Karamatić
ante.karama...@canonical.com
Canonical
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
