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-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.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:
>>>>>>>>
>>>>>>>> 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 <j...@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]
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
