Re: Juju GUI handling of empty config breaks promulgated charms

[Pete Vander Giessen]

Hi All,

Just a quick follow-up on this: both the gui and python-libjuju now use the
"config-yaml" rather than the "config" parameter when deploying a bundle,
which addresses the issue (provided you have an updated GUI or libjuju
wherever you're performing the deploy, of course).

~ PeteVG

On Thu, Feb 23, 2017 at 10:13 AM Pete Vander Giessen <
pete.vandergies...@canonical.com> wrote:

> On Thu, Feb 23, 2017 at 2:31 AM John Meinel 
> wrote:
>
> AFAICT we fixed this in Juju 1.15, but there are 2 places you can pass
> config. The old field uses the compatibility of "" means nil, the new field
> handles nil vs "" correctly. The Juju CLI should work correctly, it sounds
> like the GUI was missed to use the new field.
>
>
> I think that it's a bit more complicated than that. The GUI (and tools
> like libjuju that use the websocket api), deploy based on the "plan" that
> they get back from the API. So my guess would be that the plan is using the
> old values. Or that there's some additional parsing that needs to happen to
> the plan, which isn't well documented. ... or that its very easy to call
> the wrong interface in the websocket api. :-)
>
> Regardless, doing what looks like the "right" thing against the websocket
> api, given the plan that you get back from the api, with a bundle that has
> blank config values seems to lead to crashes. It would be nice if that got
> fixed on the Go side of things, rather than getting fixed via special logic
> in every client that talks to the websocket api ...
>
> ~ PeteVG
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju 2.0.2 picking a random ip address from maas

[Patrizio Bassi]

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"  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 
>> 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"  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 :
>>>
>>> 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 >> > 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 , 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 :
>>>
>>> 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 
>>> 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 
>>> 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 >> > 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ć :
>>>
>>> 

Re: juju 2.0.2 picking a random ip address from maas

[Ante Karamatić]

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  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"  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 :
>
> 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 
> 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 , 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 :
>
> 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 
> 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 
> 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 
> 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ć :
>
> 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 
> 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 

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

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"  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 :
>
>> 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 
>> 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 , 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 :
>>>
 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 
 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 
> 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

Re: juju 2.0.2 picking a random ip address from maas

[Patrizio Bassi]

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 :

> 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 
> 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 , 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 :
>>
>>> 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 
>>> 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 
 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 

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

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 
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 , 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 :
>
>> 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 
>> 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 
>>> 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ć  >:
>
>> 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
>>>

Re: juju 2.0.2 picking a random ip address from maas

[Patrizio Bassi]

@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 , 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 :

> 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 
> 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 
>> 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 >> > 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ć 
 :

> 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 :
>>
>> 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 

Re: juju 2.0.2 picking a random ip address from maas

[Sandor Zeestraten]

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  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 
> 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 
>> 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ć :
>>>
 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 
 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 :
>
> 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 :
>
> 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 

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

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  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 
> 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ć :
>>
>>> 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 
>>> 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 :

 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 :

 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.ba...@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 

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

"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 
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ć :
>
>> 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 
>> 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 :
>>>
>>> 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 >> > 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 :
>>>
>>> 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 >> > 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

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

What version of MAAS? Just in case the problem is a mismatch with all the
tests I've been doing so far.

John
=:->

On Mar 9, 2017 07:05, wrote:

We intentionally use "" to mean the default value for everything else,
which is why I need to understand where we are actually getting the error.
I'll try to reproduce it today.

John
=:->

On Mar 9, 2017 01:28, "Patrizio Bassi"  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 :

> 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 
> 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 :
>>
>>> 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 >> > 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 :

> 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.ba...@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 

Re: juju 2.0.2 picking a random ip address from maas

[John Meinel]

We intentionally use "" to mean the default value for everything else,
which is why I need to understand where we are actually getting the error.
I'll try to reproduce it today.

John
=:->

On Mar 9, 2017 01:28, "Patrizio Bassi"  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 :
>
>> 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 
>> 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 :
>>>
 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.ba...@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 :
>
>> 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.ba...@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 

Re: juju 2.0.2 picking a random ip address from maas

[Patrizio Bassi]

Hi All,

after some debugging i found in juju

/application

/deploy.go

func (c *DeployCommand) parseBind()
{

case 1:
endpoint = ""
space = v[0]

[]

bindings[endpoint] = space

}

so the function sets the bindings array name to null, therefore we get the
issue of "empty names".


Patrizio



2017-03-09 8:47 GMT+01:00 Patrizio Bassi :

> 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ć :
>
>> 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 
>> 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 :
>>>
>>> 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 >> > 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 :
>>>
>>> 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 >> > 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
>>>