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/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> >>>>> >>>>> ... > > [Messaggio troncato] -- 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
