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/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 <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"
>>>>>>>>>
>>>>>>>>> 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 <j...@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.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 provided by
>>>>>>>>> maas).
>>>>>>>>>
>>>>>>>>> Can you please address me? Unfortunately I'm stuck with deploy
>>>>>>>>> Thank you
>>>>>>>>>
>>>>>>>>> Patrizio
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Juju mailing list
>>>>>>>>> Juju@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
>>>>>>>>> www.patriziobassi.it
>>>>>>>>> http://piazzadelpopolo.patriziobassi.it
>>>>>>>>> --
>>>>>>>>> Juju mailing list
>>>>>>>>> Juju@lists.ubuntu.com
>>>>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>>>>>> an/listinfo/juju
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Ante Karamatić
>>>>>>>> ante.karama...@canonical.com
>>>>>>>> Canonical
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Patrizio Bassi
>>>>>>> www.patriziobassi.it
>>>>>>> http://piazzadelpopolo.patriziobassi.it
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Juju mailing list
>>>>> Juju@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
>>>
>>
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Reply via email to