juju 2.0.2 picking a random ip address from maas

John Meinel john at arbash-meinel.com
Thu Mar 9 19:28:09 UTC 2017 

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> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I'm quite new the juju and it's charms. On ubuntu 16.04 LTS I have juju
>>>> 2.0.2 using maas (2.1.3) cloud as provider.
>>>>
>>>> In maas I have configured (ready status) some machines, each one has 2
>>>> eth ports, one with a public ip (same as juju client/controller 10.x.x.x)
>>>> which resolves to machine hostname and the other meant to be private
>>>> (192.x.x.x) and without a public gateway for instance.
>>>>
>>>> When deploying any application juju gets the machine from maas and
>>>> starts using as public ip the 192.x.x.x one.
>>>>
>>>> I could not find any way to deploy using the 10.x.x.x, the guide in
>>>> https://jujucharms.com/docs/2.0/network-spaces seems not appliable to
>>>> my case (spaces/network are already correctly provided by maas).
>>>>
>>>> Can you please address me? Unfortunately I'm stuck with deploy
>>>> Thank you
>>>>
>>>> Patrizio
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju at lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Patrizio Bassi
>>>> www.patriziobassi.it
>>>> http://piazzadelpopolo.patriziobassi.it
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Patrizio Bassi
>>>> www.patriziobassi.it
>>>> http://piazzadelpopolo.patriziobassi.it
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Patrizio Bassi
>>>> <http://www.patriziobassi.it>
>>>>
>>>> ...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170309/07f7849f/attachment-0001.html>

More information about the Juju mailing list