[openstack-dev] [Neutron] BGP support

[Gary Kotton]

Hi,
In the M cycle BGP support was added in tree. I have seen specs in the L2 GW 
project for this support too. Are we planning to consolidate the efforts? Will 
the BGP code be moved from the Neutron git to the L2-GW project? Will a new 
project be created?
Sorry, a little in the dark here and it would be nice if someone could please 
provide some clarity here. It would be a pity that there were competing efforts 
and my take would be that the Neutron code would be the single source of truth 
(until we decide otherwise).
I think that the L2-GW project would be a very good place for that service code 
to reside. It can also have MPLS etc. support. So it may be a natural fit.
Thanks
Gary
__
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] [tricircle] playing tricircle with two node configuration

[Yipei Niu]

Hi, all,

After I execute the command "nova boot --flavor 1 --image
c30b097c-b185-4f70-9fcd-09ffdaee5793 --nic
net-id=a9059cde-3065-4615-859a-facd6aa66b76 --availability-zone az1 vm1",
there exist some problem with the argument port. In t-ngw.log, I find that
the status of port switches from ACTIVE to DOWN, which is marked as bold
below. Is it the reason why I failed to boot a VM?

2016-03-28 11:49:44.026 ^[[00;32mDEBUG neutronclient.client
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
http://192.168.56.101:9696//v2.0/ports.json -X POST -H "User-Agent:
python-neutronclient" -H "X-Auth-Token: 7cfcfb91173a4920adaf24db7eebd773"
-d '{"port": {"network_id": "a9059cde-3065-4615-859a-facd6aa66b76",
"admin_state_up": true}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
2016-03-28 11:49:44.254 ^[[00;32mDEBUG neutronclient.client
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
'application/json; charset=UTF-8', 'Content-Length': '384',
'X-Openstack-Request-Id': 'req-b824dc9e-2fcf-4922-96a5-83beb1f0bff3'}
{"port": {*"status": "ACTIVE"*, "name": "", "admin_state_up": true,
"network_id": "a9059cde-3065-4615-859a-facd6aa66b76", "tenant_id":
"29a524d386754a94850277afea1e569f", "device_owner": "", "mac_address":
"fa:16:3e:11:bd:09", "fixed_ips": [{"subnet_id":
"2bb5f6fd-01b5-4ad3-ac41-eb8a89a6323d", "ip_address": "10.0.8.5"}], "id":
"e27dc15d-188f-4d60-a38c-f48052d6330b", "device_id": ""}}^[[00m
^[[00;33mfrom (pid=17537) http_log_resp
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
2016-03-28 11:49:44.277 ^[[00;32mDEBUG neutronclient.client
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
admin^[[00;32m] ^[[01;35m^[[00;32mREQ: curl -i
http://192.168.56.101:20001//v2.0/ports.json -X POST -H "User-Agent:
python-neutronclient" -H "X-Auth-Token: 7cfcfb91173a4920adaf24db7eebd773"
-d '{"port": {"name": "e27dc15d-188f-4d60-a38c-f48052d6330b",
"admin_state_up": true, "network_id":
"25ebd3c0-ae47-4e77-be35-16d815bffe5c", "tenant_id":
"29a524d386754a94850277afea1e569f", "mac_address": "fa:16:3e:11:bd:09",
"fixed_ips": [{"subnet_id": "fd1abd0d-9398-4848-a3cf-57858868a480",
"ip_address": "10.0.8.5"}]}}'^[[00m ^[[00;33mfrom (pid=17537) http_log_req
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:141^[[00m
2016-03-28 11:49:44.669 ^[[00;32mDEBUG neutronclient.client
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
admin^[[00;32m] ^[[01;35m^[[00;32mRESP: 201 {'Date': 'Mon, 28 Mar 2016
03:49:44 GMT', 'Connection': 'keep-alive', 'Content-Type':
'application/json; charset=UTF-8', 'Content-Length': '808',
'X-Openstack-Request-Id': 'req-d286f85c-bc4b-4d7c-9915-666fe13b48b5'}
{"port": {*"status": "DOWN"*, "binding:host_id": "",
"allowed_address_pairs": [], "dns_assignment": [{"hostname":
"host-10-0-8-5", "ip_address": "10.0.8.5", "fqdn":
"host-10-0-8-5.openstacklocal."}], "device_owner": "", "binding:profile":
{}, "port_security_enabled": true, "fixed_ips": [{"subnet_id":
"fd1abd0d-9398-4848-a3cf-57858868a480", "ip_address": "10.0.8.5"}], "id":
"0bbf77a4-c4e4-43ad-89a0-e55f053ef4da", "security_groups":
["16f02958-2a4f-4f58-b560-b9fa76be1b0c"], "device_id": "", "name":
"e27dc15d-188f-4d60-a38c-f48052d6330b", "admin_state_up": true,
"network_id": "25ebd3c0-ae47-4e77-be35-16d815bffe5c", "dns_name": "",
"binding:vif_details": {}, "binding:vnic_type": "normal",
"binding:vif_type": "unbound", "tenant_id":
"29a524d386754a94850277afea1e569f", "mac_address":
"fa:16:3e:11:bd:09"}}^[[00m ^[[00;33mfrom (pid=17537) http_log_resp
/usr/local/lib/python2.7/dist-packages/neutronclient/common/utils.py:150^[[00m
2016-03-28 11:49:44.810 ^[[00;36mINFO eventlet.wsgi.server
[^[[01;36mreq-414f74df-019a-425c-8d49-a081706b2bd4 ^[[00;36madmin
admin^[[00;36m] ^[[01;35m^[[00;36mTraceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line 454,
in handle_one_response
result = self.application(self.environ, start_response)
  File
"/usr/local/lib/python2.7/dist-packages/pecan/middleware/recursive.py",
line 56, in __call__
return self.application(environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in
__call__
resp = self.call_func(req, *args, **self.kwargs)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in
call_func
return self.func(req, *args, **kwargs)
  File
"/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py",
line 456, in __call__
response = req.get_response(self._app)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line
1317, in send
application, catch_exc_info=False)
  File "/usr/local/lib/python2.7/dist-packages/

[openstack-dev] [searchlight] Add Nova Keypair Plugin

[Hiroyuki Eguchi]

Hi.

I am developing this plugin.
https://blueprints.launchpad.net/searchlight/+spec/nova-keypair-plugin

However I faced the problem that a admin user can not retrieve a keypair 
information created by another user.
So it is impossible to sync the keypair between OpenStack DB and Elasticsearch, 
unless connect to OpenStack DB directly.
Is there any suggestions to resolve it ?

thanks.
__
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] Nominating Julia Kreger for core reviewer

[Haomeng, Wang]

Welcome Julia and congratulations !



On Mon, Mar 28, 2016 at 11:09 AM, Shivanand Tendulker 
wrote:

> Congratulations Julia !!
>
>
>
> On Fri, Mar 25, 2016 at 9:38 PM, Jim Rollenhagen 
> wrote:
>
>> On Fri, Mar 25, 2016 at 12:03:34PM -0400, Julia Kreger wrote:
>> > On Thu, Mar 24, 2016 at 3:08 PM, Jim Rollenhagen <
>> j...@jimrollenhagen.com>
>> > wrote:
>> >
>> > > I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core.
>> >
>> >
>> > I would like to thank the academy for... oh wait... wrong speech.
>> >
>> > It is not often one gets to see a flood of positive messages from a
>> > community, from the family that makes up Ironic.  And yes, I blushed.
>> >
>> > Thank you everyone!
>>
>> I see 8 cores in; sounds like consensus. Thank YOU, Julia, for your
>> awesome work. :)
>>
>> Updating access lists now!
>>
>> // jim
>>
>> >
>> > -Julia
>>
>> >
>> __
>> > 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] [magnum] Enhance Mesos bay to a DCOS bay

[Guz Egor]

Jay, just keep in mind that Chronos can be run by Marathon. 

--- Egor
  From: Jay Lau 
 To: OpenStack Development Mailing List (not for usage questions) 
 
 Sent: Friday, March 25, 2016 7:01 PM
 Subject: Re: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay
   
Yes, that's exactly what I want to do, adding dcos cli and also add Chronos to 
Mesos Bay to make it can handle both long running services and batch jobs.
Thanks,
On Fri, Mar 25, 2016 at 5:25 PM, Michal Rostecki  
wrote:

On 03/25/2016 07:57 AM, Jay Lau wrote:

Hi Magnum,

The current mesos bay only include mesos and marathon, it is better to
enhance the mesos bay have more components and finally enhance it to a
DCOS which focus on container service based on mesos.

For more detail, please refer to
https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/

The mesosphere now has a template on AWS which can help customer deploy
a DCOS on AWS, it would be great if Magnum can also support it based on
OpenStack.

I filed a bp here
https://blueprints.launchpad.net/magnum/+spec/mesos-dcos , please show
your comments if any.

--
Thanks,

Jay Lau (Guangya Liu)



Sorry if I'm missing something, but isn't DCOS a closed source software?

However, the "DCOS cli"[1] seems to be working perfectly with Marathon and 
Mesos installed by any way if you configure it well. I think that the thing 
which can be done in Magnum is to make the experience with "DOCS" tools as easy 
as possible by using open source components from Mesosphere.

Cheers,
Michal

[1] https://github.com/mesosphere/dcos-cli

__
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




-- 
Thanks,

Jay Lau (Guangya Liu)

__
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] [release][stable][oslo] oslo.versionedobjects 1.8.0 release (mitaka)

[no-reply]

We are content to announce the release of:

oslo.versionedobjects 1.8.0: Oslo Versioned Objects library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.versionedobjects

With package available at:

https://pypi.python.org/pypi/oslo.versionedobjects

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.versionedobjects

For more details, please see below.

Changes in oslo.versionedobjects 1.7.0..1.8.0
-

3ef5821 Updated from global requirements
97b3dd8 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b252929..b7c6d23 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ oslo.concurrency>=3.5.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslotest 2.4.0 release (mitaka)

[no-reply]

We are thrilled to announce the release of:

oslotest 2.4.0: Oslo test framework

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslotest

With package available at:

https://pypi.python.org/pypi/oslotest

Please report issues through launchpad:

http://bugs.launchpad.net/oslotest

For more details, please see below.

Changes in oslotest 2.3.0..2.4.0


5a63d26 Updated from global requirements
9844dda Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview| 1 +
test-requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index e06a946..2ba9252 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15 +15 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.privsep 1.4.0 release (mitaka)

[no-reply]

We are thrilled to announce the release of:

oslo.privsep 1.4.0: OpenStack library for privilege separation

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.privsep

With package available at:

https://pypi.python.org/pypi/oslo.privsep

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.privsep

For more details, please see below.

Changes in oslo.privsep 1.3.0..1.4.0


f6340f7 Updated from global requirements
f455779 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 3e6d186..5cf3d22 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.service 1.8.0 release (mitaka)

[no-reply]

We are happy to announce the release of:

oslo.service 1.8.0: oslo.service library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.service

With package available at:

https://pypi.python.org/pypi/oslo.service

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.service

For more details, please see below.

Changes in oslo.service 1.7.0..1.8.0


427b8ad Updated from global requirements
be43c64 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 9dfef9c..2cd6aff 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12 +12 @@ oslo.concurrency>=3.5.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.reports 1.7.0 release (mitaka)

[no-reply]

We are delighted to announce the release of:

oslo.reports 1.7.0: oslo.reports library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.reports

With package available at:

https://pypi.python.org/pypi/oslo.reports

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.reports

For more details, please see below.

Changes in oslo.reports 1.6.0..1.7.0


2313c83 Updated from global requirements
ddc8e6b Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview| 1 +
test-requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 39842cd..aed8c57 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13 +13 @@ sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.policy 1.6.0 release (mitaka)

[no-reply]

We are content to announce the release of:

oslo.policy 1.6.0: Oslo Policy library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.policy

With package available at:

https://pypi.python.org/pypi/oslo.policy

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.policy

For more details, please see below.

Changes in oslo.policy 1.5.0..1.6.0
---

938d124 Updated from global requirements
aa0c7ce Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index e8793fa..c6d2840 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ requests!=2.9.0,>=2.8.1 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.db 4.7.0 release (mitaka)

[no-reply]

We are content to announce the release of:

oslo.db 4.7.0: Oslo Database library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.db

With package available at:

https://pypi.python.org/pypi/oslo.db

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.db

For more details, please see below.

Changes in oslo.db 4.6.0..4.7.0
---

244ede4 Updated from global requirements
249ebc7 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 352db43..5f8237d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.utils 3.8.0 release (mitaka)

[no-reply]

We are jubilant to announce the release of:

oslo.utils 3.8.0: Oslo Utility library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.utils

With package available at:

https://pypi.python.org/pypi/oslo.utils

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.utils

For more details, please see below.

Changes in oslo.utils 3.7.0..3.8.0
--

82d7dab Updated from global requirements
6ea71a9 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview| 3 ++-
test-requirements.txt | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index a758083..de90884 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -28 +28 @@ mock>=1.2 # BSD
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.messaging 4.6.0 release (mitaka)

[no-reply]

We are content to announce the release of:

oslo.messaging 4.6.0: Oslo Messaging API

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.messaging

With package available at:

https://pypi.python.org/pypi/oslo.messaging

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.messaging

For more details, please see below.

Changes in oslo.messaging 4.5.1..4.6.0
--

6aa85a5 Always delete exc_info tuple, even if reply fails
a14e1e1 Fail quickly if there on bad password
262c1fe Updated from global requirements
c02c6f9 Always set all socket timeouts

Diffstat (except docs and test files)
-

oslo_messaging/_drivers/impl_rabbit.py   | 61 ++--
oslo_messaging/rpc/dispatcher.py | 16 ---
requirements.txt |  2 +-
4 files changed, 60 insertions(+), 40 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 662a699..f909d35 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ futurist>=0.11.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.middleware 3.8.0 release (mitaka)

[no-reply]

We are amped to announce the release of:

oslo.middleware 3.8.0: Oslo Middleware library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.middleware

With package available at:

https://pypi.python.org/pypi/oslo.middleware

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.middleware

For more details, please see below.

Changes in oslo.middleware 3.7.0..3.8.0
---

8ecaab7 Updated from global requirements
34a7eb6 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 3 ++-
requirements.txt | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 0745a66..3dc518a 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ Jinja2>=2.8 # BSD License (3 clause)
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0
@@ -11 +11 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0



__
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][stable][oslo] oslo.concurrency 3.7.0 release (mitaka)

[no-reply]

We are satisfied to announce the release of:

oslo.concurrency 3.7.0: Oslo Concurrency library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.concurrency

With package available at:

https://pypi.python.org/pypi/oslo.concurrency

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.concurrency

For more details, please see below.

Changes in oslo.concurrency 3.6.0..3.7.0


75c5ba3 Updated from global requirements
5961237 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 3 ++-
requirements.txt | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 74b224d..ec291e3 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ iso8601>=0.1.9 # MIT
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.log 3.3.0 release (mitaka)

[no-reply]

We are psyched to announce the release of:

oslo.log 3.3.0: oslo.log library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.log

With package available at:

https://pypi.python.org/pypi/oslo.log

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.log

For more details, please see below.

Changes in oslo.log 3.2.0..3.3.0


70055c5 Updated from global requirements
0d1fb6c Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 3 ++-
requirements.txt | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index fca3bc1..b11e20e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ six>=1.9.0 # MIT
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.i18n 3.5.0 release (mitaka)

[no-reply]

We are tickled pink to announce the release of:

oslo.i18n 3.5.0: Oslo i18n library

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.i18n

With package available at:

https://pypi.python.org/pypi/oslo.i18n

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.i18n

For more details, please see below.

Changes in oslo.i18n 3.4.0..3.5.0
-

a789d2d Updated from global requirements
2672fa2 Better isolate tests and fixtures from environment
aaa6099 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview| 1 +
oslo_i18n/_message.py | 5 -
oslo_i18n/fixture.py  | 8 
test-requirements.txt | 2 +-
4 files changed, 10 insertions(+), 6 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 7da5b32..34eba45 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15 +15 @@ coverage>=3.6 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
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][stable][oslo] oslo.cache 1.6.0 release (mitaka)

[no-reply]

We are amped to announce the release of:

oslo.cache 1.6.0: Cache storage for Openstack projects.

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.cache

With package available at:

https://pypi.python.org/pypi/oslo.cache

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.cache

For more details, please see below.

Changes in oslo.cache 1.5.0..1.6.0
--

1b3367c Updated from global requirements
1fc818a Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview | 1 +
setup.cfg  | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)




__
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] Nominating Julia Kreger for core reviewer

[Shivanand Tendulker]

Congratulations Julia !!



On Fri, Mar 25, 2016 at 9:38 PM, Jim Rollenhagen 
wrote:

> On Fri, Mar 25, 2016 at 12:03:34PM -0400, Julia Kreger wrote:
> > On Thu, Mar 24, 2016 at 3:08 PM, Jim Rollenhagen  >
> > wrote:
> >
> > > I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core.
> >
> >
> > I would like to thank the academy for... oh wait... wrong speech.
> >
> > It is not often one gets to see a flood of positive messages from a
> > community, from the family that makes up Ironic.  And yes, I blushed.
> >
> > Thank you everyone!
>
> I see 8 cores in; sounds like consensus. Thank YOU, Julia, for your
> awesome work. :)
>
> Updating access lists now!
>
> // jim
>
> >
> > -Julia
>
> >
> __
> > 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] [heat] Issue with validation and preview due to get_attr==None

[Anant Patil]

On 24-Mar-16 20:26, Sergey Kraynev wrote:
> Zane, I like you idea. As example we may discuss some steps for it
> during summit session (if it need).
>
> Also I have another question, which probably came in your heads a lot
of times:
> Can we somekind improve our existing approach for validation?
> we do validation twice - before create and during it.
> The one issue, which I also see is:
> first validation is a synchronous operation, and It takes a lot of
> time, for huge stacks. May be we need to make separate state like
> validation for stacks ? and maybe it also allows to solve our current
> issue with build-in functions ?

I too had the same question since long time. I was thinking about two
possible solutions:

(1) Like you said, as of now the stack validation happens before the
response is given to user. This is not feasible for bigger stacks; the
RPC timesout before the stack template is even validated. I think we
should take the request and respond immediately with a stack-id and then
proceed with template validation and stack creation. If the template is
not correct, the stack creation or update fails with template invalid
error. I have been looking for this since long time, but could never work
on it.

(2) Giving freedom to user to skip the validation, if they are sure
about the template, they might want to skip the validation [1].

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

-- Anant

>
> On 23 March 2016 at 23:11, Zane Bitter  wrote:
>> On 23/03/16 13:14, Steven Hardy wrote:
>>>
>>> Hi all,
>>>
>>> I'm looking for some help and additional input on this bug:
>>>
>>> https://bugs.launchpad.net/heat/+bug/1559807
>>
>>
>> Hmm, I was wondering how this ever worked, but it appears you're making
>> particularly aggressive use of the list_join and map_merge Functions
there -
>> where you're not only getting the elements in the list of things to merge
>> (as presumably originally envisioned) but actually getting the list
itself
>> from an intrinsic function. If we're going to support that then those
>> functions need to handle the fact that the input argument may be
None, just
>> as they do for the list members (see the ensure_string() and ensure_map()
>> functions inside the result() methods of those two Functions).
>>
>>
>>> Basically, we have multiple issues due to the fact that we consider
>>> get_attr to resolve to None at any point before a resource is actually
>>> instantiated.
>>>
>>> It's due to this:
>>>
>>>
>>>
https://github.com/openstack/heat/blob/master/heat/engine/hot/functions.py#L163
>>>
>>> This then causes problems during validation of several intrinsic
>>> functions,
>>> because if they reference get_attr, they have to contain hacks and
>>> special-cases to work around the validate-time None value (or, as
reported
>>> in the bug, fail to validate when all would be fine at runtime).
>>>
>>>
>>>
https://github.com/openstack/heat/blob/master/heat/engine/resource.py#L1333
>>>
>>> I started digging into fixes, and there are probably a few possible
>>> approaches, e.g setting stack.Stack.strict_validate always to False, or
>>> reworking the intrinsic function validation to always work with the
>>> temporary None value.
>>>
>>> However, it's a more widespread issue than just validation - this
affects
>>> any action which happens before the actual stack gets created, so things
>>> like preview updates are also broken, e.g consider this:
>>>
>>> resources:
>>>random:
>>>  type: OS::Heat::RandomString
>>>
>>>config:
>>>  type: OS::Heat::StructuredConfig
>>>  properties:
>>>group: script
>>>config:
>>>  foo: {get_attr: [random, value]}
>>>
>>>deployment:
>>>  type: OS::Heat::StructuredDeployment
>>>  properties:
>>>config:
>>>  get_resource: config
>>>server: "dummy"
>>>
>>> On update, nothing is replaced, but if you do e.g:
>>>
>>>heat stack-update -x --dry-run
>>>
>>> You see this:
>>>
>>> | replaced  | config| OS::Heat::StructuredConfig |
>>>
>>> Which occurs due to the false comparison between the current value of
>>> "random" and the None value we get from get_attr in the temporary stack
>>> used for preview comparison:
>>>
>>>
https://github.com/openstack/heat/blob/master/heat/engine/resource.py#L528
>>>
>>> after_props.get(key) returns None, which makes us falsely declare the
>>> "config" resource gets replaced :(
>>>
>>> I'm looking for ideas on how we solve this - it's clearly a major issue
>>> which completely invalidates the results of validate and preview
>>> operations
>>> in many cases.
>>
>>
>> I've been thinking about this (for about 2 years).
>>
>> My first thought (it seemed like a good idea at the time, 2 years
ago, for
>> some reason) was for Function objects themselves to take on the types of
>> their return values, so e.g. a Function returning a list would have a
>> __getitem__ method and generally act like a list. Don't try this at home,
>> BTW, it doesn't work.
>>
>> I now

Re: [openstack-dev] [election][TC] TC Candidacy

[Mike Perez]

On 09:29 Mar 25, Mike Perez wrote:
> Hi all!
> 
> I Mike Perez aka. thingee, am announcing my candidacy for a position in the
> OpenStack Technical Committee. You can find my submitted candidacy which is
> still under review here https://review.openstack.org/297748
> 
> I am employed by the OpenStack Foundation as a Developer Coordinator to help
> bring focus/support to cross-project initiatives via the cross-project
> specs, Def Core, The Product Working group, etc.
> 
> I feel the items below have enabled others across this project to strive for
> quality. If you would all have me as a member of the Technical Committee, you
> can help me to enable more quality work in OpenStack.
> 
> * I have been working in OpenStack since 2010. I spent a good amount of my 
> time
>   working on OpenStack in my free time before being paid full time to work on
>   it. It has been an important part of my life, and rewarding to see what we
>   have all achieved together.
> 
> * I was PTL for the Cinder project in the Kilo and Liberty releases.
> 
> * I led the effort in bringing third party continuous integration to the
>   Cinder project for more than 60 different drivers. [1]
>   * I removed 25 different storage drivers from Cinder to bring quality to the
> project to ensure what was in the Kilo release would work for operators.
> I did what I believed was right, regardless of whether it would cost me
> re-election for PTL [2].
>   * See epic thread on this once deadline happened [3]
>   * In my conversations with other projects, this has enabled others to want 
> to
> follow the same effort.
> - Ironic now has a road map for doing third-party CI. [4][5]
> 
> * I have attempted to help with diversity in our community, and I think it's
>   great to have people in the committee that views this as a priority.
>   - Helped lead our community to raise $17,403 for the Ada Initiative [6],
> which was helping address gender-diversity with a focus in open source.
>   - For the Vancouver summit, I helped bring in the ally skills workshops from
> the Ada Initiative, so that our community can continue to be a welcoming
> environment [4].
>   - I have assisted Emily Hugenbruch with the OpenStack mentor program [7].
>   - Based on some of the surveys the diversity working group has been doing,
> OpenStack's tool chain of IRC, gerrit, and git was expressed as being
> difficult to get started with. I started writing documentation to provide
> step-by-step with screen shots to help improve our on-boarding experience
> [8].
> 
> * I started the OpenStack Mailing List Digest, in order to enable others to
>   keep up with the dev list on important information. [9][10]
> 
> * When Open Core was being discussed by the TC, numerous times I spoke to the
>   TC about my disagreements with accepting projects in OpenStack's big tent if
>   testing is only possible with a commercial entity. [11][12] I believe
>   OpenStack service APIs should be based off an open source reference
>   implementation that we're able to do integration tests with in gate. Anyone
>   who begins to play with OpenStack should be able to run OpenStack with full
>   features without a commercial entity/driver.
>   - See my discussions with the TC in their meeting in raising quality and
> being able to fully test projects we're considering in accepting in the 
> big
> tent [13].
> 
> * I have properly established the cross-project team [14] as well as the
>   members that represent each OpenStack project [15].
> 
> 
> As a TC member I want to bring focus in some areas:
> 
> 1) Installation Documentation - I think all projects in the big tent should
>have installation documentation. In order for projects to gain adoption and
>gather better feedback, operators need to know how to install things. Today
>majority of projects in the big tent have no installation documentation,
>some which have existed for more than three years and still nothing. Where
>are these projects going? In addition I want to make all new projects
>entering the big tent come with clear documentation for installation. See
>the beginning discussions I'm starting here [16].
> 
> 2) As expressed in the earlier point, there are some projects in the big tent
>that seem to have no clear direction and are lacking adoption after 
> existing
>for years in the community. I'd like to work with these projects and see 
> how
>we can move things forward to gain maturity, and some to be accepted in 
> with
>Defcore and refstack. Otherwise I think these projects should be 
> reevaluated
>in the value they're bringing to the big tent. This won't be easy, but it
>needs to be done to make sure community focus and resources we use from the
>Infra team is spent well. See the TC discussing CI resources VS project
>growth [17].
> 
> 3) As expressed in the earlier point, Defcore plays a role in helping us 
> define
>

[openstack-dev] [dragonflow] question about the schedule during design summit

[Li Ma]

Hi all,

I will have a tight schedule during design summit. I'd like to know
about the arrangement in Apr 28-29. So, I can try to re-schedule to
fit for the arrangement if needed.

Thanks,
-- 

Li Ma (Nick)
Email: skywalker.n...@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

Re: [openstack-dev] [release][packaging] Mitaka packaged on gentoo

[Matthew Thode]

On 03/27/2016 07:35 PM, Matt Riedemann wrote:
> 
> 
> On 3/27/2016 7:18 PM, Matthew Thode wrote:
>> On 03/27/2016 04:53 PM, Matt Riedemann wrote:
>>>
>>>
>>> On 3/25/2016 11:15 PM, Matthew Thode wrote:
 I've finished packaging mitaka on Gentoo, won't be marked stable for
 about a month.  The version packaged is based off of the stable/mitaka
 branch (noted by the version being 2016.1.).  I haven't found where
 an upgrade guide is being worked on (if anywhere), so that would
 help in
 testing if anyone knows where it is.



 __


 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

>>>
>>> There are mitaka install guides, if that helps, e.g.:
>>>
>>> http://docs.openstack.org/mitaka/install-guide-ubuntu/
>>>
>>> Otherwise the upgrade impact sections of the release notes for the
>>> projects are probably the next thing to be checking. For nova, the
>>> mitaka release notes are here:
>>>
>>> http://docs.openstack.org/releasenotes/nova/mitaka.html
>>>
>>
>> Are the release notes being gathered into one document for this release?
>>   I might be misremembering but I think Liberty had that.
>>
>>
>>
>> __
>>
>> 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
>>
> 
> Nope, it's big tent fun and the cats herd themselves now. The release
> notes are published for each project in
> http://docs.openstack.org/releasenotes/ and that's also including new
> releases for stable/liberty.
> 

Ok, at least it's gonna be consistent, long live reno.  Thanks for the info.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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][novaclient] Responses for Deletion Events

[Matt Riedemann]

On 3/23/2016 4:53 PM, Augustina Ragwitz wrote:

There's been some discussion regarding a recent bug [1] where an issue
was reported that no confirmation/success message is received from "nova
agent-delete". This behavior is inconsistent from other novaclient
delete commands which do provide a success message.

There are a two issues that need to be addressed before this behavior
can be patched:

1) What would represent sufficient expected behavior in this deletion case?

A few options have been suggested in the bug; we should probably have
consensus. We should keep in mind the novaclient is due to be deprecated
in the near future, to be replaced by the openstack-client.

The options suggested include providing a simple success response or
supporting different levels of response data with options. For instance,
only show a message if the user specifies --verbose explicitly.
novaclient is not consistent with its "delete" behavior, some calls
require --verbose while others are verbose by default.

2) How does the openstack-client behave for deletions? Should we be
consistent with that in our own client?

I've been digging around in the available documentation for the
OpenStack client and didn't see response types documented. This issue
has also not been addressed in any of the HGI or other high level
documentation. I posted a question in the #openstack-sdks channel to see
if anyone knows the answer to this.

This might be a good opportunity to think about a standard for deletion
responses if one hasn't been defined already.


[1] https://bugs.launchpad.net/python-novaclient/+bug/1557888

---
Augustina Ragwitz
Sr Systems Software Engineer, HPE Cloud
Hewlett Packard Enterprise
---
irc: auggy




__
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



The novaclient CLI is supposed to be more or less deprecated (for awhile 
now), but because of a lack of microversion support in the 
openstackclient CLI we've continued making changes to novaclient CLI.


In this case, we could just say we're not fixing it for novaclient and 
if you want it, add the behavior to openstackclient. That team probably 
has guidelines (at least in Dean's head) around how verbose a delete 
operation should be.


If we did implement something in novaclient, I'd lean toward making the 
user provide a --verbose option to get some output. After all, it's a 
CLI. If it works, you get a 0 exit code. If it fails, you get a non-0 
exit code and some error message.


I can see why `nova delete` is maybe a bit more verbose since it's a 
cast in the API. Deleting an agent isn't, it's a straight DB delete 
operation from the REST API, so it either works right away or it 
doesn't, so I think the exit code is sufficient in the default case (no 
--verbose option that is).


--

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] [release][packaging] Mitaka packaged on gentoo

[Matt Riedemann]

On 3/27/2016 7:18 PM, Matthew Thode wrote:

On 03/27/2016 04:53 PM, Matt Riedemann wrote:



On 3/25/2016 11:15 PM, Matthew Thode wrote:

I've finished packaging mitaka on Gentoo, won't be marked stable for
about a month.  The version packaged is based off of the stable/mitaka
branch (noted by the version being 2016.1.).  I haven't found where
an upgrade guide is being worked on (if anywhere), so that would help in
testing if anyone knows where it is.



__

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



There are mitaka install guides, if that helps, e.g.:

http://docs.openstack.org/mitaka/install-guide-ubuntu/

Otherwise the upgrade impact sections of the release notes for the
projects are probably the next thing to be checking. For nova, the
mitaka release notes are here:

http://docs.openstack.org/releasenotes/nova/mitaka.html



Are the release notes being gathered into one document for this release?
  I might be misremembering but I think Liberty had that.



__
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



Nope, it's big tent fun and the cats herd themselves now. The release 
notes are published for each project in 
http://docs.openstack.org/releasenotes/ and that's also including new 
releases for stable/liberty.


--

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] [release][packaging] Mitaka packaged on gentoo

[Matthew Thode]

On 03/27/2016 04:53 PM, Matt Riedemann wrote:
> 
> 
> On 3/25/2016 11:15 PM, Matthew Thode wrote:
>> I've finished packaging mitaka on Gentoo, won't be marked stable for
>> about a month.  The version packaged is based off of the stable/mitaka
>> branch (noted by the version being 2016.1.).  I haven't found where
>> an upgrade guide is being worked on (if anywhere), so that would help in
>> testing if anyone knows where it is.
>>
>>
>>
>> __
>>
>> 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
>>
> 
> There are mitaka install guides, if that helps, e.g.:
> 
> http://docs.openstack.org/mitaka/install-guide-ubuntu/
> 
> Otherwise the upgrade impact sections of the release notes for the
> projects are probably the next thing to be checking. For nova, the
> mitaka release notes are here:
> 
> http://docs.openstack.org/releasenotes/nova/mitaka.html
> 

Are the release notes being gathered into one document for this release?
 I might be misremembering but I think Liberty had that.

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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] [cinder][openstackclient] Required name option for volumes, snapshots and backups

[Mike Perez]

On 00:40 Mar 28, Jordan Pittier wrote:
> I am going to play the devil's advocate here but why can"t
> python-openstackclient have its own opinion on the matter ? This CLI seems
> to be for humans and humans love names/labels/tags and find UUIDS hard to
> remember. Advanced users who want anonymous volumes can always hit the API
> directly with curl or whatever SDK.

I suppose it could, however, names are not unique.

-- 
Mike Perez

__
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] [cinder][openstackclient] Required name option for volumes, snapshots and backups

[Jordan Pittier]

I am going to play the devil's advocate here but why can"t
python-openstackclient have its own opinion on the matter ? This CLI seems
to be for humans and humans love names/labels/tags and find UUIDS hard to
remember. Advanced users who want anonymous volumes can always hit the API
directly with curl or whatever SDK.

On Sun, Mar 27, 2016 at 4:44 PM, Duncan Thomas 
wrote:

> I think it is worth fixing the client to actually match the API, yes. The
> client seems to be determined not to actually match the API in lots of
> ways, e.g. https://bugs.launchpad.net/python-openstackclient/+bug/1561666
>
> On 24 March 2016 at 19:08, Ivan Kolodyazhny  wrote:
>
>> Hi team,
>>
>> From the Cinder point of view, both volumes, snapshots and backups APIs
>> do not require name param. But python-openstackclient requires name param
>> for these entities.
>>
>> I'm going to fix this inconsistency with patch [1]. Unfortunately, it's a
>> bit more than changing required params to not required. We have to change
>> CLI signatures. E.g. for create a volume: from [2].
>>
>> Is it acceptable? What is the right way to do such changes for OpenStack
>> Client?
>>
>>
>> [1] https://review.openstack.org/#/c/294146/
>> [2] http://paste.openstack.org/show/491771/
>> [3] http://paste.openstack.org/show/491772/
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> __
>> 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
>>
>>
>
>
> --
> --
> Duncan Thomas
>
> __
> 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] [release][packaging] Mitaka packaged on gentoo

[Matt Riedemann]

On 3/25/2016 11:15 PM, Matthew Thode wrote:

I've finished packaging mitaka on Gentoo, won't be marked stable for
about a month.  The version packaged is based off of the stable/mitaka
branch (noted by the version being 2016.1.).  I haven't found where
an upgrade guide is being worked on (if anywhere), so that would help in
testing if anyone knows where it is.



__
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



There are mitaka install guides, if that helps, e.g.:

http://docs.openstack.org/mitaka/install-guide-ubuntu/

Otherwise the upgrade impact sections of the release notes for the 
projects are probably the next thing to be checking. For nova, the 
mitaka release notes are here:


http://docs.openstack.org/releasenotes/nova/mitaka.html

--

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] [ptl][kolla][release] Deploying the big tent

[Matt Riedemann]

On 3/26/2016 11:27 AM, Steven Dake (stdake) wrote:

Hey fellow PTLs and core reviewers of  those projects,

Kolla at present deploys  the compute kit, and some other services that
folks have added over time including other projects like Ironic, Heat,
Mistral, Murano, Magnum, Manilla, and Swift.

One of my objectives from my PTL candidacy was to deploy the big tent,
and I  saw how we were not super successful as I planned in Mitaka at
filling out the big tent.

While the Kolla core team is large, and we can commit to maintaining big
tent projects that are deployed, we are at capacity every milestone of
every cycle implementing new features that the various big tent services
should conform to.  The idea of a plugin architecture for Kolla where
projects could provide their own plugins has been floated, but before we
try that, I'd prefer that the various teams in OpenStack with an
interest in having their projects consumed by Operators involve
themselves in containerizing their projects.

Again, once the job is done, the Kolla community will continue to
maintain these projects, and we hope you will stay involved in that process.

It takes roughly four 4 hour blocks to learn the implementation
architecture of Kolla and probably another 2 4 hour blocks to get a good
understanding of the Kolla deployment workflow.  Some projects (like
Neutron for example) might fit outside this norm because containerizing
them and deploying them is very complex.  But we have already finished
the job on what we believe are the hard projects.

My ask is that PTLs take responsibility or recruit someone from their
respective community to participate in the implementation of Kolla
deployment for their specific project.

Only with your help can we make the vision of a deployment system that
can deploy the big tent a reality.

Regards
-steve


__
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



Having never looked at Kolla, is there an easy way to see what projects 
are already done? Like, what would Nova need to do here? Or is it a 
matter of keeping up with new deployment changes / upgrade impacts, like 
the newish nova API database?


If that's the case, couldn't the puppet/ansible/chef projects be making 
similar requests from the project development teams?


Unless we have incentive to be contributing to Kolla, like say we 
replaced devstack in our CI setup with it, I'm having a hard time seeing 
everyone jumping in on this.


--

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] [cross-project] [all] Quotas -- service vs. library

[Jay Pipes]

On 03/16/2016 07:10 AM, Attila Fazekas wrote:

NO : For any kind of extra quota service.

In other places I saw other reasons for a quota service or similar,
  the actual cost of this approach is higher than most people would think so NO.

Maybe Library,
But I do not want to see for example the bad pattern used in nova to spread 
everywhere.

The quota usage handling MUST happen in the same DB transaction as the
resource record (volume, server..) create/update/delete  .


No, it doesn't.

This isn't even a remotely realistic thing for a distributed system like 
Nova to try. There often isn't a single DB transaction that creates or 
updates or deletes something in Nova. API calls typically traverse 3 or 
more separate compute and controller node services, saving state 
transitions to a resource record sometimes *dozens* of times over the 
course of the API call -- many of which are entirely asynchronous.


In addition to the already-distributed, mostly-asynchronous nature of 
Nova, keep in mind that a Nova deployment can have multiple cells each 
having its own entirely different database, multiple availability zones 
each with multiple cells, and multiple regions each with multiple 
availability zones.


You still want to keep a database transaction (two phase commit or 
otherwise) open for the duration of events that cross any of those 
boundaries?


No, I think not.


There is no need for.:
- reservation-expirer services or periodic tasks ..
- there is no need for quota usage correcter shell scripts or whatever
- multiple commits

We have a transaction capable DB, to help us,
not using it would be lame.


We *do* use transactions in the quota system. That's not the primary 
problem with the Nova quota system.


The major problem with the Nova quota system is that it keeps a cache of 
usage records in its quota_usages (and reservations) table instead of 
querying the primary tables that *actually* store real resources.


Any time you introduce cache tables, you introduce greater potential for 
races to occur.


Either you accept the inevitability of those race conditions, or you 
relax the constraints that you put on the locking system, and/or you get 
rid of the caching and accept some small degradation of raw performance 
of quota checks.


In my opinion, we should have a system that issues a single quota check 
against the actual resource records. [1] This check should occur right 
up front before any operation that would consume a resource. [2]


I don't actually think that this proposed quota thing should be service. 
Why? Because a separate service would inevitably be implemented by 
creating cache tables about quota usages. And that's at the root of the 
problem with race conditions in existing quota solutions in OpenStack.


Better to create a library that actually has no database of its own at 
all. Instead, have the library expose a simple and consistent API that 
relies on an implementation plugin that would live in each OpenStack 
component that needed quota checks. These plugins would query the 
*actual* resource tables that exist in their own databases to determine 
if a user's request can be satisfied.


We'd still need some central-ish place to *update* quota amounts for 
individual users/tenants/defaults. IMHO, Keystone is the logical place 
to put this kind of information. No need for a new service when we 
already have one that can serve this purpose. A previous suggestion of 
just using the auth token to either store the quotas themselves or a 
link to grab quota information for a user is a good suggestion.


Finally, someone had mentioned rate limiting in an earlier response. I 
don't believe OpenStack should be in the business of rate limiting. 
There are tested and scalable solutions that do rate limiting for HTTP 
requests. [3] Those should be used instead of Python code in a WSGI 
application or middleware service.


My two cents,
-jay

[1] In Nova, this would be the new allocations table in the 
resource-providers modeling or the instances table in the legacy modeling


[2] If there's no cache table of quota usages, there's NO reason why 
quota calculations need to be made on ANY request that doesn't actually 
consume a new resource. This means no quota calculations on DELETE 
operations, no quota calculations on most UPDATE operations (since the 
amount of consumed resources generally doesn't change at all)


[3]
https://lincolnloop.com/blog/rate-limiting-nginx/
http://www.openrepose.org/
https://tyk.io/

__
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] [tc] Non-candidacy

[Eoghan Glynn]

> Hi all,
> 
> Thanks for all the fish. But it's time for me to move over and let some
> new voices contribute to the OpenStack Technical Committee.
> 
> I will continue to be a proponent for the viewpoint that OpenStack
> should be considered a toolkit of small, focused services and utilities,
> upon which great products can be built that expose cloud computing to
> ever-broader markets.
> 
> I'll just be a proponent of this view from outside the TC.
> 
> All the best, and thanks again for the opportunity to serve this past year.

Well, thank you Jay for your service ... and kudos also for the
gentlepersonly way you declared your non-candidacy early in the
nomination period.

The fact there's the longest possible notice that an incumbent
isn't running again may encourage some extra potential first-time
candidates off the bench and make for a more open race :)

Cheers,
Eoghan  

__
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] [Kuryr][Magnum] Clarification of expanded mission statement

[Hongbin Lu]

Gal,

Thanks for clarifying the initiative. I added “[Magnum]” to the title so that 
Magnum team members can cast their inputs to this thread (if any).

Best regards,
Hongbin

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: March-19-16 6:04 AM
To: Fox, Kevin M
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Kuryr] Clarification of expanded mission statement

Hi Russell,

Thanks for starting this thread, i have been wanting to do so myself.

First, to me Kuryr is much more then just providing a "libnetwork driver" or a 
"CNI driver"
in the networking part.

Kuryr goal (to me at least) is to simplify orchestration, management and 
performance
and avoid vendor lock-in by providing these drivers but also being able to 
expose and enhance additional
policy level features that OpenStack has but are lacking in COEs, We are also 
looking at easier
deployment and packaging and providing additional value with features that make 
things more efficient and address issues
operators/users are facing (like attaching to existing Neutron networks).

We see our selfs operating both on OpenStack projects, helping with features 
needed for this integration but
also in any other project (like Kubernetes / Docker) if this will make more 
sense and show better value.

The plan is to continue this with storage, we will have to examine things and 
decide where is the best
place to locate them the pros and cons.
I personally don't want to run and start implementing things at other 
communities and under other
governance model unless they make much more sense and show better value for the 
overall solution.
So my initial reaction is that we can show a lot of value in the storage part 
as part of OpenStack Kuryr and hence
the mission statement change.

There are many features that i believe we can work in that are currently 
lacking and we will
need to examine them one by one and keep doing the design and spec process open 
with the community
so everyone can review and judge the value.
The last thing i am going to do is drive to re-implement things that are 
already there and in good enough shape,
none of us have the need or time to do that :)

In the storage area i see the plugins (and not just for Kubernetes), i see the 
persistent and re-using of storage
parts as being interesting to start with.
Another area that i included as storage is mostly disaster recovery and backup, 
i think we can bring a lot of value
to containers deployments by leveraging projects like Smaug and Freezer which 
offer application backups
and recovery.
I really prefer we do this thinking process together as a community and i 
already talked with some people that showed
interest in some of these features.

My intention was to first get the TC approval to explore this area and make 
sure it doesnt conflict and
only then start working on defining the details again with the broad community, 
openly just like we do
everything else.


On Fri, Mar 18, 2016 at 10:12 PM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:
I'd assume a volume plugin for cinder support and/or a volume plugin for manila 
support?

Either would be useful.

Thanks,
Kevin

From: Russell Bryant [rbry...@redhat.com]
Sent: Friday, March 18, 2016 4:59 AM
To: OpenStack Development Mailing List (not for usage questions); 
gal.sa...@gmail.com
Subject: [openstack-dev] [Kuryr] Clarification of expanded mission statement
The Kuryr project proposed an update to its mission statement and I agreed to 
start a ML thread seeking clarification on the update.

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

The change expands the current networking focus to also include storage 
integration.

I was interested to learn more about what work you expect to be doing.  On the 
networking side, it's clear to me: a libnetwork plugin, and now perhaps a CNI 
plugin.  What specific code do you expect to deliver as a part of your expanded 
scope?  Will that code be in Kuryr, or be in upstream projects?

If you don't know yet, that's fine.  I was just curious what you had in mind.  
We don't really have OpenStack projects that are organizing around contributing 
to other upstreams, but I think this case is fine.

--
Russell Bryant



--
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] [ptl][kolla][release] Deploying the big tent

[Steven Dake (stdake)]

From: Adam Young mailto:ayo...@redhat.com>>
Reply-To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, March 26, 2016 at 7:10 PM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [ptl][kolla][release] Deploying the big tent

On 03/26/2016 12:27 PM, Steven Dake (stdake) wrote:
Hey fellow PTLs and core reviewers of  those projects,

Kolla at present deploys  the compute kit, and some other services that folks 
have added over time including other projects like Ironic, Heat, Mistral, 
Murano, Magnum, Manilla, and Swift.

One of my objectives from my PTL candidacy was to deploy the big tent, and I  
saw how we were not super successful as I planned in Mitaka at filling out the 
big tent.

While the Kolla core team is large, and we can commit to maintaining big tent 
projects that are deployed, we are at capacity every milestone of every cycle 
implementing new features that the various big tent services should conform to. 
 The idea of a plugin architecture for Kolla where projects could provide their 
own plugins has been floated, but before we try that, I'd prefer that the 
various teams in OpenStack with an interest in having their projects consumed 
by Operators involve themselves in containerizing their projects.

Again, once the job is done, the Kolla community will continue to maintain 
these projects, and we hope you will stay involved in that process.

It takes roughly four 4 hour blocks to learn the implementation architecture of 
Kolla and probably another 2 4 hour blocks to get a good understanding of the 
Kolla deployment workflow.  Some projects (like Neutron for example) might fit 
outside this norm because containerizing them and deploying them is very 
complex.  But we have already finished the job on what we believe are the hard 
projects.

My ask is that PTLs take responsibility or recruit someone from their 
respective community to participate in the implementation of Kolla deployment 
for their specific project.

I'll take on Keystone, but only if you promise to stop using "ask" as a noun 
and instead use ye olde English "Request" in its place.
Lol.

Its a cisco thing - I guess I'm starting to speak the lingo here.

Regards
-steve



Only with your help can we make the vision of a deployment system that can 
deploy the big tent a reality.

Regards
-steve



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [puppet] Launching Puppet OpenStack Guide

[Emilien Macchi]

We're very pleased to announce the launch of Puppet OpenStack Guide
(p-o-g), a new repository [1] that will host Puppet OpenStack
documentation for developers, operators and users.
Until now, we use OpenStack Wiki [2] and we'll progressively move the
bits to p-o-g.
The usage of p-o-g will allow documentation peer-review and also will
follow how other projects build documentation.

I sent a first patch to bootstrap sphinx work:
https://review.openstack.org/#/c/298047/
If you're interested to contribute please let us know, so we can start
defining the index and move the content from Wiki.

The guide will be reachable at this URL:
http://docs.openstack.org/developer/puppet-openstack-guide

[1] http://git.openstack.org/cgit/openstack/puppet-openstack-guide/
[2] https://wiki.openstack.org/wiki/Puppet

Any question or feedback is welcome!
-- 
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

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

[Duncan Thomas]

I think it is worth fixing the client to actually match the API, yes. The
client seems to be determined not to actually match the API in lots of
ways, e.g. https://bugs.launchpad.net/python-openstackclient/+bug/1561666

On 24 March 2016 at 19:08, Ivan Kolodyazhny  wrote:

> Hi team,
>
> From the Cinder point of view, both volumes, snapshots and backups APIs do
> not require name param. But python-openstackclient requires name param for
> these entities.
>
> I'm going to fix this inconsistency with patch [1]. Unfortunately, it's a
> bit more than changing required params to not required. We have to change
> CLI signatures. E.g. for create a volume: from [2].
>
> Is it acceptable? What is the right way to do such changes for OpenStack
> Client?
>
>
> [1] https://review.openstack.org/#/c/294146/
> [2] http://paste.openstack.org/show/491771/
> [3] http://paste.openstack.org/show/491772/
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> __
> 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
>
>


-- 
-- 
Duncan Thomas
__
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] [Neutron][Dragonflow] IRC Meeting tomorrow (3/28) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 3/28) at 0900 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
*http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-03-21-08.59.html
*

Please update the agenda if you have any subject you would like to discuss
about.
__
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