Re: juju 2.0.2 picking a random ip address from maas

[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
>>   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 
>> wrote:
>>
>> Hi All,
>>
>> I'm quite new the juju and it's charms. 

Re: juju 2.0.2 picking a random ip address from maas

[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
>   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 
> 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/mailman/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

Re: juju 2.0.2 picking a random ip address from maas

[Patrizio Bassi]

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 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.patr

[Review Queue] docker-registry charm

[Matt Bruzek]

I took some time to review the docker-registry charm from Caio Begotti
today.

The charm was written in reactive and the code looked good to me, but the
charm did not deploy cleanly and had some other things that could be
improved such as setting the application version.

This will be a very useful charm for demos when it is done. Thanks.

   - Matt Bruzek 
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: MySQL charm bugs

[Rick Harding]

Looking at the page: https://jujucharms.com/mysql on the right is the link
to "submit a bug" which goes to:
https://github.com/marcoceppi/charm-mysql/issues

You can also get the bug url with the charm command.

charm show mysql bugs-url
bugs-url: https://github.com/marcoceppi/charm-mysql/issues


On Wed, Mar 8, 2017 at 2:59 PM John Meinel  wrote:

> I just saw a couple of bugs targeted at Juju that were about the MySQL
> charm:
>  https://bugs.launchpad.net/charms/+source/mysql/+bug/1670431
> and
>  https://bugs.launchpad.net/charms/+source/mysql/+bug/1670430
>
> I retargeted them at the mysql charm. Is that the correct place to put
> them?
>
> Thanks,
> John
> =:->
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

MySQL charm bugs

[John Meinel]

I just saw a couple of bugs targeted at Juju that were about the MySQL
charm:
 https://bugs.launchpad.net/charms/+source/mysql/+bug/1670431
and
 https://bugs.launchpad.net/charms/+source/mysql/+bug/1670430

I retargeted them at the mysql charm. Is that the correct place to put them?

Thanks,
John
=:->
-- 
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

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

Re: Make JaaS better for data scientists

[Francesco Banconi]

> On 8 Mar 2017, at 09:51, Merlijn Sebrechts  
> wrote:
> 
> Juju as a Service is incredibly cool. This is a great step towards making 
> Juju useful for data scientists. However, there are still a number of issues 
> that block this adoption. This email sheds some light into how, in our 
> experience, a data scientist should use Juju and identifies what issues 
> prevent data scientists from using Juju this way.

This is great feedback Merlijn, thanks a lot!
Please take a look at my comments inline for a status update on the issues you 
listed.

> The ideal workflow of a data scientist
> 
> 1. Search the Charm store for the framework you want to use.
> 2. Find the right bundle such as the Apache Spark Zeppelin bundle and click 
> on "add to new model"
> 3. login into JaaS, click deploy and add cloud credentials.
> 4. Wait until the bundle is deployed completely
> 5. Use the GUI to go to the Zeppelin UI
> 6. Do data science magic.
> 
> Blockers in this workflow
> 
>   • A bunch of Charms fail when deployed from the GUI. Juju GUI handling 
> of empty config breaks promulgated charms. [1] [2] [3]

We recently fixed this and deployed to production already, so the deployment of 
Apache Spark Zeppelin charms and all other charms affected by empty config 
issues should work now.

>   • It's not possible use the GUI to go to the Zeppelin UI because 
> Zeppelin is a subordinate. Subordinate unit details show principal unit 
> details

Interesting, I just reprioritised the issue you linked, thanks.

>   • A bunch of Big Data Charms cannot be deployed from the Charm Store 
> because it's not possible to upload large resources. [1] [2]

This has been fixed and will be made available on the next release of the charm 
tool.

>   • It's not possible to create some models with the GUI because the GUI 
> doesn't understand regular relationships to a subordinate charm

We investigated this and found the root cause for which the GUI and the CLI act 
differently. Will be fixed soon.

> Non-blocking issues:
>   • The data scientist has no idea what version of the platform he is 
> running since workload version isn't show in the GUI.

Cool, good point, we’ll figure out with UX where to include that missing piece 
of information.

> Enhancements:
>   • Bring a GUI's application address more to the front. A user now has 
> to dig into the units to see this info. This info should be front and center 
> since it's the obvious next step after the model is deployed.
>   • Bring advanced Charm states more to the front. Currently, a user has 
> to dig into the units in the sidebar to find a very badly wrapped version of 
> the unit message.

Yes this is related to the address really being a property of units, not the 
application itself. But, from the UX perspective, we should really consider 
surfacing this info, especially when there is only one unit. 

>   • Putting the public IP first in the list of IP's. 
> https://github.com/juju/juju-gui/issues/2598

Cool, trivial fix already in progress.

>   • In general, show much more info in the GUI, such as machine IP's etc.
> Next steps
> 
> If the data scientists likes what he sees, he'll have a few questions.
> 
> 1. How do I get ssh access to the machines themselves?
> 2. How do I connect my own applications to this model?

The good news is that we have these steps already in our roadmap. We already 
discussed about allowing machine access from the GUI (even if it’s not 
scheduled for the near future), the ability to relate applications cross model 
being developed by the Juju team to be available soon.

> Blockers for next steps
> 
>   • The GUI borks on the Eclipse Che Charm because it tries to parse the 
> >30.000 open ports that Eclipse Che has. The CLI shows this correctly as a 
> port range but the GUI doesn't. So we need the CLI to find the url to go to 
> eclipse che but we need access to eclipse che to get a cli. Chicken or egg?

We are already working to fix this, and it will be part of the next GUI release.

> Non-blocking issues:
>   • There is no way to export model info from the GUI and import it into 
> the CLI. Another approach to this might be to piggyback on the idea of 
> exposing the controller as an application in the "controller" model. The 
> eclipse-che charm can then connect to the controller charm to import that 
> information.

I guess this is https://github.com/juju/juju-gui/issues/2599 And yes I agree 
this must be part of your roadmap.

Thanks again for your notes: this is exactly what we need to make Juju as a 
Service better, and we’ll surely work in the direction of making it a great 
experience for data scientists.

--
Francesco





-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: cinder and ceilometer metrics architecture question

[James Page]

Hi Drew

On Wed, 8 Mar 2017 at 16:03 Drew Freiberger 
wrote:
[...]

> Unfortunately, nothing in ceilometer is picking up the
>
oslo_message_notifications on the unit where cinder is running.  I went
> to add the ceilometer-agent-charm to the unit, but found it's only
> written to pick up OS and Compute telemetry data and does not include
> the ceilometer-agent-notification package.  I found documentation here
> regarding the need to start the ceilometer-agent-notifications service:
>
> https://docs.openstack.org/developer/ceilometer/install/manual.html#installing-the-notification-agent
>
> My ultimate question for the juju-charmers is whether a new
> ceilometer-notifications-agent-charm should be written, or if we can
> extend the ceilometer-agent charm that is specifically written for
> Compute nodes currently to auto-detect it's parent charm from the
> subordinate:container relationship and configure appropriately whether
> that is cinder or nova-compute or some "other" parent?
>
> Or, am I missing something else entirely that should be picking up these
> oslo_messaging_notifications from cinder-volume-usage-audit?


The ceilometer charm should be running the ceilometer-agent-notifications
service, consuming notification messages from services via the RabbitMQ
message bus.

No additional charm should be required, the existing charms should be doing
the right things already.

Cheers

James
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: ssh keys

[Rick Harding]

This is definitely on the todo list. It's completely correct that users
should be able to manage their own keys.

On Wed, Mar 8, 2017 at 11:01 AM James Beedy  wrote:

> I'm quickly finding myself maintaining users ssh keys. How do people feel
> about making ssh keys bound to the user instead of the model? This way,
> when a user is added to a model ssh access comes with the package.
> Moreover, can we allow users to manage their own keys?
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

cinder and ceilometer metrics architecture question

[Drew Freiberger]

Hello all,

I recently came across the need to add cinder's volume telemetry data
into a client's ceilometer environment.

I've found that there was a patch for charm-cinder that enables the
cron-tick for cinder-volume-usage-audit and implemented it in a
cherry-picked fashion into my current charm (as I await timing to
upgrade this charm to the released version with the patch.)  Many thanks
to Jorge for that config feature, and this is working properly.

Referenced patch here:
https://git.openstack.org/cgit/openstack/charm-cinder/commit/?id=07ae3acbb49368c58b0ad3d119ff21db39fb31c2

Unfortunately, nothing in ceilometer is picking up the
oslo_message_notifications on the unit where cinder is running.  I went
to add the ceilometer-agent-charm to the unit, but found it's only
written to pick up OS and Compute telemetry data and does not include
the ceilometer-agent-notification package.  I found documentation here
regarding the need to start the ceilometer-agent-notifications service: 
https://docs.openstack.org/developer/ceilometer/install/manual.html#installing-the-notification-agent


My ultimate question for the juju-charmers is whether a new
ceilometer-notifications-agent-charm should be written, or if we can
extend the ceilometer-agent charm that is specifically written for
Compute nodes currently to auto-detect it's parent charm from the
subordinate:container relationship and configure appropriately whether
that is cinder or nova-compute or some "other" parent?

Or, am I missing something else entirely that should be picking up these
oslo_messaging_notifications from cinder-volume-usage-audit?

Thank you for your time and guidance,
-Drew


signature.asc
Description: PGP signature
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

ssh keys

[James Beedy]

I'm quickly finding myself maintaining users ssh keys. How do people feel
about making ssh keys bound to the user instead of the model? This way,
when a user is added to a model ssh access comes with the package.
Moreover, can we allow users to manage their own keys?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: User Groups

[Mark Shuttleworth]

On 08/03/17 07:52, James Beedy wrote:
> Managing users with Juju currently does not scale. Can we associate
> users with groups please?
>
> Find bug here -> https://bugs.launchpad.net/juju/+bug/1671149 

Yes, this is on-roadmap.

Mark

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

User Groups

[James Beedy]

Managing users with Juju currently does not scale. Can we associate users
with groups please?

Find bug here -> https://bugs.launchpad.net/juju/+bug/1671149
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Fwd: Make JaaS better for data scientists

[Merlijn Sebrechts]

Hi all


Juju as a Service is incredibly cool. This is a great step towards making
Juju useful for data scientists. However, there are still a number of
issues that block this adoption. This email sheds some light into how, in
our experience, a data scientist should use Juju and identifies what issues
prevent data scientists from using Juju this way.


The ideal workflow of a data scientist

1. Search the Charm store for the framework you want to use.
2. Find the right bundle such as the Apache Spark Zeppelin bundle
 and click on "add to
new model"
3. login into JaaS, click deploy and add cloud credentials.
4. Wait until the bundle is deployed completely
5. Use the GUI to go to the Zeppelin UI
6. Do data science magic.

Blockers in this workflow


   - A bunch of Charms fail when deployed from the GUI. *Juju GUI handling
   of empty config breaks promulgated charms. [1]
    [2]
    [3]
   *
   - It's not possible use the GUI to go to the Zeppelin UI because
   Zeppelin is a subordinate. *Subordinate unit details show principal unit
   details *
   - A bunch of Big Data Charms cannot be deployed from the Charm Store
   because it's not possible to upload large resources. [1]
    [2]
   
   - It's not possible to create some models with the GUI because the GUI
   doesn't understand regular relationships to a subordinate charm
   

Non-blocking issues:

   - The data scientist has no idea what version of the platform he is
   running since workload version isn't show in the GUI
   .

Enhancements:


   - Bring a GUI's application address more to the front. A user now has to
   dig into the units to see this info. This info should be front and center
   since it's the obvious next step after the model is deployed.
   - Bring advanced Charm states more to the front. Currently, a user has
   to dig into the units in the sidebar to find a very badly wrapped version
   of the unit message.
   - Putting the public IP first in the list of IP's.
   https://github.com/juju/juju-gui/issues/2598
   
   - In general, show much more info in the GUI, such as machine IP's etc.

Next steps

If the data scientists likes what he sees, he'll have a few questions.

1. How do I get ssh access to the machines themselves?
2. How do I connect my own applications to this model?

>From our experience, many data scientists want a web UI to do that stuff.
Installing an Ubuntu system + Juju and all its tools and configuring the
tools to connect to the model is a lot of work. This is where Data
Scientists drop out, they don't want to invest so much time just to connect
to their cluster. This is the exact reason why I built the Eclipse Che Charm
. An in-browser IDE + Console +
Charmbox.

Blockers for next steps


   - The GUI borks on the Eclipse Che Charm because it tries to parse the
   >30.000 open ports that Eclipse Che has.
    The CLI shows this
   correctly as a port range but the GUI doesn't. So we need the CLI to find
   the url to go to eclipse che but we need access to eclipse che to get a
   cli. Chicken or egg?

Non-blocking issues:



   - There is no way to export model info from the GUI and import it into
   the CLI.  Another approach
   to this might be to piggyback on the idea of exposing the controller as an
   application in the "controller" model. The eclipse-che charm can then
   connect to the controller charm to import that information.



Kind regards
Merlijn
-- 
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

[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 
>> 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
>
-- 
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]

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

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

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

juju 2.0.2 picking a random ip address from maas

[Patrizio Bassi]

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/mailman/listinfo/juju