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