from:"Patrizio Bassi"

Re: using the new bundle features in Juju 2.2.3

2017-09-16 Thread Patrizio Bassi

+1 from my side.

At the moment i have 3 bundles, dev, qa and prod which differ only by IPs
and unit number
It would be great to have a dynamic filled bundle :)

Patrizio

2017-09-16 9:02 GMT+02:00 Giuseppe Attardi <giuseppe.atta...@garr.it>:

>
> > On 15 set 2017, at 16:46, Rick Harding <rick.hard...@canonical.com>
> wrote:
> >
> > On Fri, Sep 15, 2017 at 10:33 AM Giuseppe Attardi <
> giuseppe.atta...@garr.it> wrote:
> > Is it possible to use variables in the bundle defined in the
> bundle-config?
> >
> > Not currently no, there's no string substitution in there. Are you
> looking for model specific data to make it in? Or some other input?
>
> What we do in our bundles is this:
>
> variables:
>   network-space-pub: _space_pub  space-pub
>   …
>
> services:
>   keystone:
> bindings:
>   public: *network_space_pub
>  …
>   openstack-dashboard:
> bindings:
>   shared-db: *network_space_os_mgmt
>   cluster: *network_space_os_mgmt
>   website: *network_space_pub
>
> It would be nice to place these variable definitions in the bundle-config
> file.
>
> —
>
>
>
> --
> 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
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: designate-charm/designate-sink patch backport request

2017-08-18 Thread Patrizio Bassi

Alex, All

here it is: https://bugs.launchpad.net/designate/+bug/1711647
Regards

Patrizio


2017-08-17 15:47 GMT+02:00 Alex Kavanagh <alex.kavan...@canonical.com>:

> Hi Patrizio
>
> From the looks of the bug report, it seems to have been backported to
> stable/ocata, but judging from your links, you're using stable/newton?
>
> This should probably get raised as a bug on the designate project to
> request the backport to stable/newton, so that the designate team can
> evaluate impact/etc.
>
> Best regards
> Alex.
>
>
> On Fri, Jun 23, 2017 at 3:34 PM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Hi All
>>
>> I'm using a juju-deployed openstack. Today i deployed Designate charm
>> (#9) which pulls and installs:
>>
>> *designate-sink/xenial,now 1:2.0.0-0ubuntu1 all [installed]*
>>
>> when using
>> juju config designate neutron-record-format='%(hostn
>> ame)s.%(project)s.%(zone)s'
>> the %project variable is set to 'None' because of
>> https://github.com/openstack/designate/blob/stable/newton
>> /designate/notification_handler/nova.py#L69
>>
>> The sink daemon can't resolve the project name which defaults to None.
>>
>> This commit fixes the issue for nova and neutron hooks.
>> https://github.com/openstack/designate/commit/b23cae7b7839af
>> 2d2ed38c06a126f1e2a869ddd3
>>
>> It would be great to backport to xenial stable, it looks safe. I applied
>> locally and it works flawlessy.
>>
>> I will be happy to test a new deb build if you want.
>>
>> Regards, have a nice weekend
>>
>> Patrizio
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>



-- 

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: designate-charm/designate-sink patch backport request

2017-08-14 Thread Patrizio Bassi

Hi all,

anyone giving some love to this report news here?
@Alex i added you in CC as you are working on designate charms as far as i
understood.

Thank you, regards
Patrizio

2017-06-23 16:34 GMT+02:00 Patrizio Bassi <patrizio.ba...@gmail.com>:

> Hi All
>
> I'm using a juju-deployed openstack. Today i deployed Designate charm (#9)
> which pulls and installs:
>
> *designate-sink/xenial,now 1:2.0.0-0ubuntu1 all [installed]*
>
> when using
> juju config designate neutron-record-format='%(
> hostname)s.%(project)s.%(zone)s'
> the %project variable is set to 'None' because of https://github.com/
> openstack/designate/blob/stable/newton/designate/
> notification_handler/nova.py#L69
>
> The sink daemon can't resolve the project name which defaults to None.
>
> This commit fixes the issue for nova and neutron hooks.
> https://github.com/openstack/designate/commit/
> b23cae7b7839af2d2ed38c06a126f1e2a869ddd3
>
> It would be great to backport to xenial stable, it looks safe. I applied
> locally and it works flawlessy.
>
> I will be happy to test a new deb build if you want.
>
> Regards, have a nice weekend
>
> Patrizio
>



-- 

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 application stuck, cannot remove/scale out

2017-08-07 Thread Patrizio Bassi

Dear Alex,

i didn't try further, but i'll let you know in case it happens again
Regards

Patrizio

2017-08-04 16:37 GMT+02:00 Alex Kavanagh <alex.kavan...@canonical.com>:

> Hi Patrizio
>
> Sorry you're hitting a charm problem with designate.   Has the problem
> re-occurred with a remove-machine and add-unit?  I'm doing quite a lot of
> work on the designate charm for the next release, and so would be
> interested if this is a problem we've already fixed (e.g. you could try
> juju deploy cs:~openstack-charmers-next/designate-36) but there's still
> some work going on with it.
>
> Thanks
> Alex
>
> On Fri, Aug 4, 2017 at 2:48 PM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Unfortunately i cannot fix the issue because it looks like a charm problem
>> https://paste.ubuntu.com/25240017/
>>
>> Patrizio
>>
>>
>> 2017-08-04 15:43 GMT+02:00 Tom Barber <t...@spicule.co.uk>:
>>
>>> You need to mark it resolved and if that fails you can do juju resolved
>>> designate/0 --no-retry
>>>
>>> Once its hooks have cleared out it will disappear.
>>>
>>> Tom
>>>
>>> On Fri, Aug 4, 2017 at 2:33 PM, Patrizio Bassi <patrizio.ba...@gmail.com
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> i've deployed a designate charm with maas provider in a lxd container.
>>>> when i tried to remove (juju remove-application designate) it i got the
>>>> unit stuck with  hook failed: "update-status"
>>>>
>>>> Debugging with lxc info in the host machine i found the container is
>>>> still alive and with running processes.
>>>>
>>>> now i cannot use add-unit nor remove it, it's just stuck. i rebooted
>>>> the container, no way. I used juju resolved designate/0, no way.
>>>>
>>>> How to fix this kind of problem?
>>>> Thank you
>>>>
>>>> Patrizio
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju@lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju
>>>>
>>>>
>>>
>>>
>>> --
>>> Tom Barber
>>> CTO Spicule LTD
>>> t...@spicule.co.uk
>>>
>>> http://spicule.co.uk
>>>
>>> @spiculeim <http://twitter.com/spiculeim>
>>>
>>> Schedule a meeting with me <http://meetme.so/spicule>
>>>
>>> GB: +44(0)5603641316 <+44%2056%200364%201316>
>>> US: +18448141689 <+1%20844-814-1689>
>>>
>>> <https://leanpub.com/juju-cookbook>
>>>
>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>



-- 

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 application stuck, cannot remove/scale out

2017-08-07 Thread Patrizio Bassi

Hi Alex,

that worked because i had designate in a lxd container, so it was fully
removed.
It's not feasable when you use bare metal or a single vm with several
applications: removing a hanged unit would result in several app servive
destruction

Regards,
Patrizio

2017-08-04 15:46 GMT+02:00 Alex Kavanagh <alex.kavan...@canonical.com>:

> Hi Patrizio
>
> What's the output of "juju debug-log -i unit-designate -n 1000"  ?
>
> The last few lines should indicate why designate crashed on the
> update-status hook.
>
> To force remove the unit use:
>
> juju remove-machine  --force
>
> where n is the machine number from juju status designate
>
> Hope that helps
> Alex.
>
> On Fri, Aug 4, 2017 at 2:33 PM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Hi,
>>
>> i've deployed a designate charm with maas provider in a lxd container.
>> when i tried to remove (juju remove-application designate) it i got the
>> unit stuck with  hook failed: "update-status"
>>
>> Debugging with lxc info in the host machine i found the container is
>> still alive and with running processes.
>>
>> now i cannot use add-unit nor remove it, it's just stuck. i rebooted the
>> container, no way. I used juju resolved designate/0, no way.
>>
>> How to fix this kind of problem?
>> Thank you
>>
>> Patrizio
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>



-- 

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 application stuck, cannot remove/scale out

2017-08-04 Thread Patrizio Bassi

Unfortunately i cannot fix the issue because it looks like a charm problem
https://paste.ubuntu.com/25240017/

Patrizio

2017-08-04 15:43 GMT+02:00 Tom Barber <t...@spicule.co.uk>:

> You need to mark it resolved and if that fails you can do juju resolved
> designate/0 --no-retry
>
> Once its hooks have cleared out it will disappear.
>
> Tom
>
> On Fri, Aug 4, 2017 at 2:33 PM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Hi,
>>
>> i've deployed a designate charm with maas provider in a lxd container.
>> when i tried to remove (juju remove-application designate) it i got the
>> unit stuck with  hook failed: "update-status"
>>
>> Debugging with lxc info in the host machine i found the container is
>> still alive and with running processes.
>>
>> now i cannot use add-unit nor remove it, it's just stuck. i rebooted the
>> container, no way. I used juju resolved designate/0, no way.
>>
>> How to fix this kind of problem?
>> Thank you
>>
>> Patrizio
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> Tom Barber
> CTO Spicule LTD
> t...@spicule.co.uk
>
> http://spicule.co.uk
>
> @spiculeim <http://twitter.com/spiculeim>
>
> Schedule a meeting with me <http://meetme.so/spicule>
>
> GB: +44(0)5603641316 <+44%2056%200364%201316>
> US: +18448141689 <+1%20844-814-1689>
>
> <https://leanpub.com/juju-cookbook>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

juju application stuck, cannot remove/scale out

2017-08-04 Thread Patrizio Bassi

Hi,

i've deployed a designate charm with maas provider in a lxd container.
when i tried to remove (juju remove-application designate) it i got the
unit stuck with  hook failed: "update-status"

Debugging with lxc info in the host machine i found the container is still
alive and with running processes.

now i cannot use add-unit nor remove it, it's just stuck. i rebooted the
container, no way. I used juju resolved designate/0, no way.

How to fix this kind of problem?
Thank you

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

Re: juju bug (?) when allocating floating ips to machines

2017-07-28 Thread Patrizio Bassi

Dear Heather

here you are: https://bugs.launchpad.net/juju/+bug/1707248

The external network check is not enough because, as said, the same network
ip range may be allocated in other tenants.

Regards

Patrizio

2017-07-27 19:43 GMT+02:00 Heather Lanigan <heather.lani...@canonical.com>:

> Hi Patrizio,
>
> Judging by the code in develop, we do not check the tenant_id when
> choosing a FIP.  There is an attempt to ensure the FIP is in the provided
> external network, if specified.  So that may be another work around.
>
> Please file a bug.  I'm wondering if there are more places the provider
> should be checking the tenant as well.
>
> -Heather
>
>
>
> On Thu, Jul 27, 2017 at 9:04 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Hi all
>>
>> i'm using juju 2.1.2.1 (i didn't upgrade to 2.2 yet, that's why i didn't
>> open a bug on launchpad) with openstack as cloud provider.
>>
>> When i use as credentials an Admin user (but a specific tenant) i have
>> issues with floating ip assignment: the admin user can see all the floating
>> ips in the openstack region.
>> So, if another tenant allocates an IP without assigning to a VM (so,
>> unused) juju tries to use it and attach to the VM it just deployed.
>>
>> i.e.
>>
>> user test1 is Admin and has primary project "tenant-one"
>> user test2 is member of project "tenant-two"
>>
>> credentials given to juju are test1, test1_password, tenant-one and
>> RegionOne.
>>
>> # source novarc_test1
>>
>> # neutron floatingip-list
>> +--+--+-
>> +--+
>> | id   | fixed_ip_address |
>> floating_ip_address | port_id  |
>> +--+--+-
>> +--+
>> | 03d1a8e8-fd55-4d6e-ab7e-b62061ea6206 | 192.168.0.10 | 10.1.2.19
>>   | b6ac7caf-0c6e-4d81-b055-ecb8b4bdeebd |
>> | 2b4e48ba-aad6-4d78-aff6-88b912f89bf5 | 192.168.0.20 | 10.1.2.9
>>  | 17f69b3b-97d0-4cec-8208-e4d2ac2f1034 |
>> | 3144b683-2cf5-43cf-bddd-b06cb5662430 |  | 10.1.2.22
>>   |  |
>> | 55145d85-58ea-4f15-8a0c-96a719c0fa8d | 192.168.0.22 | 10.1.2.4
>>  | 6eeaa12b-0971-496c-bd38-89e9b9d71818 |
>> +--+--+-
>> +--+
>>
>> the third line shows and ip address assigned to tenant-two by test2.
>>
>> User test1 has admin role so he has permission to see the ip.
>> Using a command like "neutron floatingip-show
>> 3144b683-2cf5-43cf-bddd-b06cb5662430" correctly shows the project_id
>> uuid related to tenant-two and not tenant-one.
>>
>> juju model is configured with
>> use-default-secgroup  model   true
>> use-floating-ip   model   true
>>
>> When trying to deploy any application juju spawns a VM, but it never ends
>> and logs:
>>
>> Unable to associate floating IP 10.1.2.22 to fixed IP 192.168.0.9 for
>> instance 3d95283c-69f2-4cf1-8980-99462a5904a2.
>>
>> Removing the unused floating ip address or using a member-only (not admin
>> user) bypass the problem: juju will allocate a new ip and associate with
>> the new VM.
>>
>> I didn't try but i do think that if an user is member of two different
>> tenants it may try to mis-use the addresses and mess with them, failing to
>> deploy.
>>
>> Desiderata: juju should check if the allocated ip address is in the same
>> tenant view of the given credentials.
>>
>> Regards
>>
>> 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

juju bug (?) when allocating floating ips to machines

2017-07-27 Thread Patrizio Bassi

Hi all

i'm using juju 2.1.2.1 (i didn't upgrade to 2.2 yet, that's why i didn't
open a bug on launchpad) with openstack as cloud provider.

When i use as credentials an Admin user (but a specific tenant) i have
issues with floating ip assignment: the admin user can see all the floating
ips in the openstack region.
So, if another tenant allocates an IP without assigning to a VM (so,
unused) juju tries to use it and attach to the VM it just deployed.

i.e.

user test1 is Admin and has primary project "tenant-one"
user test2 is member of project "tenant-two"

credentials given to juju are test1, test1_password, tenant-one and
RegionOne.

# source novarc_test1

# neutron floatingip-list
+--+--+-
+--+
| id   | fixed_ip_address |
floating_ip_address | port_id  |
+--+--+-
+--+
| 03d1a8e8-fd55-4d6e-ab7e-b62061ea6206 | 192.168.0.10 | 10.1.2.19
  | b6ac7caf-0c6e-4d81-b055-ecb8b4bdeebd |
| 2b4e48ba-aad6-4d78-aff6-88b912f89bf5 | 192.168.0.20 | 10.1.2.9
   | 17f69b3b-97d0-4cec-8208-e4d2ac2f1034 |
| 3144b683-2cf5-43cf-bddd-b06cb5662430 |  | 10.1.2.22
  |  |
| 55145d85-58ea-4f15-8a0c-96a719c0fa8d | 192.168.0.22 | 10.1.2.4
   | 6eeaa12b-0971-496c-bd38-89e9b9d71818 |
+--+--+-
+--+

the third line shows and ip address assigned to tenant-two by test2.

User test1 has admin role so he has permission to see the ip.
Using a command like "neutron floatingip-show
3144b683-2cf5-43cf-bddd-b06cb5662430"
correctly shows the project_id uuid related to tenant-two and not
tenant-one.

juju model is configured with
use-default-secgroup  model   true
use-floating-ip   model   true

When trying to deploy any application juju spawns a VM, but it never ends
and logs:

Unable to associate floating IP 10.1.2.22 to fixed IP 192.168.0.9 for
instance 3d95283c-69f2-4cf1-8980-99462a5904a2.

Removing the unused floating ip address or using a member-only (not admin
user) bypass the problem: juju will allocate a new ip and associate with
the new VM.

I didn't try but i do think that if an user is member of two different
tenants it may try to mis-use the addresses and mess with them, failing to
deploy.

Desiderata: juju should check if the allocated ip address is in the same
tenant view of the given credentials.

Regards

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

Re: CephFS Backend for Hadoop

2017-07-27 Thread Patrizio Bassi

2017-07-26 9:17 GMT+02:00 Mark Shuttleworth <m...@ubuntu.com>:

> On 26/07/17 07:14, Patrizio Bassi wrote:
>
> Deploying hadoop via juju in an openstack tenant requires a separate model
> (as far as i could design it).
> So we may use the new juju 2.2 cross model relation to relate the hadoop
> charms to the openstack ceph units.
>
> does it sound feasible?
>
>
> Yes, that sounds feasible. I'm not sure how Ceph identity / permissions
> will work in that case (i.e. who has access to which data, how Ceph will
> correlate tenants in OpenStack both through Cinder and through a direct
> relationship). In principle though, as long as the networking is arranged
> so that IP addresses and routes enable traffic to flow between your tenant
> network and your Ceph network, and as long as both sets of machines can see
> the Juju controller, they can exchange messages and traffic.
>
> Mark
>


Dear Mark,

On relation join event we may create a new ceph storage pool dedicated to
the incoming unit (i.e. prefixed with the controller/model/unit/charm name
by default). Can cephx proto

Regarding networking openstack neutron by default block traffic from tenant
VM to the admin network which it required to access the same ceph mon/osd.
It requires changing neutron or implement an external nat for instance (our
solution at the moment)

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

Re: CephFS Backend for Hadoop

2017-07-26 Thread Patrizio Bassi

Il giorno mer 26 lug 2017 alle 06:28 James Beedy  ha
scritto:

> Hello all,
>
> I will be evaluating CephFS as a backend for Hadoop over the next few
> weeks, probably start investigating how this can be delivered via the
> charms in the morning. If anyone has ventured to this realm, or has an idea
> on what the best way to deliver this might be, I would love to hear from
> you.
>
> Thanks,
>
> James
>
>
>

I do!

Probably i won't be able to test before end of the year but i plan to host
hadoop clusters in openstack tenants and i would like to share the same
ceph osd providing infrastructural storage to openstack nova/cinder.

Deploying hadoop via juju in an openstack tenant requires a separate model
(as far as i could design it).
So we may use the new juju 2.2 cross model relation to relate the hadoop
charms to the openstack ceph units.

does it sound feasible?

regards

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

Re: call for testing: relations across Juju models

2017-07-24 Thread Patrizio Bassi

gt; > A key implementation artifact is that controller-to-controller traffic
> flows
> > from the consuming model to the offering model. In the case where offer
> endpoint
> > is provides, and consumer endpoint is requires, workload traffic will
> generally
> > flow the same way - eg consumer app opens a connection to an IP address
> in the
> > offering model. So control traffic and workload traffic is
> unidirectional.
> >
> > In the case where the offer has the requires endpoint, this typically
> this means
> > that the offer application will initiate the connection to the consumer
> app. eg
> > prometheus will poll the source of the metrics is the consuming model.
> This
>
> prometheus will poll the source of the metrics *in* the consuming model.
>
> > means that the workload traffic is offer model -> consumer model, while
> the
> > control traffic is consumer model -> offer model. Hence we need
> bi-directional
> > routability between offer and consuming model in this case.
> >
> > Having the controller-to-controller traffic from flow consuming model to
> > offering mode is better for scalability and reduces complexity
> significantly. If
> > the routing issue above is not a problem in practice, then we'll stick
> with the
> > implementation as is. If not, we'll need to discuss things further.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> 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
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

designate-charm/designate-sink patch backport request

2017-06-23 Thread Patrizio Bassi

Hi All

I'm using a juju-deployed openstack. Today i deployed Designate charm (#9)
which pulls and installs:

*designate-sink/xenial,now 1:2.0.0-0ubuntu1 all [installed]*

when using
juju config designate
neutron-record-format='%(hostname)s.%(project)s.%(zone)s'
the %project variable is set to 'None' because of
https://github.com/openstack/designate/blob/stable/newton/designate/notification_handler/nova.py#L69

The sink daemon can't resolve the project name which defaults to None.

This commit fixes the issue for nova and neutron hooks.
https://github.com/openstack/designate/commit/b23cae7b7839af2d2ed38c06a126f1e2a869ddd3

It would be great to backport to xenial stable, it looks safe. I applied
locally and it works flawlessy.

I will be happy to test a new deb build if you want.

Regards, have a nice weekend

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

Re: is Hdp bundle still maintained/supported?

2017-06-20 Thread Patrizio Bassi

Dear Samuel

i deployed the hadoop-processing bundle successfully.
I had some troubles because openstack instances didn't get the dns
entry so hadoop-hdfs-namenode/datanode
could not resolve their own addresses first, then the peers'.

I did a fast hack just manually adding the entries in /etc/hosts while
waiting for Designate service to be deployed and active.

It would be great if you could add in the documentation the dns need.

This said, i run the smoke tests and they all failed. HDFS storage is
reported working instead.
I'm totally newbie in hadoop clusters so i didn't start investigation, but
i wanted to report in case you may check on your local working copy and
verify it's fine upstream.

Thank you

Patrizio




2017-06-16 12:08 GMT+02:00 Patrizio Bassi <patrizio.ba...@gmail.com>:

> Hi Samuel,
>
> thank you for fast and honest reply. I will start to take a look at
> hadoop-processing bundle.
> Regards,
>
> Patrizio
>
> 2017-06-16 9:54 GMT+02:00 Samuel Cozannet <samuel.cozan...@canonical.com>:
>
>> Hi Patrizio,
>>
>> Thanks for reaching out. There is a list of more recent charms based on
>> Big Top here: https://jujucharms.com/q/bigtop?type=charm
>> The current strategy is to focus on big top, so products from Hortonworks
>> are no longer supported as you could notice.
>>
>> The team to track is here : https://jujucharms.com/u/bigdata-charmers/
>>
>> In addition, there are 2 community teams actively involved in Big Data
>> solutions via Juju, who can help for big data solutions:
>> * http://spicule.co.uk/ (on IRC reach out to MagicalTrout)
>> * http://tengu.intec.ugent.be/v1/ (reach out to
>> merlijn.sebrec...@gmail.com)
>>
>> Best,
>> Sam
>>
>>
>>
>>
>> --
>> Samuel Cozannet
>> Cloud, Big Data and IoT Strategy Team
>> Business Development - Cloud and ISV Ecosystem
>> Changing the Future of Cloud
>> Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com> /
>> Juju <https://jujucharms.com>
>> samuel.cozan...@canonical.com
>> mob: +33 616 702 389
>> skype: samnco
>> Twitter: @SaMnCo_23
>> [image: View Samuel Cozannet's profile on LinkedIn]
>> <https://es.linkedin.com/in/scozannet>
>>
>> On Fri, Jun 16, 2017 at 9:36 AM, Patrizio Bassi <patrizio.ba...@gmail.com
>> > wrote:
>>
>>> Hi all,
>>>
>>> looking at a hadoop distro in the jujucharms is found
>>> https://jujucharms.com/hdp-hadoop/trusty/1 charm,
>>> following the announcement in https://insights.ubuntu.com
>>> /2015/02/19/ubuntu-hortonworks-and-microsoft-big-data-hosted-solution/ .
>>>
>>>
>>> I would like to know if it's still maintained, i don't see commits since
>>> 2015, version is stuck to trusty for ubuntu and hdp at 2.1.3 while upstream
>>> is on 2.2 series.
>>> the Contact Information show a no more valid email address too.
>>>
>>> Is Canonical looking at Apache bundle only?
>>>
>>> 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: multi model/cloud deploy (how to deploy kubernates-workers in multitenant openstack)

2017-06-16 Thread Patrizio Bassi

Marco,

i totally agree with you: i do not want to manage them manually, John's
suggestion is great but it's very last chance.

Regarding cross model relations i'm very interested, I can't upgrade to
juju 2.2 immediately (i'm in 2.1.2 now) but as soon as possibile i'll give
a try.

Regarding multi provider missing planning, that's a pity. It would be nice
to have a way to relocate units, balance workloads based on costs, HA and
so on...

Looking forward for more details, thank you!

Patrizio


2017-06-16 16:27 GMT+02:00 Marco Ceppi <marco.ce...@canonical.com>:

> I'd got one step further and say cross model relations are exactly what
> you're looking to do. I'd avoid using manual machine additions because it's
> really not a first class experience. In 2.2 cross model relations have
> matured quite a bit, there are still some limitations, but it might be
> worth trying.
>
> I'll try to reply in a bit with an example on AWS for cross model
> relations and Kubernetes.
>
> Marco
>
>
> On Fri, Jun 16, 2017 at 7:27 AM John Meinel <j...@arbash-meinel.com>
> wrote:
>
>> If you have started the machine yourself, you should be able to "juju
>> add-machine ssh:IP_ADDRESS" and then use that as a "juju deploy --to X"
>> target.
>>
>> However, you will still need to tear down the machine when you're done.
>> We don't yet support multi-provider models. Likely we won't, but we will
>> support cross-model relations, which would let you have some of your
>> workloads on different providers. Though if you wanted it to be logically 1
>> application, with units in different providers, that wouldn't quite work
>> the way you wanted.
>>
>> John
>> =:->
>>
>> On Fri, Jun 16, 2017 at 1:05 PM, Patrizio Bassi <patrizio.ba...@gmail.com
>> > wrote:
>>
>>> Hi All,
>>>
>>> I have a need somehow similar (at least in the background) to what
>>> reported in the thread "How to Move a machine and its application from
>>> a Model to Another "(https://lists.ubuntu.com/archives/juju/2017-June/
>>> 009111.html ).
>>>
>>> I deployed an openstack environment using juju bundles, this cloud hosts
>>> several applications and tenants.
>>>
>>> Coming to the Kubernates deploy, openstack is a "nested" provider for
>>> juju, the cloud is created and bootstrapped setting the openstack
>>> tenant/project (juju "tenant-name") we called "shared tenant". A minimal
>>> Kubernates setup is installed in this "shared" tenant. So far so good!
>>>
>>> We would like to deploy some kubernates-workers in other tenants, so
>>> each project can benefit the "shared" installation, monitoring, admin
>>> console, but run their own workload in their tenant space, so charge-back
>>> and quotas apply for instance.
>>>
>>> juju add-unit kubernates-worker can only allow in the same model, so the
>>> same cloud.
>>>
>>> Can we just force with --to statement? while for MaaS managed machine
>>> it's enough to have a known "ready" machine, it's not clear to me if in
>>> openstack i can do the same.
>>> 1) create a xenial ubuntu instance with network connectivity to
>>> juju-controller in "shared tenant"
>>> 2) tell juju to deploy the kubernates-worker units in that instance
>>>
>>> For instance, in case of unit-destroy, i would expect juju not to have
>>> the rights because the "tenant-name" is different.
>>>
>>> I saw the add-unit has a -m switch. Can, as far as the user is allowed
>>> to deploy, the -m switch be used to do a sort of "federation" between
>>> controllers?
>>> If not, any plan to implement something like that?
>>>
>>> Of course now i'm refering to the same cloud provider, but maybe in
>>> future this can led to hybrid multi-cloud installation.
>>>
>>> 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
>>
>


-- 

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: is Hdp bundle still maintained/supported?

2017-06-16 Thread Patrizio Bassi

Hi Samuel,

thank you for fast and honest reply. I will start to take a look at
hadoop-processing bundle.
Regards,

Patrizio

2017-06-16 9:54 GMT+02:00 Samuel Cozannet <samuel.cozan...@canonical.com>:

> Hi Patrizio,
>
> Thanks for reaching out. There is a list of more recent charms based on
> Big Top here: https://jujucharms.com/q/bigtop?type=charm
> The current strategy is to focus on big top, so products from Hortonworks
> are no longer supported as you could notice.
>
> The team to track is here : https://jujucharms.com/u/bigdata-charmers/
>
> In addition, there are 2 community teams actively involved in Big Data
> solutions via Juju, who can help for big data solutions:
> * http://spicule.co.uk/ (on IRC reach out to MagicalTrout)
> * http://tengu.intec.ugent.be/v1/ (reach out to
> merlijn.sebrec...@gmail.com)
>
> Best,
> Sam
>
>
>
>
> --
> Samuel Cozannet
> Cloud, Big Data and IoT Strategy Team
> Business Development - Cloud and ISV Ecosystem
> Changing the Future of Cloud
> Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com> /
> Juju <https://jujucharms.com>
> samuel.cozan...@canonical.com
> mob: +33 616 702 389
> skype: samnco
> Twitter: @SaMnCo_23
> [image: View Samuel Cozannet's profile on LinkedIn]
> <https://es.linkedin.com/in/scozannet>
>
> On Fri, Jun 16, 2017 at 9:36 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> looking at a hadoop distro in the jujucharms is found
>> https://jujucharms.com/hdp-hadoop/trusty/1 charm,
>> following the announcement in https://insights.ubuntu.com
>> /2015/02/19/ubuntu-hortonworks-and-microsoft-big-data-hosted-solution/ .
>>
>>
>> I would like to know if it's still maintained, i don't see commits since
>> 2015, version is stuck to trusty for ubuntu and hdp at 2.1.3 while upstream
>> is on 2.2 series.
>> the Contact Information show a no more valid email address too.
>>
>> Is Canonical looking at Apache bundle only?
>>
>> 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

multi model/cloud deploy (how to deploy kubernates-workers in multitenant openstack)

2017-06-16 Thread Patrizio Bassi

Hi All,

I have a need somehow similar (at least in the background) to what reported
in the thread "How to Move a machine and its application from a Model to
Another "(https://lists.ubuntu.com/archives/juju/2017-June/009111.html ).

I deployed an openstack environment using juju bundles, this cloud hosts
several applications and tenants.

Coming to the Kubernates deploy, openstack is a "nested" provider for juju,
the cloud is created and bootstrapped setting the openstack tenant/project
(juju "tenant-name") we called "shared tenant". A minimal Kubernates setup
is installed in this "shared" tenant. So far so good!

We would like to deploy some kubernates-workers in other tenants, so each
project can benefit the "shared" installation, monitoring, admin console,
but run their own workload in their tenant space, so charge-back and quotas
apply for instance.

juju add-unit kubernates-worker can only allow in the same model, so the
same cloud.

Can we just force with --to statement? while for MaaS managed machine it's
enough to have a known "ready" machine, it's not clear to me if in
openstack i can do the same.
1) create a xenial ubuntu instance with network connectivity to
juju-controller in "shared tenant"
2) tell juju to deploy the kubernates-worker units in that instance

For instance, in case of unit-destroy, i would expect juju not to have the
rights because the "tenant-name" is different.

I saw the add-unit has a -m switch. Can, as far as the user is allowed to
deploy, the -m switch be used to do a sort of "federation" between
controllers?
If not, any plan to implement something like that?

Of course now i'm refering to the same cloud provider, but maybe in future
this can led to hybrid multi-cloud installation.

Thank you

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

Re: Call for testers: preview of persistent storage support

2017-05-25 Thread Patrizio Bassi

Dear Andrew,
 what about private clouds such as maas?

Patrizio

Il giorno mer 24 ma 2017 alle 03:38 Andrew Wilkins <
andrew.wilk...@canonical.com> ha scritto:

> Hi folks,
>
> One of the things we're working on for the 2.3 release (not 2.2!) is
> persistent storage. What this means is the ability to detach storage from a
> unit, and reattach it to another unit keeping the storage contents intact.
> We would like to get some feedback before this all gets set in stone.
>
> With the changes, removing an application unit will detach storage rather
> than destroy it as Juju currently does. The storage will then be available
> for attaching to another unit using "juju attach-storage  "
> or to a new application unit using "juju deploy  --attach-storage
> "; or for removal using "juju remove-storage ".
>
> For example, I can deploy postgresql on AWS with EBS storage. If I remove
> the postgresql application, I can add another and attach the storage to it:
>
> $ juju deploy postgresql --storage pgdata=100G,ebs
> Located charm "cs:postgresql-148".
> Deploying charm "cs:postgresql-148".
> (wait for postgresql/0 to become active)
>
> $ juju remove-application postgresql
> removing application postgresql
> - will detach storage pgdata/0
> (wait for postgresql/0 and machine 0 to be removed)
>
> $ juju deploy postgresql postgresql2 --attach-storage pgdata/0 --to
> zone=
> Located charm "cs:postgresql-148".
> Deploying charm "cs:postgresql-148".
> (wait for postgresql2/0 to become active)
>
> If you like, you can confirm for yourself that the data is persisted by
> logging into the first machine and runing "sudo -u postgres psql", creating
> some data, and then checking that it is still there from the second machine.
>
> (The --to zone=... is required due to a limitation that we will remove by
> the time 2.3 is released. EBS volumes and EC2 instances must be created in
> the same AZ, and that's not automatic yet. This is fixed by
> https://github.com/juju/juju/pull/7378 which, at the time of writing this
> email, has not yet been merged.)
>
> If you have any interest in these changes, please help us make them great
> by testing out this early release:
>
> $ sudo snap install --channel=edge --classic juju-axw
> $ /snap/bin/juju-axw.juju bootstrap ...
>
> The new/updated commands are:
>  - juju attach-storage  
>  - juju detach-storage 
>  - juju remove-storage 
>  - juju deploy  --attach-storage 
>
> (We'll also be adding --attach-storage to the "juju add-unit" command
> soon.)
>
> Thank you!
>
> Cheers,
> Andrew
> --
> 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
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: ceph-* openstack charms force ntp installation and configuration

2017-05-13 Thread Patrizio Bassi

Done!

ceph-radosgw: https://bugs.launchpad.net/charms/+source/ceph/+bug/1690514
ceph-mon: https://bugs.launchpad.net/charms/+source/ceph/+bug/1690513

2017-05-13 1:31 GMT+02:00 Paul Gear <paul.g...@canonical.com>:

> On 12/05/17 20:01, Patrizio Bassi wrote:
> > Hi,
> >
> > i'm deployed an openstack environment customizing the telemetry bundle.
> >
> > i noticed ceph-mon/rados-gw containers don't join with ntp charm
> > (correct), but they just install and run a local ntpd.
> > ...
> > considering time source is already in the physical machine i do think
> > it's useless to run such service in the container, and, in case it's
> > really needed, it should obey to user settings.
> >
> > do you need a bug report?
> > Regards
> >
> > Patrizio
>
> Hi Patrizio,
>
> Looks like the charms are hard-coding the list of packages to install:
>
> https://github.com/openstack/charm-ceph-radosgw/blob/
> fd401d5b95a0cda5763a44946df80c6b1951561d/hooks/hooks.py#L86
>
> https://github.com/openstack/charm-ceph-mon/blob/
> 733bad44f2689b2bdf61847d21a0e0109c2a4438/lib/ceph/__init__.py#L76
>
> Definitely seems worth a bug on both charms.
>
> Regards,
> Paul
>
>
> --
> 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
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

ceph-* openstack charms force ntp installation and configuration

2017-05-12 Thread Patrizio Bassi

Hi,

i'm deployed an openstack environment customizing the telemetry bundle.

i noticed ceph-mon/rados-gw containers don't join with ntp charm (correct),
but they just install and run a local ntpd.

i.e.
juju ssh ceph-radosgw/0

ubuntu@juju-e33f9c-0-lxd-2:~$ ps aux |grep ntp
ubuntu4892  0.0  0.0  12944   944 pts/0S+   09:55   0:00 grep
--color=auto ntp
root 19711  0.0  0.0 103708  4936 ?Ssl  May05   1:20
/usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 112:116
ubuntu@juju-e33f9c-0-lxd-2:~$

grep ubuntu /etc/ntp.conf
pool 0.ubuntu.pool.ntp.org iburst
pool 1.ubuntu.pool.ntp.org iburst
pool 2.ubuntu.pool.ntp.org iburst
pool 3.ubuntu.pool.ntp.org iburst
pool ntp.ubuntu.com

considering time source is already in the physical machine i do think it's
useless to run such service in the container, and, in case it's really
needed, it should obey to user settings.

do you need a bug report?
Regards

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

Re: juju deployed openstack nova-lxd cannot start instances

2017-05-12 Thread Patrizio Bassi

Dear James, All

i opened a bug, hope you can give it some love.
https://bugs.launchpad.net/juju/+bug/1690345

Thank you for support

Patrizio

Il giorno mar 9 mag 2017 alle 14:13 Patrizio Bassi <patrizio.ba...@gmail.com>
ha scritto:

> Dear James/all,
>
> I checked /etc/nova/nova.conf in kvm and lxd hypervisor and they look the
> same.
> Regarding glance section it just contains the same endpoint
>
> [glance]
> api_servers = http://10.10.10.95:9292
>
> Following the backtrace it seems it cannot get the image metadata at all.
> I checked the upstream source at https://github.com/openstack/
> nova-lxd/blob/master/nova/virt/lxd/driver.py#L398
>
> has changed the galnce-lxd sync code. Maybe it has been fixed already, did
> anyone try? do we have a bleeding edge ppa to test against?
>
> Patrizio
>
>
> 2017-05-08 18:21 GMT+02:00 Patrizio Bassi <patrizio.ba...@gmail.com>:
>
>>
>>
>> 2017-05-08 18:11 GMT+02:00 James Page <james.p...@ubuntu.com>:
>>
>>> Hi Patrizio
>>>
>>> On Mon, 8 May 2017 at 11:53 Patrizio Bassi <patrizio.ba...@gmail.com>
>>> wrote:
>>> [...]
>>>
>>>> 1) [minor] accessing horizon in the hypervisor list it is seen as
>>>> hostname without fqdn while other 4 hosts has fqdn.
>>>>
>>>
>>> Yes there is a minor diff between LXD and KVM hypervisors:
>>>
>>>   https://bugs.launchpad.net/nova-lxd/+bug/1521319
>>>
>>> however that should not effect things functionally.
>>>
>>
>> Yes, it looks fine, but a bit ugly :)
>>
>>
>>>
>>>
>>>> 2) [major] i cannot boot a lxd image
>>>>
>>>> following https://jujucharms.com/u/openstack-charmers-next/
>>>> openstack-lxd/ i imported the xenial image in glance by
>>>>
>>>> # glance image-create --name="xenial_lxd" --visibility public
>>>> --progress --container-format=bare --disk-format=*root-tar* --property
>>>> architecture="x86_64" < ~/openstack/images/xenial-
>>>> server-cloudimg-amd64-root.tar.gz
>>>>
>>>> i got errors like:
>>>>
>>>> 8446f64e0b504345b48673a3e3a328f1 35515180b8b646329e2caa2372250e0b - -
>>>> -] [instance: e4daef69-525c-4413-b39b-7df5e7822f02] Build of instance
>>>> e4daef69-525c-4413-b39b-7df5e7822f02 aborted: *Image  is unacceptable:
>>>> Bad Image format: Image  could not be found.*
>>>>
>>>> in https://linuxcontainers.org//lxd/getting-started-openstack/ instead
>>>> i see it suggests *--disk-format=raw* but actually nothing changes for
>>>> me, same error.
>>>>
>>>
>>> The disk-format property for LXD images can be raw or root-tar - either
>>> should work.  That error is propagating up from the interaction of the
>>> driver with glance - which might indicate a missing relation between the
>>> nova-compute-lxd service and glance?
>>>
>>>
>>
>> It looks i have (i just replaced nova-compute with nova-lxd)
>>
>> # juju status|grep nova|grep glance
>> image-serviceglance nova-cloud-controller
>>  regular
>> image-serviceglance nova-compute
>> regular
>> image-serviceglance *nova-lxd*
>> regular
>>
>> What else can i check?
>>
>>
>>> I tried with Trusty too, in case xenial image may have been corrupted,
>>>> same issue.
>>>>
>>>> So which format should we use for lxd, root-tar (i do think so) or raw?
>>>> And is lxd driver really working?
>>>>
>>>
>>> The root tarball format is the correct format to use.
>>>
>>
>> Ok, fine...even if in https://docs.openstack.org/
>> image-guide/image-formats.html or https://docs.openstack.
>> org/developer/glance/formats.html i can't find that format
>>
>>
>>
>>>
>>>> It was reported with a similar issue some months ago:
>>>> https://ask.openstack.org/en/question/101255/unable-to-
>>>> start-an-instance-using-nova-lxd/
>>>>
>>>> Another important issue is that lxd hypervisor seems to get scheduled
>>>> to run qcow2 images too, failing, but i guess this can be fixed by adding
>>>> hostgroup, i din't investigate yet.
>>>>
>>>
>>> Its possible to run both hypervisors in the same region, but you must
>>> set the hypervisor type property on all images:
>>>
>>>   --property hypervisor_type=lxc
>>>
>>> or
>>>
>>>   --property hypervisor_type=qemu
>>>
>>> Setting this value will ensure that when you boot an instance of the
>>> image, it gets scheduled to the correct hypervisor type for the image.
>>>
>>
>> This is great, it'll give a try as soon i can boot a lxd image (now i
>> just disabled all kvm hypervisors so just a lxd hypervisor is there).
>>
>>
>>>
>>> Hope that helps move your forward.
>>>
>>> James
>>>
>>
>> Thank you for support
>> Patrizio
>>
>
>
>
> --
>
> 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 deployed openstack nova-lxd cannot start instances

2017-05-09 Thread Patrizio Bassi

Dear James/all,

I checked /etc/nova/nova.conf in kvm and lxd hypervisor and they look the
same.
Regarding glance section it just contains the same endpoint

[glance]
api_servers = http://10.10.10.95:9292

Following the backtrace it seems it cannot get the image metadata at all. I
checked the upstream source at
https://github.com/openstack/nova-lxd/blob/master/nova/virt/lxd/driver.py#L398

has changed the galnce-lxd sync code. Maybe it has been fixed already, did
anyone try? do we have a bleeding edge ppa to test against?

Patrizio


2017-05-08 18:21 GMT+02:00 Patrizio Bassi <patrizio.ba...@gmail.com>:

>
>
> 2017-05-08 18:11 GMT+02:00 James Page <james.p...@ubuntu.com>:
>
>> Hi Patrizio
>>
>> On Mon, 8 May 2017 at 11:53 Patrizio Bassi <patrizio.ba...@gmail.com>
>> wrote:
>> [...]
>>
>>> 1) [minor] accessing horizon in the hypervisor list it is seen as
>>> hostname without fqdn while other 4 hosts has fqdn.
>>>
>>
>> Yes there is a minor diff between LXD and KVM hypervisors:
>>
>>   https://bugs.launchpad.net/nova-lxd/+bug/1521319
>>
>> however that should not effect things functionally.
>>
>
> Yes, it looks fine, but a bit ugly :)
>
>
>>
>>
>>> 2) [major] i cannot boot a lxd image
>>>
>>> following https://jujucharms.com/u/openstack-charmers-next/o
>>> penstack-lxd/ i imported the xenial image in glance by
>>>
>>> # glance image-create --name="xenial_lxd" --visibility public --progress
>>> --container-format=bare --disk-format=*root-tar* --property
>>> architecture="x86_64" < ~/openstack/images/xenial-serv
>>> er-cloudimg-amd64-root.tar.gz
>>>
>>> i got errors like:
>>>
>>> 8446f64e0b504345b48673a3e3a328f1 35515180b8b646329e2caa2372250e0b - -
>>> -] [instance: e4daef69-525c-4413-b39b-7df5e7822f02] Build of instance
>>> e4daef69-525c-4413-b39b-7df5e7822f02 aborted: *Image  is unacceptable:
>>> Bad Image format: Image  could not be found.*
>>>
>>> in https://linuxcontainers.org//lxd/getting-started-openstack/ instead
>>> i see it suggests *--disk-format=raw* but actually nothing changes for
>>> me, same error.
>>>
>>
>> The disk-format property for LXD images can be raw or root-tar - either
>> should work.  That error is propagating up from the interaction of the
>> driver with glance - which might indicate a missing relation between the
>> nova-compute-lxd service and glance?
>>
>>
>
> It looks i have (i just replaced nova-compute with nova-lxd)
>
> # juju status|grep nova|grep glance
> image-serviceglance nova-cloud-controller
>  regular
> image-serviceglance nova-compute
> regular
> image-serviceglance *nova-lxd*
> regular
>
> What else can i check?
>
>
>> I tried with Trusty too, in case xenial image may have been corrupted,
>>> same issue.
>>>
>>> So which format should we use for lxd, root-tar (i do think so) or raw?
>>> And is lxd driver really working?
>>>
>>
>> The root tarball format is the correct format to use.
>>
>
> Ok, fine...even if in https://docs.openstack.org/ima
> ge-guide/image-formats.html or https://docs.openstack.org/
> developer/glance/formats.html i can't find that format
>
>
>
>>
>>> It was reported with a similar issue some months ago:
>>> https://ask.openstack.org/en/question/101255/unable-to-start
>>> -an-instance-using-nova-lxd/
>>>
>>> Another important issue is that lxd hypervisor seems to get scheduled to
>>> run qcow2 images too, failing, but i guess this can be fixed by adding
>>> hostgroup, i din't investigate yet.
>>>
>>
>> Its possible to run both hypervisors in the same region, but you must set
>> the hypervisor type property on all images:
>>
>>   --property hypervisor_type=lxc
>>
>> or
>>
>>   --property hypervisor_type=qemu
>>
>> Setting this value will ensure that when you boot an instance of the
>> image, it gets scheduled to the correct hypervisor type for the image.
>>
>
> This is great, it'll give a try as soon i can boot a lxd image (now i just
> disabled all kvm hypervisors so just a lxd hypervisor is there).
>
>
>>
>> Hope that helps move your forward.
>>
>> James
>>
>
> Thank you for support
> Patrizio
>



-- 

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 deployed openstack nova-lxd cannot start instances

2017-05-08 Thread Patrizio Bassi

2017-05-08 18:11 GMT+02:00 James Page <james.p...@ubuntu.com>:

> Hi Patrizio
>
> On Mon, 8 May 2017 at 11:53 Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
> [...]
>
>> 1) [minor] accessing horizon in the hypervisor list it is seen as
>> hostname without fqdn while other 4 hosts has fqdn.
>>
>
> Yes there is a minor diff between LXD and KVM hypervisors:
>
>   https://bugs.launchpad.net/nova-lxd/+bug/1521319
>
> however that should not effect things functionally.
>

Yes, it looks fine, but a bit ugly :)


>
>
>> 2) [major] i cannot boot a lxd image
>>
>> following https://jujucharms.com/u/openstack-charmers-next/openstack-lxd/
>> i imported the xenial image in glance by
>>
>> # glance image-create --name="xenial_lxd" --visibility public --progress
>> --container-format=bare --disk-format=*root-tar* --property
>> architecture="x86_64" < ~/openstack/images/xenial-serv
>> er-cloudimg-amd64-root.tar.gz
>>
>> i got errors like:
>>
>> 8446f64e0b504345b48673a3e3a328f1 35515180b8b646329e2caa2372250e0b - - -]
>> [instance: e4daef69-525c-4413-b39b-7df5e7822f02] Build of instance
>> e4daef69-525c-4413-b39b-7df5e7822f02 aborted: *Image  is unacceptable:
>> Bad Image format: Image  could not be found.*
>>
>> in https://linuxcontainers.org//lxd/getting-started-openstack/ instead i
>> see it suggests *--disk-format=raw* but actually nothing changes for me,
>> same error.
>>
>
> The disk-format property for LXD images can be raw or root-tar - either
> should work.  That error is propagating up from the interaction of the
> driver with glance - which might indicate a missing relation between the
> nova-compute-lxd service and glance?
>
>

It looks i have (i just replaced nova-compute with nova-lxd)

# juju status|grep nova|grep glance
image-serviceglance nova-cloud-controller
 regular
image-serviceglance nova-compute
regular
image-serviceglance *nova-lxd*
regular

What else can i check?


> I tried with Trusty too, in case xenial image may have been corrupted,
>> same issue.
>>
>> So which format should we use for lxd, root-tar (i do think so) or raw?
>> And is lxd driver really working?
>>
>
> The root tarball format is the correct format to use.
>

Ok, fine...even if in https://docs.openstack.org/
image-guide/image-formats.html or https://docs.openstack.org/
developer/glance/formats.html i can't find that format



>
>> It was reported with a similar issue some months ago:
>> https://ask.openstack.org/en/question/101255/unable-to-start
>> -an-instance-using-nova-lxd/
>>
>> Another important issue is that lxd hypervisor seems to get scheduled to
>> run qcow2 images too, failing, but i guess this can be fixed by adding
>> hostgroup, i din't investigate yet.
>>
>
> Its possible to run both hypervisors in the same region, but you must set
> the hypervisor type property on all images:
>
>   --property hypervisor_type=lxc
>
> or
>
>   --property hypervisor_type=qemu
>
> Setting this value will ensure that when you boot an instance of the
> image, it gets scheduled to the correct hypervisor type for the image.
>

This is great, it'll give a try as soon i can boot a lxd image (now i just
disabled all kvm hypervisors so just a lxd hypervisor is there).


>
> Hope that helps move your forward.
>
> James
>

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

juju deployed openstack nova-lxd cannot start instances

2017-05-08 Thread Patrizio Bassi

Dear All,

I have a blocking error with lxd virt type. I have a juju-deployed
Openstack which can run kvm instances.
I added a new machine, deployed nova-lxd with all the relations it needed
(lxd was deployed with zfs storage)

1) [minor] accessing horizon in the hypervisor list it is seen as hostname
without fqdn while other 4 hosts has fqdn.
2) [major] i cannot boot a lxd image

following https://jujucharms.com/u/openstack-charmers-next/openstack-lxd/ i
imported the xenial image in glance by

# glance image-create --name="xenial_lxd" --visibility public --progress
--container-format=bare --disk-format=*root-tar* --property
architecture="x86_64" <
~/openstack/images/xenial-server-cloudimg-amd64-root.tar.gz

i got errors like:

8446f64e0b504345b48673a3e3a328f1 35515180b8b646329e2caa2372250e0b - - -]
[instance: e4daef69-525c-4413-b39b-7df5e7822f02] Build of instance
e4daef69-525c-4413-b39b-7df5e7822f02 aborted: *Image  is unacceptable: Bad
Image format: Image  could not be found.*

in https://linuxcontainers.org//lxd/getting-started-openstack/ instead i
see it suggests *--disk-format=raw* but actually nothing changes for me,
same error.

I tried with Trusty too, in case xenial image may have been corrupted, same
issue.

So which format should we use for lxd, root-tar (i do think so) or raw? And
is lxd driver really working?

It was reported with a similar issue some months ago:
https://ask.openstack.org/en/question/101255/unable-to-start-an-instance-using-nova-lxd/

Another important issue is that lxd hypervisor seems to get scheduled to
run qcow2 images too, failing, but i guess this can be fixed by adding
hostgroup, i din't investigate yet.

Thank you for your support,
Regards

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

openstack-telemetry blocked: memcached requires ipv6

2017-05-03 Thread Patrizio Bassi

Hi all,

in MAAS i added ipv6.disable = 1 to cmd line params for my machines and
this makes all ceilometer-agent/XXX units to be stuck as blocked due to
"Services not running that should be: memcached"

Logging in a machine i see:
May 03 15:08:22 juju-e46e9f-1-lxd-4 systemd-memcached-wrapper[29361]:
failed to listen on TCP port 11211: Address family not supported by protocol

is it mandatory or can we have a config in the charm to disable ipv6?

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

2017-04-27 Thread Patrizio Bassi

Hi John,

i'm writing you again after long time i didn't check juju deploys for a
while.

Basically the dns-name (what juju status shows in Public address column) is
still wrong

juju show-machine 0
model: openstack
machines:
  "0":
juju-status:
  current: started
  since: 27 Apr 2017 14:06:02Z
  version: 2.1.2
*dns-name: 10.1.12.63*
ip-addresses:
- 10.1.12.63
- 10.1.4.63
- 10.1.8.63
instance-id: ne3nqh
machine-status:
  current: running
  message: Deployed

if i do a reverse lookup of dns name is get
Host 63.12.1.10.in-addr.arpa. not found: 3(NXDOMAIN)

while 10.1.8.63 (the only IP on the space i bind) correctly resolves.
I do think this is a bug.

Juju should
1) validate the ip from maas

"links": [
{
"id": 513753,
"mode": "static",
   * "ip_address": "10.1.8.63",*
"subnet": {
   * "space": "space-management",*
"id": 10,
"rdns_mode": 2,
"allow_proxy": true,


]
while it picks up IPs from other network spaces

2) in case more than 1 ip is found on the same space it should try to do a
reverse dns lookup and pick the one registered. If all resolve, just pick
one.


For containers hosted on the same machine instead i get the right ip
bindings.

Patrizio


2017-03-10 16:55 GMT+01:00 John Meinel <j...@arbash-meinel.com>:

> Bindings can be set explicitly in bundles because each piece of the bundle
> takes different bindings.
>
> mysql:
>   ...
>   bindings:
> "": space
> telemetry:
>   ...
>   bindings:
>"": space
>
> You can't specify deploy bundle with binding because each application is
> likely to be bound differently.
>
> John
> =:->
>
> On Fri, Mar 10, 2017 at 8:28 AM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Hi John,
>>
>> i do agree about ip addresses may be changing from application to
>> application but the ip addresses showed should be the ip juju
>> controller/client may reach the vm/container/bare metal. It should be, if
>> possibile, the machine hostname or the reverse lookup in the dns server, if
>> any.
>>
>> For instance in my case i just have 2 ethernet interfaces, quite simple
>> design: eth0 is the public one, with its hostname in the dns, eth1 is other
>> net with a private one. Why should juju show the private one? Infact it's
>> not working (question is, how do you deploy openstack with juju with more
>> than 1 eth ports?).
>>
>> I tried with a openstack telemetry bundle.  --bind cannot be passed to a
>> bundle so i tried just to add a
>> constraints: spaces=management
>> for all machines described in the bundle, but, as design, it just select
>> a machine that has access to that space, doesn't bind anything
>>
>> Basically all containers fail because of networking.
>>
>>   0/lxd/3:
>> juju-status:
>>   current: pending
>>   since: 10 Mar 2017 10:53:59Z
>> instance-id: pending
>> machine-status:
>>   current: allocating
>>   message: 'failed to start instance (unable to setup network: no
>> obvious
>> space for container "0/lxd/3", host machine has spaces:
>> "management",
>> "private"), retrying in 10s (3 more attempts)'
>>
>> This is blocking everything for me.
>>
>> Patrizio
>>
>>
>>
>> 2017-03-10 14:35 GMT+01:00 John Meinel <j...@arbash-meinel.com>:
>>
>>> The Address reported for the Machine is not necessarily the address that
>>> is given to the applications themselves. You can run more than just 1
>>> application on a machine, so they aren't strictly correlated. The question
>>> is whether when relating that application to another application what
>>> addresses it will share. And I'm pretty sure that is actually accurate.
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Fri, Mar 10, 2017 at 2:41 AM, Patrizio Bassi <
>>> patrizio.ba...@gmail.com> wrote:
>>>
>>>> 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 versio

Re: Juju deploy same application twice, failed "application already exist"

2017-04-21 Thread Patrizio Bassi

Fantastic!

I checked the docs but i didn't find that using different name could allow
multiple instances

I will test  asap to check if i can deal with it.

Thank you!

Patrizio
Il giorno ven 21 apr 2017 alle 16:24 Dmitrii Shcherbakov <
dmitrii.shcherba...@canonical.com> ha scritto:

> Patrizio,
>
> In a bundle:
>
>   nova-compute-kvm:
> charm: cs:xenial/nova-compute
> ...
> options:
> ...
>   virt-type: kvm
>   nova-compute-lxd:
> charm: cs:xenial/nova-compute
> ...
> options:
> ...
>   virt-type: lxd
>
>
> Best Regards,
> Dmitrii Shcherbakov
>
> Field Software Engineer
> IRC (freenode): Dmitrii-Sh
>
> On Fri, Apr 21, 2017 at 5:12 PM, Patrizio Bassi <patrizio.ba...@gmail.com>
> wrote:
>
>> Dear All
>>
>> this conversation led me to an interesting (for me at least!) speculation
>> about nova-compute charm.
>>
>> At the moment the nova-compute charm has "virt-type" param supporting
>> kvm, xen, uml, lxc, qemu, lxd.
>> At the same time we have nova-compute-vmware charm which is an
>> indipendent app.
>>
>> So, in case i may want to have an openstack with kvm and vmware mixed,
>> juju allows it (just talking about juju, not considering openstack
>> opportunity to have them really working).
>>
>> What if i want to have two nova-compute installations, one unit with kvm
>> and one with lxd? As far i know we cannot.
>> So it would be nice to add a feature such as:
>>
>> juju deploy  which defaults the deployed app to charm name
>> juju deploy  -name 
>>
>> so all units will be in mycustomname/00XXX format, we kee the original
>> charm reference (for upgrades for instance) and we can use multiple
>> configurations under a different "umbrella"
>>
>> ie.
>> nova-compute/0 (with default kvm)
>> nova-compute/1 (with default kvm)
>> nova-compute/2 (with default kvm)
>> mynova-compute/0 (with lxd)
>> mynova-compute/1 (with lxd)
>> mynova-compute/2 (with lxd)
>>
>> regards,
>> Patrizio
>>
>>
>> 2017-04-21 9:55 GMT+02:00 Mark Shuttleworth <m...@ubuntu.com>:
>>
>>> On 20/04/17 13:36, fengxia wrote:
>>> >
>>> > I c. So I should have used add-unit command instead of "deploy". Is
>>> > that right?
>>> >
>>>
>>> Yup :)
>>>
>>> --
>>> 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
>>
>> --
>> 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
-- 
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

2017-03-10 Thread Patrizio Bassi

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 

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 

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

Re: juju 2.0.2 picking a random ip address from maas

2017-03-09 Thread 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" <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 , 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.
>>>
>>>

Re: juju 2.0.2 picking a random ip address from maas

2017-03-09 Thread 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 <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 , 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 usi

Re: juju 2.0.2 picking a random ip address from maas

2017-03-09 Thread 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 <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/
> 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 <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

Re: juju 2.0.2 picking a random ip address from maas

2017-03-09 Thread Patrizio Bassi

Hi All,

after some debugging i found in juju
<https://github.com/juju/juju/tree/eb98521dc187927bebe390e0172136033f80487e/cmd/juju>
/application
<https://github.com/juju/juju/tree/eb98521dc187927bebe390e0172136033f80487e/cmd/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 <patrizio.ba...@gmail.com>:

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

Re: juju 2.0.2 picking a random ip address from maas

2017-03-08 Thread 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 <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 a

Re: juju 2.0.2 picking a random ip address from maas

2017-03-08 Thread 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 <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
-- 
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

2017-03-08 Thread 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 <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
-- 
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

2017-03-08 Thread 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

Re: using the new bundle features in Juju 2.2.3

Re: designate-charm/designate-sink patch backport request

Re: designate-charm/designate-sink patch backport request

Re: juju application stuck, cannot remove/scale out

Re: juju application stuck, cannot remove/scale out

Re: juju application stuck, cannot remove/scale out

juju application stuck, cannot remove/scale out

Re: juju bug (?) when allocating floating ips to machines

juju bug (?) when allocating floating ips to machines

Re: CephFS Backend for Hadoop

Re: CephFS Backend for Hadoop

Re: call for testing: relations across Juju models

designate-charm/designate-sink patch backport request

Re: is Hdp bundle still maintained/supported?

Re: multi model/cloud deploy (how to deploy kubernates-workers in multitenant openstack)

Re: is Hdp bundle still maintained/supported?

multi model/cloud deploy (how to deploy kubernates-workers in multitenant openstack)

Re: Call for testers: preview of persistent storage support

Re: ceph-* openstack charms force ntp installation and configuration

ceph-* openstack charms force ntp installation and configuration

Re: juju deployed openstack nova-lxd cannot start instances

Re: juju deployed openstack nova-lxd cannot start instances

Re: juju deployed openstack nova-lxd cannot start instances

juju deployed openstack nova-lxd cannot start instances

openstack-telemetry blocked: memcached requires ipv6

Re: juju 2.0.2 picking a random ip address from maas

Re: Juju deploy same application twice, failed "application already exist"

Re: juju 2.0.2 picking a random ip address from maas

Re: juju 2.0.2 picking a random ip address from maas

Re: juju 2.0.2 picking a random ip address from maas

Re: juju 2.0.2 picking a random ip address from maas

Re: juju 2.0.2 picking a random ip address from maas

Re: juju 2.0.2 picking a random ip address from maas

Re: juju 2.0.2 picking a random ip address from maas

Re: juju 2.0.2 picking a random ip address from maas

juju 2.0.2 picking a random ip address from maas

36 matches

Site Navigation

Mail list logo

Footer information