Re: [Openstack] [neutron][devstack] Issue with Neutron L3 extension and flat provider network.

[Michael Turek]

We actually already explicitly in our localrc

IP_VERSION=4

Thanks for the suggestion though!

On 06/08/2016 11:11 AM, Jens Rosenboom wrote:

2016-06-08 16:49 GMT+02:00 Michael Turek :

Hey all,

We have a CI setup that uses a single flat provider network.

Originally devstack would create a network here
(https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/services/l3#L144)
and we were good to go.

However, recently we started also hitting this net-create
(https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/services/l3#L201).
This fails as we do not have a tenant available for the second network.
Specific error is 'Unable to create the network. No tenant network is
available for allocation.'.

This started happening after this merged
https://review.openstack.org/#/c/318145

Originally this second net-create wouldn't happen as we explicitly disabled
L3 via the Q_L3_ENABLED=False option. I'm wondering what the proper way to
skip this block of code now is. I'm guessing we need to disable the router
extension, but I'm not quite sure how to do that in devstack.

Does anyone have any insight? Any help is appreciated, thanks!

Might be similar to what triggered
https://review.openstack.org/#/c/326638/ , so in that case you would
want to
change your setup to v4-only.




___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [neutron][devstack] Issue with Neutron L3 extension and flat provider network.

[Michael Turek]

Should also mention that upon closer inspection 'Q_L3_ENABLED' isn't in 
use by devstack anymore. That being said, q-l3 is not in our list of 
enabled services.


On 06/08/2016 11:20 AM, Michael Turek wrote:

We actually already explicitly in our localrc

IP_VERSION=4

Thanks for the suggestion though!

On 06/08/2016 11:11 AM, Jens Rosenboom wrote:

2016-06-08 16:49 GMT+02:00 Michael Turek :

Hey all,

We have a CI setup that uses a single flat provider network.

Originally devstack would create a network here
(https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/services/l3#L144) 


and we were good to go.

However, recently we started also hitting this net-create
(https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/services/l3#L201). 


This fails as we do not have a tenant available for the second network.
Specific error is 'Unable to create the network. No tenant network is
available for allocation.'.

This started happening after this merged
https://review.openstack.org/#/c/318145

Originally this second net-create wouldn't happen as we explicitly 
disabled
L3 via the Q_L3_ENABLED=False option. I'm wondering what the proper 
way to
skip this block of code now is. I'm guessing we need to disable the 
router

extension, but I'm not quite sure how to do that in devstack.

Does anyone have any insight? Any help is appreciated, thanks!

Might be similar to what triggered
https://review.openstack.org/#/c/326638/ , so in that case you would
want to
change your setup to v4-only.






___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] retrieve all instances whatever tenant/user via python SDK

[Remo Mattei]

Did you try the nova list --all-t

Ciao

Inviato da iPhone

> Il giorno 08 giu 2016, alle ore 06:20, Jean-Pierre Ribeauville 
>  ha scritto:
> 
> Hi all,
>  
> By running this piece if code :
>  
> ………
> def get_nova_credentials_v2():
> d = {}
> d['version'] = '2'
> d['username'] = os.environ['OS_USERNAME']
> d['api_key'] = os.environ['OS_PASSWORD']
> d['auth_url'] = os.environ['OS_AUTH_URL']
> d['project_id'] = os.environ['OS_TENANT_NAME']
> return d
>  
> credentials = get_nova_credentials_v2()
> nova_client = Client(**credentials)
>  
> print(nova_client.servers.list())
> ……
>  
> I’m able to retrieve the instances list when specifying the tenant and 
> username to whom the instances « belong ».
>  
> As I want to retrieve all instances , I tried to use admin as tenant and user 
> , then no instance are found ( all my instances are under “demo”).
>  
> Via Horizon , all instances are retrievable under admin .
>  
> Did I miss something  ?
>  
> Thx for help.
>  
> Regards,
>  
> Jean-Pierre RIBEAUVILLE
>  
> +33 1 4717 2049
>  
> 
>  
> !DSPAM:1,57581db3283461494078773!
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> !DSPAM:1,57581db3283461494078773!
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] retrieve all instances whatever tenant/user via python SDK

[Jean-Pierre Ribeauville]

Hi,


Following this link 
(https://ask.openstack.org/en/question/50087/list-all-servers-with-python-nova-client/
 ),
I found the solution :

for server in nova_client.servers.list(search_opts={'all_tenants': 1}):
print server.id, server.name


Thx to all.

Regards,

J.P.
From: Jean-Pierre Ribeauville
Sent: mercredi 8 juin 2016 17:24
To: 'Remo Mattei'
Cc: openstack@lists.openstack.org
Subject: RE: [Openstack] retrieve all instances whatever tenant/user via python 
SDK

Hi,

nova list --all-t  works fine ( with “admin”  environment variables).

So it means that , within the python code,   I have to find a way to issue same 
request  , i.e.  by specifying “all tenant” parameter.

For sure , I want ( if possible)  to avoid to issue a request for every tenant 
!!

Any idea is welcome.

Thx for help.
Grazie mille.

J.P.

From: Remo Mattei [mailto:r...@italy1.com]
Sent: mercredi 8 juin 2016 17:07
To: Jean-Pierre Ribeauville
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] retrieve all instances whatever tenant/user via python 
SDK

Did you try the nova list --all-t

Ciao

Inviato da iPhone

Il giorno 08 giu 2016, alle ore 06:20, Jean-Pierre Ribeauville 
> ha scritto:
Hi all,

By running this piece if code :

………
def get_nova_credentials_v2():
d = {}
d['version'] = '2'
d['username'] = os.environ['OS_USERNAME']
d['api_key'] = os.environ['OS_PASSWORD']
d['auth_url'] = os.environ['OS_AUTH_URL']
d['project_id'] = os.environ['OS_TENANT_NAME']
return d

credentials = get_nova_credentials_v2()
nova_client = Client(**credentials)

print(nova_client.servers.list())
……

I’m able to retrieve the instances list when specifying the tenant and username 
to whom the instances « belong ».

As I want to retrieve all instances , I tried to use admin as tenant and user , 
then no instance are found ( all my instances are under “demo”).

Via Horizon , all instances are retrievable under admin .

Did I miss something  ?

Thx for help.

Regards,

Jean-Pierre RIBEAUVILLE

+33 1 4717 2049



!DSPAM:1,57581db3283461494078773!
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


!DSPAM:1,57581db3283461494078773!
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [neutron][devstack] Issue with Neutron L3 extension and flat provider network.

[Michael Turek]

Hey all,

We have a CI setup that uses a single flat provider network.

Originally devstack would create a network here 
(https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/services/l3#L144) 
and we were good to go.


However, recently we started also hitting this net-create 
(https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/services/l3#L201). 
This fails as we do not have a tenant available for the second network. 
Specific error is 'Unable to create the network. No tenant network is 
available for allocation.'.


This started happening after this merged 
https://review.openstack.org/#/c/318145


Originally this second net-create wouldn't happen as we explicitly 
disabled L3 via the Q_L3_ENABLED=False option. I'm wondering what the 
proper way to skip this block of code now is. I'm guessing we need to 
disable the router extension, but I'm not quite sure how to do that in 
devstack.


Does anyone have any insight? Any help is appreciated, thanks!

-Mike


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] retrieve all instances whatever tenant/user via python SDK

[Leslie-Alexandre DENIS]

The simplest thing to do is to pass --debug to the nova or openstack cli list 
command and catch the argument from the curl URL.

The other way is to check the Nova API documentation and the SDK too.

See you.

On June 8, 2016 5:24:14 PM CEST, Jean-Pierre Ribeauville 
 wrote:
>Hi,
>
>nova list --all-t  works fine ( with “admin”  environment variables).
>
>So it means that , within the python code,   I have to find a way to
>issue same request  , i.e.  by specifying “all tenant” parameter.
>
>For sure , I want ( if possible)  to avoid to issue a request for every
>tenant !!
>
>Any idea is welcome.
>
>Thx for help.
>Grazie mille.
>
>J.P.
>
>From: Remo Mattei [mailto:r...@italy1.com]
>Sent: mercredi 8 juin 2016 17:07
>To: Jean-Pierre Ribeauville
>Cc: openstack@lists.openstack.org
>Subject: Re: [Openstack] retrieve all instances whatever tenant/user
>via python SDK
>
>Did you try the nova list --all-t
>
>Ciao
>
>Inviato da iPhone
>
>Il giorno 08 giu 2016, alle ore 06:20, Jean-Pierre Ribeauville
>> ha scritto:
>Hi all,
>
>By running this piece if code :
>
>………
>def get_nova_credentials_v2():
>d = {}
>d['version'] = '2'
>d['username'] = os.environ['OS_USERNAME']
>d['api_key'] = os.environ['OS_PASSWORD']
>d['auth_url'] = os.environ['OS_AUTH_URL']
>d['project_id'] = os.environ['OS_TENANT_NAME']
>return d
>
>credentials = get_nova_credentials_v2()
>nova_client = Client(**credentials)
>
>print(nova_client.servers.list())
>……
>
>I’m able to retrieve the instances list when specifying the tenant and
>username to whom the instances « belong ».
>
>As I want to retrieve all instances , I tried to use admin as tenant
>and user , then no instance are found ( all my instances are under
>“demo”).
>
>Via Horizon , all instances are retrievable under admin .
>
>Did I miss something  ?
>
>Thx for help.
>
>Regards,
>
>Jean-Pierre RIBEAUVILLE
>
>+33 1 4717 2049
>
>
>
>!DSPAM:1,57581db3283461494078773!
>___
>Mailing list:
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>Post to :
>openstack@lists.openstack.org
>Unsubscribe :
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
>!DSPAM:1,57581db3283461494078773!
>
>
>
>
>___
>Mailing list:
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>Post to : openstack@lists.openstack.org
>Unsubscribe :
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [oslo] Issues with pbr when building custom packages

[Sam Morrison]

> On 9 Jun 2016, at 8:16 AM, Sam Morrison  wrote:
> 
> 
> 
>> On 8 Jun 2016, at 10:51 PM, Doug Hellmann  wrote:
>> 
>> Excerpts from Sam Morrison's message of 2016-06-08 16:59:37 +1000:
>>> We have been building our own packages for a few years now and I’ve just 
>>> started to build packages for liberty.
>>> 
>>> I got an error from pbr telling me my version was incompatible. An example 
>>> version we were producing was 12.0.3+a74~gea340da+trusty
>>> 
>>> So had a read of http://docs.openstack.org/developer/pbr/semver.html 
>>>  and have fixed it to 
>>> be this format however I’m still getting an error:
>>> 
>>> Exception occurred:
>>> File "/usr/lib/python2.7/dist-packages/pbr/version.py", line 215, in 
>>> from_pip_string
>>>   % (remainder, version_string))
>>> ValueError: Unknown remainder ['gea340da'] in '12.0.3.a74.gea340da'
>>> 
>>> From the website mentioned above this seems like it should be valid. I’ve 
>>> had a look in the code and it looks like this type of version isn’t 
>>> supported.
>>> 
>>> So is this a bug in pbr or am I doing something wrong? We build packages 
>>> based on git versions so I want to keep the hash in there.
>>> 
>>> Thanks,
>>> Sam
>> 
>> This is working as designed. pbr follows PEP-440 [1] versioning,
>> which IIRC doesn't include version control references like git SHAs.
>> 
>> The version you describe appears to be the 74th alpha pre-release of
>> 12.0.3. Is that what you intend? That's a lot of pre-releases.
>> 
>> pbr will automatically append a numbered dev suffix to versions,
>> so the 74th commit after 12.0.3 would be something like 12.0.4.dev74,
>> indicating that it is a development version leading to 12.0.4.
>> 
>> Which project are you packaging, and in what context?
> 
> Thanks Doug,
> 
> So is that openstack document wrong?
> 
> I'm packaging nova, we have a bunch of custom commits and extra back ports in 
> our version. Having the git hash in there is extremely helpful and I also 
> don't want to conflict with the official openstack release. 
> I don't care really what the version number is as long as when I add a new 
> commit the version number increases. 
> 
> Having a look at that document I think I should do something like 
> 
> 12.0.3.post74+gea340da
> 

OK this isn’t accepted either, I get the following error:

Exception occurred:
  File "/usr/lib/python2.7/dist-packages/pbr/version.py", line 211, in 
from_pip_string
post_count = int(component[4:])
ValueError: invalid literal for int() with base 10: '74+gea340da’

In pep 440 under semantic versioning it states: 

"Specific build information may also be included in local version labels.”

And

"Local version identifiers MUST comply with the following scheme: [+]"


Am I doing something wrong here?




> Any ideas? 
> 
> Thanks,
> Sam
> 
> 
> 
>> 
>> Doug
>> 
>> [1] https://www.python.org/dev/peps/pep-0440/
>> 
>> ___
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [oslo] Issues with pbr when building custom packages

[Doug Hellmann]

Excerpts from Sam Morrison's message of 2016-06-09 08:16:11 +1000:
> 
> > On 8 Jun 2016, at 10:51 PM, Doug Hellmann  wrote:
> > 
> > Excerpts from Sam Morrison's message of 2016-06-08 16:59:37 +1000:
> >> We have been building our own packages for a few years now and I’ve just 
> >> started to build packages for liberty.
> >> 
> >> I got an error from pbr telling me my version was incompatible. An example 
> >> version we were producing was 12.0.3+a74~gea340da+trusty
> >> 
> >> So had a read of http://docs.openstack.org/developer/pbr/semver.html 
> >>  and have fixed it to 
> >> be this format however I’m still getting an error:
> >> 
> >> Exception occurred:
> >>  File "/usr/lib/python2.7/dist-packages/pbr/version.py", line 215, in 
> >> from_pip_string
> >>% (remainder, version_string))
> >> ValueError: Unknown remainder ['gea340da'] in '12.0.3.a74.gea340da'
> >> 
> >> From the website mentioned above this seems like it should be valid. I’ve 
> >> had a look in the code and it looks like this type of version isn’t 
> >> supported.
> >> 
> >> So is this a bug in pbr or am I doing something wrong? We build packages 
> >> based on git versions so I want to keep the hash in there.
> >> 
> >> Thanks,
> >> Sam
> > 
> > This is working as designed. pbr follows PEP-440 [1] versioning,
> > which IIRC doesn't include version control references like git SHAs.
> > 
> > The version you describe appears to be the 74th alpha pre-release of
> > 12.0.3. Is that what you intend? That's a lot of pre-releases.
> > 
> > pbr will automatically append a numbered dev suffix to versions,
> > so the 74th commit after 12.0.3 would be something like 12.0.4.dev74,
> > indicating that it is a development version leading to 12.0.4.
> > 
> > Which project are you packaging, and in what context?
> 
> Thanks Doug,
> 
> So is that openstack document wrong?

> I'm packaging nova, we have a bunch of custom commits and extra back ports in 
> our version. Having the git hash in there is extremely helpful and I also 
> don't want to conflict with the official openstack release. 
> I don't care really what the version number is as long as when I add a new 
> commit the version number increases. 
> 
> Having a look at that document I think I should do something like 
> 
> 12.0.3.post74+gea340da

According to the comments in pbr/version.py it looks like you want

  12.0.3.74.gea340da

I've added a patch with a test that shows that works, as well as a fix
for the syntax including the "post" in https://review.openstack.org/327424

If you're doing your own packaging, how are you feeding the version
number into pbr? Via the environment variable?

Doug

> 
> Any ideas? 
> 
> Thanks,
> Sam
> 
> > 
> > Doug
> > 
> > [1] https://www.python.org/dev/peps/pep-0440/
> > 
> > ___
> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [oslo] Issues with pbr when building custom packages

[Sam Morrison]

> On 8 Jun 2016, at 10:51 PM, Doug Hellmann  wrote:
> 
> Excerpts from Sam Morrison's message of 2016-06-08 16:59:37 +1000:
>> We have been building our own packages for a few years now and I’ve just 
>> started to build packages for liberty.
>> 
>> I got an error from pbr telling me my version was incompatible. An example 
>> version we were producing was 12.0.3+a74~gea340da+trusty
>> 
>> So had a read of http://docs.openstack.org/developer/pbr/semver.html 
>>  and have fixed it to 
>> be this format however I’m still getting an error:
>> 
>> Exception occurred:
>>  File "/usr/lib/python2.7/dist-packages/pbr/version.py", line 215, in 
>> from_pip_string
>>% (remainder, version_string))
>> ValueError: Unknown remainder ['gea340da'] in '12.0.3.a74.gea340da'
>> 
>> From the website mentioned above this seems like it should be valid. I’ve 
>> had a look in the code and it looks like this type of version isn’t 
>> supported.
>> 
>> So is this a bug in pbr or am I doing something wrong? We build packages 
>> based on git versions so I want to keep the hash in there.
>> 
>> Thanks,
>> Sam
> 
> This is working as designed. pbr follows PEP-440 [1] versioning,
> which IIRC doesn't include version control references like git SHAs.
> 
> The version you describe appears to be the 74th alpha pre-release of
> 12.0.3. Is that what you intend? That's a lot of pre-releases.
> 
> pbr will automatically append a numbered dev suffix to versions,
> so the 74th commit after 12.0.3 would be something like 12.0.4.dev74,
> indicating that it is a development version leading to 12.0.4.
> 
> Which project are you packaging, and in what context?

Thanks Doug,

So is that openstack document wrong?

I'm packaging nova, we have a bunch of custom commits and extra back ports in 
our version. Having the git hash in there is extremely helpful and I also don't 
want to conflict with the official openstack release. 
I don't care really what the version number is as long as when I add a new 
commit the version number increases. 

Having a look at that document I think I should do something like 

12.0.3.post74+gea340da

Any ideas? 

Thanks,
Sam



> 
> Doug
> 
> [1] https://www.python.org/dev/peps/pep-0440/
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [oslo] Issues with pbr when building custom packages

[Doug Hellmann]

Excerpts from Sam Morrison's message of 2016-06-08 16:59:37 +1000:
> We have been building our own packages for a few years now and I’ve just 
> started to build packages for liberty.
> 
> I got an error from pbr telling me my version was incompatible. An example 
> version we were producing was 12.0.3+a74~gea340da+trusty
> 
>  So had a read of http://docs.openstack.org/developer/pbr/semver.html 
>  and have fixed it to be 
> this format however I’m still getting an error:
> 
> Exception occurred:
>   File "/usr/lib/python2.7/dist-packages/pbr/version.py", line 215, in 
> from_pip_string
> % (remainder, version_string))
> ValueError: Unknown remainder ['gea340da'] in '12.0.3.a74.gea340da'
> 
> From the website mentioned above this seems like it should be valid. I’ve had 
> a look in the code and it looks like this type of version isn’t supported.
> 
> So is this a bug in pbr or am I doing something wrong? We build packages 
> based on git versions so I want to keep the hash in there.
> 
> Thanks,
> Sam

This is working as designed. pbr follows PEP-440 [1] versioning,
which IIRC doesn't include version control references like git SHAs.

The version you describe appears to be the 74th alpha pre-release of
12.0.3. Is that what you intend? That's a lot of pre-releases.

pbr will automatically append a numbered dev suffix to versions,
so the 74th commit after 12.0.3 would be something like 12.0.4.dev74,
indicating that it is a development version leading to 12.0.4.

Which project are you packaging, and in what context?

Doug

[1] https://www.python.org/dev/peps/pep-0440/

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] retrieve all instances whatever tenant/user via python SDK

[Jean-Pierre Ribeauville]

Hi all,

By running this piece if code :

.
def get_nova_credentials_v2():
d = {}
d['version'] = '2'
d['username'] = os.environ['OS_USERNAME']
d['api_key'] = os.environ['OS_PASSWORD']
d['auth_url'] = os.environ['OS_AUTH_URL']
d['project_id'] = os.environ['OS_TENANT_NAME']
return d

credentials = get_nova_credentials_v2()
nova_client = Client(**credentials)

print(nova_client.servers.list())
..

I'm able to retrieve the instances list when specifying the tenant and username 
to whom the instances < belong >.

As I want to retrieve all instances , I tried to use admin as tenant and user , 
then no instance are found ( all my instances are under "demo").

Via Horizon , all instances are retrievable under admin .

Did I miss something  ?

Thx for help.

Regards,

Jean-Pierre RIBEAUVILLE

+33 1 4717 2049

[axway_logo_tagline_87px]

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Swift] 404 re-reading just created container

[Mark Kirkwood]

On 08/06/16 19:07, Mark Kirkwood wrote:


changing this servers line to include the other proxy's memcache too 
(e.g proxy 192.168.122.21 again):


$ cat /etc/swift/proxy-server.conf
...
[filter:cache]
use = egg:swift#memcache
memcache_servers = 192.168.122.21:11211,192.168.122.24:11211

I no longer see any 404s with my test. Reading the install docs (a bit 
more carefully this time it seems), I see that they are leaning us 
towards doing that - am I understanding that correctly?




A completely different approach is to remove the 'cache' entry from the 
proxy pipeline. Obviously this is not ideal from a 
performance/scalability point of view, but we currently have a very 
small object storage archive so - for now - performance is not that 
critical. It will be later for sure, but that gives us time to plan for 
(centralized etc) memcache resources that Swift can be easily amended to 
use. Thoughts - is it crazy to switch off caching?


regards

Mark

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Nova and Magnum on the same host?

[Turbo Fredriksson]

My use-case require me to have Containers for certain rings
and real VMs for others.

But I also want to utilize my hardware to max, while keeping
the electricity bill (and cooling) as low as possible. This
means that I need (want!) to run both the VMs and the Containers
on the same host.

I've just started with Openstack, so I have _many_ questions,
and this is the first one: Can I run both Nova (full VMs) and
Magnum (Containers) on the same physical host?

As in, will Openstack realize that the physical host is full
(with mixed VMs and Containers) so that it will start filling
the next physical machine? Because I'm assuming that's what it
does, realize that there's no more "space" (resources) left
on the host and know that it can't put any new instance on there,
but need to start filling another one.

Or does it just throw the instances out randomly on physical
nodes?
--
As soon as you find a product that you really like,
they will stop making it.
- Wilson's Law


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Datas exchange between an instance and its compute Node ?

[Jean-Pierre Ribeauville]

Hi,

Is there any recommended  way to exchange datas  (i.e  128 bytes every 20 
seconds) between an instance and its compute node  ?

On RHEV  infra,  I'm using a channel device ; it seems quite impossible to use 
the same way on OpenStack.
(I didn't find a way to create the virtio controller and  the channel device 
before launching the instance)

Thx for help.

Regards,

Jean-Pierre RIBEAUVILLE

+33 1 4717 2049

[axway_logo_tagline_87px]

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] ConnectFailure error upon triggering “nova image-list” command using openstack-mitaka release

[Chinmaya Dwibedy]

Hi ,


I am getting the ConnectFailure error message upon triggering “nova
image-list” command. nova-api process should be listening on 8774. It
doesn't look like it is not running. Also I do not find any error logs in
nova-api.log nova-compute.log and nova-conductor.log. I am using openstack-
mitaka release on host (Cent OS 7.2). How can I debug and know what
prevents it from running ? please suggest.


Note: This was working while back and got this issue all of a sudden.


Here are some logs.


[root@localhost ~(keystone_admin)]# nova image-list

ERROR (ConnectFailure): Unable to establish connection to
http://172.18.121.48:8774/v2/4bc608763cee41d9a8df26d3ef919825

[root@localhost ~(keystone_admin)]#



[root@localhost ~(keystone_admin)]# service openstack-nova-api restart

Redirecting to /bin/systemctl restart  openstack-nova-api.service

Job for openstack-nova-api.service failed because the control process
exited with error code. See "systemctl status openstack-nova-api.service"
and "journalctl -xe" for details.

[root@localhost ~(keystone_admin)]# systemctl status
openstack-nova-api.service

â openstack-nova-api.service - OpenStack Nova API Server

   Loaded: loaded (/usr/lib/systemd/system/openstack-nova-api.service;
enabled; vendor preset: disabled)

   Active: activating (start) since Wed 2016-06-08 07:59:20 EDT; 2s ago

 Main PID: 179955 (nova-api)

   CGroup: /system.slice/openstack-nova-api.service

   ââ179955 /usr/bin/python2 /usr/bin/nova-api



Jun 08 07:59:20 localhost systemd[1]: Starting OpenStack Nova API Server...

Jun 08 07:59:22 localhost python2[179955]: detected unhandled Python
exception in '/usr/bin/nova-api'

[root@localhost ~(keystone_admin)]#



[root@localhost ~(keystone_admin)]#  keystone endpoint-list

/usr/lib/python2.7/site-packages/keystoneclient/shell.py:64:
DeprecationWarning: The keystone CLI is deprecated in favor of
python-openstackclient. For a Python library, continue using
python-keystoneclient.

  'python-keystoneclient.', DeprecationWarning)

/usr/lib/python2.7/site-packages/keystoneclient/v2_0/client.py:145:
DeprecationWarning: Constructing an instance of the
keystoneclient.v2_0.client.Client class without a session is deprecated as
of the 1.7.0 release and may be removed in the 2.0.0 release.

  'the 2.0.0 release.', DeprecationWarning)

/usr/lib/python2.7/site-packages/keystoneclient/v2_0/client.py:147:
DeprecationWarning: Using the 'tenant_name' argument is deprecated in
version '1.7.0' and will be removed in version '2.0.0', please use the
'project_name' argument instead

  super(Client, self).__init__(**kwargs)

/usr/lib/python2.7/site-packages/debtcollector/renames.py:45:
DeprecationWarning: Using the 'tenant_id' argument is deprecated in version
'1.7.0' and will be removed in version '2.0.0', please use the 'project_id'
argument instead

  return f(*args, **kwargs)

/usr/lib/python2.7/site-packages/keystoneclient/httpclient.py:371:
DeprecationWarning: Constructing an HTTPClient instance without using a
session is deprecated as of the 1.7.0 release and may be removed in the
2.0.0 release.

  'the 2.0.0 release.', DeprecationWarning)

/usr/lib/python2.7/site-packages/keystoneclient/session.py:140:
DeprecationWarning: keystoneclient.session.Session is deprecated as of the
2.1.0 release in favor of keystoneauth1.session.Session. It will be removed
in future releases.

  DeprecationWarning)

/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/base.py:56:
DeprecationWarning: keystoneclient auth plugins are deprecated as of the
2.1.0 release in favor of keystoneauth1 plugins. They will be removed in
future releases.

  'in future releases.', DeprecationWarning)

+--+---+-+-+-+--+

|id|   region  |
publicurl|
internalurl   |
adminurl|service_id|

+--+---+-+-+-+--+

| 02fcec9a7b834128b3e30403c4ed0de7 | RegionOne |
http://172.18.121.48:8080/v1/AUTH_%(tenant_id)s |
http://172.18.121.48:8080/v1/AUTH_%(tenant_id)s |
http://172.18.121.48:8080/v1/AUTH_%(tenant_id)s |
5533324a63d8402888040832640a19d0 |

| 295802909413422cb7c22dc1e268bce9 | RegionOne |
http://172.18.121.48:8774/v2/%(tenant_id)s   |
http://172.18.121.48:8774/v2/%(tenant_id)s   |
http://172.18.121.48:8774/v2/%(tenant_id)s   |
f7fe68bf4cec47a4a3c942f3916dc377 |

| 2a125f10b0d04f8a9306dede85b65514 | RegionOne |
http://172.18.121.48:9696|
http://172.18.121.48:9696
|http://172.18.121.48:9696|

Re: [Openstack] [Swift] 404 re-reading just created container

[Mark Kirkwood]

On 08/06/16 10:50, Mark Kirkwood wrote:

On 08/06/16 07:06, Pete Zaitcev wrote:


The proxies are load balanced behind Haproxy (which I'm guessing is
causing the 404 - see below)

HAproxy is often troublesome, but I don't expect it is at fault in
this instance. The logs that you quoted show that the proxy-server
returned the 404. Do proxies happen to talk to separate memcached
instances by any chance?


Yeah - good point, each proxy has its own memcache.



Following up this point,

I can reproduce this issue by putting haproxy in front of some 
development proxies I have running as VMs on my workstation (easier to 
amend config in this case):


So I have 2 Swift proxies, each using itself as a memcache server (e.g 
proxy 192.168.122.21), other one (192.168.122.24) defined similarly:


$ cat /etc/swift/proxy-server.conf
...
[filter:cache]
use = egg:swift#memcache
memcache_servers = 192.168.122.21:11211

changing this servers line to include the other proxy's memcache too 
(e.g proxy 192.168.122.21 again):


$ cat /etc/swift/proxy-server.conf
...
[filter:cache]
use = egg:swift#memcache
memcache_servers = 192.168.122.21:11211,192.168.122.24:11211

I no longer see any 404s with my test. Reading the install docs (a bit 
more carefully this time it seems), I see that they are leaning us 
towards doing that - am I understanding that correctly?


regards

Mark





___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Issue with dev_type: type-PCI using openstack-mitaka release on host (Cent OS 7.2)

[Moshe Levi]

From: Chinmaya Dwibedy [mailto:ckdwib...@gmail.com]
Sent: Wednesday, June 08, 2016 8:39 AM
To: Moshe Levi 
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] Issue with dev_type: type-PCI using openstack-mitaka 
release on host (Cent OS 7.2)

Hi Moshe,

Thank you for the clarification. I want to passthrough PCI device . Thus  I 
have configured the “device_type”: “type-PCI” in nova.conf. But  it shows 
“dev_type: type-PF” in MariaDB and nova.compute log. I think it should show 
“dev_type: type-PCI”. Am I missing anything ?
This will do what you called passthrough you PCI device is just indicated that 
your PCI has is actually Physical Function (you are passing (Ethernet 
controller) )
So Libvirt will do this:

  

  


Regards,
Chinmaya

On Wed, Jun 8, 2016 at 10:58 AM, Moshe Levi 
> wrote:


From: Chinmaya Dwibedy [mailto:ckdwib...@gmail.com]
Sent: Wednesday, June 08, 2016 7:43 AM
To: openstack@lists.openstack.org
Subject: [Openstack] Issue with dev_type: type-PCI using openstack-mitaka 
release on host (Cent OS 7.2)

Hi All,

I want the Ethernet Card to be used for PCI Passthrough device. Note that, I 
have installed openstack-mitaka release on host (Cent OS 7.2).

[root@localhost ~(keystone_admin)]# lspci -nn | grep 154d
07:00.0 Ethernet controller [0200]: Intel Corporation Ethernet 10G 2P X520 
Adapter [8086:154d] (rev 01)
07:00.1 Ethernet controller [0200]: Intel Corporation Ethernet 10G 2P X520 
Adapter [8086:154d] (rev 01)
[root@localhost ~(keystone_admin)]#

Here goes the configurations done in nova.conf

pci_alias={"vendor_id":"8086", "product_id":"154d", "device_type":"type-PCI", 
"name":"a1"}
pci_passthrough_whitelist =  [{"vendor_id":"8086","product_id":"154d"}]
scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter,PciPassthroughFilter



MariaDB [nova]> select pci_stats from compute_nodes;
+---+
| pci_stats 





|
+---+
| {"nova_object.version": "1.1", "nova_object.changes": ["objects"], 
"nova_object.name": "PciDevicePoolList", 
"nova_object.data": {"objects": [{"nova_object.version": "1.1", 
"nova_object.changes": ["count", "numa_node", "vendor_id", "product_id", 
"tags"], "nova_object.name": "PciDevicePool", 
"nova_object.data": {"count": 2, "numa_node": 0, "vendor_id": "8086", 
"product_id": "154d", "tags": {"dev_type": "type-PF"}}, 
"nova_object.namespace": "nova"}]}, "nova_object.namespace": "nova"} |
+---+
1 row in set (0.00 sec)

MariaDB [nova]> select count(*) from pci_devices where status="available" and 
deleted=0;
+--+
| count(*) |
+--+
|2 |
+--+
1 row in set (0.00 sec)

MariaDB [nova]>

MariaDB [nova]> SELECT * FROM nova.pci_devices;

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[John McDowall]

Juno,

Sorry jumped the gun not published yet :-(. Will send you the link when it is 
published.

Apologies

John

From: Na Zhu >
Date: Wednesday, June 8, 2016 at 1:41 AM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>, 
Srilatha Tangirala >
Subject: Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN

John,

Is the blueprint Louis posted this one?
https://blueprints.launchpad.net/networking-sfc/+spec/networking-sfc-ovn-driver

If not, can you send me the link?


Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, 
Shanghai, China (201203)



From:John McDowall 
>
To:Na Zhu/China/IBM@IBMCN, Srilatha Tangirala 
>
Cc:"disc...@openvswitch.org" 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>
Date:2016/06/08 12:55
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN




Juno, Srilatha,

I need some help – I have fixed most of the obvious typo’s in the three repos 
and merged them with mainline. There is still a problem with the build I think 
in mech_driver.py but I will fix it asap in the am.

However I am not sure of the best way to interface between sfc and ovn.

In networking_sfc/services/src/drivers/ovn/driver.py there is a function that 
creates a deep copy of the port-chain dict, 
create_port_chain(self,contact,port_chain).

Looking at networking-ovn I think it should use mech_driver.py so we can call 
the OVS-IDL to send the parameters to ovn. However I am not sure of the best 
way to do it. Could you make some suggestions or send me some sample code 
showing the best approach?

I will get the ovs/ovn cleaned up and ready. Also Louis from the networking-sfc 
has posted a draft blueprint.

Regards

John

From: Na Zhu >
Date: Monday, June 6, 2016 at 7:54 PM
To: John McDowall 
>, Ryan 
Moats >
Cc: "disc...@openvswitch.org" 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>, 
Srilatha Tangirala >
Subject: Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN

Hi John,

I do not know any better approach, I think it is good to write all the 
parameters in the creation of a port chain, this can avoid saving many data in 
northbound db which are not used. We can do it in that way currently, if the 
community has opposite ideas, we can change, what do you think?

Hi Ryan,

Do you agree with that?



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, 
Shanghai, China (201203)



From:John McDowall 
>
To:Na Zhu/China/IBM@IBMCN
Cc:"disc...@openvswitch.org" 
>, Ryan Moats 
>, Srilatha Tangirala 
>, "OpenStack Development 
Mailing List (not for usage questions)" 
>
Date:2016/06/06 23:36
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN




Juno,

Let me check – my intention was that the networking-sfc OVNB driver would 
configure all aspects 

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[John McDowall]

Amitabha,

Thanks for looking at it . I took the suggestion from Juno and implemented it. 
I think it is a good solution as it minimizes impact on both networking-ovn and 
networking-sfc. I have updated my repos, if you have suggestions for 
improvements let me know.

I agree that there needs to be some refactoring of the networking-sfc driver 
code. I think the team did a good job with it as it was easy for me to create 
the OVN driver ( copy and paste). As more drivers are created I think the model 
will get polished and refactored.

Regards

John

From: Amitabha Biswas >
Date: Tuesday, June 7, 2016 at 11:36 PM
To: John McDowall 
>
Cc: Na Zhu >, Srilatha Tangirala 
>, "OpenStack Development 
Mailing List (not for usage questions)" 
>, 
discuss >
Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN

Hi John,

Looking at the code with Srilatha, it seems like the 
https://github.com/doonhammer/networking-ovn
 repo has gone down the path of having a sfc_ovn.py file in the 
networking-ovn/ovsdb directory. This file deals with the SFC specific OVSDB 
transactions in OVN. So to answer your question of invoking OVS-IDL, we can 
import the src_ovn.py file from 
networking_sfc/services/src/drivers/ovn/driver.py and invoke calls into IDL.

Another aspect from a networking-sfc point of view is the duplication of code 
between networking_sfc/services/src/drivers/ovn/driver.py and 
networking_sfc/services/src/drivers/ovs/driver.py in the 
https://github.com/doonhammer/networking-sfc
 repo. There should be a mechanism to coalesce the common code and invoke the 
OVS and OVN specific parts separately.

Regards
Amitabha

On Jun 7, 2016, at 9:54 PM, John McDowall 
> wrote:

Juno, Srilatha,

I need some help – I have fixed most of the obvious typo’s in the three repos 
and merged them with mainline. There is still a problem with the build I think 
in mech_driver.py but I will fix it asap in the am.

However I am not sure of the best way to interface between sfc and ovn.

In networking_sfc/services/src/drivers/ovn/driver.py there is a function that 
creates a deep copy of the port-chain dict, 
create_port_chain(self,contact,port_chain).

Looking at networking-ovn I think it should use mech_driver.py so we can call 
the OVS-IDL to send the parameters to ovn. However I am not sure of the best 
way to do it. Could you make some suggestions or send me some sample code 
showing the best approach?

I will get the ovs/ovn cleaned up and ready. Also Louis from the networking-sfc 
has posted a draft blueprint.

Regards

John

From: Na Zhu >
Date: Monday, June 6, 2016 at 7:54 PM
To: John McDowall 
>, Ryan 
Moats >
Cc: "disc...@openvswitch.org" 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>, 
Srilatha Tangirala >
Subject: Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN

Hi John,

I do not know any better approach, I think it is good to write all the 
parameters in the creation of a port chain, this can avoid saving many data in 
northbound db which are not used. We can do it in that way currently, if the 
community has opposite ideas, we can change, what do you think?

Hi Ryan,

Do you agree with that?



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, 
Shanghai, China (201203)



From:John McDowall 
>
To:Na Zhu/China/IBM@IBMCN
Cc:"disc...@openvswitch.org" 

Re: [openstack-dev] [nova] Austin summit priorities session recap

[Alexandre Levine]

Hi Matt,

According to the state of this review: 
https://review.openstack.org/#/c/317689/ the works aren't going to be 
done in this cycle.


Do you think it'd be possible for our driver to cut in now?

Feodor participated in reviewing and helped as much as possible with 
current efforts and if needed we can spare even more resources to help 
with the refactoring in the next cycle.


Best regards,

  Alex Levine


On 5/10/16 7:40 PM, Matt Riedemann wrote:

On 5/10/2016 11:24 AM, Alexandre Levine wrote:

Hi Matt,

Sorry I couldn't reply earlier - was away.
I'm worrying about ScaleIO ephemeral storage backend
(https://blueprints.launchpad.net/nova/+spec/scaleio-ephemeral-storage-backend) 


which is not in this list but various clients are very interested in
having it working along with or instead of Ceph. Especially I'm worrying
in view of the global libvirt storage pools refactoring which looks like
a quite global effort to me judging by a number of preliminary reviews.
It seems to me that we wouldn't be able to squeeze ScaleIO additions
after this refactoring.
What can be done about it?
We could've contribute our initial changes to current code (which would
potentially allow easy backporting to previous versions as a benefit
afterwards) and promise to update our parts along with the refactoring
reviews or something like this.

Best regards,
  Alex Levine


On 5/6/16 3:34 AM, Matt Riedemann wrote:

There are still a few design summit sessions from the summit that I'll
recap but I wanted to get the priorities session recap out as early as
possible. We held that session in the last slot on Thursday. The full
etherpad is here [1].

The first part of the session was mostly going over schedule 
milestones.


We already started Newton with a freeze on spec approvals for new
things since we already have a sizable backlog [2]. Now that we're
past the summit we can approve specs for new things again.

The full Newton release schedule for Nova is in this wiki [3].

These are the major dates from here on out:

* June 2: newton-1, non-priority spec approval freeze
* June 30: non-priority feature freeze
* July 15: newton-2
* July 19-21: Nova Midcycle
* Aug 4: priority spec approval freeze
* Sept 2: newton-3, final python-novaclient release, FeatureFreeze,
Soft StringFreeze
* Sept 16: RC1 and Hard StringFreeze
* Oct 7, 2016: Newton Release

The important thing for most people right now is we have exactly four
weeks until the non-priority spec approval freeze. We then have about
one month after that to land all non-priority blueprints.

Keep in mind that we've already got 52 approved blueprints and most of
those were re-approved from Mitaka, so have been approved for several
weeks already.

The non-priority blueprint cycle is intentionally restricted in Newton
because of all of the backlog work we've had spilling over into this
release. We really need to focus on getting as much of that done as
possible before taking on more new work.

For the rest of the priorities session we talked about what our actual
review priorities are for Newton. The list with details and owners is
already available here [4].

In no particular order, these are the review priorities:

* Cells v2
* Scheduler
* API Improvements
* os-vif integration
* libvirt storage pools (for live migration)
* Get Me a Network
* Glance v2 Integration

We *should* be able to knock out glance v2, get-me-a-network and
os-vif relatively soon (I'm thinking sometime in June).

Not listed in [4] but something we talked about was volume
multi-attach with Cinder. We said this was going to be a 'stretch
goal' contingent on making decent progress on that item by
non-priority feature freeze *and* we get the above three smaller
priority items completed.

Another thing we talked about but isn't going to be a priority is
NFV-related work. We talked about cleaning up technical debt and
additional testing for NFV but had no one in the session signed up to
own that work or with concrete proposals on how to make improvements
in that area. Since we can't assign review priorities to something
that nebulous it was left out. Having said that, Moshe Levi has
volunteered to restart and lead the SR-IOV/PCI bi-weekly meeting [5]
(thanks again, Moshe!). So if you (or your employer, or your vendor)
are interested in working on NFV in Nova please attend that meeting
and get involved in helping out that subteam.

[1] https://etherpad.openstack.org/p/newton-nova-summit-priorities
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html 


[3] https://wiki.openstack.org/wiki/Nova/Newton_Release_Schedule
[4]
https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html 



[5]
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093541.html 






__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port is Active

[Salvatore Orlando]

Neutron has the ability already of sending an event as a REST call to
notify a third party that a port became active [1]
This is used by Nova to hold on booting instances until network has been
wired.
Perhaps kuryr could leverage this without having to tap into the AMQP bus,
as that would be implementation-specific - since there would be an
assumption about having a plugin that communicates with the reference impl
l2 agent.

Salvatore

[1]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/notifiers/nova.py



On 8 June 2016 at 17:23, Mohammad Banikazemi  wrote:

> For the Kuryr project, in order to support blocking until vifs are plugged
> in (that is adding config options similar to the following options define
> in Nova: vif_plugging_is_fatal and vif_plugging_timeout), we need to detect
> that the Neutron plugin being used is done with plugging a given vif.
>
> Here are a few options:
>
> 1- The simplest approach seems to be polling for the status of the Neutron
> port to become Active. (This may lead to scalability issues but short of
> having a specific goal for scalability, it is not clear that will be the
> case.)
> 2- Alternatively, We could subscribe to the message queue and wait for
> such a port update event.
> 3- It was also suggested that we could use l2 agent extension to detect
> such an event but that seems to limit us to certain Neutron plugins and
> therefore not acceptable.
>
> I was wondering if there are other and better options.
>
> Best,
>
> Mohammad
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port is Active

[Mohammad Banikazemi]

For the Kuryr project, in order to support blocking until vifs are plugged
in (that is adding config options similar to the following options define
in Nova: vif_plugging_is_fatal and vif_plugging_timeout), we need to detect
that the Neutron plugin being used is done with plugging a given vif.

Here are a few options:

1- The simplest approach seems to be polling for the status of the Neutron
port to become Active. (This may lead to scalability issues but short of
having a specific goal for scalability, it is not clear that will be the
case.)
2- Alternatively, We could subscribe to the message queue and wait for such
a port update event.
3- It was also suggested that we could use l2 agent extension to detect
such an event but that seems to limit us to certain Neutron plugins and
therefore not acceptable.

I was wondering if there are other and better options.

Best,

Mohammad
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] How to get instance name only by floating ip and then change it to hostname

[David Moreau Simard]

It doesn't look like the --ip parameter searches through the floating
IPs, that's probably a UX expectation issue and improvement that could
be done to the CLI client.

Something like this should get you what you want:

openstack server set $(openstack server list -f value |awk
'/11.11.111.11/ {print $1}') --name newname

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Tue, Jun 7, 2016 at 11:19 AM, OpenStack Mailing List Archive
 wrote:
> Link: https://openstack.nimeyo.com/86809/?show=86809#q86809
> From: Wenqi 
>
> Hi,
> What is the cli to get the instance name only and then change it to
> hostname?
> I know how to get the instance info table from private ip by below command:
> nova list --ip 11.11.111.11
> I just want the name and then use the below command to change it with
> hostname
> nova rename server name
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-announce] [new][ironic] ironic-ui 1.1.2 release (mitaka)

[no-reply]

We are pleased to announce the release of:

ironic-ui 1.1.2: Ironic plugin UI for Horizon to allow users to view
and manage bare metal nodes, ports and drivers.

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/ironic-ui

With package available at:

https://pypi.python.org/pypi/ironic-ui

Please report issues through launchpad:

http://bugs.launchpad.net/ironic-ui

For more details, please see below.

Changes in ironic-ui 1.1.1..1.1.2
-

09f0b88 Eliminate dependency on master version of horizon

Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index aea4a8b..ec77dc5 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6 +6 @@
--e git://github.com/openstack/horizon.git#egg=horizon
+http://tarballs.openstack.org/horizon/horizon-stable-mitaka.tar.gz#egg=horizon



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-dev] [new][ironic] bifrost 1.0.2 release (mitaka)

[no-reply]

We are satisfied to announce the release of:

bifrost 1.0.2: Deployment of physical machines using OpenStack Ironic
and Ansible

This release is part of the mitaka stable release series.

For more details, please see below.

Changes in bifrost 1.0.1..1.0.2
---

9db927b Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index a703a54..cdd2511 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ pbr>=1.6 # Apache-2.0
-Babel>=1.3 # BSD
+Babel!=2.3.0,!=2.3.1,!=2.3.2,!=2.3.3,>=1.3 # BSD



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-ovn] Integration with OVN NAT gateway (Proposal)

[Amitabha Biswas]

Here is the proposal in etherpad to make it more readable:

https://etherpad.openstack.org/p/Integration_with_OVN_L3_Gateway 


Thanks
Amitabha

> On Jun 7, 2016, at 5:12 PM, Amitabha Biswas  wrote:
> 
> Sorry that was a typo, it should read:
> 
>> Note that the MAC addresses of gtrp and dtrp will be the same on each OVN 
>> Join Network, but because they are in different branches of the network 
>> topology it doesn’t matter.
> Amitabha
> 
>> On Jun 7, 2016, at 4:39 PM, Bhalachandra Banavalikar 
>> > wrote:
>> 
>> Can you please provide more details on lgrp and lip ports (last bullet in 
>> section 1)?
>> 
>> Thanks,
>> Bhal
>> 
>> Amitabha Biswas ---06/07/2016 01:56:23 PM---This proposal 
>> outlines the modifications needed in networking-ovn (addresses 
>> https://bugs.launchpad .
>> 
>> From:  Amitabha Biswas >
>> To:  "OpenStack Development Mailing List (not for usage questions)" 
>> > >
>> Cc:  Chandra Sekhar Vejendla/San Jose/IBM@IBMUS
>> Date:  06/07/2016 01:56 PM
>> Subject:  [openstack-dev] [neutron][networking-ovn] Integration with OVN NAT 
>> gateway (Proposal)
>> 
>> 
>> 
>> 
>> This proposal outlines the modifications needed in networking-ovn (addresses 
>> https://bugs.launchpad.net/networking-ovn/+bug/1551717 
>> ) to provide 
>> Floating IP (FIP) and SNAT using the L3 gateway router patches.
>> 
>> http://patchwork.ozlabs.org/patch/624312/ 
>>  
>> http://patchwork.ozlabs.org/patch/624313/ 
>>  
>> http://patchwork.ozlabs.org/patch/624314/ 
>>  
>> http://patchwork.ozlabs.org/patch/624315/ 
>>  
>> http://patchwork.ozlabs.org/patch/629607/ 
>> 
>> 
>> Diagram:
>> 
>> +---+ +---+
>> | NET 1 | | NET 2 |
>> +---+ +---+
>> | |
>> | * |
>> | ** ** |
>> | ** * * ** |
>> +---RP1 * DR * RP2 --+
>> ** * * **
>> ** **  
>> *  
>> DTRP (168.254.128.2)
>> |
>> |
>> |
>> +--+
>> | Transit Network |
>> | 169.254.128.0/30 |
>> +--+
>> |
>> |
>> |
>> |
>> GTRP (169.254.128.1)
>> ***  
>> ** **  
>> ** * * ** +--+
>> * GW *-| Provider Network |
>> ** * * ** +--+
>> ** **  
>> ***  
>> 
>> New Entities:
>> OVN Join/Transit Networks
>> One per Neutron Router - /30 address space with only 2 ports for e.g. 
>> 169.254.128.0/30
>> Created when an external gateway is added to a router.
>> One extra datapath per router with an External Gateway.
>> (Alternate option - One Transit Network in a deployment, IPAM becomes a 
>> headache - Not discussed here).
>> Prevent Neutron from using that /30 address space. Specify in networking-ovn 
>> conf file.
>> Create 1 new “Join” neutron network (to represent all Join OVN Networks) in 
>> the networking-ovn.
>> Note that it may be possible to replace the Join/Transit network using 
>> Router Peering in later versions (not discussed here).
>> Allocate 2 ports in the Join network in the networking-ovn plugin.
>> Logical Gateway Transit Router Port (gtrp), 169.254.128.1
>> Logical Distributed Transit Router Port (dtrp), 169.254.128.2
>> Note that Neutron only sees 1 Join network with 2 ports; OVN sees a replica 
>> of this Join network as a new Logical Switch for each Gateway Router. The 
>> mapping of OVN Logical Switch(es) Join(s) to Gateway Router is discussed in 
>> OVN (Default) Gateway Routers below.
>> Note that the MAC addresses of gtrp and dtrp will be the same on each OVN 
>> Join Network, but because they are in different branches of the network 
>> topology it doesn’t matter.
>> OVN (Default) Gateway Routers:
>> One per Neutron Router.
>> 2 ports
>> Logical Gateway Transit Router Port (gtrp), 169.254.128.1 (same for each OVN 
>> Join network).
>> External/Provider Router Port (legwrp), this is allocated by neutron.
>> Scheduling - The current OVN gateway proposal relies on the CMS/nbctl to 
>> decide on which hypervisor (HV) to schedule a particular gateway router.
>> A setting on the chassis (new external_id key or a new column) that allows 
>> the hypervisor admin to specify that a chassis can or cannot be used to host 
>> a gateway router (similar to a network node in OpenStack). Default - Allow 
>> (for compatibility purposes).
>> The networking-ovn plugin picks up the list of “candidate” chassis from the 
>> Southbound DB and uses an existing scheduling algorithm
>> Use a simple random.choice i.e. ChanceScheduler (Version 1)
>> Tap into the neutron’s LeastRouterScheduler - but 

[openstack-dev] [kolla] cinder implementation + lvm

[Carlos Cesario]

Hi Dev-team, 

Please, if possible could someone confirm me details about cinder 
implementation on kolla (current master branch). 
I have facing some problems with Kolla deploy (AIO method) and Cinder with lvm. 
The current code on master branch does not deploy cinder without enable iscsi - 
enable_iscsi ( already reported on list 
https://www.mail-archive.com/openstack-dev%40lists.openstack.org/msg85315.html) 

Another point is the mandatory iscsi driver to lvm works. According cinder the 
documentation 
http://docs.openstack.org/mitaka/install-guide-rdo/cinder-storage-install.html 
the iscsi driver doe not needed to lvm works. Is it a Kolla dependency!? If yes 
is there an spec doc for it ? 


Best regards, 


Carlos 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [tacker] Request to create puppet-tacker

[Dan Radez]

sure will, thx Emilien
Dan

On 06/08/2016 09:08 AM, Emilien Macchi wrote:
> Yeah, super good news!
> Please do the same as I did in https://review.openstack.org/326720 and
> https://review.openstack.org/326721
> 
> Add me as reviewer because I need to sign-off the 2 patches (I'm current PTL).
> Once it's done & merged, you'll be able to deprecate the old
> repository on your github with a nice README giving the link of the
> new module.
> 
> I haven't looked at the code yet but we'll probably have to adjust
> some bits, add some testing (beaker [1], etc). Please make sure that
> we have some packaging available in RDO (I checked on Ubuntu and they
> don't provide it) so we can download it during our beaker tests.
> 
> Also a last thing, in order to help us to make the module compliant &
> consistent, please read how we wrote the recent modules. For example
> you can look puppet-gnocchi or puppet-aodh that are clean modules.
> We recently had a lot of new modules: vitrage, watcher, tacker,
> congress, (I'm working now on octavia) - which means reviews might
> take more time than usual because our team will review the new modules
> carefuly to make sure the code is clean & consistent from beginning
> (and avoid the puppet-monasca story). Please be patient and help us by
> reading how we did other modules.
> 
> Thanks a ton for your collaboration and we're looking forward for this
> new challenge,
> 
> [1] https://github.com/puppetlabs/beaker
> 
> On Wed, Jun 8, 2016 at 8:11 AM, Iury Gregory  wrote:
>> Awesome!
>>
>> You just need to follow the same process that Emilien pointed for
>> puppet-congress. If you need any help please let us know.
>>
>> 1- Move  https://github.com/radez/puppet-tacker to OpenStack
>> 2- Add it to our governance
>> 3- Follow
>> http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html
>>
>>
>>
>> 2016-06-08 8:56 GMT-03:00 Dan Radez :
>>>
>>> I also have puppet-tacker module that has existed before the project was
>>> part of big tent.
>>>
>>> It was based on cookie cutter originally but will probably need some
>>> adjustments to adhere to standards.
>>>
>>> I'd like to get the project establish so that the code can be run
>>> through the proper review process.
>>>
>>> exiting repo is here: https://github.com/radez/puppet-tacker
>>>
>>> Dan Radez
>>> freenode: radez
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>>
>> ~
>> Att[]'s
>> Iury Gregory Melo Ferreira
>> Master student in Computer Science at UFCG
>> E-mail:  iurygreg...@gmail.com
>> ~
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [tacker] Request to create puppet-tacker

[Dan Radez]

FYI, tacker community:
https://review.openstack.org/#/c/327173/
https://review.openstack.org/#/c/327178/

Radez

On 06/08/2016 10:54 AM, Dan Radez wrote:
> sure will, thx Emilien
> Dan
> 
> On 06/08/2016 09:08 AM, Emilien Macchi wrote:
>> Yeah, super good news!
>> Please do the same as I did in https://review.openstack.org/326720 and
>> https://review.openstack.org/326721
>>
>> Add me as reviewer because I need to sign-off the 2 patches (I'm current 
>> PTL).
>> Once it's done & merged, you'll be able to deprecate the old
>> repository on your github with a nice README giving the link of the
>> new module.
>>
>> I haven't looked at the code yet but we'll probably have to adjust
>> some bits, add some testing (beaker [1], etc). Please make sure that
>> we have some packaging available in RDO (I checked on Ubuntu and they
>> don't provide it) so we can download it during our beaker tests.
>>
>> Also a last thing, in order to help us to make the module compliant &
>> consistent, please read how we wrote the recent modules. For example
>> you can look puppet-gnocchi or puppet-aodh that are clean modules.
>> We recently had a lot of new modules: vitrage, watcher, tacker,
>> congress, (I'm working now on octavia) - which means reviews might
>> take more time than usual because our team will review the new modules
>> carefuly to make sure the code is clean & consistent from beginning
>> (and avoid the puppet-monasca story). Please be patient and help us by
>> reading how we did other modules.
>>
>> Thanks a ton for your collaboration and we're looking forward for this
>> new challenge,
>>
>> [1] https://github.com/puppetlabs/beaker
>>
>> On Wed, Jun 8, 2016 at 8:11 AM, Iury Gregory  wrote:
>>> Awesome!
>>>
>>> You just need to follow the same process that Emilien pointed for
>>> puppet-congress. If you need any help please let us know.
>>>
>>> 1- Move  https://github.com/radez/puppet-tacker to OpenStack
>>> 2- Add it to our governance
>>> 3- Follow
>>> http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html
>>>
>>>
>>>
>>> 2016-06-08 8:56 GMT-03:00 Dan Radez :

 I also have puppet-tacker module that has existed before the project was
 part of big tent.

 It was based on cookie cutter originally but will probably need some
 adjustments to adhere to standards.

 I'd like to get the project establish so that the code can be run
 through the proper review process.

 exiting repo is here: https://github.com/radez/puppet-tacker

 Dan Radez
 freenode: radez

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> --
>>>
>>> ~
>>> Att[]'s
>>> Iury Gregory Melo Ferreira
>>> Master student in Computer Science at UFCG
>>> E-mail:  iurygreg...@gmail.com
>>> ~
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[John McDowall]

Juni,

Thanks – added the code and everything builds, just need to debug end-to-end 
now.  I think your approach is the best so far all the IDL code for accessing 
ovs/ovn is in networking-ovn. The OVN driver in networking-sfc calls the IDL 
code to access ovs/ovn. There is minimal linkage between networking-sfc and 
networking-ovn , just one import:

from networking_ovn.ovsdb import impl_idl_ovn

I think this is what Ryan was asking for.

I have updated all repos so we can think about creating WIP patches.

Regards

John
From: Na Zhu >
Date: Wednesday, June 8, 2016 at 12:44 AM
To: John McDowall 
>
Cc: "disc...@openvswitch.org" 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>, 
Srilatha Tangirala >
Subject: Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN

Hi John,

I think you can create ovsdb idl client in networking-sfc to connect to 
OVN_Northbound DB, then call the APIs you add to networking-ovn to configure 
SFC.
Now OVN is a ML2 mechanism driver (OVNMechanismDriver), not core plugin, the 
OVN L3 (OVNL3RouterPlugin) is a neutron service plugin like vpn, sfc and ect.

You can refer to method OVNMechanismDriver._ovn and OVNL3RouterPlugin._ovn, 
they both create ovsdb idl client object, so in your ovn driver, you can do it 
in the same way. Here is the code sample:

class OVNSfcDriver(driver_base.SfcDriverBase,
   ovs_sfc_db.OVSSfcDriverDB)
..
@property
def _ovn(self):
if self._ovn_property is None:
LOG.info(_LI("Getting OvsdbOvnIdl"))
self._ovn_property = impl_idl_ovn.OvsdbOvnIdl(self)
return self._ovn_property

..
@log_helpers.log_method_call
def create_port_chain(self, context):
port_chain = context.current
for flow_classifier in port_chain:
first get the flow classifier contents
then call self._ovn.create_lflow_classifier()
for port_pair_groups in port_chain:
get the port_pair_group contents
then call self._ovn.create_lport_pair_group()
for port_pair in port_pair_group
first get the port_pair contents
then call self._ovn.create_lport_pair()







Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, 
Shanghai, China (201203)



From:John McDowall 
>
To:Na Zhu/China/IBM@IBMCN, Srilatha Tangirala 
>
Cc:"disc...@openvswitch.org" 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>
Date:2016/06/08 12:55
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN




Juno, Srilatha,

I need some help – I have fixed most of the obvious typo’s in the three repos 
and merged them with mainline. There is still a problem with the build I think 
in mech_driver.py but I will fix it asap in the am.

However I am not sure of the best way to interface between sfc and ovn.

In networking_sfc/services/src/drivers/ovn/driver.py there is a function that 
creates a deep copy of the port-chain dict, 
create_port_chain(self,contact,port_chain).

Looking at networking-ovn I think it should use mech_driver.py so we can call 
the OVS-IDL to send the parameters to ovn. However I am not sure of the best 
way to do it. Could you make some suggestions or send me some sample code 
showing the best approach?

I will get the ovs/ovn cleaned up and ready. Also Louis from the networking-sfc 
has posted a draft blueprint.

Regards

John

From: Na Zhu >
Date: Monday, June 6, 2016 at 7:54 PM
To: John McDowall 
>, Ryan 
Moats >
Cc: "disc...@openvswitch.org" 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>, 
Srilatha Tangirala >
Subject: Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN

Hi John,

I do not know 

Re: [openstack-dev] Reasoning behind my vote on the Go topic

[Gregory Haynes]

On Wed, Jun 8, 2016, at 03:46 AM, Thierry Carrez wrote:
> Another option (raised by dims) is to find a way to allow usage of 
> golang (or another language) in a more granular way: selectively allow 
> projects which really need another tool to use it. The benefit is that 
> it lets project teams make a case and use the best tool for the job, 
> while limiting the cross-project impact and without opening the 
> distraction floodgates of useless rewrites. The drawback is that 
> depending on how it's done, it may place the TC in the role of granting 
> "you're tall enough to use Go" badges, creating new endless discussions 
> and more "you're special" exceptions. That said, I'm still interested in 
> exploring that option, for one reason. I think that whenever a project 
> team considers adding a component or a rewrite in another language, they 
> are running into an interesting problem with Python, on which they 
> really could use advice from the rest of the OpenStack community. I'd 
> really like to see a cross-project team of Python performance experts to 
> look at the problem this specific team has that makes them want to use 
> another language. That seems like a great way to drive more practice 
> sharing and reduce fragmentation in "OpenStack" in general. We might 
> just need to put the bar pretty high so that we are not flooded by silly 
> rewrite requests.
> 

++.  There's a lot of value in these issues getting bubbled up to the
cross-project level: If we have identified a serious hurdle then this
knowledge really shouldn't live inside of a single project. Otherwise,
if we haven't identified such an issue, then the (the greater openstack
community) can offer some alternative solutions which is also a huge
win.

I completely understand the fear that we might be creating an endless
review stream for the TC by making them the review squad for getting
approval to use a new language, and I agree that we need to make sure
that doesn't happen. OTOH, I strongly believe that in almost all of the
cases which would be proposed some alternative solutions could be found.
I worry that if we just tell these folks 'the solution you thought of
isn't allowed' rather than offer an outlet for seriously investigating
the issue were likely to see teams try and find ways around that
restriction when really we want to identify another solution to the
problem. A perf team sounds like a great way to help both the tribal
knowledge problem and support the type of problem solving we are asking
for. Sign me up :).

Cheers,
Greg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] Virtual Mid Cycle Coordinates - July 19/20

[Fabio Giannetti (fgiannet)]

Monasca Mid Cycle Day 1
July 19 2016
7am to noon PDT

Webex

Join WebEx meeting:
https://cisco.webex.com/ciscosales/j.php?MTID=mb490140119f1f6f518160d85b108
0a13


Meeting number: 200 700 937
Meeting password: mXdvExYq
  


Join by phone  
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 200 700 937
Numeric meeting password: 17093037



Monasca Mid Cycle Day 2
July 20 2016
7am to noon PDT

Webex


Join WebEx meeting:
https://cisco.webex.com/ciscosales/j.php?MTID=m84f9f81d7c1c171be6365716522d
e15e

Meeting number: 205 141 519
Meeting password: 8VyzUiyr

Join by phone  
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 205 141 519
Numeric meeting password: 01558880


See you there.
Fabio


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Gauvain Pocentek]

Hi James,

Le 2016-06-08 12:20, James Page a écrit :

Hi

We're currently blocked on becoming an OpenStack project under the
big-tent by the licensing of the 26 OpenStack charms under GPL v3.

I'm proposing that we re-license the following code repositories as 
Apache 2.0:


  charm-ceilometer
  charm-ceilometer-agent
  charm-ceph
  charm-ceph-mon
  charm-ceph-osd
  charm-ceph-radosgw
  charm-cinder
  charm-cinder-backup
  charm-cinder-ceph
  charm-glance
  charm-hacluster
  charm-heat
  charm-keystone
  charm-lxd
  charm-neutron-api
  charm-neutron-api-odl
  charm-neutron-gateway
  charm-neutron-openvswitch
  charm-nova-cloud-controller
  charm-nova-compute
  charm-odl-controller
  charm-openstack-dashboard
  charm-openvswitch-odl
  charm-percona-cluster
  charm-rabbitmq-server
  charm-swift-proxy
  charm-swift-storage

The majority of contributors are from Canonical (from whom I have
permission to make this switch) with a further 18 contributors from
outside of Canonical who I will be directly contacting for approval in
gerrit as reviews are raised for each repository.


No problem on my side to change the license to apache 2.0.

Thanks for checking with us.

Gauvain




Any new charms and supporting repositories will be licensed under
Apache 2.0 from the outset.

Cheers

James
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Gauvain Pocentek

Objectif Libre - Infrastructure et Formations Linux
http://www.objectif-libre.com
phone: +33 972 54 98 01 / +33 611 60 84 25

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Stepping down from Trove Core

[Craig Vyvial]

Victoria,

Thank for your contributions to Trove and wish you the best. Its been great
working with you in the community.

-Craig Vyvial

On Tue, Jun 7, 2016 at 1:34 PM Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> After one year and a half contributing to the Trove project,
> I have decided to change my focus and start gaining more experience
> on other storage and data-management related projects.
>
> Because of this decision, I'd like to ask to be removed from the Trove core 
> team.
>
> I want to thank Trove community for all the good work and shared experiences.
> Working with you all has been a very fulfilling experience.
>
> All the best,
>
> Victoria
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Stepping down from Trove Core

[Mariam John]

Thank you Victoria for all your hard work and dedication to the Trove
project. It's been a pleasure knowing you and working with you.

Wish you all the best and good luck.

Regards,
Mariam.




From:   Victoria Martínez de la Cruz 
To: OpenStack Development Mailing List

Date:   06/07/2016 01:37 PM
Subject:[openstack-dev] [Trove] Stepping down from Trove Core



After one year and a half contributing to the Trove project,
I have decided to change my focus and start gaining more experience
on other storage and data-management related projects.

Because of this decision, I'd like to ask to be removed from the Trove core
team.

I want to thank Trove community for all the good work and shared
experiences.
Working with you all has been a very fulfilling experience.

All the best,

Victoria
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][SFC]

[Alioune]

I've switched from devstack to a normal deployment of openstack/mitaka and
neutron-l2 agent is working fine with sfc. I can boot instances, create
ports.
However I can not create neither flow-classifier nor port-pair ...

neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix
22.1.20.1/32 --destination-ip-prefix 172.4.5.6/32 --protocol tcp
--source-port 23:23 --destination-port 100:100 FC1

returns: neutron flow-classifier-create: error: argument
--logical-source-port is required
Try 'neutron help flow-classifier-create' for more information.

 neutron port-pair-create --ingress=p1 --egress=p2 PP1
404 Not Found

The resource could not be found.

Neutron server returns request_ids:
['req-1bfd0983-4a61-4b32-90b3-252004d90e65']

neutron --version
4.1.1

p1,p2,p3,p4 have already been created, I can ping instances attached to
these ports.
Since I've not installed networking-sfc, are there additional config to set
in neutron config files ?
Or is it due to neutron-client version ?

Regards

On 8 June 2016 at 20:31, Mohan Kumar  wrote:

> neutron agent not able to fetch details from ovsdb . Could you check below
> options 1.restart ovsdb-server and execute ovs_vsctl list-br  2.   execute
> ovs- vsctl list-br manually and try to check error.
>
> 3. Could be ovs cleanup issue , please check the output of sudo service
> openvswitch restart and /etc/init.d/openvswich** restart , both should be
> same
>
> Thanks.,
> Mohankumar.N
> On Jun 7, 2016 6:04 PM, "Alioune"  wrote:
>
>> Hi Mohan/Cathy
>>  I've installed now ovs 2.4.0 and followed
>> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining but
>> I got this error :
>> Regards,
>>
>> + neutron-ovs-cleanup
>> 2016-06-07 11:25:36.465 22147 INFO neutron.common.config [-] Logging
>> enabled!
>> 2016-06-07 11:25:36.468 22147 INFO neutron.common.config [-]
>> /usr/local/bin/neutron-ovs-cleanup version 7.1.1.dev4
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl [-]
>> Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline',
>> '--format=json', '--', 'list-br'].
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
>> Traceback (most recent call last):
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File
>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in
>> run_vsctl
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
>> log_fail_as_error=False).rstrip()
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File
>> "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
>> raise RuntimeError(m)
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
>> RuntimeError:
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
>> Command: ['sudo', 'ovs-vsctl', '--timeout=10', '--oneline',
>> '--format=json', '--', 'list-br']
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Exit
>> code: 1
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
>> 2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
>> 2016-06-07 11:25:36.512 22147 CRITICAL neutron [-] RuntimeError:
>> Command: ['sudo', 'ovs-vsctl', '--timeout=10', '--oneline',
>> '--format=json', '--', 'list-br']
>> Exit code: 1
>>
>> 2016-06-07 11:25:36.512 22147 ERROR neutron Traceback (most recent call
>> last):
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/usr/local/bin/neutron-ovs-cleanup", line 10, in 
>> 2016-06-07 11:25:36.512 22147 ERROR neutron sys.exit(main())
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/cmd/ovs_cleanup.py", line 89, in main
>> 2016-06-07 11:25:36.512 22147 ERROR neutron ovs_bridges =
>> set(ovs.get_bridges())
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/common/ovs_lib.py", line 132, in
>> get_bridges
>> 2016-06-07 11:25:36.512 22147 ERROR neutron return
>> self.ovsdb.list_br().execute(check_error=True)
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 83, in execute
>> 2016-06-07 11:25:36.512 22147 ERROR neutron txn.add(self)
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/ovsdb/api.py", line 70, in __exit__
>> 2016-06-07 11:25:36.512 22147 ERROR neutron self.result =
>> self.commit()
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 50, in commit
>> 2016-06-07 11:25:36.512 22147 ERROR neutron res = self.run_vsctl(args)
>> 2016-06-07 11:25:36.512 22147 ERROR neutron   File
>> "/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 70, in
>> run_vsctl
>> 2016-06-07 11:25:36.512 22147 ERROR neutron ctxt.reraise = False
>> 2016-06-07 11:25:36.512 

[openstack-dev] Trove weekly meeting minutes

[Amrith Kumar]

The summary of the Trove weekly meeting held just now.

Action Items:
- prepare for next weeks meeting; things that we can get into Newton

Full transcript at 
http://eavesdrop.openstack.org/meetings/trove/2016/trove.2016-06-08-18.00.html

Thanks,

-amrith

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Update on resource providers work

[Sean Dague]

On 06/08/2016 03:31 PM, Matt Riedemann wrote:
> On 6/6/2016 7:26 AM, Jay Pipes wrote:
>> Once the InventoryList and AllocationList objects are merged, then we
>> will focus on reviews of the placement REST API patches [3]. Again, we
>> are planning on having the nova-compute resource tracker call these REST
>> API calls directly (while continuing to use the Nova ComputeNode object
>> for saving legacy inventory information). Clearly, before the resource
>> tracker can call this placement REST API, we need the placement REST API
>> service to be created and a client for it added to OSC. Once this client
>> exists, we can add code to the resource tracker which uses it.
> 
> Wait, we're going to require python-openstackclient in Nova to call the
> placement REST API? That seems bad given the dependencies that OSC pulls
> in. Why not just create the REST API wrapper that we need within Nova
> and then split that out later to whichever client it's going to live in?

Yes, that ^^^

Just use keystoneauth1 and hand rolled json. We shouldn't be talking
about a ton of code.

Pulling python-openstackclient back into Nova as a dependency is really
a hard NACK for a bunch of reasons, including the way dependencies work.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [new][ironic] ironic-python-agent 1.2.2 release (mitaka)

[no-reply]

We are pumped to announce the release of:

ironic-python-agent 1.2.2: Ironic Python Agent Ramdisk

This release is part of the mitaka stable release series.

For more details, please see below.

1.2.2
^


New Features


* The driver_internal_info internal setting
  "agent_continue_if_ata_erase_failed" allows operators to enable disk
  cleaning operations to fallback from a failed ata_erase operation to
  disk shredding operations.


Bug Fixes
*

* On start up wait up to 30 seconds for the first disk device
  suitable for deployment to appear. This is to fix both inspection
  and deployment on hardware that takes long to initialize (e.g. some
  RAID devices).

* IPA will now attempt to unlock a security locked drive with a
  'NULL' password if it is found to be enabled, however this will only
  work if the password was previously set to a 'NULL' value, such as
  if a failure during a previous ata_erase sequence.

* Potential command failures in the secure erase process are now
  captured and raised as BlockDeviceEraseError exceptions.

Changes in ironic-python-agent 1.2.1..1.2.2
---

b6bdaf0 Provide fallback from ATA erase to shredding
2ec82a4 Wait for at least one suitable disk to appear on start up
c65d30f TinyIPA: Shave off some file size from tinyipa ramdisk
8ece8ba TinyIPA: Precompile python code for faster load
d053f9d Use TinyCore Linux 7.x for TinyIPA
cc8cab2 Optimise tinyipa boot time
29ba706 Enable branch tagging during tinyipa build
30cf976 Remove "Experimental" warning from tinyipa README

Diffstat (except docs and test files)
-

imagebuild/tinyipa/Makefile|   4 +-
imagebuild/tinyipa/README.rst  |   3 -
imagebuild/tinyipa/build-tinyipa.sh|  16 +-
imagebuild/tinyipa/build_files/bootlocal.sh|   4 +
imagebuild/tinyipa/build_files/buildreqs.lst   |   4 +-
imagebuild/tinyipa/build_files/fakeuname   |   2 +-
imagebuild/tinyipa/build_files/finalreqs.lst   |   5 +-
imagebuild/tinyipa/finalise-tinyipa.sh |  40 +++-
ironic_python_agent/api/app.py |   1 +
ironic_python_agent/hardware.py|  79 ++-
releasenotes/notes/disk-wait-2e0e85e0947f80e9.yaml |   5 +
.../enable-cleaning-fallback-57e8c9aa2f24e63d.yaml |  14 ++
14 files changed, 378 insertions(+), 40 deletions(-)




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Update on resource providers work

[Matt Riedemann]

On 6/6/2016 7:26 AM, Jay Pipes wrote:

Once the InventoryList and AllocationList objects are merged, then we
will focus on reviews of the placement REST API patches [3]. Again, we
are planning on having the nova-compute resource tracker call these REST
API calls directly (while continuing to use the Nova ComputeNode object
for saving legacy inventory information). Clearly, before the resource
tracker can call this placement REST API, we need the placement REST API
service to be created and a client for it added to OSC. Once this client
exists, we can add code to the resource tracker which uses it.


Wait, we're going to require python-openstackclient in Nova to call the 
placement REST API? That seems bad given the dependencies that OSC pulls 
in. Why not just create the REST API wrapper that we need within Nova 
and then split that out later to whichever client it's going to live in?


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Nominate Ilya Kutukov for the fuel-web-core team

[Bulat Gaifullin]

Hey Fuelers,

I'd like to nominate Ilya Kutukov for the fuel-web-core team.
Ilya`s doing good reviews with detailed feedback [1],
and has implemented custom graph execution engine for Fuel.
Also Ilya`s implemented new database models for storing deployment tasks in 
Fuel.


Fuel Cores, please reply back with +1/-1.

[1] http://stackalytics.com/report/contribution/fuel-web/90 



Regards,
Bulat Gaifullin
Mirantis Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][reno][infra] merging tags between branches is confusing our release notes

[John Dickinson]

On 8 Jun 2016, at 11:13, Doug Hellmann wrote:

> tl;dr: The switch from pre-versioning to post-versioning means that
> sometimes master appears to be older than stable/$previous, so we
> merge "final" tags from stable/$previous into master to make up for
> it. This introduces versions into the history of master that aren't
> *really* there, but git sees them and so does reno. That, in turn,
> means that the release notes generated from master may place some
> notes in the wrong version, suggesting that something happened
> sooner than it did. I propose that we stop merging tags, and instead
> introduce a new tag on master after we create a branch to ensure
> that the version number there is always higher than stable/$previous.
>
>
> Background
> --
>
> Over the last year or so we've switched from pre-versioning (declaring
> versions in setup.cfg) to post-versioning (relying solely on git
> tags for versions). This made the release process simpler, because
> we didn't need to worry about synchronizing the change of version
> strings within setup.cfg as we created our branches. A side-effect,
> though, is that the version from which we tag appears on both
> branches. That means that stable/$previous and master both have the
> same version for some period of time, and then stable/$previous
> receives a final tag and has a version newer than master. To
> compensate, we merge that final tag from stable/$previous into
> master (taking only the tag, without any of the code changes), so
> that master again has the same version.
>
>
> The Problem
> ---
>
> The tag may be merged into master after other changes have landed
> in master but not stable/$previous, and if those changes include
> release notes then reno will associate them with the newly merged
> tag, rather than the correct version number.
>
> Here's an example I have been using to test reno. In it, 3 separate
> reno notes are created on two branches. Note 1 is on master when
> it is tagged 1.0.0. Then master is branched and note 2 is added to
> the branch and tagged 1.1.0. Then the tag is merged into master and
> note 3 is added.
>
>   * af93946 (HEAD -> master, tag: 2.0.0) add slug-0003.yaml
>   * f78d1a2 add ignore-2.txt
>   *   4502dbd merge 1.1.0 tag into master
>   |\
>   | * bf50a97 (tag: 1.1.0, test_merge_tags) add slug-0002.yaml
>   * | 1e4d846 add ignore-1.txt
>   |/
>   * 9f481a9 (tag: 1.0.0) add slug-0001.yaml
>
> Before the tag is applied to note 3, it appears to be part of 1.1.0,
> even though it is not from the branch where that version was created
> and the version 1.1.0 is included in the release notes for master,
> even though that version should not really be a part of that series.
>
> Technically reno is doing the right thing, because even "git describe"
> honors the merged tag and treats commit f78d1a2 as 1.1.0-4-gaf93946.
> So because we've merged the version number into a different series
> branch, that version becomes part of that series.
>
>
> The Proposal
> 
>
> We should stop merging tags between branches, at all. Then our git
> branches will be nice and linear, without merges, and reno will
> associate the correct version number with each note.
>
> To compensate for the fact that master will have a lower version
> number after the branch, we can introduce a new alpha tag on master
> to raise its version. So, after creating stable/$series from version
> X.0.0.0rc1, we would tag the next commit on master with X+1.0.0.0a1.
> All subsequent commits on master would then be considered to be
> part of the X+1.0.0 series.

This seems to go back to the essence of pre-versioning. Instead of updating a 
string in a file, you've updated it as a tag. You've still got the coordination 
issues at release to deal with (when and what to tag) and the issue of knowing 
what the next release is before you've landed any patches that will be in that 
release.

Isn't the reason that the branch is merged back in because otherwise per can't 
generate a valid version number? You've "solved" that by hiding the release 
version number behind the new *a1 tag. Therefore, for any commit on the master 
branch, the only ancestor commits that are tagged will have the *a1 tags, and 
the actual release tags will never be reachable by walking up parent commits 
(assuming there is at least one commit on a release branch, which seems normal).



>
> Libraries and other projects that follow the cycle-with-intermediary
> release model won't need this treatment, because we're not using
> alpha or beta versions for them and they are tagged more often than
> the projects following the cycle-with-milestones model.
>
>
> Possible Issues
> ---
>
> We will be moving back to a situation where we have to orchestrate
> multiple operations when we create branches. Adding an extra tag
> isn't a lot of work, though, and it doesn't really matter what the
> commit is that gets the tag, so if there's 

Re: [openstack-dev] [Neutron] neutron-lib and dependencies in neutron reference implementation

[Gal Sagie]

For example references to the various different agents which are an
implementation details to me

On Wed, Jun 8, 2016 at 8:51 PM, Henry Gessau  wrote:

> Gal Sagie  wrote:
> > Hello all,
> >
> > I have recently came across some missing constants in neutron-lib and
> sent
> > a patch but i wanted to try and understand the scope of the lib.
> >
> > I see that the Neutron lib consist of many definitions which are actually
> > part of the reference implementation and are not really "generic" Neutron
> > parts.
>
> Can you give specific examples of 'not really generic' constants?
>
> > I am wondering if this is the right approach, especially since i think an
> > end goal is to split between the two (some day..)
> >
> > My suggestion would be to at least split these two in the neutron-lib,
> but maybe
> > i miss understood the scope of the lib
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

The G.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [tacker] Request to create puppet-tacker

[Sridhar Ramaswamy]

This is exciting. Thanks Dan for your contribution!

I hope to see a similar contribution for Tacker deployment using
openstack-ansible :)

- Sridhar

On Wed, Jun 8, 2016 at 8:18 AM, Dan Radez  wrote:

> FYI, tacker community:
> https://review.openstack.org/#/c/327173/
> https://review.openstack.org/#/c/327178/
>
> Radez
>
> On 06/08/2016 10:54 AM, Dan Radez wrote:
> > sure will, thx Emilien
> > Dan
> >
> > On 06/08/2016 09:08 AM, Emilien Macchi wrote:
> >> Yeah, super good news!
> >> Please do the same as I did in https://review.openstack.org/326720 and
> >> https://review.openstack.org/326721
> >>
> >> Add me as reviewer because I need to sign-off the 2 patches (I'm
> current PTL).
> >> Once it's done & merged, you'll be able to deprecate the old
> >> repository on your github with a nice README giving the link of the
> >> new module.
> >>
> >> I haven't looked at the code yet but we'll probably have to adjust
> >> some bits, add some testing (beaker [1], etc). Please make sure that
> >> we have some packaging available in RDO (I checked on Ubuntu and they
> >> don't provide it) so we can download it during our beaker tests.
> >>
> >> Also a last thing, in order to help us to make the module compliant &
> >> consistent, please read how we wrote the recent modules. For example
> >> you can look puppet-gnocchi or puppet-aodh that are clean modules.
> >> We recently had a lot of new modules: vitrage, watcher, tacker,
> >> congress, (I'm working now on octavia) - which means reviews might
> >> take more time than usual because our team will review the new modules
> >> carefuly to make sure the code is clean & consistent from beginning
> >> (and avoid the puppet-monasca story). Please be patient and help us by
> >> reading how we did other modules.
> >>
> >> Thanks a ton for your collaboration and we're looking forward for this
> >> new challenge,
> >>
> >> [1] https://github.com/puppetlabs/beaker
> >>
> >> On Wed, Jun 8, 2016 at 8:11 AM, Iury Gregory 
> wrote:
> >>> Awesome!
> >>>
> >>> You just need to follow the same process that Emilien pointed for
> >>> puppet-congress. If you need any help please let us know.
> >>>
> >>> 1- Move  https://github.com/radez/puppet-tacker to OpenStack
> >>> 2- Add it to our governance
> >>> 3- Follow
> >>>
> http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html
> >>>
> >>>
> >>>
> >>> 2016-06-08 8:56 GMT-03:00 Dan Radez :
> 
>  I also have puppet-tacker module that has existed before the project
> was
>  part of big tent.
> 
>  It was based on cookie cutter originally but will probably need some
>  adjustments to adhere to standards.
> 
>  I'd like to get the project establish so that the code can be run
>  through the proper review process.
> 
>  exiting repo is here: https://github.com/radez/puppet-tacker
> 
>  Dan Radez
>  freenode: radez
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> ~
> >>> Att[]'s
> >>> Iury Gregory Melo Ferreira
> >>> Master student in Computer Science at UFCG
> >>> E-mail:  iurygreg...@gmail.com
> >>> ~
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Austin summit priorities session recap

[Matt Riedemann]

On 6/8/2016 12:05 PM, Alexandre Levine wrote:

Hi Matt,

According to the state of this review:
https://review.openstack.org/#/c/317689/ the works aren't going to be
done in this cycle.

Do you think it'd be possible for our driver to cut in now?

Feodor participated in reviewing and helped as much as possible with
current efforts and if needed we can spare even more resources to help
with the refactoring in the next cycle.

Best regards,

  Alex Levine




Alex,

Unfortunately the spec for the scaleio image backend wasn't approved 
before the non-priority spec approval freeze so it's going to have to 
wait for Ocata.


I realize this is frustrating. We do already have 85 approved blueprints 
for Newton though including the libvirt imagebackend refactor which the 
scaleio change is going to be dependent on, so I still urge helping out 
with that in any way possible to move it along and make sure that 
dependency gets completed in Newton.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] OSIC cluster accepteed

[Vikram Hosakote (vhosakot)]

I'd like to help with kolla scaling on the OSIC cluster too.

Regards,
Vikram Hosakote
IRC: vhosakot

From: Jeffrey Zhang >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, June 8, 2016 at 9:42 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] OSIC cluster accepteed

Cool.
Do we have any test list now?
and how can i help for this? I am very interested in this
test.

On Tue, Jun 7, 2016 at 4:52 PM, Paul Bourke 
> wrote:
Michal,

I'd be interested in helping with this. Keep us updated!

-Paul


On 03/06/16 17:58, Michał Jastrzębski wrote:
Hello Kollagues,

Some of you might know that I submitted request for 130 nodes out of
osic cluster for testing Kolla. We just got accepted. Time window will
be 3 weeks between 7/22 and 8/14, so we need to make most of it. I'd
like some volunteers to help me with tests, setup and such. We need to
prepare test scenerios, streamline bare metal deployment and prepare
architectures we want to run through. I would also make use of our
global distribution to keep nodes being utilized 24h.

Nodes we're talking about are pretty powerful 256gigs of ram each, 12
ssd disks in each and 10Gig networking all the way. We will get IPMI
access to it so bare metal provisioning will have to be there too
(good time to test out bifrost right?:))

Cheers,
Michal

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][reno][infra] merging tags between branches is confusing our release notes

[Doug Hellmann]

tl;dr: The switch from pre-versioning to post-versioning means that
sometimes master appears to be older than stable/$previous, so we
merge "final" tags from stable/$previous into master to make up for
it. This introduces versions into the history of master that aren't
*really* there, but git sees them and so does reno. That, in turn,
means that the release notes generated from master may place some
notes in the wrong version, suggesting that something happened
sooner than it did. I propose that we stop merging tags, and instead
introduce a new tag on master after we create a branch to ensure
that the version number there is always higher than stable/$previous.


Background
--

Over the last year or so we've switched from pre-versioning (declaring
versions in setup.cfg) to post-versioning (relying solely on git
tags for versions). This made the release process simpler, because
we didn't need to worry about synchronizing the change of version
strings within setup.cfg as we created our branches. A side-effect,
though, is that the version from which we tag appears on both
branches. That means that stable/$previous and master both have the
same version for some period of time, and then stable/$previous
receives a final tag and has a version newer than master. To
compensate, we merge that final tag from stable/$previous into
master (taking only the tag, without any of the code changes), so
that master again has the same version.


The Problem
---

The tag may be merged into master after other changes have landed
in master but not stable/$previous, and if those changes include
release notes then reno will associate them with the newly merged
tag, rather than the correct version number.

Here's an example I have been using to test reno. In it, 3 separate
reno notes are created on two branches. Note 1 is on master when
it is tagged 1.0.0. Then master is branched and note 2 is added to
the branch and tagged 1.1.0. Then the tag is merged into master and
note 3 is added.

  * af93946 (HEAD -> master, tag: 2.0.0) add slug-0003.yaml
  * f78d1a2 add ignore-2.txt
  *   4502dbd merge 1.1.0 tag into master
  |\
  | * bf50a97 (tag: 1.1.0, test_merge_tags) add slug-0002.yaml
  * | 1e4d846 add ignore-1.txt
  |/
  * 9f481a9 (tag: 1.0.0) add slug-0001.yaml

Before the tag is applied to note 3, it appears to be part of 1.1.0,
even though it is not from the branch where that version was created
and the version 1.1.0 is included in the release notes for master,
even though that version should not really be a part of that series.

Technically reno is doing the right thing, because even "git describe"
honors the merged tag and treats commit f78d1a2 as 1.1.0-4-gaf93946.
So because we've merged the version number into a different series
branch, that version becomes part of that series.


The Proposal


We should stop merging tags between branches, at all. Then our git
branches will be nice and linear, without merges, and reno will
associate the correct version number with each note.

To compensate for the fact that master will have a lower version
number after the branch, we can introduce a new alpha tag on master
to raise its version. So, after creating stable/$series from version
X.0.0.0rc1, we would tag the next commit on master with X+1.0.0.0a1.
All subsequent commits on master would then be considered to be
part of the X+1.0.0 series.

Libraries and other projects that follow the cycle-with-intermediary
release model won't need this treatment, because we're not using
alpha or beta versions for them and they are tagged more often than
the projects following the cycle-with-milestones model.


Possible Issues
---

We will be moving back to a situation where we have to orchestrate
multiple operations when we create branches. Adding an extra tag
isn't a lot of work, though, and it doesn't really matter what the
commit is that gets the tag, so if there's nothing on master beyond
the point where a branch needs to be created we can add a minor
change somewhere just to have something to tag.

fungi pointed out that if we backport anything by using a fast-forward
merge from master to stable/$previous, we will pull the newer version
number back into the older series. We already have that issue,
today, though, for anything backported after the first milestone.
So while we're shrinking the safe window period, this is not a new
problem.

Some cycle-with-milestone projects may not merge commits into master
very soon after their branches are created. We can address that by
waiting, or by introducing a small commit just for the purpose of
having something to tag.


Alternatives


Do nothing and live with some of our early release notes in a version
being "not quite right." I don't consider this acceptable.

Switch back to pre-versioning. We dropped this for a good reason,
it makes synchronizing all of the actions needed to create a release
branch a real 

Re: [openstack-dev] [Trove] Stepping down from Trove Core

[Amrith Kumar]

Victoria,

Thank you very much for your contribution to Trove. All the very best to you 
and the projects you will be working on.

-amrith


From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com]
Sent: Tuesday, June 07, 2016 2:34 PM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [Trove] Stepping down from Trove Core


After one year and a half contributing to the Trove project,

I have decided to change my focus and start gaining more experience

on other storage and data-management related projects.



Because of this decision, I'd like to ask to be removed from the Trove core 
team.



I want to thank Trove community for all the good work and shared experiences.

Working with you all has been a very fulfilling experience.



All the best,



Victoria
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][reno][infra] merging tags between branches is confusing our release notes

[Doug Hellmann]

Excerpts from John Dickinson's message of 2016-06-08 11:30:03 -0700:
> 
> On 8 Jun 2016, at 11:13, Doug Hellmann wrote:
> 
> > tl;dr: The switch from pre-versioning to post-versioning means that
> > sometimes master appears to be older than stable/$previous, so we
> > merge "final" tags from stable/$previous into master to make up for
> > it. This introduces versions into the history of master that aren't
> > *really* there, but git sees them and so does reno. That, in turn,
> > means that the release notes generated from master may place some
> > notes in the wrong version, suggesting that something happened
> > sooner than it did. I propose that we stop merging tags, and instead
> > introduce a new tag on master after we create a branch to ensure
> > that the version number there is always higher than stable/$previous.
> >
> >
> > Background
> > --
> >
> > Over the last year or so we've switched from pre-versioning (declaring
> > versions in setup.cfg) to post-versioning (relying solely on git
> > tags for versions). This made the release process simpler, because
> > we didn't need to worry about synchronizing the change of version
> > strings within setup.cfg as we created our branches. A side-effect,
> > though, is that the version from which we tag appears on both
> > branches. That means that stable/$previous and master both have the
> > same version for some period of time, and then stable/$previous
> > receives a final tag and has a version newer than master. To
> > compensate, we merge that final tag from stable/$previous into
> > master (taking only the tag, without any of the code changes), so
> > that master again has the same version.
> >
> >
> > The Problem
> > ---
> >
> > The tag may be merged into master after other changes have landed
> > in master but not stable/$previous, and if those changes include
> > release notes then reno will associate them with the newly merged
> > tag, rather than the correct version number.
> >
> > Here's an example I have been using to test reno. In it, 3 separate
> > reno notes are created on two branches. Note 1 is on master when
> > it is tagged 1.0.0. Then master is branched and note 2 is added to
> > the branch and tagged 1.1.0. Then the tag is merged into master and
> > note 3 is added.
> >
> >   * af93946 (HEAD -> master, tag: 2.0.0) add slug-0003.yaml
> >   * f78d1a2 add ignore-2.txt
> >   *   4502dbd merge 1.1.0 tag into master
> >   |\
> >   | * bf50a97 (tag: 1.1.0, test_merge_tags) add slug-0002.yaml
> >   * | 1e4d846 add ignore-1.txt
> >   |/
> >   * 9f481a9 (tag: 1.0.0) add slug-0001.yaml
> >
> > Before the tag is applied to note 3, it appears to be part of 1.1.0,
> > even though it is not from the branch where that version was created
> > and the version 1.1.0 is included in the release notes for master,
> > even though that version should not really be a part of that series.
> >
> > Technically reno is doing the right thing, because even "git describe"
> > honors the merged tag and treats commit f78d1a2 as 1.1.0-4-gaf93946.
> > So because we've merged the version number into a different series
> > branch, that version becomes part of that series.
> >
> >
> > The Proposal
> > 
> >
> > We should stop merging tags between branches, at all. Then our git
> > branches will be nice and linear, without merges, and reno will
> > associate the correct version number with each note.
> >
> > To compensate for the fact that master will have a lower version
> > number after the branch, we can introduce a new alpha tag on master
> > to raise its version. So, after creating stable/$series from version
> > X.0.0.0rc1, we would tag the next commit on master with X+1.0.0.0a1.
> > All subsequent commits on master would then be considered to be
> > part of the X+1.0.0 series.
> 
> This seems to go back to the essence of pre-versioning. Instead of updating a 
> string in a file, you've updated it as a tag. You've still got the 
> coordination issues at release to deal with (when and what to tag) and the 
> issue of knowing what the next release is before you've landed any patches 
> that will be in that release.

This only affects milestone-based projects, and all of them are
currently raising their major version number each cycle to indicate the
cycle boundary. So it's easy to know what the next version will be.

It's not quite as burdensome as the post-versioning thing we were
doing because it's not necessary to commit something *before*
creating the branch or starting the release candidate phase.

> 
> Isn't the reason that the branch is merged back in because otherwise per 
> can't generate a valid version number?

I don't think it's related to versions being "valid," but to making
things feel less confusing to human consumers at the expense of
(what I think is) giving a misleading picture of the version history.

We started merging the tags between branches because the version
that ends up in the 

Re: [openstack-dev] [Neutron] neutron-lib and dependencies in neutron reference implementation

[Henry Gessau]

Gal Sagie  wrote:
> Hello all,
> 
> I have recently came across some missing constants in neutron-lib and sent
> a patch but i wanted to try and understand the scope of the lib.
> 
> I see that the Neutron lib consist of many definitions which are actually
> part of the reference implementation and are not really "generic" Neutron
> parts.

Can you give specific examples of 'not really generic' constants?

> I am wondering if this is the right approach, especially since i think an
> end goal is to split between the two (some day..)
> 
> My suggestion would be to at least split these two in the neutron-lib, but 
> maybe
> i miss understood the scope of the lib


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Virtual midcycle date poll

[Jim Rollenhagen]

And, as a note, I've added an RSVP and details on communication channels
and such on the etherpad.

Details are also on the wiki now:
https://wiki.openstack.org/wiki/VirtualSprints#Ironic_Virtual_Newton_Midcycle
https://wiki.openstack.org/wiki/Sprints#Future_sprints_for_Newton

// jim

On Mon, Jun 06, 2016 at 11:10:19AM -0400, Jim Rollenhagen wrote:
> By the way, I created an etherpad for the midcycle to start bringing in
> ideas. You know what to do. :)
> 
> https://etherpad.openstack.org/p/ironic-newton-midcycle
> 
> // jim
> 
> On Wed, Jun 01, 2016 at 02:45:33PM -0400, Jim Rollenhagen wrote:
> > On Thu, May 19, 2016 at 09:25:18AM -0400, Jim Rollenhagen wrote:
> > > Hi Ironickers,
> > > 
> > > We decided in our last meeting that the midcycle for Newton will again
> > > be virtual. Now, we need to choose a date. Please indicate which options
> > > work for you (more than one may be selected):
> > > 
> > > http://doodle.com/poll/gpug7ynd9fn4rdfe
> > > 
> > > I'll close this poll two Mondays from now, May 30.
> > > 
> > > Note that this will be similar to the last midcycle; likely split up
> > > into two sessions. Last time was 1500-2000 UTC and -0400 UTC. If
> > > that worked for folks, we'll do the same times again.
> > 
> > June 20-22 won, with the votes being 18 to 14.
> > 
> > The actual dates UTC will be something like:
> > 
> > June 20 1500-2000
> > June 21 -0400
> > June 21 1500-2000
> > June 22 -0400
> > June 22 1500-2000
> > June 23 -0400
> > 
> > I'll send out communication channels and such before the end of next
> > week.
> > 
> > See you all there!
> > 
> > // jim
> > 
> > > 
> > > Thanks!
> > > 
> > > // jim
> > > 
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [meghdwar] Base code to use

[prakash RAMCHANDRAN]

Hi all,Appreciate the initiative taken by individuals to join and discuss the 
possibility of using codes from different Cloudlet projects.We know the 
requirements cross the boundaries of Nova and Neutron and hence the chalenge is 
to ensure we have a better specification.Thus reviewing codes will give us the 
state of ark of Cloudlet, but we need to persue ause case that will be simple 
and commercially useful for providers to use the megdwar cloudlet platform as a 
service. The Edge Cloud Services differ from Central cloud even under MEC, OEC, 
OpenFog to name a few. IOT archietcures require an Aggregator and host gateway 
at edge to offer IOT services. Thus all road lead to Edge Application gateway 
services. Lets first study few we have at hand and plan for code init and 
migrations accordingly.refer
https://wiki.openstack.org/wiki/Meghdwar
Here are details and lets debate till next meetingNext meeting: Meghdwar on irc 
June 15th 7am-8am PDT #opnestack-meghdwarMeetings: Wednesday's from 7-8am PDT 
(Wed 14:00-15:00 UTC) irc Channel : #openstack-meghdwarMeghdwar-irc June 8th 
7am-8am PDT #opnestack-meghdwar summaryTopic : What is meghdwarlink 
https://launchpad.net/meghdwar This is a follow up project to create a project 
for Edge Cloud Services im Openstack Earlier effort for a Micro Service API as 
Cloud let failed link https://launchpad.net/cloudlet Cloudlet as defined by 
CMU/OEC is a VM at the edge supporting AR/VR applications In a three tier the 
client is an UE/Mobile equipment/Smartphone with client and connecting to edge 
Cloudlet The edge cloudlet serves the AR/VR application from within the VM The 
Central Cloud is where you may register and downlaod applications or apps link 
http://beyondtheclouds.github.io/ Review the Video of Discovery initiative, 
mainly supported through the Inria Project Labs program and the I/O labs, a 
joint lab between Inria and Orange Labs. The aim of project is to try build 
sustainable (power reduction) network Pops distrubuted as IaaS.The 8 minute 
video shows how openstack is used to deliver the Discovery service with Nova 
and Redis in-meory data structure stores. link 
https://hal.inria.fr/hal-01320235 Revising OpenStack Internals to Operate 
Massively Distributed Clouds is on this link.action on satyak - Support to 
resolve Devstack ticket for Mitaka action on prakash - Ask Kiryong Ha CMU to 
provide bitucket access to Cloudlet code for Proevisioning and Openstack 
projects in CMU ija or OEC action on prakash/ad_rien - Review 
beyondclouds.github.io and work with ad_rien to see if we can use it along 
CMU/OEC Cloudlet or independednt of itNext meeting same time Wednesday 7AM-8 AM 
PDT /Attendees: ad_rien: adrien.le...@inria.fr pramchan: pramc...@yahoo.com 
narinder: narinder.gu...@canonical.com satyak: satyavit...@gmail.com
ThanksPrakash
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[OpenStack-Infra] Fwd: JJB 1.6.0 "Cannot create a file when that file already exists"

[Sebastian Schuberth]

Hi,

since upgrading to JJB 1.6.0 from 1.5.0 today I consistently get
"Cannot create a file when that file already exists" errors on update
/ delete operations on Windows. The stack trace looks like

$ jenkins-jobs delete github-checker.yaml
INFO:jenkins_jobs.builder:Removing jenkins job(s): github-checker.yaml
Traceback (most recent call last):
  File "c:\python27\lib\runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "c:\python27\lib\runpy.py", line 72, in _run_code
exec code in run_globals
  File "C:\Python\Scripts\jenkins-jobs.exe\__main__.py", line 9, in 
  File "c:\python27\lib\site-packages\jenkins_jobs\cmd.py", line 191, in main
execute(options, config)
  File "c:\python27\lib\site-packages\jenkins_jobs\cmd.py", line 357, in execute
builder.delete_job(job, options.path)
  File "c:\python27\lib\site-packages\jenkins_jobs\builder.py", line
322, in delete_job
self.cache.save()
  File "c:\python27\lib\site-packages\jenkins_jobs\builder.py", line
113, in save
self._os.rename(tfile.name, self.cachefilename)
WindowsError: [Error 183] Cannot create a file when that file already exists
ERROR:jenkins_jobs.builder:Failed to write to cache file
'C:\Users\name\.cache\jenkins_jobs\cache-host-jobs-https___hostname_com_.yml'
on exit: [Error 183] Cannot create a file when that file already
exists

Is anyone else seeing this?

--
Sebastian Schuberth

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[Openstack-operators] DVR (kilo) connecting subnets in different routers

[Gustavo Randich]

Hi,

(Using Kilo/DVR)

I want to connect two tenant subnets which are connected to different
routers.

I had to add a port in tenant-network1 as an interface in router2 and a
port in tenant-network2 as an interface in router1 to make it work. I.e.,
if I only add network1 to router2, DVR does not route back the traffic.

Is this expected?

Thanks


# CREATE ROUTER / NETWORK 1
neutron net-create tenant-network1
neutron subnet-create tenant-network1 10.97.0.0/25 --name subnet1 --gateway
10.97.0.1
neutron router-create router1
neutron router-gateway-set router1 admin-external-vlan
neutron router-interface-add router1 subnet1

# CREATE ROUTER / NETWORK 2
neutron net-create tenant-network2
neutron subnet-create tenant-network2 10.97.2.0/25 --name subnet2 --gateway
10.97.2.1
neutron router-create router2
neutron router-gateway-set router2 admin-external-vlan
neutron router-interface-add router2 subnet2

# CONNECT SUBNET 1 & 2
neutron port-create tenant-network1 # capture portid
neutron router-interface-add router2 port=$portid
neutron port-create tenant-network2 # capture portid
neutron router-interface-add router1 port=$portid
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [puppet] vision on new modules

[Emilien Macchi]

Hi folks,

Over the last months we've been creating more and more modules [1] [2]
and I would like to take the opportunity to continue some discussion
we had during the last Summits about the quality of our modules.

[1] octavia, vitrage, ec2api, tacker, watcher, congress, magnum,
mistral, zaqar, etc.
[2] by the end of Newton, we'll have ~ 33 Puppet modules !

Announce your work
As a reminder, we have defined a process when adding new modules:
http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html
This process is really helpful to scale our project and easily add modules.
If you're about to start a new module, I suggest you to start this
process and avoid to start it on your personal github, because you'll
loose the valuable community review on your work.

Iterate
I've noticed some folks pushing 3000 LOC in Gerrit when adding the
bits for new Puppet modules (after the first cookiecutter init).
That's IMHO bad, because it makes reviews harder, slower and expose
the risk of missing something during the review process. Please write
modules bits by bits.
Example: start with init.pp for common bits, then api.pp, etc.
For each bit, add its unit tests & functional tests (beaker). It will
allow us to write modules with good design, good tests and good code
in general.

Write tests
A good Puppet module is one that we can use to successfully deploy an
OpenStack service. For that, please add beaker tests when you're
initiating a module. Not at the end of your work, but for every new
class or feature.
It helps to easily detect issues that we'll have when running Puppet
catalog and quickly fix it. It also helps community to report feedback
on packaging, Tempest or detect issues in our libraries.
If you're not familiar with beaker, you'll see in existing modules
that there is nothing complicated, we basically write a manifest that
will deploy the service.


If you're new in this process, please join our IRC channel on freenode
#puppet-openstack and don't hesitate to poke us.

Any feedback / comment is highly welcome,
Thanks,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-announce] [new][puppet] puppet-sahara 9.0.0 release (newton)

[no-reply]

We are eager to announce the release of:

puppet-sahara 9.0.0: Puppet module for OpenStack Sahara

This release is part of the newton release series.

For more details, please see below.

9.0.0
^


New Features


* Add support for oslo_messaging_amqp backend via puppet-oslo
  resource

* Add openstack-db tag to Exec that run db-sync.

* Switch to puppet-oslo resource usage (instead of manual
  configuration file editing).


Deprecation Notes
*

* verbose option is now deprecated for removal, the parameter has no
  effect.


Other Notes
***

* Drop all Qpid support, it was removed from Oslo in Mitaka.

Changes in puppet-sahara 8.0.0..9.0.0
-

52fa78e Cleanup README
9f986a6 Change wiki to docs
36d4233 Prepare 9.0.0 release
0611bb6 Revert "Deprecate use_syslog"
75561b6 Deprecate use_syslog
951083a Add other-requirements.txt for bindep
67cd93a Deprecate verbose option in logging
41df393 Introduce support for oslo.messaging amqp driver configuration
e9662c9 Add kombu_failover_strategy and kombu_compression options
d0bade5 Add 'openstack-db' tag to db-sync Exec resource
ce60148 Fix markdown format typo
0d4b0cc Add support for db_max_retries param
e5f369e Test multiple operating systems for db
b4290d3 Totally drop Qpid support
0ce1456 Enable Sahara testing on Ubuntu
0008bc5 Update Sahara for using puppet-oslo
071f543 Do not raise error when ca_file is not passed
bf3789b Import release notes from stable/mitaka
960f81b Gemfile: rely on puppet-openstack_spec_helper for dependencies
1f456e1 acceptance: disabling testing on ubuntu

Diffstat (except docs and test files)
-

Gemfile|  23 +-
README.md  |  14 +-
examples/basic.pp  |   1 -
manifests/db.pp|  53 +---
manifests/db/sync.pp   |   1 +
manifests/init.pp  | 339 -
manifests/logging.pp   |  58 ++--
manifests/notify.pp|  16 +-
manifests/params.pp|   2 -
manifests/policy.pp|   2 +
metadata.json  |   7 +-
other-requirements.txt |   0
.../add_oslo_messaging_amqp-2969450d2f6f1f5e.yaml  |   3 +
releasenotes/notes/drop_qpid-2aa008638bbdee5b.yaml |   3 +
.../notes/openstack_db_tag-acac480da506925b.yaml   |   3 +
.../notes/switch_to_oslo-4ebb3a914d2d8b4e.yaml |   4 +
.../verbose-deprecation-2cc63616acbfd49e.yaml  |   4 +
releasenotes/source/conf.py|   4 +-
releasenotes/source/index.rst  |   1 +
releasenotes/source/mitaka.rst |   6 +
spec/acceptance/basic_sahara_spec.rb   |   6 +-
spec/classes/sahara_db_postgresql_spec.rb  |  48 +--
spec/classes/sahara_db_spec.rb |   9 +-
spec/classes/sahara_db_sync_spec.rb|  39 +--
spec/classes/sahara_init_spec.rb   |  99 --
spec/classes/sahara_logging_spec.rb|   6 +-
spec/classes/sahara_notify_spec.rb |  16 +-
spec/classes/sahara_policy_spec.rb |   1 +
28 files changed, 412 insertions(+), 356 deletions(-)


Requirements updates


diff --git a/other-requirements.txt b/other-requirements.txt
new file mode 100644
index 000..e69de29



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [new][puppet] puppet-swift 9.0.0 release (newton)

[no-reply]

We are overjoyed to announce the release of:

puppet-swift 9.0.0: Puppet module for OpenStack Swift

This release is part of the newton release series.

For more details, please see below.

9.0.0
^

Add hooks for external install & svc management.

This is the first Mitaka release for puppet-swift module.

puppet-swift supports Ubuntu 16.04 xenial


New Features


* Add ability to configure container_sync middleware.

* Add ability to manage swift container-sync-realms config for
  specifying the allowable clusters and their information.

* This adds defined anchor points for external modules to hook into
  the software install, config and service dependency chain. This
  allows external modules to manage software installation (virtualenv,
  containers, etc) and service management (pacemaker) without needing
  rely on resources that may change or be renamed.

* Update Ceilometer proxy to support Oslo Messaging.

* Allow to manage Swift service with swiftinit service provider.
  This is an initial step towards using swift-init to manage multiple
  swift services out of different configuration files such as is
  needed to run a separate replication network.

* swift-ring-builder 2.2.2+ output parsing support.

* Add support to change meta entry for ring devices.

* Release notes are no longer maintained by hand, we now use the
  reno tool to manage them.

* Previous version of puppet-swift hard coded upstart for ubuntu,
  that restriction is removed for ubuntu now.  xenial will use systemd
  by default. 'swiftinit' service provider now also supports xenial
  using systemd for service start at boot control.


Deprecation Notes
*

* Create ring builders under swift user instead of root.

* Change defaults fro incoming/outgoing chmod for rsync. Defaults
  are now Du=rwx,g=rx,o=rx,Fu=rw,g=r,o=r.

* Set mount_check to True by default.

* Stop calling ::concat::setup, that is a deprecate class.

* swift_hash_suffix is now deprecated and swift_hash_path_suffix
  with swift_hash_path_prefix should be used.


Other Notes
***

* remove swift_hash_suffix deprecated in Mitaka and change tests to
  use swift_hash_path_suffix.

Changes in puppet-swift 8.0.0b1..9.0.0
--

2d84cf4 Remove deprecated swift_hash_suffix
7b5fde7 Cleanup README
2311832 Change wiki to docs
557fdc3 Prepare 9.0.0 release
ec4db84 Allow to configure container_sync middleware
7dac7b8 increase the maximum version of concat
c659733 Add hooks for external install & svc management
056e257 Add keystone to swift-proxy, use dispersion-report
a94df7b Fix tests for concat 2.1.0
92b3e6e Add other-requirements.txt for bindep
9ecbada Remove verbose
df59fcb Grammar corrections in comment
5323bf8 Swift-ring-builder skip line 'Ring up-to-date..'
d705401 Support xenial with swift-init service provider
5785a28 Do not use any specific service provider for ubuntu
f569ed0 Fix up some typos in the proxy manifests
1c91097 Replace File with Concat in dependencies
80eff15 Fix unit tests failing against Puppet 4.3.0
a24f850 Add Unit Tests for Swift_config type
6a43438 Keystone endpoints should go before the service
b70f528 Gemfile: rely on puppet-openstack_spec_helper for dependencies
379d9fc Add rmq credentials to each host in proxy
56d14a6 Import release notes from stable/mitaka
76e1be1 Release 8.0.0
ed6c23a releasenotes: add notes for Mitaka cycle
d0cfff2 Add basic structure for ReNo
07d9a99 typos and grammar fixes in the README
ed5dfad fix rst in README

Diffstat (except docs and test files)
-

.gitignore |   4 +
CHANGELOG.md   |   5 +
Gemfile|  24 +-
README.md  |  81 ---
lib/puppet/provider/service/swiftinit.rb   |  61 ++---
.../ini_setting.rb |  10 +
lib/puppet/provider/swift_ring_builder.rb  |   4 +
.../type/swift_container_sync_realms_config.rb |  53 +
manifests/auth_file.pp |   3 +
manifests/bench.pp |   2 +
manifests/client.pp|   3 +-
manifests/config.pp|  10 +-
manifests/deps.pp  |  59 +
manifests/dispersion.pp|  12 +-
manifests/init.pp  |  48 ++--
manifests/keystone/auth.pp |  11 +
manifests/keystone/dispersion.pp   |   2 +
manifests/objectexpirer.pp |   1 +
manifests/params.pp|   6 +-
manifests/proxy.pp |   1 +
manifests/proxy/account_quotas.pp  |   3 +
manifests/proxy/authtoken.pp   |   4 +
manifests/proxy/bulk.pp|   3 +

[openstack-dev] [nova] Initial oslo.privsep conversion?

[Matt Riedemann]

While sitting in Angus' cross-project session on oslo.privsep at the 
Austin summit I believe I had a conversation with myself in my head that 
Nova should stop adding new rootwrap filters and anything new should use 
oslo.privsep.


For example:

https://review.openstack.org/#/c/182257/

However, we don't have anything in Nova using oslo.privsep directly. We 
have os-brick and soon we'll have os-vif using oslo.privsep, but those 
are indirect.


Looking at the change in Neutron for using privsep [1] it's pretty 
complicated. So I'm struggling with requiring new changes to Nova that 
require new rootwrap filters to use privsep when we don't have an 
example in tree of how to do this.


Is anyone working on something like that yet that I haven't seen? If 
not, has anyone thought about doing something or is interested in doing 
it? Because I don't think it's really fair to prevent new things until 
that happens - although the flip side to that is there isn't an example 
until someone is forced to do it.


Other thoughts? Is anyone willing to help here? I'm assuming there will 
need to be hand-holding from Angus at least initially.


[1] https://review.openstack.org/#/c/155631/

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-announce] [new][puppet] puppet-oslo 9.0.0 release (newton)

[no-reply]

We are pumped to announce the release of:

puppet-oslo 9.0.0: Puppet module for Oslo

This is the first release of puppet-oslo. This release is part of the
newton release series.

For more details, please see below.

9.0.0
^

First release of puppet-oslo.

Changes in puppet-oslo 37042fd4884cce2af4bab06e4336f2bf45b23698..9.0.0
--

4dc92c6 metadata.json: fix module name
e4a3303 Prepare 9.0.0 release
70163b3 Change wiki to docs
79405c9 Support pylibmc and memcache cache backend
0667a56 Added transport URL example from oslo.messaging docs
60663a9 Fix the version dependencies of openstacklib
df24567 Add other-requirements.txt for bindep
e7aa897 Add structure for reno
a868b0b Enable SSL proxy middleware configuration
cafe848 Add oslo.middleware defines
b3d13ee Deprecate verbose option in logging
b79dda8 Totally drop Qpid support
678fd92 Implement oslo::service define
93e9470 Switch oslo to use rspec-puppet-facts
004b813 Refactor array values processing
a3853cf Add "rpc_response_timeout" to oslo::messaging::default define
b4c9d6a Update oslo::policy define
f019bba Add oslo::messaging::default define
5321163 Update oslo::concurrency define
bf40ad3 Update oslo::cache define
a06fbf0 Improvements for oslo::db define
8ae52af Improvements for oslo::log define
887def4 Add ability to configure oslo_messaging_notifications
ab9e2c8 Gemfile: rely on puppet-openstack_spec_helper for dependencies
151b161 Fix define name to oslo::messaging::rabbit
5b4a439 Fix values for rabbit_hosts
14b9a2d Rework oslo-messaging-rabbit class
e913e8e Add define oslo::messaging::amqp
b0bfb22 docs: Update README.md to point to new Beaker URL
83062c3 Fix multiple bugs in puppet-oslo
4f93244 Add define oslo::db.
c961197 Change default value to $::os_service_default
6ad427b Add define oslo::policy
62a468a Add spec_helper and spec_helper_acceptance file
166914f Collect versions of oslo libraries in Tuskar
a0e5491 Collect versions of oslo libraries in Zaqar
ed1c9f6 Collect versions of oslo libraries in Sahara
c6a508c Collect versions of oslo libraries in Rally
6a8058c Add rspec test for oslo::versionedobjects
338d766 Use is_service_default for the warning message.
c9324e1 Add some logging related parameters.
27b56d3 Collect versions of oslo libraries in Murano
8d5ce99 Collect versions of oslo libraries in Tempest
0f4cab1 Collect versions of oslo libraries in Mistral
63bbb79 Collect versions of oslo libraries in Ironic
cfdee70 Collect versions of oslo libraries in Ironic
a730e0f Collect versions of oslo libraries in Gnocchi
b7b066e Collect versions of oslo libraries in barbican
a0167b0 Collect versions of oslo libraries in Aodh
1e441e4 Add define oslo::log
787a7b6 Collect versions of oslo libraries in Swift
27e7f82 Add define oslo::versionedobjects
2ae2cc2 Change defualt value and fix some mistakes
feb5132 Add define oslo::concurrency
f136c86 Collect versions of oslo libraries in Trove
3f187ca Collect versions of oslo libraries in Neutron
49989f0 Collect versions of oslo libraries in Manila
ba550f7 Collect versions of oslo libraries in Keystone
bb5c566 Collect versions of oslo libraries in Heat
2d5594c Collect versions of oslo libraries in Glance
919d8fa Clean up unused rspec test
f0c8632 Add versions of oslo libraries in Designate
b86091e Add define oslo::messaging_rabbit
11c109f Add list of openstack project oslo version
59387cc Add define oslo::cache



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [new][ironic] ironic-inspector 2.2.7 release (liberty)

[no-reply]

We are psyched to announce the release of:

ironic-inspector 2.2.7: Hardware introspection for OpenStack Bare
Metal

This release is part of the liberty stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/ironic-inspector

Please report issues through launchpad:

http://bugs.launchpad.net/ironic-inspector

For more details, please see below.

Changes in ironic-inspector 2.2.6..2.2.7


d821c1d Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b2bb718..4407f49 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -14 +14 @@ python-ironicclient>=0.8.0
-python-keystoneclient!=1.8.0,>=1.6.0
+python-keystoneclient!=1.8.0,<3.0.0,>=1.6.0



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-dev] [release][reno] FAQ: Why is reno showing notes for released versions on the "unreleased.html" page?

[Doug Hellmann]

I've had several people notice recently that release notes on the
"unreleased.html" page are actually including notes from the mitaka
release. This is because of the instructions we're giving reno.

First, the "unreleased.rst" page is poorly named (my fault). It is
actually the "current" branch, as the title inside the rst file
indicates. The instructions given to reno via the directives in
that file tell it to scan the "current" branch, whatever that happens
to be.

We need it to do that to test the release notes build with a patch
under review, because while the patch is still under review it does
not live on any of the named branches (it's not on master until
it's merged into master, etc.). So, in order to ensure that new
release notes do not break the HTML build, we test them on this
special page.

As reno scans a branch, it looks for all versions visible down the
linear history of that branch. It happens that now our master
branches include multiple versions in their history with release
notes, and so reno reports all of them.

This may also occur on future stable branches, since the history
for stable/newton will include the version tagged to create the
branch for stable/mitaka.  If you would prefer that "newton.html"
page not include older versions, you can add the "earliest-version"
parameter to the release-notes directive to specify a version where
reno should stop. [1]

Setting the "earliest-version" on the page that scans the current
branch may result in notes being left out of the test build, so
please do not do that.

Doug

[1] 
http://docs.openstack.org/developer/reno/sphinxext.html#directive-release-notes

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[OpenStack-Infra] Trouble deploying a job with a Groovy postbuild step via JJB

[Sebastian Schuberth]

Hi,

using JJB 1.5.0 and Jenkins 2.5 I cannot get Groovy postbuild steps to
work. My YAML file has:

- job:
# ...
publishers:
- groovy-postbuild: |
def summary = manager.createSummary('completed.gif')
def results = new File(manager.build.workspace.remote,
'results.txt').text
results = results.replace("\n", '')
results = results.replace('false', 'false')
results = results.replace('true', 'true')
summary.appendText(results, false)

Calling "jenkins-jobs test" seems to correctly generate XML which has:

  

  0
  false