Re: [openstack-dev] [dragonflow]Part of the OpenStack Big-tent

[Li Ma]

Congrats ;-)

-- 

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] [fuel] Fuel plugins: lets have some rules

[Andreas Jaeger]

On 2016-02-03 03:27, Dmitry Borodaenko wrote:
> [...]
> Level 1. Plugin is actively supported by Fuel team
> 
> As we expand plugin capabilities and move more functionality from Fuel
> core into plugins, we will inevitably get to the point where some
> plugins are required to successfully complete even a basic deployment
> (aka "pass BVT"). Even before that, we may decide that some plugins are
> important enough for our reference architecture to allow the state of
> these plugins to affect our release cycle: allow Critical bugs in them
> to affect Fuel release, cover them in acceptance testing for Fuel
> releases and maintenance updates, and so on.


> Obviously, whole Fuel team is expected to support such plugins, and is
> self-motivated to provide timely help to their maintainers to keep them
> healthy. In addition to the expectations from the previous support
> level, we should track the list of these release-critical plugins in the
> policy section of fuel-specs [7].

So, these are plugins that will be officially part of fuel team? You
depend on it for successful installation...

Andreas


> [7] https://git.openstack.org/cgit/openstack/fuel-specs/tree/policy
> 
> Thoughts, comments, objections?
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
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] [glance][nova] images v1-v2 property name asymmetry

[Brian Rosmaita]

Here's the situation:

image property set:
- Images v1 API: all image property names are converted to lowercase
before they're stored
- Compute v2 API: all image property names are converted to lowercase
before they're stored
- Images v2 API: image properties are stored in the case specified when
they were created

image property get:
- Images v2 API: all image property names are returned in lowercase only
- Compute v2 API: all image property names are returned in lowercase only
- Images v2 API: image property names are returned as originally set

Note: this applies only to property NAMES.  In all 3 APIs, values are
returned in the same case pattern in which they were created.  Details of
the above are avaliable on an etherpad [2].

Here is why this matters.
(1)  Current Glance behavior is that property names are treated as if they
were un-cased.  In other words, if you create a property
'CamelCasedPropertyName' on image 1234, you cannot create another property
named 'camelCasedPropertyName' on image 1234.  Adding "duplicate"
properties in v2 is currently blocked more by a fortuitous bug than by
design.  If this is the behavior we want (and I think it is), then we need
to make the duplication detection more robust.

(2)  The current patch for the CIM metadata definitions [0] is defining
property names in all lowercase, for example,
'instructionsetextensionname' instead of 'InstructionSetExtensionName' as
on an earlier patch.  In addition to being more readable, the CamelCased
names are what's actually used in the CIM schema.  Lin's reason for the
change is that if image consumers looking for image metadata are using the
Images v1 or the Compute API, they won't find CamelCased property names
among the image properties.  By keeping everything lowercase, we eliminate
the problem of a developer forgetting to normalize image property names
before testing for their existence.

(3)  This issue impacts the work underway to convert Nova to consuming the
Images v2 API.

We need to formalize the intended behavior.  Here's a proposal:
(a) If you use the Images v1 API or the Compute API to *set* an image
property name, you get lowercase only.
(b) If you use the Images v1 API or the Compute API to *get* an image
proeprty name, you get lowercase only.
(c) The behavior of the Compute API with respect to image property names
should not change when Nova starts using the Images v2 API.
(d) If you use the Images v2 API to *set* image property names, they are
stored as cased in the request.
(e) For the purposes of preventing duplicate image property names on a
single image, property names are *case insensitive*.
(f) If you use the Images v2 API to *get* image property names, you will
receive them as they were stored, but you should treat them as case
insensitive.

This proposal is basically what we've got now, plus the recommendation
that image property names be treated as case insensitive when using the
Images v2 API.

We need to get consensus on this quickly so that the implementation of the
CIM Namespace Metadata spec [1] can be completed.  The hold up at the
moment is whether the property names should be CamelCased or simply
lowercased.  My opinion is that if everyone's going to make all property
names lowercase just to be safe, then we ought to go ahead and enforce
this in the Images API, that is, make the Images v2 API act just like the
Images v1 API in this regard.

cheers,
brian


[0] https://review.openstack.org/#/c/265152/6
[1] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/cim
-namespace-metadata-definitions.html
[2] https://etherpad.openstack.org/p/images-v1-v2-property-names-asymmetry





__
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] Devstack jobs failing

[Joshua Hesketh]

Hi all,

Just a heads up that devstack jobs are failing in the gate. I'm currently
investigating but unfortunately haven't found anything yet and don't have
much time this evening.

Hopefully somebody smarter than I will look at it shortly.

Cheers,
Josh
__
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] sqlalchemy-utils fails devstack install

[Shinobu Kinjo]

Sorry, I don't use master.
But AFAICT there is no issue with stable/liberty.

Rgrds,
Shinobu 

- Original Message -
From: "Isao Watanabe" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, February 25, 2016 2:02:09 PM
Subject: Re: [openstack-dev] sqlalchemy-utils fails devstack install

Hello, @Shinobu

I'm using master branch.

Best regards,
Watanabe.isao



> -Original Message-
> From: Shinobu Kinjo [mailto:ski...@redhat.com]
> Sent: Thursday, February 25, 2016 1:55 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] sqlalchemy-utils fails devstack install
> 
> Which branch are you using?
> 
> Rgds,
> Shinobu
> 
> - Original Message -
> From: "Isao Watanabe" 
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, February 25, 2016 1:45:48 PM
> Subject: [openstack-dev] sqlalchemy-utils fails devstack install
> 
> Hello team
> 
> Does anyone know about why sqlalchemy-utils fails devstack install since
> about 3:00 UTC, Feb 25th?
> 
> Our CI start to fail and in log it says:
> 
> 2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c
> /opt/stack/new/requirements/upper-constraints.txt (line 24))
> 2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz
> (112kB)
> 2016-02-25 03:34:23.031 | Complete output from command python setup.py
> egg_info:
> 2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command:
> 'extras_require' must be a dictionary whose values are strings or lists of
> strings containing valid project/version requirement specifiers.
> 2016-02-25 03:34:23.031 |
> 2016-02-25 03:34:23.031 | 
> 2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed with
> error code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils
> 
> However, in mirror[1] which we are using, the package is just there, which
> confused me.
> [1] http://mirror.dfw.rax.openstack.org/pypi/simple/sqlalchemy-utils/
> 
> Thanks for any help.
> 
> Best regards,
> Watanabe.isao
> 
> 
> 
> 
> __
> 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] sqlalchemy-utils fails devstack install

[Watanabe, Isao]

Hello, @ Tony

Thank you for the information.
About your question:
> I wonder if all the failures share a common python? perhaps 3.4?
In my environment, I'm using python2.7.6.
But, 3.4 is also been installed.

$ readlink -f $(which python) | xargs -I % sh -c 'echo -n "%: "; % -V'
/usr/bin/python2.7: Python 2.7.6

$ python -V
Python 2.7.6

$ dpkg -l|grep python3.4
ii  libpython3.4-minimal:amd64   3.4.3-1ubuntu1~14.04.3   amd64 
   Minimal subset of the Python language (version 3.4)
ii  libpython3.4-stdlib:amd643.4.3-1ubuntu1~14.04.3   amd64 
   Interactive high-level object-oriented language (standard library, 
version 3.4)
ii  python3.43.4.3-1ubuntu1~14.04.3   amd64 
   Interactive high-level object-oriented language (version 3.4)
ii  python3.4-minimal3.4.3-1ubuntu1~14.04.3   amd64 
   Minimal subset of the Python language (version 3.4)

Best regards,
Watanabe.isao



> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Thursday, February 25, 2016 2:54 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] sqlalchemy-utils fails devstack install
> 
> On Thu, Feb 25, 2016 at 04:45:48AM +, Watanabe, Isao wrote:
> > Hello team
> >
> > Does anyone know about why sqlalchemy-utils fails devstack install
> > since about 3:00 UTC, Feb 25th?
> 
> I don't have anything helpful to add really other than:
> 
> This bug https://bugs.launchpad.net/devstack/+bug/1548591 was opened 2 days
> ago ; but
> http://logstash.openstack.org/#/dashboard/file/logstash.json?query=messa
> ge:%5C%22error%20in%20SQLAlchemy-Utils%20setup%20command:%5C%22=864
> 000s
> 
> Matches your timeline that it's started being an issue in the last 2 hours
> 
> Shows that's really hurting kolla, but openstack-ansible, devstack, neutron
> and octavia are all affected.
> 
> Typically somethign like this will happen when a new release for $project
> comes out but:
> SQLAlchemy-Utils-0.31.6.tar.gz :
> 2016-01-21T12:36:09
> 
> And I4ff173ed9559d3dfe38cde15dc0f9a9487b45528 merged it into u-c on Sun Jan
> 24
> 06:26:51 2016 +
> 
> Looksing at:
> https://github.com/kvesteri/sqlalchemy-utils/blob/master/setup.py#L25-L5
> 8
> 
> I wonder if all the failures share a common python? perhaps 3.4?
> 
> Yours Tony.
__
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][oslo] taskflow 1.30.0 release (mitaka)

[no-reply]

We are satisfied to announce the release of:

taskflow 1.30.0: Taskflow structured state management library.

This release is part of the mitaka release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/taskflow

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

For more details, please see below.

Changes in taskflow 1.29.0..1.30.0
--

057d1da Updated from global requirements
4389c1a Sqlalchemy-utils double entry (already in test-requirements.txt)

Diffstat (except docs and test files)
-

requirements.txt | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 91d55b4..8a7d201 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -44 +44 @@ automaton>=0.5.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0
@@ -54,2 +53,0 @@ debtcollector>=1.2.0 # Apache-2.0
-# For sqlalchemy persistence backend
-sqlalchemy-utils # BSD License



__
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][oslo] tooz 1.34.0 release (mitaka)

[no-reply]

We are pleased to announce the release of:

tooz 1.34.0: Coordination library for distributed systems.

This release is part of the mitaka release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/tooz

Please report issues through launchpad:

http://bugs.launchpad.net/python-tooz/

For more details, please see below.

Changes in tooz 1.33.0..1.34.0
--

ea570c6 Compute requires_beating

Diffstat (except docs and test files)
-

tooz/coordination.py  | 3 +++
tooz/drivers/memcached.py | 3 ---
tooz/drivers/redis.py | 3 ---
3 files changed, 3 insertions(+), 6 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] [Keystone] State of Fernet tokens

[Morgan Fainberg]

On Wed, Feb 24, 2016 at 9:27 PM, Morgan Fainberg 
wrote:

>
>
> On Wed, Feb 24, 2016 at 8:50 PM, Adam Young  wrote:
>
>> A lot of people seem to be counting on Fernet tokens, so I figured I'd
>> give a quick update.
>>
>> Back in December, I made a quick check to see what would happen if we
>> swapped Fernet in as the default token provider.  A bunch of tests fails.
>> Lance Bragstad and Raildo Mascena took that and ran with it.
>>
>> As of tonight, there are 18 Failed test.  4 are due to trust tokens on
>> V2.  we need to explicitly prevent trust execution for the V2 API, as the
>> rules are not being enforced.  We sent up a warning about this before, but
>> let me make it explicit;  V2 Trust support is being yanked due to the need
>> to make Fernet work.
>>
>> There are also some strange things going on with revocation events. Since
>> token revocations are only going to be handled via the revocation event API
>> (not revocation list) we need to get this right.
>>
>> Here is the complete list of failing tests right now:
>>
>>
>> These  three are the trust tests I described above.
>>
>> {0}
>> keystone.tests.unit.test_auth.AuthWithTrust.test_delete_tokens_for_user_invalidates_tokens_from_trust
>> [0.420011s] ... FAILED
>> {0}
>> keystone.tests.unit.test_auth.AuthWithTrust.test_token_from_trust_cant_get_another_token
>> [0.443193s] ... FAILED
>> {1}
>> keystone.tests.unit.test_auth.AuthWithTrust.test_delete_trust_revokes_token
>> [0.465307s] ... FAILED
>>
>>
>> Something seems to be strange with Cache invalidation.  They all deal
>> with token deletion, which is handled by Revocation Events now.
>> But this seems to be a test problem, not with the main code.
>>
>> {5}
>> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_unscoped_token
>> [0.082660s] ... FAILED
>> {4}
>> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user
>> [0.085062s] ... FAILED
>> {3}
>> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant
>> [0.106043s] ... FAILED
>> {1}
>> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_id
>> [0.081628s] ... FAILED
>> {1}
>> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user
>> [0.244603s] ... FAILED
>> {1}
>> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant
>> [0.237667s] ... FAILED
>> {6}
>> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_unscoped_token
>> [0.278852s] ... FAILED
>> {0}
>> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_id
>> [0.254170s] ... FAILED
>>
>>
> All of these cache validation tests are failing for two distinct reasons:
>
> 1) the Fernet token key repository fixture is not being used for the
> classes. Add in the use of the key_repository fixture and the first failure
> will go away
>
> 2) The test is insanely synthetic and doesn't actually create data in the
> identity or assignment backends. These tests need to be real test cases not
> relying on the fact that the token backend contains the validated dataset.
> This basically comes down to doing the load_fixtures() call and making sure
> to use "real" project_id/user_id combinations.
>
>

Latest patchset resolves issues with cache invalidation


> {5}
>> keystone.tests.unit.test_v3_assignment.AssignmentInheritanceTestCase.test_crud_inherited_and_direct_assignment_on_projects
>> [1.390265s] ... FAILED
>> {3}
>> keystone.tests.unit.test_no_admin_token_auth.TestNoAdminTokenAuth.test_request_no_admin_token_auth
>> [0.111520s] ... FAILED
>>
>> Since the revocation list is not going to be used with Fernet, I am not
>> too worried about these.  I think these tests can be changed to use PKI
>> tokens for now.
>>
>>
> Skip the revocation_list tests for Fernet absolutely.
>
>

Latest patchset skips revocation_list get attempts with Fernet.


>
>> {2} keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_md5
>> [2.025202s] ... FAILED
>> {2}
>> keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_sha256
>> [1.650198s] ... FAILED
>> {6}
>> keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_audit_id_only_token
>> [1.024048s] ... FAILED
>> {5}
>> keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_ids_token
>> [1.091590s] ... FAILED
>>
>> And this one?  Passed when I ran it directly.  Looks like a bad test
>> setup.
>> {3}
>> keystone.tests.unit.test_v3_filters.IdentityTestListLimitCase.test_list_users_filtered_by_funny_name
>> [2.169297s] ... FAILED
>>
>>
>> Review is here:
>> https://review.openstack.org/#/c/258650
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> 

[openstack-dev] [release][oslo] osprofiler 1.2.0 release (mitaka)

[no-reply]

We are happy to announce the release of:

osprofiler 1.2.0: OpenStack Profiler Library

This release is part of the mitaka release series.

With package available at:

https://pypi.python.org/pypi/osprofiler

For more details, please see below.

Changes in osprofiler 1.1.0..1.2.0
--

54d58a7 Remove flake8 ignore list in tox.ini

Diffstat (except docs and test files)
-

osprofiler/opts.py | 28 ++--
tox.ini|  1 -
2 files changed, 14 insertions(+), 15 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

[openstack-dev] [release][oslo] stevedore 1.12.0 release (mitaka)

[no-reply]

We are psyched to announce the release of:

stevedore 1.12.0: Manage dynamic plugins for Python applications

This release is part of the mitaka release series.

With source available at:

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

With package available at:

https://pypi.python.org/pypi/stevedore

Please report issues through launchpad:

https://bugs.launchpad.net/python-stevedore

For more details, please see below.

Changes in stevedore 1.11.0..1.12.0
---

8a19d5f Add a reference to entry_point_inspector

Diffstat (except docs and test files)
-

1 file changed, 6 insertions(+)




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

[no-reply]

We are jazzed to announce the release of:

oslotest 2.3.0: Oslo test framework

This release is part of the mitaka 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.2.0..2.3.0


548ccc8 Add some gitignore files
14a292b Fix misspelling

Diffstat (except docs and test files)
-

.gitignore  | 9 ++---
2 files changed, 7 insertions(+), 4 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

[openstack-dev] [release][oslo] oslo.vmware 2.5.0 release (mitaka)

[no-reply]

We are jazzed to announce the release of:

oslo.vmware 2.5.0: Oslo VMware library

This release is part of the mitaka release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.vmware 2.4.0..2.5.0
---

7e649b2 Updated from global requirements
8c22a17 Updated from global requirements
4d6595c Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index c3ed946..11ace7c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12 +12 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0
@@ -18 +18 @@ suds-jurko>=0.6 # LGPL
-eventlet>=0.18.2 # MIT
+eventlet!=0.18.3,>=0.18.2 # MIT
@@ -21 +21 @@ urllib3>=1.8.3 # MIT
-oslo.concurrency>=2.3.0 # Apache-2.0
+oslo.concurrency>=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][oslo] oslo.utils 3.7.0 release (mitaka)

[no-reply]

We are chuffed to announce the release of:

oslo.utils 3.7.0: Oslo Utility library

This release is part of the mitaka 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.6.0..3.7.0
--

e30a1a8 Add method check_string_length
aba1c07 Add missing versionchanged for configdrive

Diffstat (except docs and test files)
-

oslo_utils/strutils.py| 35 +++
2 files changed, 69 insertions(+)




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

[no-reply]

We are overjoyed to announce the release of:

oslo.versionedobjects 1.7.0: Oslo Versioned Objects library

This release is part of the mitaka 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.6.0..1.7.0
-

e87bca4 Updated from global requirements
57114f7 Updated from global requirements
b16584c Fix messages in exceptions raised due to invalid state transitions

Diffstat (except docs and test files)
-

oslo_versionedobjects/fields.py| 14 +++---
requirements.txt   |  4 ++--
3 files changed, 25 insertions(+), 12 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 0aad60c..b252929 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ Babel>=1.3 # BSD
-oslo.concurrency>=2.3.0 # Apache-2.0
+oslo.concurrency>=3.5.0 # Apache-2.0
@@ -11 +11 @@ oslo.serialization>=1.10.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][oslo] oslo.service 1.7.0 release (mitaka)

[no-reply]

We are glad to announce the release of:

oslo.service 1.7.0: oslo.service library

This release is part of the mitaka 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.6.0..1.7.0


c2288f2 Updated from global requirements
b0fc1fd Correct some help text
aa09a86 Fix typo in help text
321c185 wsgi: decrease the default number of greenthreads in pool
01d747a Updated from global requirements

Diffstat (except docs and test files)
-

oslo_service/_options.py | 13 +++--
requirements.txt |  4 ++--
2 files changed, 9 insertions(+), 8 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 26fce4d..9dfef9c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -10,2 +10,2 @@ monotonic>=0.6 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
-oslo.concurrency>=2.3.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0
+oslo.concurrency>=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][oslo] oslo.db 4.6.0 release (mitaka)

[no-reply]

We are thrilled to announce the release of:

oslo.db 4.6.0: Oslo Database library

This release is part of the mitaka 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.

4.6.0
^


Upgrade Notes
*

* The default value of "max_overflow" config option has been
  increased from 10 to 50 in order to allow OpenStack services heavily
  using DBs to better handle spikes of concurrent requests and lower
  the probability of getting a pool timeout issue.

  This change potentially leads to increasing of the number of open
  connections to an RDBMS server. Depending on the configuration, you
  may see "too many connections" errors in logs of OpenStack services
  / RDBMS server. The max limit of connections can be set by the means
  of these config options:

  http://dev.mysql.com/doc/refman/5.7/en/server-system-
  variables.html#sysvar_max_connections
  http://www.postgresql.org/docs/current/static/runtime-config-
  connection.html#GUC-MAX-CONNECTIONS

  For details, please see the following LP:

  https://bugs.launchpad.net/oslo.db/+bug/1535375

  and the ML thread:

  http://lists.openstack.org/pipermail/openstack-
  dev/2015-December/082717.html


Other Notes
***

* Introduce reno for deployer release notes.

Changes in oslo.db 4.5.0..4.6.0
---

db5ecf6 Increase the default max_overflow value
8717f08 Updated from global requirements
91cd18e add reno for release notes management
a78c2fe Updated from global requirements
ca1cbe9 Updated from global requirements
15a05b3 Clarify the types for retry_interval args of wrap_db_retry

Diffstat (except docs and test files)
-

oslo_db/api.py |   7 +-
oslo_db/options.py |   1 +
releasenotes/notes/add-reno-e5c2f63e73c25959.yaml  |   3 +
...ease-default-max-overflow-0af787268807f926.yaml |  25 ++
releasenotes/source/_static/.placeholder   |   0
releasenotes/source/_templates/.placeholder|   0
releasenotes/source/conf.py| 277 +
releasenotes/source/index.rst  |   9 +
releasenotes/source/liberty.rst|   6 +
releasenotes/source/unreleased.rst |   5 +
requirements.txt   |   2 +-
setup.cfg  |   3 +-
tox.ini|   3 +
13 files changed, 336 insertions(+), 5 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 3bc705b..352db43 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11 +11 @@ oslo.context>=0.2.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][oslo] oslo.serialization 2.4.0 release (mitaka)

[no-reply]

We are stoked to announce the release of:

oslo.serialization 2.4.0: Oslo Serialization library

This release is part of the mitaka release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.serialization 2.3.0..2.4.0
--

6b5116b 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 caf4a21..359c249 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -14 +14 @@ msgpack-python>=0.4.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][oslo] oslo.reports 1.6.0 release (mitaka)

[no-reply]

We are psyched to announce the release of:

oslo.reports 1.6.0: oslo.reports library

This release is part of the mitaka 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.5.0..1.6.0


7878a12 Updated from global requirements
18e6ade Updated from global requirements

Diffstat (except docs and test files)
-

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


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 00a6882..ae8992b 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12 +12 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 06da880..39842cd 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -14 +14 @@ oslo.config>=3.4.0 # Apache-2.0
-eventlet>=0.18.2 # MIT
+eventlet!=0.18.3,>=0.18.2 # MIT



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

[no-reply]

We are gleeful to announce the release of:

oslo.policy 1.5.0: Oslo Policy library

This release is part of the mitaka 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.4.0..1.5.0
---

5fb13ed 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 577f164..e8793fa 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ oslo.serialization>=1.10.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][oslo] oslo.log 3.2.0 release (mitaka)

[no-reply]

We are content to announce the release of:

oslo.log 3.2.0: oslo.log library

This release is part of the mitaka 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.

3.2.0
^

Upgrade Notes

* The deprecated use_syslog_rfc_format configuration option has been
  removed.

Changes in oslo.log 3.1.0..3.2.0


3836095 use log.warning instead of log.warn
b9954b1 Imported Translations from Zanata
961e351 Updated from global requirements
ef9f69f Remove deprecated use-syslog-rfc-format option

Diffstat (except docs and test files)
-

oslo_log/_options.py   | 10 
oslo_log/handlers.py   | 31 +---
oslo_log/locale/ja/LC_MESSAGES/oslo_log.po | 57 ++
oslo_log/log.py|  6 +--
oslo_log/versionutils.py   |  2 +-
.../remove-syslog-rfc-format-7a06772c0bb48e9b.yaml |  4 ++
requirements.txt   |  2 +-
8 files changed, 78 insertions(+), 62 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 42cf040..fca3bc1 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -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][oslo] oslo.rootwrap 4.1.0 release (mitaka)

[no-reply]

We are satisfied to announce the release of:

oslo.rootwrap 4.1.0: Oslo Rootwrap

This release is part of the mitaka release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.rootwrap 4.0.0..4.1.0
-

8e069b0 Updated from global requirements

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 9f2a3f7..2de1043 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -24 +24 @@ mock>=1.2 # BSD
-eventlet>=0.18.2 # MIT
+eventlet!=0.18.3,>=0.18.2 # MIT



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

[no-reply]

We are excited to announce the release of:

oslo.i18n 3.4.0: Oslo i18n library

This release is part of the mitaka 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.3.0..3.4.0
-

c6e44bc Imported Translations from Zanata

Diffstat (except docs and test files)
-

oslo_i18n/locale/ja/LC_MESSAGES/oslo_i18n.po | 18 ++
1 file changed, 18 insertions(+)




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

[no-reply]

We are pumped to announce the release of:

oslo.middleware 3.7.0: Oslo Middleware library

This release is part of the mitaka 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.6.0..3.7.0
---

bb8dbeb work around doc build error

Diffstat (except docs and test files)
-

.gitignore  | 1 +
4 files changed, 19 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

[openstack-dev] [release][oslo] oslo.context 2.2.0 release (mitaka)

[no-reply]

We are stoked to announce the release of:

oslo.context 2.2.0: Oslo Context library

This release is part of the mitaka release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.context 2.1.0..2.2.0


187d574 Standardize an oslo.policy credentials dictionary
217a4ed Revert "Add common oslo.log format parameters"
f383bd2 Add roles to context

Diffstat (except docs and test files)
-

oslo_context/context.py| 35 +---
2 files changed, 57 insertions(+), 32 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

[openstack-dev] [release][oslo] oslo.config 3.9.0 release (mitaka)

[no-reply]

We are happy to announce the release of:

oslo.config 3.9.0: Oslo Configuration API

This release is part of the mitaka release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

3.9.0
^

Other Notes

* Start using reno for managing release notes.

Changes in oslo.config 3.8.0..3.9.0
---

77400b2 remove redundant call to set explicit target
3da593d clear the cache before mutating the config files
3410f05 Updated from global requirements
0025777 Add None-check to find_file
92306bc add support for mutable options in the config generator
7a4ac44 add unreleased page to release notes build
8247698 add a release note mentioning our use of reno
68d5def Add reno for release notes management

Diffstat (except docs and test files)
-

.gitignore|   3 +
oslo_config/cfg.py|   4 +-
oslo_config/generator.py  |  31 ++-
oslo_config/sphinxext.py  |  24 +-
oslo_config/version.py|  18 ++
releasenotes/notes/.placeholder   |   0
releasenotes/notes/add-reno-71dc832ce29b962f.yaml |   3 +
releasenotes/source/_static/.placeholder  |   0
releasenotes/source/_templates/.placeholder   |   0
releasenotes/source/conf.py   | 277 ++
releasenotes/source/index.rst |   9 +
releasenotes/source/liberty.rst   |   6 +
releasenotes/source/unreleased.rst|   5 +
test-requirements.txt |   1 +
tox.ini   |   3 +
18 files changed, 482 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 015e3f2..fe3d3d1 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -22,0 +23 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+reno>=0.1.1 # Apache2



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

[no-reply]

We are happy to announce the release of:

oslo.cache 1.4.0: Cache storage for Openstack projects.

This release is part of the mitaka 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.3.0..1.4.0
--

ee407d0 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 7df43d6..9867a50 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11 +11 @@ oslo.log>=1.14.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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Tony Breeds]

On Thu, Feb 25, 2016 at 04:45:48AM +, Watanabe, Isao wrote:
> Hello team
> 
> Does anyone know about why sqlalchemy-utils fails devstack install since
> about 3:00 UTC, Feb 25th?

I don't have anything helpful to add really other than:

This bug https://bugs.launchpad.net/devstack/+bug/1548591 was opened 2 days ago 
; but
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22error%20in%20SQLAlchemy-Utils%20setup%20command:%5C%22=864000s

Matches your timeline that it's started being an issue in the last 2 hours

Shows that's really hurting kolla, but openstack-ansible, devstack, neutron and
octavia are all affected.

Typically somethign like this will happen when a new release for $project comes 
out but:
SQLAlchemy-Utils-0.31.6.tar.gz : 2016-01-21T12:36:09

And I4ff173ed9559d3dfe38cde15dc0f9a9487b45528 merged it into u-c on Sun Jan 24
06:26:51 2016 +

Looksing at: 
https://github.com/kvesteri/sqlalchemy-utils/blob/master/setup.py#L25-L58

I wonder if all the failures share a common python? perhaps 3.4?

Yours Tony.


signature.asc
Description: PGP 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] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review

[Angus Lees]

(Reposting my reply to your gerrit comment here as well - conversation will
probably be easier here than in gerrit)

On Thu, 25 Feb 2016 at 00:07 Duncan Thomas  wrote:

> My (negative) feedback is on the review - I'm really not sure that this
> matches what I understood the vision of privsep to be at all.
>
> - If this is the vision / the new vision then I think it is majorly
> flawed.
>
> - If it is skipping the vision in the name of expediency of
> implementation, then I think it has gone too far in that direction and
> we've better off holding off one more cycle and putting it in next cycle
> instead with a touch more purity of vision.
>
> Apologies since you've clearly put work into it, and I should have
> provided such feedback earlier.
>

Yes, I agree with your concerns 100% and I'm actually quite glad that you
also understand that this isn't a very satisfying use of privsep.

Better uses of privsep would look more like
https://review.openstack.org/#/c/258252/ - but they're slow to write since
they typically involve quite a bit of refactoring of code in order to move
the trust boundary to a useful point up the call stack.  For os-brick in
particular, I found it quite difficult/risky performing such code refactors
without an easy way to actually test the affected low-level device
manipulation.

At the nova mid-cycle (and again in the nova-cinder VC conversation you
were part of), it was decided that the difficulties in merging the os-brick
rootwrap filters into nova (and I presume cinder) were too urgent to wait
for such a slow os-brick refactoring process.  The conclusion we reached
was that we would do a quick+dirty rootwrap drop-in replacement that
effectively just ran commands as root for Mitaka, and then we would come
back and refactor various codepaths away from that mechanism over time.
This is that first quick+dirty change.
I tried to capture that in the commit description, but evidently did a poor
job - if the above makes it any clearer to you, I'd welcome any suggested
rewording for the commit description.

TL;DR: what this buys us is the ability to use new/different command lines
in os-brick without having to go through a rootwrap filters merge in
downstream projects (and it is also that first baby step towards a
technology that will allow something better in the future).


Please continue to ask questions, since I know very few people have
actually looked at any of privsep nor the os-brick change until now.

 - Gus


> On 24 February 2016 at 14:59, Michał Dulko  wrote:
>
>> On 02/24/2016 04:51 AM, Angus Lees wrote:
>> > Re: https://review.openstack.org/#/c/277224
>> >
>> > Most of the various required changes have flushed out by now, and this
>> > change now passes the dsvm-full integration tests(*).
>> >
>> > (*) well, the experimental job anyway.  It still relies on a
>> > merged-but-not-yet-released change in oslo.privsep so gate + 3rd party
>> > won't pass until that happens.
>> >
>> > What?
>> > This change replaces os-brick's use of rootwrap with a quick+dirty
>> > privsep-based drop-in replacement.  Privsep doesn't actually provide
>> > much security isolation when used in this way, but it *does* now run
>> > commands with CAP_SYS_ADMIN (still uid=0/gid=0) rather than full root
>> > superpowers.  The big win from a practical point of view is that it
>> > also means os-brick's rootwrap filters file is essentially deleted and
>> > no longer has to be manually merged with downstream projects.
>> >
>> > Code changes required in nova/cinder:
>> > There is one change each to nova+cinder to add the relevant
>> > privsep-helper command to rootwrap filters, and a devstack change to
>> > add a nova.conf/cinder.conf setting.  That's it - this is otherwise a
>> > backwards/forwards compatible change for nova+cinder.
>> >
>> > Deployment changes required in nova/cinder:
>> > A new "privsep_rootwrap.helper_command" needs to be defined in
>> > nova/cinder.conf (default is something sensible using sudo), and
>> > rootwrap filters or sudoers updated depending on the exact command
>> > chosen.  Be aware that any commands will now be run with CAP_SYS_ADMIN
>> > (only), and if that's insufficient for your hardware/drivers it can be
>> > tweaked with other oslo_config options.
>> >
>> > Risks:
>> > The end-result is still just running the same commands as before, via
>> > a different path - so there's not a lot of adventurousness here.  The
>> > big behavioural change is CAP_SYS_ADMIN, and (as highlighted above)
>> > it's conceivable that the driver for some exotic os-brick/cinder
>> > hardware out there wants something more than that.
>> >
>> > Work remaining:
>> > - global-requirements change needed (for os-brick) once the latest
>> > oslo.privsep release is made
>> > - cinder/nova/devstack changes need to be merged
>> > - after the above, the os-brick gate integration jobs will be able to
>> > pass, and it can be merged
>> > - If we want to *force* 

Re: [openstack-dev] [Keystone] State of Fernet tokens

[Morgan Fainberg]

On Wed, Feb 24, 2016 at 8:50 PM, Adam Young  wrote:

> A lot of people seem to be counting on Fernet tokens, so I figured I'd
> give a quick update.
>
> Back in December, I made a quick check to see what would happen if we
> swapped Fernet in as the default token provider.  A bunch of tests fails.
> Lance Bragstad and Raildo Mascena took that and ran with it.
>
> As of tonight, there are 18 Failed test.  4 are due to trust tokens on
> V2.  we need to explicitly prevent trust execution for the V2 API, as the
> rules are not being enforced.  We sent up a warning about this before, but
> let me make it explicit;  V2 Trust support is being yanked due to the need
> to make Fernet work.
>
> There are also some strange things going on with revocation events. Since
> token revocations are only going to be handled via the revocation event API
> (not revocation list) we need to get this right.
>
> Here is the complete list of failing tests right now:
>
>
> These  three are the trust tests I described above.
>
> {0}
> keystone.tests.unit.test_auth.AuthWithTrust.test_delete_tokens_for_user_invalidates_tokens_from_trust
> [0.420011s] ... FAILED
> {0}
> keystone.tests.unit.test_auth.AuthWithTrust.test_token_from_trust_cant_get_another_token
> [0.443193s] ... FAILED
> {1}
> keystone.tests.unit.test_auth.AuthWithTrust.test_delete_trust_revokes_token
> [0.465307s] ... FAILED
>
>
> Something seems to be strange with Cache invalidation.  They all deal with
> token deletion, which is handled by Revocation Events now.
> But this seems to be a test problem, not with the main code.
>
> {5}
> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_unscoped_token
> [0.082660s] ... FAILED
> {4}
> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user
> [0.085062s] ... FAILED
> {3}
> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant
> [0.106043s] ... FAILED
> {1}
> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_id
> [0.081628s] ... FAILED
> {1}
> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user
> [0.244603s] ... FAILED
> {1}
> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant
> [0.237667s] ... FAILED
> {6}
> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_unscoped_token
> [0.278852s] ... FAILED
> {0}
> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_id
> [0.254170s] ... FAILED
>
>
All of these cache validation tests are failing for two distinct reasons:

1) the Fernet token key repository fixture is not being used for the
classes. Add in the use of the key_repository fixture and the first failure
will go away

2) The test is insanely synthetic and doesn't actually create data in the
identity or assignment backends. These tests need to be real test cases not
relying on the fact that the token backend contains the validated dataset.
This basically comes down to doing the load_fixtures() call and making sure
to use "real" project_id/user_id combinations.


> {5}
> keystone.tests.unit.test_v3_assignment.AssignmentInheritanceTestCase.test_crud_inherited_and_direct_assignment_on_projects
> [1.390265s] ... FAILED
> {3}
> keystone.tests.unit.test_no_admin_token_auth.TestNoAdminTokenAuth.test_request_no_admin_token_auth
> [0.111520s] ... FAILED
>
> Since the revocation list is not going to be used with Fernet, I am not
> too worried about these.  I think these tests can be changed to use PKI
> tokens for now.
>
>
Skip the revocation_list tests for Fernet absolutely.


>
> {2} keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_md5
> [2.025202s] ... FAILED
> {2}
> keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_sha256
> [1.650198s] ... FAILED
> {6}
> keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_audit_id_only_token
> [1.024048s] ... FAILED
> {5}
> keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_ids_token
> [1.091590s] ... FAILED
>
> And this one?  Passed when I ran it directly.  Looks like a bad test
> setup.
> {3}
> keystone.tests.unit.test_v3_filters.IdentityTestListLimitCase.test_list_users_filtered_by_funny_name
> [2.169297s] ... FAILED
>
>
> Review is here:
> https://review.openstack.org/#/c/258650
>
> __
> 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

Re: [openstack-dev] sqlalchemy-utils fails devstack install

[Watanabe, Isao]

Hello, @Shinobu

I'm using master branch.

Best regards,
Watanabe.isao



> -Original Message-
> From: Shinobu Kinjo [mailto:ski...@redhat.com]
> Sent: Thursday, February 25, 2016 1:55 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] sqlalchemy-utils fails devstack install
> 
> Which branch are you using?
> 
> Rgds,
> Shinobu
> 
> - Original Message -
> From: "Isao Watanabe" 
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, February 25, 2016 1:45:48 PM
> Subject: [openstack-dev] sqlalchemy-utils fails devstack install
> 
> Hello team
> 
> Does anyone know about why sqlalchemy-utils fails devstack install since
> about 3:00 UTC, Feb 25th?
> 
> Our CI start to fail and in log it says:
> 
> 2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c
> /opt/stack/new/requirements/upper-constraints.txt (line 24))
> 2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz
> (112kB)
> 2016-02-25 03:34:23.031 | Complete output from command python setup.py
> egg_info:
> 2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command:
> 'extras_require' must be a dictionary whose values are strings or lists of
> strings containing valid project/version requirement specifiers.
> 2016-02-25 03:34:23.031 |
> 2016-02-25 03:34:23.031 | 
> 2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed with
> error code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils
> 
> However, in mirror[1] which we are using, the package is just there, which
> confused me.
> [1] http://mirror.dfw.rax.openstack.org/pypi/simple/sqlalchemy-utils/
> 
> Thanks for any help.
> 
> Best regards,
> Watanabe.isao
> 
> 
> 
> 
> __
> 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] sqlalchemy-utils fails devstack install

[Shinobu Kinjo]

Which branch are you using?

Rgds,
Shinobu

- Original Message -
From: "Isao Watanabe" 
To: openstack-dev@lists.openstack.org
Sent: Thursday, February 25, 2016 1:45:48 PM
Subject: [openstack-dev] sqlalchemy-utils fails devstack install

Hello team

Does anyone know about why sqlalchemy-utils fails devstack install since about 
3:00 UTC, Feb 25th?

Our CI start to fail and in log it says:

2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c 
/opt/stack/new/requirements/upper-constraints.txt (line 24))
2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz (112kB)
2016-02-25 03:34:23.031 | Complete output from command python setup.py 
egg_info:
2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command: 
'extras_require' must be a dictionary whose values are strings or lists of 
strings containing valid project/version requirement specifiers.
2016-02-25 03:34:23.031 | 
2016-02-25 03:34:23.031 | 
2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed with error 
code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils

However, in mirror[1] which we are using, the package is just there, which 
confused me.
[1] http://mirror.dfw.rax.openstack.org/pypi/simple/sqlalchemy-utils/

Thanks for any help.

Best regards,
Watanabe.isao



__
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][Kuryr] Kuryr-Magnum integration (nested containers)

[Fawad Khaliq]

Folks,

Thanks for the reviews. The spec [1] has been updated after the latest
feedback.

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

Thanks,
Fawad Khaliq


On Mon, Feb 22, 2016 at 11:58 PM, Fawad Khaliq  wrote:

> Hi folks,
>
> The spec [1] for Mangum-Kuryr integration is out and has already gone
> through good discussion and updates. Please take out some time to review,
> we would like to converge on the design soon.
>
> [1] https://review.openstack.org/#/c/269039/5
>
> Thanks,
> Fawad Khaliq
>
>
__
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] [Keystone] State of Fernet tokens

[Adam Young]

A lot of people seem to be counting on Fernet tokens, so I figured I'd 
give a quick update.


Back in December, I made a quick check to see what would happen if we 
swapped Fernet in as the default token provider.  A bunch of tests 
fails.  Lance Bragstad and Raildo Mascena took that and ran with it.


As of tonight, there are 18 Failed test.  4 are due to trust tokens on 
V2.  we need to explicitly prevent trust execution for the V2 API, as 
the rules are not being enforced.  We sent up a warning about this 
before, but let me make it explicit;  V2 Trust support is being yanked 
due to the need to make Fernet work.


There are also some strange things going on with revocation events. 
Since token revocations are only going to be handled via the revocation 
event API (not revocation list) we need to get this right.


Here is the complete list of failing tests right now:


These  three are the trust tests I described above.

{0} 
keystone.tests.unit.test_auth.AuthWithTrust.test_delete_tokens_for_user_invalidates_tokens_from_trust 
[0.420011s] ... FAILED
{0} 
keystone.tests.unit.test_auth.AuthWithTrust.test_token_from_trust_cant_get_another_token 
[0.443193s] ... FAILED
{1} 
keystone.tests.unit.test_auth.AuthWithTrust.test_delete_trust_revokes_token 
[0.465307s] ... FAILED



Something seems to be strange with Cache invalidation.  They all deal 
with token deletion, which is handled by Revocation Events now.

But this seems to be a test problem, not with the main code.

{5} 
keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_unscoped_token 
[0.082660s] ... FAILED
{4} 
keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user 
[0.085062s] ... FAILED
{3} 
keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant 
[0.106043s] ... FAILED
{1} 
keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_id 
[0.081628s] ... FAILED
{1} 
keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user 
[0.244603s] ... FAILED
{1} 
keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant 
[0.237667s] ... FAILED
{6} 
keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_unscoped_token 
[0.278852s] ... FAILED
{0} 
keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_id 
[0.254170s] ... FAILED


{5} 
keystone.tests.unit.test_v3_assignment.AssignmentInheritanceTestCase.test_crud_inherited_and_direct_assignment_on_projects 
[1.390265s] ... FAILED
{3} 
keystone.tests.unit.test_no_admin_token_auth.TestNoAdminTokenAuth.test_request_no_admin_token_auth 
[0.111520s] ... FAILED


Since the revocation list is not going to be used with Fernet, I am not 
too worried about these.  I think these tests can be changed to use PKI 
tokens for now.



{2} 
keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_md5 
[2.025202s] ... FAILED
{2} 
keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_sha256 
[1.650198s] ... FAILED
{6} 
keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_audit_id_only_token 
[1.024048s] ... FAILED
{5} 
keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_ids_token 
[1.091590s] ... FAILED


And this one?  Passed when I ran it directly.  Looks like a bad test setup.
{3} 
keystone.tests.unit.test_v3_filters.IdentityTestListLimitCase.test_list_users_filtered_by_funny_name 
[2.169297s] ... FAILED



Review is here:
https://review.openstack.org/#/c/258650
__
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] sqlalchemy-utils fails devstack install

[Watanabe, Isao]

Hello team

Does anyone know about why sqlalchemy-utils fails devstack install since about 
3:00 UTC, Feb 25th?

Our CI start to fail and in log it says:

2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c 
/opt/stack/new/requirements/upper-constraints.txt (line 24))
2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz (112kB)
2016-02-25 03:34:23.031 | Complete output from command python setup.py 
egg_info:
2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command: 
'extras_require' must be a dictionary whose values are strings or lists of 
strings containing valid project/version requirement specifiers.
2016-02-25 03:34:23.031 | 
2016-02-25 03:34:23.031 | 
2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed with error 
code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils

However, in mirror[1] which we are using, the package is just there, which 
confused me.
[1] http://mirror.dfw.rax.openstack.org/pypi/simple/sqlalchemy-utils/

Thanks for any help.

Best regards,
Watanabe.isao



__
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] What's up in our CI?

[Emilien Macchi]

On 02/24/2016 09:37 PM, Emilien Macchi wrote:
> 
> 
> On 02/24/2016 09:28 PM, Emilien Macchi wrote:
>> 1/ CI failures
>> For those who contributed to Puppet OpenStack modules over the last
>> days, you might have noticed our CI was pretty unstable.
>>
>> The main reason is that our 2 scenarios are overloaded by the number of
>> services & tests, so they randomly timeout.
>>
>> Here are some actions that should bring back our CI in a good shape:
>> * Add scenario003 and move some services from 001/002 to 003
>>   https://review.openstack.org/284388
>> * Optimize Zuul layout to consume less resources in OpenStack Infra
>>   https://review.openstack.org/284431
>> * Continue to reduce to 2 the number of workers when possible
>>   https://review.openstack.org/284289
>> * Investigate why `gem install r10k` takes 12 minutes on Internap cloud
>>   (instead of a few seconds on other clouds)
>>   https://review.openstack.org/#/c/283696/
>>
>>
>> 2/ scenario001 is the RBD scenario
>> scenario001 is now deploying Glance, Nova, Cinder and Gnocchi with RBD
>> backend (Ceph).
>> We can call it a Compute + Telemetry + Ceph scenario.
>>
>>
>> 3/ What's next
>> Currently in the pipe:
>> * running tempest with plugins
>> * add Zaqar
>> * add Neutron FWaaS, LBaaS
>> * on scenario002: use Swift for Glance backand and Neutron ML2
>> linuxbridge (instead of ML2 OVS).
>> * more (please bring ideas & feedback)
>>
>> Any questions / suggestions are welcome,
>>
> 
> I realize we have a new thing:
> 
> 4/ Canonical updated UCA packaging for Mitaka (last update was in
> December). Our integration jobs running on Trusty are all broken now.
> 
> We're investigating that but if we don't find a fix by tomorrow morning
> I'll propose to disable voting on Ubuntu.

So I've noticed multiple issues, some of them are going to be fixed
soon, but others need further investigation.
We also have chicken & egg problem where we need a patch in
puppet-neutron required by our integration CI to pass, and vice-versa.
  https://review.openstack.org/284503
  https://review.openstack.org/283714

I propose we disable voting on Ubuntu integration jobs:
https://review.openstack.org/284515

Until we stabilize a little bit.

Once we sort this out:
* we'll re-enable voting for trusty jobs
* I'll cut a Mitaka beta release
-- 
Emilien Macchi



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] [puppet] What's up in our CI?

[Emilien Macchi]

On 02/24/2016 09:28 PM, Emilien Macchi wrote:
> 1/ CI failures
> For those who contributed to Puppet OpenStack modules over the last
> days, you might have noticed our CI was pretty unstable.
> 
> The main reason is that our 2 scenarios are overloaded by the number of
> services & tests, so they randomly timeout.
> 
> Here are some actions that should bring back our CI in a good shape:
> * Add scenario003 and move some services from 001/002 to 003
>   https://review.openstack.org/284388
> * Optimize Zuul layout to consume less resources in OpenStack Infra
>   https://review.openstack.org/284431
> * Continue to reduce to 2 the number of workers when possible
>   https://review.openstack.org/284289
> * Investigate why `gem install r10k` takes 12 minutes on Internap cloud
>   (instead of a few seconds on other clouds)
>   https://review.openstack.org/#/c/283696/
> 
> 
> 2/ scenario001 is the RBD scenario
> scenario001 is now deploying Glance, Nova, Cinder and Gnocchi with RBD
> backend (Ceph).
> We can call it a Compute + Telemetry + Ceph scenario.
> 
> 
> 3/ What's next
> Currently in the pipe:
> * running tempest with plugins
> * add Zaqar
> * add Neutron FWaaS, LBaaS
> * on scenario002: use Swift for Glance backand and Neutron ML2
> linuxbridge (instead of ML2 OVS).
> * more (please bring ideas & feedback)
> 
> Any questions / suggestions are welcome,
> 

I realize we have a new thing:

4/ Canonical updated UCA packaging for Mitaka (last update was in
December). Our integration jobs running on Trusty are all broken now.

We're investigating that but if we don't find a fix by tomorrow morning
I'll propose to disable voting on Ubuntu.
-- 
Emilien Macchi



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

[openstack-dev] [puppet] What's up in our CI?

[Emilien Macchi]

1/ CI failures
For those who contributed to Puppet OpenStack modules over the last
days, you might have noticed our CI was pretty unstable.

The main reason is that our 2 scenarios are overloaded by the number of
services & tests, so they randomly timeout.

Here are some actions that should bring back our CI in a good shape:
* Add scenario003 and move some services from 001/002 to 003
  https://review.openstack.org/284388
* Optimize Zuul layout to consume less resources in OpenStack Infra
  https://review.openstack.org/284431
* Continue to reduce to 2 the number of workers when possible
  https://review.openstack.org/284289
* Investigate why `gem install r10k` takes 12 minutes on Internap cloud
  (instead of a few seconds on other clouds)
  https://review.openstack.org/#/c/283696/


2/ scenario001 is the RBD scenario
scenario001 is now deploying Glance, Nova, Cinder and Gnocchi with RBD
backend (Ceph).
We can call it a Compute + Telemetry + Ceph scenario.


3/ What's next
Currently in the pipe:
* running tempest with plugins
* add Zaqar
* add Neutron FWaaS, LBaaS
* on scenario002: use Swift for Glance backand and Neutron ML2
linuxbridge (instead of ML2 OVS).
* more (please bring ideas & feedback)

Any questions / suggestions are welcome,
-- 
Emilien Macchi



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] [ceilometer] Unable to get IPMI meter readings

[Lu, Lianhao]

On Feb 25, 2016 06:18, Kapil wrote:
> Hi
> 
> 
> I discussed this problem with gordc on the telemetry IRC channel but I 
> am still facing issues.
> 
> I am running the ceilometer-agent-ipmi on the compute nodes, I changed 
> pipeline.yaml of the compute node to include the ipmi meters and 
> resource as "ipmi://localhost".
> 
> - name: meter_ipmi
>   interval: 60
>   resources:
>   - ipmi://localhost meters: - "hardware.ipmi.node*" -
>   "hardware.ipmi*" - "hardware.degree*" sinks: - meter_sink I 
> have ipmitool installed on the compute nodes and restarted the 
> ceilometer services on compute and controller nodes. Yet, I am not 
> receiving any ipmi meters when I run "ceilometer meter-list". I also 
> tried passing the hypervisor IP address and the ipmi address I get 
> when I run "ipmitool lan print" to resources but to no avail.
> 
> 
> Please help in this regard.
> 
> 
> Thanks
> Kapil Agarwal

Hi Kapil,

Would you please turn on debug/verbose configurations and paste the log of 
ceilometer-agent-ipmi on http://paste.openstack.org ?

-Lianhao Lu
__
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] Now part of OpenStack big-tent

[Baohua Yang]

Great and congrats!

On Wed, Feb 24, 2016 at 11:51 PM, Gal Sagie  wrote:

> Hello Everyone,
>
> Just wanted to update you that Kuryr [1] was officially accepted yesterday
> as a
> big tent project.
>
> We are currently facing some interesting challenges and times and if you
> are running containers in OpenStack in mixed environments you most
> certainly
> want to look and examine Kuryr.
>
> We are holding a weekly IRC meeting [2] which is alternating between time
> zones
> so you have no excuse :) everyone are welcome!
>
> We want to help and solve more challenges in the realm of containers
> networking
> deployments in OpenStack and if you are deploying this either in
> development or
> in production we would love to hear your experience and the problems you
> are facing
> and try to help you manage this better, feel free to share!
>
> [1] https://wiki.openstack.org/wiki/Kuryr
> [2] https://wiki.openstack.org/wiki/Meetings/Kuryr
>
> __
> 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 wishes!
Baohua
__
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] Fwd: [Juno] LBaaS v1.0 mystery device_id

[surekha saharan]

Hello All,

I can't find the "device_id" anywhere the port in vip returns.
Below is the details of a vip, note the port_id "
*03a12958-656f-492b-8114-65d037ad6743"*

*neutron lb-vip-show
b2b11f89-48fc-4fd4-99f9-6f26977f353a+-+--+|
Field| Value
|+-+--+| address
 | 30.0.0.138|| admin_state_up   | True
 || connection_limit | -1
   || description  |
  || id   |
b2b11f89-48fc-4fd4-99f9-6f26977f353a || name | vip2
 || pool_id  |
4e0a1909-08f9-4124-94c0-ef0650b36512 || port_id  |
03a12958-656f-492b-8114-65d037ad6743 || protocol | HTTP
 || protocol_port| 80
   || session_persistence |
  || status   | ACTIVE
   || status_description  |
  || subnet_id|
61ed9305-7b15-484a-b843-cb759aebc163 || tenant_id|
3418d53683654d37b47caa1b66b72a21
|+-+--+*


Now, if I get the details of the above port, I get the device_id "*
724fc160-2b2e-597e-b9ed-7f65313cd73f".*

*The id of the vip is part of name attribute
"vip-b2b11f89-48fc-4fd4-99f9-6f26977f353a "*


* neutron port-show
03a12958-656f-492b-8114-65d037ad6743+---+---+|
Field  | Value

|+---+---+|
admin_state_up | True

|| allowed_address_pairs |

|| binding:host_id| ubuntu
||
binding:profile| {}

|| binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
|| binding:vif_type   | ovs

|| binding:vnic_type | normal
||
device_id  | 724fc160-2b2e-597e-b9ed-7f65313cd73f
  || device_owner   |
neutron:LOADBALANCER
  ||
extra_dhcp_opts|

|| fixed_ips  | {"subnet_id":
"61ed9305-7b15-484a-b843-cb759aebc163", "ip_address": "30.0.0.138"} || id
| 03a12958-656f-492b-8114-65d037ad6743
  || mac_address|
fa:16:3e:ec:2e:3b
 || name
  | vip-b2b11f89-48fc-4fd4-99f9-6f26977f353a
  || network_id |
ef132b57-edc1-4d64-9591-38b80f73e23f
  || security_groups|
3365e9e0-4038-4800-b6b3-364b34e177d1
  || status | ACTIVE
||
tenant_id  | 3418d53683654d37b47caa1b66b72a21

|+---+---+*
I cannot find the device_id anywhere as part of "nova list" or any other
neutron command, what is this device_id referring to.

Appreciate any response on this.

Regards,
Surekha
__
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] solving API case sensitivity issues

[Chris Friesen]

On 02/24/2016 02:34 PM, Sean Dague wrote:


There are no urls stored here. This is content coming through the body.
While I do appreciate many folks weighing in that haven't read the bug
yet, I would be even better if people did read the bug first.

We have the ability to decide at the API level what the behavior is of
payloads in POST / GET. Given the majority of our users are on mysql,
they've never had access to case sensitive overlapping metadata on
aggregates before. Doing so seems odd and potentially confusing.


On the other hand, coming from a UNIX environment where case sensitivity is the 
default, it seems odd that we'd intentionally become case-insensitive.


For option 2 do we need to actually update the DB column description?  Or is 
there a way to alter the query to be case-insensitive without altering the 
column itself (using collate maybe)?


Chris

__
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]How to manage the life cycle of resources in a stack?

[Zane Bitter]

On 24/02/16 11:27, zhu4236926 wrote:

Hi guys,
 I  get some resources by creating a stack, e.g. ,the resources may
be 2 volumes, volume A and volume B.  If the volume A and volume B are
useless, we can delete them by deleting the stack , we also can delete
them by cinder.If  they are deleted by cinder, though the volumes have
been delete, the resources and stack are still exist,  a tenant has the
maxmum quantity of stacks, so I may couldn't  create the stack if the
number of left stacks exceed the limit . If I delete by deleting the
stack, the volume A and volume B would be deleted both, may be I just
want to delete the volume A and reservce volume B.
 So how should I manage the resources(volumeA and volumeB) created
by heat, deleted by cinder or heat?


If you're creating stuff through Heat you should continue to manage it 
through Heat. So either delete the stack or, as Steve said, update the 
stack to remove those volumes.


That's the best way, but if you do delete stuff in Cinder directly, you 
*should* still be able to delete the stack later. I don't recommend 
doing it that way around though.


cheers,
Zane.

[Also this is more of a question for ask.openstack.org rather than the 
development list]



__
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] [openstack-ansible] Installing networking-* pythonclient extensions to multiple locations

[Kevin Carter]

Hi Javeria,


We could call out our supported sub-projects in the `openstack_services.yml` 
file and install them as part of the plugin backend similar to what we've done 
with the "neutron_lbaas" package[0][1]. However, this would not specifically 
fix the neutron clients in all places as you've mentioned. While I can make a 
case for the utility container to get the extra neutron-client-extensions, I'm 
not sure we need them everywhere. Do we suspect a user or service may need 
access to the additional client extensions from the Heat or Nova venvs or 
anywhere else for that matter?



[0] - 
https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/os_neutron/defaults/main.yml#L349

[1] - 
https://github.com/openstack/openstack-ansible/blob/master/playbooks/defaults/repo_packages/openstack_services.yml#L85-L87


--

Kevin Carter
IRC: cloudnull


From: Javeria Khan 
Sent: Sunday, February 21, 2016 5:09 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [openstack-ansible] Installing networking-* 
pythonclient extensions to multiple locations

Hey everyone,

At the moment OSA installs the python-neutronclient in a few locations 
including the containers neutron-server, utility, heat, tempest.

Now neutron has a bunch of sub-projects like networking-l2gw [1], 
networking-bgpvpn [2] networking-plumgrid [5] etc, which have their own 
python-neutronclient CLI extensions [3][4][5] in their respective repositories 
and packages.

Since these CLI extensions are not part of the neutron packages and must be 
enabled by installing the additional networking-* packages. We don't install 
most of these sub-projects in OSA at the moment, however moving forward do you 
think its reasonable to install said packages in every location that installs 
the neutron client inside the OSA plays? If so, then how would you recommend we 
go about it since the installation will be conditional on the enabling of the 
relevant neutron subproject features?

[1] https://github.com/openstack/networking-l2gw
[2] https://github.com/openstack/networking-bgpvpn
[3] 
https://github.com/openstack/networking-l2gw/tree/master/networking_l2gw/l2gatewayclient
[4] 
https://github.com/openstack/networking-bgpvpn/tree/master/networking_bgpvpn/neutronclient
[5] https://github.com/openstack/networking-plumgrid


Thanks,
Javeria
__
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] python-novaclient region setting

[Jamie Lennox]

On 23 February 2016 at 01:02, Monty Taylor  wrote:

> On 02/21/2016 11:40 PM, Andrey Kurilin wrote:
>
>> Hi!
>> `novaclient.client.Client` entry-point supports almost the same
>> arguments as `novaclient.v2.client.Client`. The difference is only in
>> api_version, so you can set up region via `novaclient.client.Client` in
>> the same way as `novaclient.v2.client.Client`.
>>
>
> The easiest way to get a properly constructed nova Client is with
> os-client-config:
>
> import os_client_config
>
> OS_PROJECT_NAME="d8af8a8f-a573-48e6-898a-af333b970a2d"
> OS_USERNAME="0b8c435b-cc4d-4e05-8a47-a2ada0539af1"
> OS_PASSWORD="REDACTED"
> OS_AUTH_URL="http://auth.vexxhost.net;
> OS_REGION_NAME="ca-ymq-1"
>
> client = os_client_config.make_client(
> 'compute',
> auth_url=OS_AUTH_URL, username=OS_USERNAME,
> password=OS_PASSWORD, project_name=OS_PROJECT_NAME,
> region_name=OS_REGION_NAME)
>
> The upside is that the constructor interface is the same for all of the
> rest of the client libs too (just change the first argument) - and it will
> also read in OS_ env vars or named clouds from clouds.yaml if you have them
> set.
>
> (The 'simplest' way is to put your auth and region information into a
> clouds.yaml file like this:
>
>
> http://docs.openstack.org/developer/os-client-config/#site-specific-file-locations
>
> Such as:
>
> # ~/.config/openstack/clouds.yaml
> clouds:
>   vexxhost:
>  profile: vexxhost
>  auth:
>project_name: d8af8a8f-a573-48e6-898a-af333b970a2d
>username: 0b8c435b-cc4d-4e05-8a47-a2ada0539af1
>password: REDACTED
>  region_name: ca-ymq-1
>
>
> And do:
>
> client = os_client_config.make_client('compute', cloud='vexxhost')
>
>
> If you don't want to do that for some reason but you'd like to construct a
> novaclient Client object by hand:
>
>
> from keystoneauth1 import loading
> from keystoneauth1 import session as ksa_session
> from novaclient import client as nova_client
>
> OS_PROJECT_NAME="d8af8a8f-a573-48e6-898a-af333b970a2d"
> OS_USERNAME="0b8c435b-cc4d-4e05-8a47-a2ada0539af1"
> OS_PASSWORD="REDACTED"
> OS_AUTH_URL="http://auth.vexxhost.net;
> OS_REGION_NAME="ca-ymq-1"
>
> # Get the auth loader for the password auth plugin
> loader = loading.get_plugin_loader('password')
> # Construct the auth plugin
> auth_plugin = loader.load_from_options(
> auth_url=OS_AUTH_URL, username=OS_USERNAME, password=OS_PASSWORD,
> project_name=OS_PROJECT_NAME)
>

note that loaders here are generally things like load from config file, or
load from argparse arguments. If you are doing everything in a script like
this you would probably just use the keystoneauth1.identity.Password like

from keystoneauth1 import identity

auth_plugin = identity.Password(auth_url=)



> # Construct a keystone session
> # Other arguments that are potentially useful here are:
> #  verify - bool, whether or not to verify SSL connection validity
> #  cert - SSL cert information
> #  timout - time in seconds to use for connection level TCP timeouts
> session = ksa_session.Session(auth_plugin)
>
> # Now make the client
> # Other arguments you may be interested in:
> #  service_name - if you need to specify a service name for finding the
> # right service in the catalog
> #  service_type - if the cloud in question has given a different
> # service type (should be 'compute' for nova - but
> # novaclient sets it, so it's safe to omit in most cases
> #  endpoint_override - if you want to tell it to use a different URL
> #  than what the keystone catalog returns
> #  endpoint_type - if you need to specify admin or internal
> #  endpoints rather than the default 'public'
> #  Note that in glance and barbican, this key is called
> #  'interface'
> client = nova_client.Client(
> version='2.0', # or set the specific microversion you want
> session=session, region_name=OS_REGION_NAME)
>
> It might be clear why I prefer the os_client_config factory function
> instead - but what I prefer and what you prefer might not be the same
> thing. :)
>
> On Mon, Feb 22, 2016 at 6:11 AM, Xav Paice > > wrote:
>>
>> Hi,
>>
>> In http://docs.openstack.org/developer/python-novaclient/api.html
>> it's got some pretty clear instructions not to
>> use novaclient.v2.client.Client but I can't see another way to
>> specify the region - there's more than one in my installation, and
>> no param for region in novaclient.client.Client
>>
>> Shall I hunt down/write a blueprint for that?
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > 

[openstack-dev] [ceilometer] Unable to get IPMI meter readings

[Kapil]

Hi

I discussed this problem with gordc on the telemetry IRC channel but I am
still facing issues.

I am running the ceilometer-agent-ipmi on the compute nodes, I changed
pipeline.yaml of the compute node to include the ipmi meters and resource
as "ipmi://localhost".

- name: meter_ipmi
  interval: 60
  resources:
  - ipmi://localhost
  meters:
  - "hardware.ipmi.node*"
  - "hardware.ipmi*"
  - "hardware.degree*"
  sinks:
  - meter_sink

I have ipmitool installed on the compute nodes and restarted the ceilometer
services on compute and controller nodes. Yet, I am not receiving any ipmi
meters when I run "ceilometer meter-list". I also tried passing the
hypervisor IP address and the ipmi address I get when I run "ipmitool lan
print" to resources but to no avail.

Please help in this regard.

Thanks
Kapil Agarwal
__
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] [rpm-packaging] RDO Mitaka 3 test day, March 10, 11

[Rich Bowen]

TL;DR:
* Mitaka 3 RDO test day, March 10, 11:
https://www.rdoproject.org/testday/mitaka/milestone3/
* On-site RDO test day in Brno:
https://www.rdoproject.org/testday/mitaka/brno-on-site/
* Demo of deploying RDO with TripleO:
https://www.youtube.com/watch?v=4O8KvC66eeU


Mitaka milestone 3 is coming soon [1] and, as per usual, we're planning
a test day about a week out from that - March 10th and 11th. We've got
the usual page of instructions [2] for testing.

This time, however, we have two bonus events.

First, we're delighted that Eliska Malikova is putting together an
on-site test day at the Red Hat office in Brno, for anyone in that
general area. If you wish to attend, please register [3] so that we know
how much pizza to order. (Attendance is limited to 50, so please
register sooner rather than later.)

Second, as we attempt to get more people testing TripleO, John
Trownbridge (that's Trown on IRC) will be doing a demo of the TripleO
Quickstart he's been working on. This will be conducted as a YouTube
live stream [4] and will also be recorded, and available at that same
location after the fact.

So, please, come help us ensure that Mitaka is the best RDO yet. As
usual, we'll be on #rdo (on Freenode IRC), and on the rdo-list mailing
list, to field any questions. Full details are on the test day website
[5] and, a usual, we can use lots of help making the test case
instructions better, so that more people can participate.

Thanks!

--Rich


[1] http://releases.openstack.org/mitaka/schedule.html
[2] https://www.rdoproject.org/testday/mitaka/milestone3/
[3]
https://www.eventbrite.com/e/rdo-on-site-test-day-brno-tickets-5934822213
[4] https://www.youtube.com/watch?v=4O8KvC66eeU
[5] https://www.rdoproject.org/testday/mitaka/milestone3/


-- 
Rich Bowen - rbo...@redhat.com
OpenStack Community Liaison, Red Hat
http://rdoproject.org/

__
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] Intra-column wrapping in python-neutronclient

[Steve Baker]

On 25/02/16 06:23, Carl Baldwin wrote:

Hi,

I've noticed a new behavior from the python-neutronclient which
disturbs me.  For me, this just started happening with my latest build
of devstack which I built yesterday.  It didn't happen with another
recent but little bit older devstack.

The issue is that the client is now wrapping content within columns.
For example:

   
+-+-+--+
   | id  | name| subnets
   |
   
+-+-+--+
   | eb850219-6a42-42ed-ac6a-| public  |
099745e5-4925-4572-a88f- |
   | 927b03a0dc77| | a5376206c892
172.24.4.0/24   |
   | | | 5b6dfb0d-c97e-48ae-
   |
   | | | 98c9-7fe3e1e8e88b
2001:db8::/64  |
   | ec73110f-   | private | 4073b9e7-a58e-4d6e-
   |
   | 86ad-4292-9547-7c2789a7023b | | a2e4-7a45ae899671
10.0.0.0/24|
   | | |
f12aee80-fc13-4adf-a0eb- |
   | | | 706af4319094
fd9d:e27:3eab::/64  |
   
+-+-+--+

Notice how the ids in the first column are wrapped within the column.
I personally don't see this as an aesthetic improvement.  It destroys
by ability to cut and paste the data within this column.  When I
stretch my console out to fix it, I have to rerun the command with the
new window width to fix it.  I used to be able to stretch my console
horizontally and the wrapped would automatically go away.
My intention was that it be a usability improvement rather than merely 
an aesthetic one. Yes, it is unfortunate that it affects this specific 
copy paste scenario but there are others where it is improved. I've 
often been in the situation where I don't know which uuid to copy 
because of the amount of overlap of unrelated columns.

How can I turned this off now?  Also, can I request that this new
"feature" be disabled by default?

Table resizing only occurs when a tty is present. This means that any 
existing script which parses table output will not be affected. It also 
means that you can disable it by piping your command to cat.


If you're unwilling to adapt, or specify formatting options, or pipe to 
cat, then I would recommend that you submit a change to cliff to read a 
user set environment variable to switch off table resizing.


__
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] [stable] Suggestion to remove stable/liberty and stable branches support from ironic-python-agent

[Alan Pevec]

> The tricky bit is that RDO does not include patches in our packages
> built from trunk (trunk.rdoproject.org), and for liberty we first check
> if stable/liberty exists, then fallback to master if it does not. So the
> presence of stable/liberty that is not actually the recommended way to
> build IPA for liberty is a bit not ideal for us.

Trunk builder will first use branch specified per project per release,
and we can now override that easily in rdoinfo.

> All of that said, I totally understand not wanting to delete a branch.
> Especially since I think I am the one who Dmitry is referring to asking
> for it. (Though I think what I wanted was releases which is subtly
> different)

that goes under "for historical reasons" :)

> I think there are some hacks I could make in our trunk builder if I at
> least have a ML post like this as justification. I am not 100% sure that
> is possible though.

No hacks needed and I've referenced this ML post:
https://github.com/redhat-openstack/rdoinfo/pull/158
Please let me know if that's what you wanted, to avoid further confusion :)

Cheers,
Alan

__
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] containers across availability zones

[Adrian Otto]

Ricardo,

The blueprint is approved, thanks!

Adrian

> On Feb 24, 2016, at 2:53 PM, Ricardo Rocha  wrote:
> 
> Thanks, done.
> 
> https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones
> 
> We might have something already to expose the labels in the docker
> daemon config.
> 
> On Wed, Feb 24, 2016 at 6:01 PM, Vilobh Meshram
>  wrote:
>> +1 from me too for the idea. Please file a blueprint. Seems feasible and
>> useful.
>> 
>> -Vilobh
>> 
>> 
>> On Tue, Feb 23, 2016 at 7:25 PM, Adrian Otto 
>> wrote:
>>> 
>>> Ricardo,
>>> 
>>> Yes, that approach would work. I don’t see any harm in automatically
>>> adding tags to the docker daemon on the bay nodes as part of the swarm heat
>>> template. That would allow the filter selection you described.
>>> 
>>> Adrian
>>> 
 On Feb 23, 2016, at 4:11 PM, Ricardo Rocha 
 wrote:
 
 Hi.
 
 Has anyone looked into having magnum bay nodes deployed in different
 availability zones? The goal would be to have multiple instances of a
 container running on nodes across multiple AZs.
 
 Looking at docker swarm this could be achieved using (for example)
 affinity filters based on labels. Something like:
 
 docker run -it -d -p 80:80 --label nova.availability-zone=my-zone-a
 nginx
 https://docs.docker.com/swarm/scheduler/filter/#use-an-affinity-filter
 
 We can do this if we change the templates/config scripts to add to the
 docker daemon params some labels exposing availability zone or other
 metadata (taken from the nova metadata).
 
 https://docs.docker.com/engine/userguide/labels-custom-metadata/#daemon-labels
 
 It's a bit less clear how we would get heat to launch nodes across
 availability zones using ResourceGroup(s), but there are other heat
 resources that support it (i'm sure this can be done).
 
 Does this make sense? Any thoughts or alternatives?
 
 If it makes sense i'm happy to submit a blueprint.
 
 Cheers,
 Ricardo
 
 
 __
 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 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] containers across availability zones

[Ricardo Rocha]

Thanks, done.

https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones

We might have something already to expose the labels in the docker
daemon config.

On Wed, Feb 24, 2016 at 6:01 PM, Vilobh Meshram
 wrote:
> +1 from me too for the idea. Please file a blueprint. Seems feasible and
> useful.
>
> -Vilobh
>
>
> On Tue, Feb 23, 2016 at 7:25 PM, Adrian Otto 
> wrote:
>>
>> Ricardo,
>>
>> Yes, that approach would work. I don’t see any harm in automatically
>> adding tags to the docker daemon on the bay nodes as part of the swarm heat
>> template. That would allow the filter selection you described.
>>
>> Adrian
>>
>> > On Feb 23, 2016, at 4:11 PM, Ricardo Rocha 
>> > wrote:
>> >
>> > Hi.
>> >
>> > Has anyone looked into having magnum bay nodes deployed in different
>> > availability zones? The goal would be to have multiple instances of a
>> > container running on nodes across multiple AZs.
>> >
>> > Looking at docker swarm this could be achieved using (for example)
>> > affinity filters based on labels. Something like:
>> >
>> > docker run -it -d -p 80:80 --label nova.availability-zone=my-zone-a
>> > nginx
>> > https://docs.docker.com/swarm/scheduler/filter/#use-an-affinity-filter
>> >
>> > We can do this if we change the templates/config scripts to add to the
>> > docker daemon params some labels exposing availability zone or other
>> > metadata (taken from the nova metadata).
>> >
>> > https://docs.docker.com/engine/userguide/labels-custom-metadata/#daemon-labels
>> >
>> > It's a bit less clear how we would get heat to launch nodes across
>> > availability zones using ResourceGroup(s), but there are other heat
>> > resources that support it (i'm sure this can be done).
>> >
>> > Does this make sense? Any thoughts or alternatives?
>> >
>> > If it makes sense i'm happy to submit a blueprint.
>> >
>> > Cheers,
>> >  Ricardo
>> >
>> >
>> > __
>> > 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] solving API case sensitivity issues

[Sean Dague]

On 02/24/2016 03:13 PM, Mooney, Sean K wrote:
> 
> 
>> -Original Message-
>> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
>> Sent: Wednesday, February 24, 2016 5:46 PM
>> To: Sean Dague ; openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [nova] solving API case sensitivity issues
>>
>> On Wed, 2016-02-24 at 11:40 -0500, Sean Dague wrote:
>>> On 02/24/2016 11:28 AM, James Bottomley wrote:
 On Wed, 2016-02-24 at 07:48 -0500, Sean Dague wrote:
> We have a specific bug around aggregrate metadata setting in Nova
> which exposes a larger issue with our mysql schema.
> https://bugs.launchpad.net/nova/+bug/1538011
>
> On mysql the following will explode with a 500:
>
>> nova aggregate-create agg1
>> nova aggregate-set-metadata agg1 abc=1 nova
>> aggregate-set-metadata agg1 ABC=2
>
> mysql (by default) treats abc == ABC. However the python code does
> not.
> Personally I would argue that the python code is correct
> and they should not be considered the same. ABC and abc are two different keys
> in the aggregate metadata and I do not think it is correct to treat them the 
> same.
> Assuming the above commands I would expect the metadata to contain  two key 
> pairs [abc=1,ABC=2]
> 
>
> We have a couple of options:
>
> 1) make the API explicitly case fold
>
> 2) update the mysql DB to use latin_bin collation for these
> columns
> This should not be latin_bin as Unicode is allowed in URLs this should really 
> be utf8_bin

There are no urls stored here. This is content coming through the body.
While I do appreciate many folks weighing in that haven't read the bug
yet, I would be even better if people did read the bug first.

We have the ability to decide at the API level what the behavior is of
payloads in POST / GET. Given the majority of our users are on mysql,
they've never had access to case sensitive overlapping metadata on
aggregates before. Doing so seems odd and potentially confusing.

-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

Re: [openstack-dev] [nova] solving API case sensitivity issues

[Mooney, Sean K]

> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Wednesday, February 24, 2016 5:46 PM
> To: Sean Dague ; openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] solving API case sensitivity issues
> 
> On Wed, 2016-02-24 at 11:40 -0500, Sean Dague wrote:
> > On 02/24/2016 11:28 AM, James Bottomley wrote:
> > > On Wed, 2016-02-24 at 07:48 -0500, Sean Dague wrote:
> > > > We have a specific bug around aggregrate metadata setting in Nova
> > > > which exposes a larger issue with our mysql schema.
> > > > https://bugs.launchpad.net/nova/+bug/1538011
> > > >
> > > > On mysql the following will explode with a 500:
> > > >
> > > > > nova aggregate-create agg1
> > > > > nova aggregate-set-metadata agg1 abc=1 nova
> > > > > aggregate-set-metadata agg1 ABC=2
> > > >
> > > > mysql (by default) treats abc == ABC. However the python code does
> > > > not.
Personally I would argue that the python code is correct
and they should not be considered the same. ABC and abc are two different keys
in the aggregate metadata and I do not think it is correct to treat them the 
same.
Assuming the above commands I would expect the metadata to contain  two key 
pairs [abc=1,ABC=2]

> > > >
> > > > We have a couple of options:
> > > >
> > > > 1) make the API explicitly case fold
> > > >
> > > > 2) update the mysql DB to use latin_bin collation for these
> > > > columns
This should not be latin_bin as Unicode is allowed in URLs this should really 
be utf8_bin
> > > >
> > > > 3) make this a 400 error because duplicates were found
> > > >
> > > >
> > > > Options 1 & 2 make all OpenStack environments consistent
> > > > regardless of backend.
> > > >
> > > > Option 2 is potentially expensive TABLE alter.
> > > >
> > > > Option 3 gets rid of the 500 error, however at the risk that the
> > > > behavior for this API is different depending on DB backend. Which
> > > > is less than ideal.
> > > >
> > > >
> > > > My preference is slightly towards #1. It's taken a long time for
> > > > someone to report this issue, so I think it's an edge case, and
> > > > people weren't think about this being case sensitive. It has the
> > > > risk of impacting someone on an odd db platform that has been
> > > > using that feature.
> > > >
> > > > There are going to be a few other APIs to clean up in a similar
> > > > way.
> > > > I don't think this comes in under a microversion because of how
> > > > deep in the db api layer this is, and it's just not viable to keep
> > > > both paths.
> > >
> > > This is actually one of the curses wished on us by REST.  Since the
> > > intent is to use web requests for the API, the API name must follow
> > > the case sensitivity rules for URL matching (case insensitive).
> >
> > Um... since when are URLs generically case insensitive? The host
> > portion is - https://tools.ietf.org/html/r
> > https://tools.ietf.org/html/rfc3986#section-3.2.2c3986#section-3.2.2
> > and the scheme
> > portion is - https://tools.ietf.org/html/rfc3986#section-3.1 however
> > nothing about the PATH specifies that it should or must be (in section
> > 3.3)
I would agree with this we should not assume that URLs are case sensitive nor 
should
We assume they are ascii. I would be in favor of option 2 with utf8_bin as this 
support
Both Unicode and case sensitivity.
> 
> Heh, OK, I'm out of date.  When we first argued over this, Microsoft
> required case insensitive matching for the path component because IIS
> was doing lookups on vfat filesystems which are naturally case
> insensitive.  If that's been excised from the standard, I'm happy to
> keep it in the dustbin of history.
> 
> > While it's a little off topic, this is the 2nd time in a month it came
> > up, so I'd like to know if there is a reference for the case
> > insensitive pov.
> 
> I checked; it looks to be implementation specific.  So php, for
> instance, does case sensitive
> 
> /index.php != /Index.php
> 
> But drupal does case insensitive
> 
> /node/6 == /Node/6 == /NoDe/6
> 
> So all in all, a bit of a mess.
> 
> 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

__
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] Intra-column wrapping in python-neutronclient

[Kevin Benton]

Right, but it breaks for humans too because it interferes with copy-paste.
:)

On Wed, Feb 24, 2016 at 9:46 AM, Akihiro Motoki  wrote:

> cliff-based client including neutronclient and openstackclient
> supports various formatters.
> I don't think it is a good idea to depend on the output of 'table'
> formatter.
> My understanding is 'table' formatter (the default formatter) is for
> human readability.
> IMHO it is better to use json formatter or value formatter if we need
> to pick up a returned value.
> You can use '-f json' or '-f value -c id' with -create.
>
> This is the reason I proposed fixes around non-table formatters like
> https://review.openstack.org/#/c/255696/ or
> https://review.openstack.org/#/c/284088/.
>
> Anyway, it is bad to break devstack :(
>
> 2016-02-25 2:32 GMT+09:00 Carl Baldwin :
> > I ran this by our all-knowing PTL who told me to go back to
> > cliff==1.15.0.  My devstack had picked up cliff==2.0.0 which is what
> > seems to have introduced this behavior.  Reverting to the older
> > version fixed this quirky behavior.
> >
> > Before today, I didn't even know what cliff was.  :)
> >
> > Carl
> >
> > On Wed, Feb 24, 2016 at 10:23 AM, Carl Baldwin 
> wrote:
> >> Hi,
> >>
> >> I've noticed a new behavior from the python-neutronclient which
> >> disturbs me.  For me, this just started happening with my latest build
> >> of devstack which I built yesterday.  It didn't happen with another
> >> recent but little bit older devstack.
> >>
> >> The issue is that the client is now wrapping content within columns.
> >> For example:
> >>
> >>
>  
> +-+-+--+
> >>   | id  | name| subnets
> >>   |
> >>
>  
> +-+-+--+
> >>   | eb850219-6a42-42ed-ac6a-| public  |
> >> 099745e5-4925-4572-a88f- |
> >>   | 927b03a0dc77| | a5376206c892
> >> 172.24.4.0/24   |
> >>   | | | 5b6dfb0d-c97e-48ae-
> >>   |
> >>   | | | 98c9-7fe3e1e8e88b
> >> 2001:db8::/64  |
> >>   | ec73110f-   | private | 4073b9e7-a58e-4d6e-
> >>   |
> >>   | 86ad-4292-9547-7c2789a7023b | | a2e4-7a45ae899671
> >> 10.0.0.0/24|
> >>   | | |
> >> f12aee80-fc13-4adf-a0eb- |
> >>   | | | 706af4319094
> >> fd9d:e27:3eab::/64  |
> >>
>  
> +-+-+--+
> >>
> >> Notice how the ids in the first column are wrapped within the column.
> >> I personally don't see this as an aesthetic improvement.  It destroys
> >> by ability to cut and paste the data within this column.  When I
> >> stretch my console out to fix it, I have to rerun the command with the
> >> new window width to fix it.  I used to be able to stretch my console
> >> horizontally and the wrapped would automatically go away.
> >>
> >> How can I turned this off now?  Also, can I request that this new
> >> "feature" be disabled by default?
> >>
> >> Carl
> >
> >
> __
> > 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] OpenStack UX Core nomination

[Kruithof Jr, Pieter]

I would like to nominate Dan Kingshott as a core for the OpenStack UX project.

His contributions haven’t always been visible to the overall community, but Dan 
has been very active in reviewing mocks, providing context based on his 
experience as an operator and helping to recruit participants for user research 
efforts for over a year.

This is based on the goal of the OpenStack UX to formalize contributions from 
operators, architects, service admins, etc. to the community.

Piet
PTL, OpenStack UX project

__
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] [dragonflow]Part of the OpenStack Big-tent

[Eran Gampel]

Hi all,
Dragonflow was officially accepted yesterday as a big-tent project.

Dragonflow is a distributed SDN controller for OpenStack® supporting
distributed- Switching, Routing, DHCP and more.

Dragonflow was designed to support containers networking and large scale
production loads.

Our main Roadmap for Mitka are:

Security Groups , Selective DB distribution, Pluggable Pub/Sub Mechanism,
distributed DNAT, DB and local controller cache consistency assurance.

We are trying to tackle common challenges for distributed systems at scale
and focus on reliability, We welcome new contributors who wish to join our
effort.

We are holding a weekly IRC meeting [1], and everyone is welcome.

[1] https://wiki.openstack.org/wiki/Meetings/Dragonflow

[2]https://wiki.openstack.org/wiki/Dragonflow

[3]http://www.slideshare.net/gampel/dragonflow-01-2016-tlv-m

__
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][cinder] os-brick 1.1.0 release (mitaka)

[no-reply]

We are jubilant to announce the release of:

os-brick 1.1.0: OpenStack Cinder brick library for managing local
volume attaches

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/os-brick

With package available at:

https://pypi.python.org/pypi/os-brick

Please report issues through launchpad:

http://bugs.launchpad.net/os-brick

For more details, please see below.

Changes in os-brick 1.0.0..1.1.0


c84dfef Fix setting the multipath_id
2d60736 Updated from global requirements
0d25bbb Include multipath -ll output in failed to parse warning

Diffstat (except docs and test files)
-

os_brick/initiator/connector.py|  7 +++
requirements.txt   |  4 ++--
3 files changed, 38 insertions(+), 6 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index de2c245..81b35a4 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ Babel>=1.3 # BSD
-eventlet>=0.18.2 # MIT
+eventlet!=0.18.3,>=0.18.2 # MIT
@@ -13 +13 @@ oslo.service>=1.0.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

Re: [openstack-dev] [puppet] Austin Design Summit space needs

[Matt Fischer]

On Wed, Feb 24, 2016 at 8:30 AM, Emilien Macchi  wrote:

> Puppet OpenStack folks,
>
> As usual, Thierry Carrez sent an e-mail to PTLs about space needs for
> the next OpenStack Summit in Austin.
>
>
> We can have 3 kinds of slots:
>
> * Fishbowl slots (Wed-Thu) - we had 2 in Tokyo.
> Our traditional largish rooms organized in fishbowl style, with
> advertised session content on the summit schedule for increased external
> participation. Ideal for when wider feedback is essential.
>
> * Workroom slots (Tue-Thu) - we had 3 in Tokyo.
> Smaller rooms organized in boardroom style, with topic buried in the
> session description, in an effort to limit attendance and not overcrowd
> the room. Ideal to get work done and prioritize work in small teams.
>
> * Contributors meetup (Fri) - we had 0 in Tokyo.
> Half-day session(s) on the Friday to get into the Newton action while
> decisions and plans are still hot, or to finish discussions started
> during the week, whatever works for you.
>
>
> I suggest we keep the same model as Tokyo, I think it worked pretty well
> for us.
> Though I'm wondering if we should also ask for a contributors meetup?
> Do we really need that?
>
>
> Any feedback from developers and operators are highly welcome.
>


I think what we had in Tokyo worked pretty well for the workroom's I
attended. I don't recall however if we did a general feedback issues
session in a larger room? Chris or Colleen used to lead these back in
ATL/Paris days. With some of the questions on the ML recently seems like it
would be interesting to find out what issues people are having outside of
the usual operators. Perhaps that's one of the fishbowls?
__
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] [app-catalog] IRC Meeting Thursday February 25th at 17:00UTC

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for February 25th
at 17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

One topic we'll cover will be space needs at the Austin summit.  In
Tokyo we had one fishbowl session and one workroom slot.  Will we need
more than that in Austin?  If you've got any opinions on that, please
either respond on the mailing list here or join us on IRC tomorrow!

-Christopher

__
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][VPNaaS] Question regarding creating an IPSec Connection Site with multiple subnets attached to a router on each site in stable/kilo

[Chirag Shahani]

Hi All,

I am using https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall to
install VPNaaS with single devstack and two routers.


stack@whiskey:/opt/stack$ neutron router-list
+--+--+---+-+---+
| id   | name | external_gateway_info

  | distributed | ha|
+--+--+---+-+---+
| 6e730589-113e-4105-af61-3945bc5c9413 | r1   | {"network_id":
"dfcb5c47-712c-4c6e-b98e-53ea9688d7d5", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "fcb87cfa-734b-  | False   |
False |
|  |  | 47d0-83b2-523ecbd2fa5c",
"ip_address": "5.5.5.3"}]}
  | |   |
| eaeae30a-e281-42a7-9c38-1f678ec1ccbf | r2   | {"network_id":
"dfcb5c47-712c-4c6e-b98e-53ea9688d7d5", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "fcb87cfa-734b-  | False   |
False |
|  |  | 47d0-83b2-523ecbd2fa5c",
"ip_address": "5.5.5.4"}]}
  | |   |
+--+--+---+-+---+

stack@whiskey:/opt/stack$ neutron vpn-service-list
+--++--++
| id   | name   | router_id
   | status |
+--++--++
| 59adbee1-7cc7-415e-8273-d4c2491ab878 | myvpn  |
6e730589-113e-4105-af61-3945bc5c9413 | ACTIVE |
| c453caf5-839a-4687-b44a-148014671fce | myvpn2 |
eaeae30a-e281-42a7-9c38-1f678ec1ccbf | ACTIVE |
+--++--++



(neutron) stack@whiskey:/opt/stack$ neutron ipsec-site-connection-list
+--++--+---++
| id   | name   | peer_address |
auth_mode | status |
+--++--+---++
| 0f5db508-5248-48e4-a76e-f4ef17d8f975 | vpnconnection1 | 5.5.5.4  |
psk   | ACTIVE |
| 5db83673-4e3c-41ef-8697-dd6a33e57576 | vpnconnection2 | 5.5.5.3  |
psk   | ACTIVE |
+--++--+---++
stack@whiskey:/opt/stack$

stack@whiskey:/opt/stack$ nova list
+--+--+++-++
| ID   | Name | Status | Task State | Power
State | Networks   |
+--+--+++-++
| c390da65-9a5c-40d3-aa55-6627f66afabb | vm1  | ACTIVE | -  |
Running | n1=1.1.1.3 |
| 2186a7dd-b5c9-464e-bc10-bd8a92890509 | vm2  | ACTIVE | -  |
Running | n2=2.2.2.3 |
+--+--+++-++


>From the above three commands, I could get the topology mentioned in the
install guide to work perfectly and could ping the vm's on the two routers
from each other.


Now, I added 2 more subnets to each router on either side and spun 2 vms's
(vm3 and vm4) on subnets s3 and s4 attached to routers r1 and r2
respectively.


Now create a vpn service myvpn3 with r1 and s3 & myvpn4  with r2 and s4.

stack@whiskey:/opt/stack$ neutron vpn-service-list
+--++--++
| id   | name   | router_id
   | status |
+--++--++
| 05bdaa03-374d-4df6-af67-96ad209b8126 | myvpn4 |
eaeae30a-e281-42a7-9c38-1f678ec1ccbf | PENDING_CREATE |
| 4fd6fc1f-9f5e-4980-a28c-520a1c3a8e8a | myvpn3 |
6e730589-113e-4105-af61-3945bc5c9413 | PENDING_CREATE |
| 59adbee1-7cc7-415e-8273-d4c2491ab878 | myvpn  |
6e730589-113e-4105-af61-3945bc5c9413 | ACTIVE |
| c453caf5-839a-4687-b44a-148014671fce | myvpn2 |
eaeae30a-e281-42a7-9c38-1f678ec1ccbf | ACTIVE |
+--++--++


Now create a ipsec-site-conneciton.

stack@whiskey:/opt/stack$ neutron ipsec-site-connection-create --name
vpnconnection3 --vpnservice-id myvpn3 

Re: [openstack-dev] [heat]How to manage the life cycle of resources in a stack?

[Steve Baker]

On 25/02/16 05:27, zhu4236926 wrote:

Hi guys,
I  get some resources by creating a stack, e.g. ,the resources may 
be 2 volumes, volume A and volume B.  If the volume A and volume B are 
useless, we can delete them by deleting the stack , we also can delete 
them by cinder.If  they are deleted by cinder, though the volumes have 
been delete, the resources and stack are still exist,  a tenant has 
the maxmum quantity of stacks, so I may couldn't  create the stack if 
the number of left stacks exceed the limit . If I delete by deleting 
the stack, the volume A and volume B would be deleted both, may be I 
just want to delete the volume A and reservce volume B.
So how should I manage the resources(volumeA and volumeB) created 
by heat, deleted by cinder or heat?


The best approach would be to modify the template to remove the volumes 
that you no longer need then do a stack-update. Once the stack ends up 
being empty you can choose to delete it.
__
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] Outreachy May-Aug 2016: Call for funding and mentors

[Victoria Martínez de la Cruz]

Hi everyone,

Quick update on the Outreachy  program,
including a request for funding and volunteer mentors. For those of you who
are not aware, Outreachy helps people from groups underrepresented in free
and open source software get involved by matching interns with established
mentors in the upstream community.

OpenStack haven't confirmed the participation to this Outreachy round yet,
but despite of that we are receiving applicants interested in contribute to
different projects. We have already 10 volunteer mentors for OpenStack this
next cycle, which will take place May 23 - August 23, 2016. OpenStack could
use a few more volunteer mentors for any project. You can learn more about
what is expected from mentors and how to apply here:
https://wiki.openstack.org/wiki/Outreachy/Mentors

We have some potential sponsors, but we could use some additional sponsors
to help support the large increase in OpenStack applicants. The sponsorship
cost is 6,500 USD per intern, which provide them a stipend for the
three-month program. You can learn more about sponsorship here:
https://wiki.gnome.org/Outreachy/Admin/InfoForOrgs#Action

I personally believe Outreachy is one of the most important and effective
diversity efforts we’ve invested in to date. We’ve had some amazing
graduates become long-term contributors to our community.

Please help spread the word. If you are interested in becoming a mentor or
sponsoring an intern, please contact me (victoria AT redhat.com) or
Mahati (mahati.chamarthy
AT gmail.com).

Thanks,

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] [glance] Austin Design Summit space needs

[Nikhil Komawar]

Here are a few ideas that I've in mind (more than 6 for now) for the
workroom sessions (of course that can be prioritized):

1. Import refactor
2. Glare
3. Quotas
4. State of Image sharing, community images, Hierarchical Images etc.
5. glance_store improvements, general gate jobs discussions, releases
discussions, logging, notification etc.
6. First hand & closed loop dedicated operator, superuser, general user,
experience, etc. feedback
7. Feedback into the team from other projects, cross projects, general
workflow, etc. changes
8. Priorities discussions

I think we can utilize the contributors meetup for some of them but all
of them potentially involve folks who may not necessarily be first level
contributors to Glance or at all (in case they want to attend other
meetup). Also, asking for 8 (or more than 6) would be ill effect against
being good openstack citizens.

On 2/24/16 12:25 PM, Flavio Percoco wrote:
>
>
> On Wed, Feb 24, 2016 at 12:27 PM, Nikhil Komawar
> > wrote:
>
> Can we make it ? :
>
> FB 3
> W 6
> C 2
>
>
>
> Could you elaborate on why you think we need 6 workroom sessions?
>
> Back in Tokyo, 5 seemed more than enough and there will be more
> projects to host in Austin.
>
> Cheers,
> Flavio
>  
>
>
> On 2/24/16 10:42 AM, Flavio Percoco wrote:
>> Hey Folks,
>>
>> It's that time of the year. We need to choose what our needs with
>> regards to slots and sessions are for the next summit.
>>
>> We can choose among 3 different types of sessions:
>>
>> * Fishbowl slots (Wed-Thu)
>> Our traditional largish rooms organized in fishbowl style, with
>> advertised session content on the summit schedule for increased
>> external
>> participation. Ideal for when wider feedback is essential.
>>
>> * Workroom slots (Tue-Thu)
>> Smaller rooms organized in boardroom style, with topic buried in the
>> session description, in an effort to limit attendance and not
>> overcrowd
>> the room. Ideal to get work done and prioritize work in small teams.
>>
>> * Contributors meetup (Fri)
>> Half-day session(s) on the Friday to get into the Newton action while
>> decisions and plans are still hot, or to finish discussions started
>> during the week, whatever works for you.
>>
>> Our usage in Tokyo was: 3, 5, 2
>>
>> I'd recommend we keep it that way. Thoughts? 
>> Cheers,
>> Flavio
>>
>> -- 
>> @flaper87
>> Flavio Percoco
>>
>>
>>
>> 
>> __
>> 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,
> Nikhil
>
>
>
>
> -- 
> @flaper87
> Flavio Percoco
>

-- 

Thanks,
Nikhil

__
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] will we use os-vif in kuryr

[Mohammad Banikazemi]

Yes, we have been aware of the os-vif effort and will try to use it as soon
as it is released. The scripts we currently use are to enable the use of
the Neutron reference plugins/drivers in the meantime.

Best,

Mohammad




From:   "Daniel P. Berrange" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   02/18/2016 05:36 AM
Subject:Re: [openstack-dev] [Kuryr] will we use os-vif in kuryr



On Thu, Feb 18, 2016 at 09:01:35AM +, Liping Mao (limao) wrote:
> Hi Kuryr team,
>
> I see couple of commits to add support for vif plug.
> https://review.openstack.org/#/c/280411/
> https://review.openstack.org/#/c/280878/
>
> Do we have plan to use os-vif?
> https://github.com/openstack/os-vif

FYI, we're trying reasonably hard to *not* make any assumptions about
what compute or network services are using os-vif. ie, we want os-vif
as a framework to be usable from Nova, or any other compute manager,
and likewise be usable from Neutron or any other network manager.
Obviously the actual implementations may be different, but the general
os-vif framework tries to be agnostic.

Regards,
Daniel
--
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
:|
|: http://libvirt.org  -o- http://virt-manager.org
:|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/
:|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
:|

__
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] Intra-column wrapping in python-neutronclient

[Rick Jones]

On 02/24/2016 09:46 AM, Akihiro Motoki wrote:

cliff-based client including neutronclient and openstackclient
supports various formatters.
I don't think it is a good idea to depend on the output of 'table' formatter.
My understanding is 'table' formatter (the default formatter) is for
human readability.
IMHO it is better to use json formatter or value formatter if we need
to pick up a returned value.
You can use '-f json' or '-f value -c id' with -create.


Be that as it may, it is equally bad if not worse to gratuitously (IMO) 
change output formats.  Even if it is meant to be "only" human-readable.


And it is arguably the case that this new format is less human-readable 
than what was before, even discounting the loss of straight-forward 
cut-and-paste.  And I would not discount the importance of 
straight-forward cut-and-paste.


rick jones



This is the reason I proposed fixes around non-table formatters like
https://review.openstack.org/#/c/255696/ or
https://review.openstack.org/#/c/284088/.

Anyway, it is bad to break devstack :(

2016-02-25 2:32 GMT+09:00 Carl Baldwin :

I ran this by our all-knowing PTL who told me to go back to
cliff==1.15.0.  My devstack had picked up cliff==2.0.0 which is what
seems to have introduced this behavior.  Reverting to the older
version fixed this quirky behavior.

Before today, I didn't even know what cliff was.  :)

Carl

On Wed, Feb 24, 2016 at 10:23 AM, Carl Baldwin  wrote:

Hi,

I've noticed a new behavior from the python-neutronclient which
disturbs me.  For me, this just started happening with my latest build
of devstack which I built yesterday.  It didn't happen with another
recent but little bit older devstack.

The issue is that the client is now wrapping content within columns.
For example:

   
+-+-+--+
   | id  | name| subnets
   |
   
+-+-+--+
   | eb850219-6a42-42ed-ac6a-| public  |
099745e5-4925-4572-a88f- |
   | 927b03a0dc77| | a5376206c892
172.24.4.0/24   |
   | | | 5b6dfb0d-c97e-48ae-
   |
   | | | 98c9-7fe3e1e8e88b
2001:db8::/64  |
   | ec73110f-   | private | 4073b9e7-a58e-4d6e-
   |
   | 86ad-4292-9547-7c2789a7023b | | a2e4-7a45ae899671
10.0.0.0/24|
   | | |
f12aee80-fc13-4adf-a0eb- |
   | | | 706af4319094
fd9d:e27:3eab::/64  |
   
+-+-+--+

Notice how the ids in the first column are wrapped within the column.
I personally don't see this as an aesthetic improvement.  It destroys
by ability to cut and paste the data within this column.  When I
stretch my console out to fix it, I have to rerun the command with the
new window width to fix it.  I used to be able to stretch my console
horizontally and the wrapped would automatically go away.

How can I turned this off now?  Also, can I request that this new
"feature" be disabled by default?

Carl


__
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] solving API case sensitivity issues

[James Bottomley]

On Wed, 2016-02-24 at 11:40 -0500, Sean Dague wrote:
> On 02/24/2016 11:28 AM, James Bottomley wrote:
> > On Wed, 2016-02-24 at 07:48 -0500, Sean Dague wrote:
> > > We have a specific bug around aggregrate metadata setting in Nova
> > > which
> > > exposes a larger issue with our mysql schema.
> > > https://bugs.launchpad.net/nova/+bug/1538011
> > > 
> > > On mysql the following will explode with a 500:
> > > 
> > > > nova aggregate-create agg1
> > > > nova aggregate-set-metadata agg1 abc=1
> > > > nova aggregate-set-metadata agg1 ABC=2
> > > 
> > > mysql (by default) treats abc == ABC. However the python code
> > > does
> > > not.
> > > 
> > > We have a couple of options:
> > > 
> > > 1) make the API explicitly case fold
> > > 
> > > 2) update the mysql DB to use latin_bin collation for these
> > > columns
> > > 
> > > 3) make this a 400 error because duplicates were found
> > > 
> > > 
> > > Options 1 & 2 make all OpenStack environments consistent
> > > regardless
> > > of
> > > backend.
> > > 
> > > Option 2 is potentially expensive TABLE alter.
> > > 
> > > Option 3 gets rid of the 500 error, however at the risk that the
> > > behavior for this API is different depending on DB backend. Which
> > > is
> > > less than ideal.
> > > 
> > > 
> > > My preference is slightly towards #1. It's taken a long time for 
> > > someone to report this issue, so I think it's an edge case, and 
> > > people weren't think about this being case sensitive. It has the
> > > risk 
> > > of impacting someone on an odd db platform that has been using
> > > that
> > > feature.
> > > 
> > > There are going to be a few other APIs to clean up in a similar
> > > way. 
> > > I don't think this comes in under a microversion because of how
> > > deep 
> > > in the db api layer this is, and it's just not viable to keep
> > > both
> > > paths.
> > 
> > This is actually one of the curses wished on us by REST.  Since the
> > intent is to use web requests for the API, the API name must follow
> > the
> > case sensitivity rules for URL matching (case insensitive). 
> 
> Um... since when are URLs generically case insensitive? The host
> portion
> is - https://tools.ietf.org/html/r
> https://tools.ietf.org/html/rfc3986#section-3.2.2c3986#section-3.2.2 
> and the scheme
> portion is - https://tools.ietf.org/html/rfc3986#section-3.1 however
> nothing about the PATH specifies that it should or must be (in
> section 3.3)

Heh, OK, I'm out of date.  When we first argued over this, Microsoft
required case insensitive matching for the path component because IIS
was doing lookups on vfat filesystems which are naturally case
insensitive.  If that's been excised from the standard, I'm happy to
keep it in the dustbin of history.

> While it's a little off topic, this is the 2nd time in a month it 
> came up, so I'd like to know if there is a reference for the case
> insensitive pov.

I checked; it looks to be implementation specific.  So php, for
instance, does case sensitive

/index.php != /Index.php

But drupal does case insensitive

/node/6 == /Node/6 == /NoDe/6

So all in all, a bit of a mess.

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

Re: [openstack-dev] [Neutron] Intra-column wrapping in python-neutronclient

[Akihiro Motoki]

cliff-based client including neutronclient and openstackclient
supports various formatters.
I don't think it is a good idea to depend on the output of 'table' formatter.
My understanding is 'table' formatter (the default formatter) is for
human readability.
IMHO it is better to use json formatter or value formatter if we need
to pick up a returned value.
You can use '-f json' or '-f value -c id' with -create.

This is the reason I proposed fixes around non-table formatters like
https://review.openstack.org/#/c/255696/ or
https://review.openstack.org/#/c/284088/.

Anyway, it is bad to break devstack :(

2016-02-25 2:32 GMT+09:00 Carl Baldwin :
> I ran this by our all-knowing PTL who told me to go back to
> cliff==1.15.0.  My devstack had picked up cliff==2.0.0 which is what
> seems to have introduced this behavior.  Reverting to the older
> version fixed this quirky behavior.
>
> Before today, I didn't even know what cliff was.  :)
>
> Carl
>
> On Wed, Feb 24, 2016 at 10:23 AM, Carl Baldwin  wrote:
>> Hi,
>>
>> I've noticed a new behavior from the python-neutronclient which
>> disturbs me.  For me, this just started happening with my latest build
>> of devstack which I built yesterday.  It didn't happen with another
>> recent but little bit older devstack.
>>
>> The issue is that the client is now wrapping content within columns.
>> For example:
>>
>>   
>> +-+-+--+
>>   | id  | name| subnets
>>   |
>>   
>> +-+-+--+
>>   | eb850219-6a42-42ed-ac6a-| public  |
>> 099745e5-4925-4572-a88f- |
>>   | 927b03a0dc77| | a5376206c892
>> 172.24.4.0/24   |
>>   | | | 5b6dfb0d-c97e-48ae-
>>   |
>>   | | | 98c9-7fe3e1e8e88b
>> 2001:db8::/64  |
>>   | ec73110f-   | private | 4073b9e7-a58e-4d6e-
>>   |
>>   | 86ad-4292-9547-7c2789a7023b | | a2e4-7a45ae899671
>> 10.0.0.0/24|
>>   | | |
>> f12aee80-fc13-4adf-a0eb- |
>>   | | | 706af4319094
>> fd9d:e27:3eab::/64  |
>>   
>> +-+-+--+
>>
>> Notice how the ids in the first column are wrapped within the column.
>> I personally don't see this as an aesthetic improvement.  It destroys
>> by ability to cut and paste the data within this column.  When I
>> stretch my console out to fix it, I have to rerun the command with the
>> new window width to fix it.  I used to be able to stretch my console
>> horizontally and the wrapped would automatically go away.
>>
>> How can I turned this off now?  Also, can I request that this new
>> "feature" be disabled by default?
>>
>> Carl
>
> __
> 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] [kolla][infra] Publishing kolla images to docker-registry.openstack.org

[Jeremy Stanley]

On 2016-02-24 15:47:12 + (+), Steven Dake (stdake) wrote:
[...]
> Where we are stumped is should we push to registry.openstack.org
> which I would prefer, or push to the docker registry.

If we use a Jenkins publisher the files get pulled from the slave
where they were generated to the Jenkins master server and then
copied from there to the archive location. This might present some
significant disk utilization issues on our Jenkins masters given the
file sizes you've quoted, so I wouldn't recommend that as a
solution.

Another possible publication model is what we did with log uploads
to Swift containers, where the Jenkins slave is given temporary
constrained write credentials assigned by Zuul and directly uploads
the files to the container, though index generation becomes a
challenge if you need any sort of hierarchical organization (it's
not like a POSIX filesystem so emulating Apache autoindex is
challenging).

Another major challenge for either of these is bandwidth. It's
entirely possible your images are built on slaves in France and then
shipped across the Atlantic to Dallas for archiving. I would not
expect this to be a fast operation.

> Another issue is getting the authentication credentials in the
> gate securely - somehow it needs to be injected into our post jobs
> without us having to check our credentials into the repository.

If uploading to a third party service, the way we do that is to
upload the files from the single-use slave first to a location under
our control (by way of one of the mechanisms described above), and
then run another job dependent on a trusted long-lived slave to
retrieve the file and upload it to the final destination using
preinstalled credentials for that remote service.

The storage and bandwidth needs for this use case make me suspect
our CI system is a poor place to attempt to implement such a
solution, but hopefully others have ideas which simply aren't
occurring to me.
-- 
Jeremy Stanley

__
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] Intra-column wrapping in python-neutronclient

[Carl Baldwin]

I ran this by our all-knowing PTL who told me to go back to
cliff==1.15.0.  My devstack had picked up cliff==2.0.0 which is what
seems to have introduced this behavior.  Reverting to the older
version fixed this quirky behavior.

Before today, I didn't even know what cliff was.  :)

Carl

On Wed, Feb 24, 2016 at 10:23 AM, Carl Baldwin  wrote:
> Hi,
>
> I've noticed a new behavior from the python-neutronclient which
> disturbs me.  For me, this just started happening with my latest build
> of devstack which I built yesterday.  It didn't happen with another
> recent but little bit older devstack.
>
> The issue is that the client is now wrapping content within columns.
> For example:
>
>   
> +-+-+--+
>   | id  | name| subnets
>   |
>   
> +-+-+--+
>   | eb850219-6a42-42ed-ac6a-| public  |
> 099745e5-4925-4572-a88f- |
>   | 927b03a0dc77| | a5376206c892
> 172.24.4.0/24   |
>   | | | 5b6dfb0d-c97e-48ae-
>   |
>   | | | 98c9-7fe3e1e8e88b
> 2001:db8::/64  |
>   | ec73110f-   | private | 4073b9e7-a58e-4d6e-
>   |
>   | 86ad-4292-9547-7c2789a7023b | | a2e4-7a45ae899671
> 10.0.0.0/24|
>   | | |
> f12aee80-fc13-4adf-a0eb- |
>   | | | 706af4319094
> fd9d:e27:3eab::/64  |
>   
> +-+-+--+
>
> Notice how the ids in the first column are wrapped within the column.
> I personally don't see this as an aesthetic improvement.  It destroys
> by ability to cut and paste the data within this column.  When I
> stretch my console out to fix it, I have to rerun the command with the
> new window width to fix it.  I used to be able to stretch my console
> horizontally and the wrapped would automatically go away.
>
> How can I turned this off now?  Also, can I request that this new
> "feature" be disabled by default?
>
> Carl

__
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] [glance] Austin Design Summit space needs

[Flavio Percoco]

On Wed, Feb 24, 2016 at 12:27 PM, Nikhil Komawar 
wrote:

> Can we make it ? :
>
> FB 3
> W 6
> C 2
>
>

Could you elaborate on why you think we need 6 workroom sessions?

Back in Tokyo, 5 seemed more than enough and there will be more projects to
host in Austin.

Cheers,
Flavio


>
> On 2/24/16 10:42 AM, Flavio Percoco wrote:
>
> Hey Folks,
>
> It's that time of the year. We need to choose what our needs with regards
> to slots and sessions are for the next summit.
>
> We can choose among 3 different types of sessions:
>
> * Fishbowl slots (Wed-Thu)
> Our traditional largish rooms organized in fishbowl style, with
> advertised session content on the summit schedule for increased external
> participation. Ideal for when wider feedback is essential.
>
> * Workroom slots (Tue-Thu)
> Smaller rooms organized in boardroom style, with topic buried in the
> session description, in an effort to limit attendance and not overcrowd
> the room. Ideal to get work done and prioritize work in small teams.
>
> * Contributors meetup (Fri)
> Half-day session(s) on the Friday to get into the Newton action while
> decisions and plans are still hot, or to finish discussions started
> during the week, whatever works for you.
>
> Our usage in Tokyo was: 3, 5, 2
>
> I'd recommend we keep it that way. Thoughts?
> Cheers,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
>
>
> __
> 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
>
>
> --
>
> Thanks,
> Nikhil
>
>


-- 
@flaper87
Flavio Percoco
__
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] Intra-column wrapping in python-neutronclient

[Carl Baldwin]

Hi,

I've noticed a new behavior from the python-neutronclient which
disturbs me.  For me, this just started happening with my latest build
of devstack which I built yesterday.  It didn't happen with another
recent but little bit older devstack.

The issue is that the client is now wrapping content within columns.
For example:

  
+-+-+--+
  | id  | name| subnets
  |
  
+-+-+--+
  | eb850219-6a42-42ed-ac6a-| public  |
099745e5-4925-4572-a88f- |
  | 927b03a0dc77| | a5376206c892
172.24.4.0/24   |
  | | | 5b6dfb0d-c97e-48ae-
  |
  | | | 98c9-7fe3e1e8e88b
2001:db8::/64  |
  | ec73110f-   | private | 4073b9e7-a58e-4d6e-
  |
  | 86ad-4292-9547-7c2789a7023b | | a2e4-7a45ae899671
10.0.0.0/24|
  | | |
f12aee80-fc13-4adf-a0eb- |
  | | | 706af4319094
fd9d:e27:3eab::/64  |
  
+-+-+--+

Notice how the ids in the first column are wrapped within the column.
I personally don't see this as an aesthetic improvement.  It destroys
by ability to cut and paste the data within this column.  When I
stretch my console out to fix it, I have to rerun the command with the
new window width to fix it.  I used to be able to stretch my console
horizontally and the wrapped would automatically go away.

How can I turned this off now?  Also, can I request that this new
"feature" be disabled by default?

Carl

__
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] convergence cancel messages

[Clint Byrum]

Excerpts from Anant Patil's message of 2016-02-23 23:08:31 -0800:
> Hi,
> 
> I would like the discuss various approaches towards fixing bug
> https://launchpad.net/bugs/1533176
> 
> When convergence is on, and if the stack is stuck, there is no way to
> cancel the existing request. This feature was not implemented in
> convergence, as the user can again issue an update on an in-progress
> stack. But if a resource worker is stuck, the new update will wait
> for-ever on it and the update will not be effective.
> 
> The solution is to implement cancel request. Since the work for a stack
> is distributed among heat engines, the cancel request will not work as
> it does in legacy way. Many or all of the heat engines might be running
> worker threads to provision a stack.
> 
> I could think of two options which I would like to discuss:
> 
> (a) When a user triggered cancel request is received, set the stack
> current traversal to None or something else other than current
> traversal. With this the new check-resources/workers will never be
> triggered. This is okay as long as the worker(s) is not stuck. The
> existing workers will finish running, and no new check-resource
> (workers) will be triggered, and it will be a graceful cancel.  But the
> workers that are stuck will be stuck for-ever till stack times-out.  To
> take care of such cases, we will have to implement logic of "polling"
> the DB at regular intervals (may be at each step() of scheduler task)
> and bail out if the current traversal is updated. Basically, each worker
> will "poll" the DB to see if the current traversal is still valid and if
> not, stop itself. The drawback of this approach is that all the workers
> will be hitting the DB and incur a significant overhead.  Besides, all
> the stack workers irrespective of whether they will be cancelled or not,
> will keep on hitting DB. The advantage is that it probably is easier to
> implement. Also, if the worker is stuck in particular "step", then this
> approach will not work.
> 
> (b) Another approach is to send cancel message to all the heat engines
> when one receives a stack cancel request. The idea is to use the thread
> group manager in each engine to keep track of threads running for a
> stack, and stop the thread group when a cancel message is received. The
> advantage is that the messages to cancel stack workers is sent only when
> required and there is no other over-head. The draw-back is that the
> cancel message is 'broadcasted' to all heat engines, even if they are
> not running any workers for the given stack, though, in such cases, it
> will be a just no-op for the heat-engine (the message will be gracefully
> discarded).

Oh hah, I just sent (b) as an option to avoid (a) without really
thinking about (b) again.

I don't think the cancel broadcasts are all that much of a drawback. I
do think you need to rate limit cancels though, or you give users the
chance to DDoS the system.

__
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] convergence cancel messages

[Clint Byrum]

Excerpts from Anant Patil's message of 2016-02-24 00:56:34 -0800:
> On 24-Feb-16 13:12, Clint Byrum wrote:
> > Excerpts from Anant Patil's message of 2016-02-23 23:08:31 -0800:
> >> Hi,
> >>
> >> I would like the discuss various approaches towards fixing bug
> >> https://launchpad.net/bugs/1533176
> >>
> >> When convergence is on, and if the stack is stuck, there is no way to
> >> cancel the existing request. This feature was not implemented in
> >> convergence, as the user can again issue an update on an in-progress
> >> stack. But if a resource worker is stuck, the new update will wait
> >> for-ever on it and the update will not be effective.
> >>
> >> The solution is to implement cancel request. Since the work for a stack
> >> is distributed among heat engines, the cancel request will not work as
> >> it does in legacy way. Many or all of the heat engines might be running
> >> worker threads to provision a stack.
> >>
> >> I could think of two options which I would like to discuss:
> >>
> >> (a) When a user triggered cancel request is received, set the stack
> >> current traversal to None or something else other than current
> >> traversal. With this the new check-resources/workers will never be
> >> triggered. This is okay as long as the worker(s) is not stuck. The
> >> existing workers will finish running, and no new check-resource
> >> (workers) will be triggered, and it will be a graceful cancel.  But the
> >> workers that are stuck will be stuck for-ever till stack times-out.  To
> >> take care of such cases, we will have to implement logic of "polling"
> >> the DB at regular intervals (may be at each step() of scheduler task)
> >> and bail out if the current traversal is updated. Basically, each worker
> >> will "poll" the DB to see if the current traversal is still valid and if
> >> not, stop itself. The drawback of this approach is that all the workers
> >> will be hitting the DB and incur a significant overhead.  Besides, all
> >> the stack workers irrespective of whether they will be cancelled or not,
> >> will keep on hitting DB. The advantage is that it probably is easier to
> >> implement. Also, if the worker is stuck in particular "step", then this
> >> approach will not work.
> >>
> > 
> > I think this is the simplest option. And if the polling gets to be too
> > much, you can implement an observer pattern where one worker is just
> > assigned to poll the traversal and if it changes, RPC to the known
> > active workers that they should cancel any jobs using a now-cancelled
> > stack version.
> > 
> > __
> > 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
> > 
> 
> Hi Clint,
> 
> I see that observer pattern is simple, but IMO it too is not efficient.
> To implement it, we will have to note down in DB the worker to engine-id
> relationship for all the workers, and then go through all of them and
> send targeted cancel messages. This will also need us to have thread
> group manager in each engine so that it can stop the thread group
> running workers for the stack.
> 

You have to have that thread group manager anyway, or you can't ever
cancel anything in progress. That same thread group manager could also
be managing timeouts.

Apologies for my lack of understanding of where the implementation
has gone, I thought you would already have that mapping in the DB. If
that's a problem though, for this case you can have a notification
channel for cancellations, and have the management thread listen to
that, with its own local awareness of what is being worked on.

__
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] containers across availability zones

[Vilobh Meshram]

+1 from me too for the idea. Please file a blueprint. Seems feasible and
useful.

-Vilobh

On Tue, Feb 23, 2016 at 7:25 PM, Adrian Otto 
wrote:

> Ricardo,
>
> Yes, that approach would work. I don’t see any harm in automatically
> adding tags to the docker daemon on the bay nodes as part of the swarm heat
> template. That would allow the filter selection you described.
>
> Adrian
>
> > On Feb 23, 2016, at 4:11 PM, Ricardo Rocha 
> wrote:
> >
> > Hi.
> >
> > Has anyone looked into having magnum bay nodes deployed in different
> > availability zones? The goal would be to have multiple instances of a
> > container running on nodes across multiple AZs.
> >
> > Looking at docker swarm this could be achieved using (for example)
> > affinity filters based on labels. Something like:
> >
> > docker run -it -d -p 80:80 --label nova.availability-zone=my-zone-a nginx
> > https://docs.docker.com/swarm/scheduler/filter/#use-an-affinity-filter
> >
> > We can do this if we change the templates/config scripts to add to the
> > docker daemon params some labels exposing availability zone or other
> > metadata (taken from the nova metadata).
> >
> https://docs.docker.com/engine/userguide/labels-custom-metadata/#daemon-labels
> >
> > It's a bit less clear how we would get heat to launch nodes across
> > availability zones using ResourceGroup(s), but there are other heat
> > resources that support it (i'm sure this can be done).
> >
> > Does this make sense? Any thoughts or alternatives?
> >
> > If it makes sense i'm happy to submit a blueprint.
> >
> > Cheers,
> >  Ricardo
> >
> >
> __
> > 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] A prototype implementation towards the "shared state scheduler"

[Ed Leafe]

On 02/24/2016 05:56 AM, Chris Dent wrote:

>> I'd actually also be interested if this has a potential to reduce the
>> demand on the message bus. I've been investigating this for a while,
>> and I
>> found that RabbitMQ will happily consume 5 high end CPU cores on a
>> single box
>> just to serve the needs of 1000 idle compute nodes.
> 
> What do we need to do, as a community, to start treating and
> thinking about this problem as a bug rather than something we have
> to deal with or work around? "Fear of messaging" is putting a big
> limitation on our possible solutions to a fair few problems (notably
> scheduling).

Some chatter is necessary to assure system health, but yeah, this should
be considered a bug. I'm sure that if a RabbitMQ expert were able to
observe this, the response would be "you're doing it wrong", and we
might fix this.

-- 

-- Ed Leafe


__
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] [sahara] Final client release for Mitaka

[Sergey Lukjanov]

Hi sahara folks,

if you have any idea on what should be merged into python-saharaclient
before the final client release for Mitaka, please, raise you hand till
EOW, we're planning to discuss it tomorrow on IRC meeting and try to
release client on Friday.

https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Agenda

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
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] [nova] solving API case sensitivity issues

[Sean Dague]

On 02/24/2016 11:28 AM, James Bottomley wrote:
> On Wed, 2016-02-24 at 07:48 -0500, Sean Dague wrote:
>> We have a specific bug around aggregrate metadata setting in Nova
>> which
>> exposes a larger issue with our mysql schema.
>> https://bugs.launchpad.net/nova/+bug/1538011
>>
>> On mysql the following will explode with a 500:
>>
>>> nova aggregate-create agg1
>>> nova aggregate-set-metadata agg1 abc=1
>>> nova aggregate-set-metadata agg1 ABC=2
>>
>> mysql (by default) treats abc == ABC. However the python code does
>> not.
>>
>> We have a couple of options:
>>
>> 1) make the API explicitly case fold
>>
>> 2) update the mysql DB to use latin_bin collation for these columns
>>
>> 3) make this a 400 error because duplicates were found
>>
>>
>> Options 1 & 2 make all OpenStack environments consistent regardless
>> of
>> backend.
>>
>> Option 2 is potentially expensive TABLE alter.
>>
>> Option 3 gets rid of the 500 error, however at the risk that the
>> behavior for this API is different depending on DB backend. Which is
>> less than ideal.
>>
>>
>> My preference is slightly towards #1. It's taken a long time for 
>> someone to report this issue, so I think it's an edge case, and 
>> people weren't think about this being case sensitive. It has the risk 
>> of impacting someone on an odd db platform that has been using that
>> feature.
>>
>> There are going to be a few other APIs to clean up in a similar way. 
>> I don't think this comes in under a microversion because of how deep 
>> in the db api layer this is, and it's just not viable to keep both
>> paths.
> 
> This is actually one of the curses wished on us by REST.  Since the
> intent is to use web requests for the API, the API name must follow the
> case sensitivity rules for URL matching (case insensitive). 

Um... since when are URLs generically case insensitive? The host portion
is - https://tools.ietf.org/html/rfc3986#section-3.2.2 and the scheme
portion is - https://tools.ietf.org/html/rfc3986#section-3.1 however
nothing about the PATH specifies that it should or must be (in section 3.3)

While it's a little off topic, this is the 2nd time in a month it came
up, so I'd like to know if there is a reference for the case insensitive
pov.

-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

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

[Cheng, Yingxin]

Sorry for the late reply.

On 22 February 2016 at 18:45, John Garbutt wrote:
> On 21 February 2016 at 13:51, Cheng, Yingxin  wrote:
> > On 19 February 2016 at 5:58, John Garbutt wrote:
> >> On 17 February 2016 at 17:52, Clint Byrum  wrote:
> >> > Excerpts from Cheng, Yingxin's message of 2016-02-14 21:21:28 -0800:
> >> Long term, I see a world where there are multiple scheduler Nova is
> >> able to use, depending on the deployment scenario.
> >
> > Technically, what I've implemented is a new type of scheduler host
> > manager `shared_state_manager.SharedHostManager`[1] with the ability
> > to synchronize host states directly from resource trackers.
> 
> Thats fine. You just get to re-use more code.
> 
> Maybe I should say multiple scheduling strategies, or something like that.
> 
> >> So a big question for me is, does the new scheduler interface work if
> >> you look at slotting in your prototype scheduler?
> >>
> >> Specifically I am thinking about this interface:
> >> https://github.com/openstack/nova/blob/master/nova/scheduler/client/_
> >> _init__.py
> 
> I am still curious if this interface is OK for your needs?
> 

The added interfaces from scheduler side is:
https://review.openstack.org/#/c/280047/2/nova/scheduler/client/__init__.py 
1. I can remove "notify_schedulers" because the same message can be sent 
through "send_commit" instead.
2. The "send_commit" interface is required because there should be a way to 
send state updates from compute node to a specific scheduler.

The added/changed interfaces from compute side is:
https://review.openstack.org/#/c/280047/2/nova/compute/rpcapi.py 
1. The "report_host_state" interface is required. When a scheduler is up, it 
must ask compute node for the latest host state. It is also required when the 
scheduler detects that it's host state is out of sync and it should ask compute 
node for a synced state(its rare due to network issues or bugs).
2. The new parameter "claim" should be added to interface 
"build_and_run_instance" because compute node should reply whether a scheduler 
claim is successful. Scheduler can thus track its claims and can be updated by 
successful claims from other schedulers immediately. The compute node can thus 
decide whether a scheduler decision is made from the "shared-state" scheduler, 
that's the *tricky* part to support both types of schedulers.

> Making this work across both types of scheduler might be tricky, but I think 
> it is
> worthwhile.
> 
> >> > This mostly agrees with recent tests I've been doing simulating
> >> > 1000 compute nodes with the fake virt driver.
> >>
> >> Overall this agrees with what I saw in production before moving us to
> >> the caching scheduler driver.
> >>
> >> I would love a nova functional test that does that test. It will help
> >> us compare these different schedulers and find the strengths and 
> >> weaknesses.
> >
> > I'm also working on implementing the functional tests of nova
> > scheduler, there is a patch showing my latest progress:
> > https://review.openstack.org/#/c/281825/
> >
> > IMO scheduler functional tests are not good at testing real
> > performance of different schedulers, because all of the services are
> > running as green threads instead of real processes. I think the better
> > way to analysis the real performance and the strengths and weaknesses
> > is to start services in different processes with fake virt driver(i.e.
> > Clint Byrum's work) or Jay Pipe's work in emulating different designs.
> 
> Having an option to run multiple process seems OK, if its needed.
> Although starting with a greenlet version that works in the gate seems best.
> 
> Lets try a few things, and see what predicts the results in real environments.

Sure.

> >> I am really interested how your prototype and the caching scheduler 
> >> compare?
> >> It looks like single node scheduler will perform in a very similar
> >> way, but multiple schedulers are less likely to race each other,
> >> although there are quite a few races?
> >
> > I think the major weakness of caching scheduler comes from its host
> > state update model, i.e. updating host states from db every `
> > CONF.scheduler_driver_task_period`
> > seconds.
> 
> The trade off is that consecutive scheduler decisions don't race each other, 
> at all.
> Say you have a burst of 1000 instance builds and you want to avoid build 
> failures
> (but accept sub optimal placement, and you are using fill first), thats a 
> very good
> trade off.
> 
> Consider a burst of 1000 deletes, it may take you 60 seconds to notice they 
> are
> all deleted and you have lots more free space, but that doesn't cause build
> failures like excessive races for the same resources will, at least under the 
> usual
> conditions where you are not yet totally full (i.e. non-HPC use cases).
> 
> I was shocked how well the caching_scheduler works in practice. I assumed it
> would be terrible, but when we tried it, it worked well.

Re: [openstack-dev] [all] A proposal to separate the design summit

[Walter A. Boring IV]

On 02/23/2016 06:14 AM, Qiming Teng wrote:



I don't think the proposal removes that opportunity. Contributors
/can/ still go to OpenStack Summits. They just don't /have to/. I
just don't think every contributor needs to be present at every
OpenStack Summit, while I'd like to see most of them present at
every separated contributors-oriented event[tm].

Yes they can, but if contributors go to the design summit, then they
also have to get travel budget to go to the new Summit.   So, design
summits,  midcycle meetups, and now the split off marketing summit.
This is making it overall more expensive for contributors that meet
with customers.


My take of this is that we are saving the cost by isolating developers
(contributors) from users/customers.

And that is exactly a problem for contributors like myself that use the
conference to meet with customers.   If we split off the summit from
developers, then I'll also have to travel to yet another meetup, just to
meet with customers.

For contributors that just focus on design and development, the proposed
change is probably fine, but for everyone else this seems to make things 
worse

and adds additional costs and travel.

Walt

__
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] solving API case sensitivity issues

[Chris Dent]

On Wed, 24 Feb 2016, James Bottomley wrote:


This is actually one of the curses wished on us by REST.  Since the
intent is to use web requests for the API, the API name must follow the
case sensitivity rules for URL matching (case insensitive).  However,
the rest of the parameters can be case sensitive.  That means that if
your column name maps to an API, it must be case insensitive, but if it
maps to a data input it may be case sensitive.


I'm not sure what you are going on about here. URLs are case
sensitive[1]. If Nova is using case insensitive rules for route matching
that's a Nova thing and has nothing to do with either REST or HTTP.

[1] https://tools.ietf.org/html/rfc7230#section-2.7.3

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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] Now part of OpenStack big-tent

[Antoni Segura Puimedon]

On Wed, Feb 24, 2016 at 4:51 PM, Gal Sagie  wrote:
> Hello Everyone,
>
> Just wanted to update you that Kuryr [1] was officially accepted yesterday
> as a
> big tent project.

We should probably get Kuryr to be selectable as a tag to subscribe to in

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

>
> We are currently facing some interesting challenges and times and if you
> are running containers in OpenStack in mixed environments you most certainly
> want to look and examine Kuryr.
>
> We are holding a weekly IRC meeting [2] which is alternating between time
> zones
> so you have no excuse :) everyone are welcome!
>
> We want to help and solve more challenges in the realm of containers
> networking
> deployments in OpenStack and if you are deploying this either in development
> or
> in production we would love to hear your experience and the problems you are
> facing
> and try to help you manage this better, feel free to share!
>
> [1] https://wiki.openstack.org/wiki/Kuryr
> [2] https://wiki.openstack.org/wiki/Meetings/Kuryr

__
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][murano][fuel-plugins] Move Murano to plugin from Fuel box

[Denis Egorenko]

Hello folks,

i would like to notify you, that we are going to remove Murano as built
in Fuel and move this functionality to fuel-plugin.

Transition from Fuel built in to Fuel plugin deployment will follow next
way:

* Murano deployment in Fuel 9.0 will be deprecated: we leave an ability to
deploy it,
  keeping puppet manifests for Murano in fuel-library, keeping UI settings
  untill plugin will be prepared and tested;

* Once plugin is ready, Fuel 9.0 deployment from built in Murano will
  forbidden. All Murano codebase will be removed from Fuel in next release.

Since Murano will be a plugin, it will have his own development cycle,
differ from Fuel releases.

There is specification for this activity [1]. Any feedback is welcome.

[1] https://review.openstack.org/275124

-- 
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
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] solving API case sensitivity issues

[James Bottomley]

On Wed, 2016-02-24 at 07:48 -0500, Sean Dague wrote:
> We have a specific bug around aggregrate metadata setting in Nova
> which
> exposes a larger issue with our mysql schema.
> https://bugs.launchpad.net/nova/+bug/1538011
> 
> On mysql the following will explode with a 500:
> 
> > nova aggregate-create agg1
> > nova aggregate-set-metadata agg1 abc=1
> > nova aggregate-set-metadata agg1 ABC=2
> 
> mysql (by default) treats abc == ABC. However the python code does
> not.
> 
> We have a couple of options:
> 
> 1) make the API explicitly case fold
> 
> 2) update the mysql DB to use latin_bin collation for these columns
> 
> 3) make this a 400 error because duplicates were found
> 
> 
> Options 1 & 2 make all OpenStack environments consistent regardless
> of
> backend.
> 
> Option 2 is potentially expensive TABLE alter.
> 
> Option 3 gets rid of the 500 error, however at the risk that the
> behavior for this API is different depending on DB backend. Which is
> less than ideal.
> 
> 
> My preference is slightly towards #1. It's taken a long time for 
> someone to report this issue, so I think it's an edge case, and 
> people weren't think about this being case sensitive. It has the risk 
> of impacting someone on an odd db platform that has been using that
> feature.
> 
> There are going to be a few other APIs to clean up in a similar way. 
> I don't think this comes in under a microversion because of how deep 
> in the db api layer this is, and it's just not viable to keep both
> paths.

This is actually one of the curses wished on us by REST.  Since the
intent is to use web requests for the API, the API name must follow the
case sensitivity rules for URL matching (case insensitive).  However,
the rest of the parameters can be case sensitive.  That means that if
your column name maps to an API, it must be case insensitive, but if it
maps to a data input it may be case sensitive.

I think option 1 is the best course, but someone will have to take a
look and make sure there are no APIs that suddenly have case
insensitivity rules for data inputs that aren't expressed currently.

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

[openstack-dev] [heat]How to manage the life cycle of resources in a stack?

[zhu4236926]

Hi guys,
I  get some resources by creating a stack, e.g. ,the resources may be 2 
volumes, volume A and volume B.  If the volume A and volume B are useless, we 
can delete them by deleting the stack , we also can delete them by cinder.If  
they are deleted by cinder, though the volumes have been delete, the resources 
and stack are still exist,  a tenant has the maxmum quantity of stacks, so I 
may couldn't  create the stack if the number of left stacks exceed the limit . 
If I delete by deleting the stack, the volume A and volume B would be deleted 
both, may be I just want to delete the volume A and reservce volume B.
So how should I manage the resources(volumeA and volumeB) created by heat, 
deleted by cinder or heat?




Best Regards,
Sylvernass




 





 





 





 





 





 





 __
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] [glance] Austin Design Summit space needs

[Nikhil Komawar]

Can we make it ? :

FB 3
W 6
C 2

On 2/24/16 10:42 AM, Flavio Percoco wrote:
> Hey Folks,
>
> It's that time of the year. We need to choose what our needs with
> regards to slots and sessions are for the next summit.
>
> We can choose among 3 different types of sessions:
>
> * Fishbowl slots (Wed-Thu)
> Our traditional largish rooms organized in fishbowl style, with
> advertised session content on the summit schedule for increased external
> participation. Ideal for when wider feedback is essential.
>
> * Workroom slots (Tue-Thu)
> Smaller rooms organized in boardroom style, with topic buried in the
> session description, in an effort to limit attendance and not overcrowd
> the room. Ideal to get work done and prioritize work in small teams.
>
> * Contributors meetup (Fri)
> Half-day session(s) on the Friday to get into the Newton action while
> decisions and plans are still hot, or to finish discussions started
> during the week, whatever works for you.
>
> Our usage in Tokyo was: 3, 5, 2
>
> I'd recommend we keep it that way. Thoughts? 
> Cheers,
> Flavio
>
> -- 
> @flaper87
> Flavio Percoco
>
>
>
> __
> 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,
Nikhil

__
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] Now part of OpenStack big-tent

[Gal Sagie]

Hello Everyone,

Just wanted to update you that Kuryr [1] was officially accepted yesterday
as a
big tent project.

We are currently facing some interesting challenges and times and if you
are running containers in OpenStack in mixed environments you most certainly
want to look and examine Kuryr.

We are holding a weekly IRC meeting [2] which is alternating between time
zones
so you have no excuse :) everyone are welcome!

We want to help and solve more challenges in the realm of containers
networking
deployments in OpenStack and if you are deploying this either in
development or
in production we would love to hear your experience and the problems you
are facing
and try to help you manage this better, feel free to share!

[1] https://wiki.openstack.org/wiki/Kuryr
[2] https://wiki.openstack.org/wiki/Meetings/Kuryr
__
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][infra] Publishing kolla images to docker-registry.openstack.org

[Steven Dake (stdake)]

Ricardo,

I measured the disk space used by the docker registry.

For ubuntu images, it is 1.5gb.
For centos images, it is 2.5gb.
For oraclelinux images, it is 2.5gb. (derivative of centos)
The delta between centos and Ubuntu has to do with the usage of apt vs
yum, where apt only installs a minimum set of requirement files.

For all distro and source combinations it is 1.5+1.5+2.5+2.5+2.5+2.5=13
Gbs for all containers (about 500 or so containers)

13gb * (3 release tags + 1 release tag + 3 Rcs per cycle) = 91gb per cycle
13gb * 30 days = 390gb

So the storage requirements are not as bad as originally thought.

Note it takes me 6 minutes to build on my PCIE SSD with gigabit to the
Internet via Cox communications.  It takes 2 minutes to push to a local
registry at 10 gigabit with PCIE SSDs.

Our gate job with mirrors of the APT repos takes between 25 and 30 minutes
to build.  A post job to build and push the commit on tag or nightly is
easy for us to tackle on the kolla end.

Where we are stumped is should we push to registry.openstack.org which I
would prefer, or push to the docker registry.

Another issue is getting the authentication credentials in the gate
securely - somehow it needs to be injected into our post jobs without us
having to check our credentials into the repository.

Regards
-steve



On 2/23/16, 9:58 AM, "Steven Dake (stdake)"  wrote:

>Ricardo,
>
>Apologies in lag, I remember reading your email but not answering
>personally.  I thought Michal's response was appropriate but there is a
>bit more to it.
>
>We definitely want to have images for the following events:
>* Any tag such as a milestone, or release candidate, or release
>* Nightly builds for folks that want to run bleeding edge without the pain
>of building images
>
>The nightly builds can easily be culled after 30 days.
>
>We have implementations for centos, ubuntu, and oracle linux.  We have
>source and binary versions of both these distros, so essentially we have 6
>sets of registry images.
>
>There are 115 containers we would build, push, and tag.  I think Michal's
>estimate is for a limited subset of the containers.  Ideally we would want
>to build and push all the containers in our repository, which I believe is
>10-15GB per distro+build type combination.
>
>At the high end, we are looking at
>* (for permanently tagged releases) 15gb*6 sets of images * (3 milestone
>tags + 1 release tag + 1-3 RC's per cycle = 7) * 2 release cycles per year
>= 1 terabyte of images per cycle growing approximately ~ 1.3 terabytes per
>year
>* (for the nightly builds), 15bb*6 sets of images * 30 = 2.7 terabytes in
>continuous use.
>
>So that is 2.2 TB baseline + 1TB per year growth.  As we add containers
>over time, the yearly growth may increase, but I doubt would ever be more
>then 2 terabytes in the next 4 release cycles of OpenStack.
>
>There are several registry storage backends available including swift, so
>if infra has swift available, that would be a viable option.
>
>I'll get an exact number for our containers as they build today and
>respond to this thread since it affects the estimate.
>
>It is not critical the storage be SSD, since tag and nightly build
>operations could happen with long run-time on the post jobs I believe
>without harming infra resources (although they may go past the 90 minute
>limit infra likes to stick to without SSD).  I don't have any non-SSD to
>test the build with, so I have no idea what performance impact the SSDs
>have.  I know when I went from regular SSD to PCI-E NVM SSD (Intel 750) my
>build times dropped from 50 minutes to about 15 minutes.
>
>Note we don't have gate jobs at present for oracle linux nor Ubuntu
>binary.  Only CentOS binary, CentOS source, and Ubuntu source are in our
>gates at present.  For the present term, storage would be 630GB per year.
>
>I'll get back to you with exact numbers on storage used by the registry in
>a full build scenario today.
>
>Regards
>-steve
>
>
>On 2/21/16, 9:26 AM, "Michał Jastrzębski"  wrote:
>
>>I'd say 5Gigs should be enough for all the images per distro (maybe
>>less if we have to squeeze). Since we have have 2 strongly supported
>>distro 10Gigs. If we would like to add all distros we support, that's
>>20-25 (I think). That also depends how many older versions we want to
>>keep (current+stable would be absolute minimum, we might increase it
>>to milestones). We have lot's of options to tweak so no one will get
>>hurt, and if we have dedicated machine for us (which we should because
>>apart from disk space, registry can actually eat up lots of IOPS, can
>>be VM tho with disk that can handle that), I think any dedicated,
>>industry standard, disk should be enough (but SSD would be great).
>>
>>Cheers,
>>Michal
>>
>>On 20 February 2016 at 16:14, Ricardo Carrillo Cruz
>> wrote:
>>> Hi Steve
>>>
>>> When you say the registry would require a machine with plenty of disk
>>>space,
>>> do you have 

[openstack-dev] [glance] Austin Design Summit space needs

[Flavio Percoco]

Hey Folks,

It's that time of the year. We need to choose what our needs with regards
to slots and sessions are for the next summit.

We can choose among 3 different types of sessions:

* Fishbowl slots (Wed-Thu)
Our traditional largish rooms organized in fishbowl style, with
advertised session content on the summit schedule for increased external
participation. Ideal for when wider feedback is essential.

* Workroom slots (Tue-Thu)
Smaller rooms organized in boardroom style, with topic buried in the
session description, in an effort to limit attendance and not overcrowd
the room. Ideal to get work done and prioritize work in small teams.

* Contributors meetup (Fri)
Half-day session(s) on the Friday to get into the Newton action while
decisions and plans are still hot, or to finish discussions started
during the week, whatever works for you.

Our usage in Tokyo was: 3, 5, 2

I'd recommend we keep it that way. Thoughts?
Cheers,
Flavio

-- 
@flaper87
Flavio Percoco
__
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] Austin Design Summit space needs

[Emilien Macchi]

Puppet OpenStack folks,

As usual, Thierry Carrez sent an e-mail to PTLs about space needs for
the next OpenStack Summit in Austin.


We can have 3 kinds of slots:

* Fishbowl slots (Wed-Thu) - we had 2 in Tokyo.
Our traditional largish rooms organized in fishbowl style, with
advertised session content on the summit schedule for increased external
participation. Ideal for when wider feedback is essential.

* Workroom slots (Tue-Thu) - we had 3 in Tokyo.
Smaller rooms organized in boardroom style, with topic buried in the
session description, in an effort to limit attendance and not overcrowd
the room. Ideal to get work done and prioritize work in small teams.

* Contributors meetup (Fri) - we had 0 in Tokyo.
Half-day session(s) on the Friday to get into the Newton action while
decisions and plans are still hot, or to finish discussions started
during the week, whatever works for you.


I suggest we keep the same model as Tokyo, I think it worked pretty well
for us.
Though I'm wondering if we should also ask for a contributors meetup?
Do we really need that?


Any feedback from developers and operators are highly welcome.

Deadline: March 5th.
Thanks,
-- 
Emilien Macchi



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] [kolla] New Meeting Times altrernating 16:30 and 23; 00 UTC.

[Steven Dake (stdake)]

Jeffrey,

The weeks are calculated using the ISO standard for week conventions.  This is 
the 8th week.

Regards
-steve


From: Jeffrey Zhang >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, February 24, 2016 at 7:12 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] New Meeting Times altrernating 16:30 and 
23; 00 UTC.

hi Steven,

did you make some mistake? this week is the 9th( odd week). So the meeting time 
should be on wednesday at 2300 UTC.

Every two weeks (on even weeks) on Wednesday at 1630 
UTC 
in #openstack-meeting-4 (IRC 
webclient)
Every two weeks (on odd weeks) on Wednesday at 2300 
UTC 
in #openstack-meeting-4 (IRC 
webclient)

On Wed, Feb 24, 2016 at 8:50 PM, Steven Dake (stdake) 
> wrote:
Hey folks,

We agreed some time ago to be more inclusive and have an APAC/US meeting.  I am 
happy to announce that work has completed.

Please see:

http://eavesdrop.openstack.org/#Kolla_Team_Meeting

>From there you can download an ical file which will insert directly into your 
>calendar for your connivance.

NB the next meeting is held Wednesday February 24th @ t 16:30 UTC .  The 
meeting on  March 4th will be held at 23:00UTC.  The 23:00 UTC time is our UTC 
timeslot.

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




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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Adam Heczko]

+1, although I'm not core:)

On Wed, Feb 24, 2016 at 4:04 PM, Sergey Kolekonov 
wrote:

> +1
>
> On Wed, Feb 24, 2016 at 5:49 PM, Moshe Levi  wrote:
>
>> +1 J
>>
>>
>>
>> *From:* Ivan Berezovskiy [mailto:iberezovs...@mirantis.com]
>> *Sent:* Wednesday, February 24, 2016 4:47 PM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew
>> Mosesohn for Fuel Library Core
>>
>>
>>
>> +1 for Matthew!
>>
>>
>>
>> 2016-02-24 17:34 GMT+03:00 Fedor Zhadaev :
>>
>> +1
>>
>>
>>
>> On Wed, Feb 24, 2016 at 5:30 PM Julia Aranovich 
>> wrote:
>>
>> +1
>>
>>
>>
>> On Wed, Feb 24, 2016 at 4:57 PM Denis Egorenko 
>> wrote:
>>
>> I'm not a fuel core member, but i also would like to vote +1 for Matthew.
>> He's doing great job!
>>
>>
>>
>> 2016-02-24 16:02 GMT+03:00 Aleksandr Didenko :
>>
>> +1
>>
>>
>>
>> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
>> wrote:
>>
>> Fellow Fuelers
>>
>>
>>
>> I would like to kindly ask you to consider voting for Matthew Mosesohn as
>> a Fuel Library Core
>>
>> reviewer.
>>
>>
>>
>> Matthew has been working with Fuel since its inception, worked on
>> countless amount of features, such as :
>>
>>
>>
>> Master Node Upgrades and Backup
>>
>> Improvements to Fuel Infra
>>
>> Mitaka, Kilo and Juno Support
>>
>> Detachable Services Plugins
>>
>> RHOS Support in Fuel
>>
>> UCA Support
>>
>> Refactoring of Haproxy and Firewall pieces
>>
>>
>>
>> He has also been known as our Fuel Master node and Docker guru and has
>> been continuously working on bugfixing where he scores as a bug squashing
>> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
>> throughout FL history).
>>
>>
>>
>> As you can see, there is not a piece of Fuel Library that he has not yet
>> gained experience with.
>>
>>
>>
>> And this can easily be fetched with simple statistics of Matt's
>> contribution. He is the topmost contributor to all Fuel projects among all
>> Fuel Library folks and is the 3rd contributor of Fuel Library.
>>
>> He also reviews a lot and has a fair amount of -1's (he is not as cruel
>> as me, though :-))
>>
>>
>>
>> Having that said, I would like to open the vote to promote Matt to
>> OpenStack Fuel Library core reviewers.
>>
>>
>>
>> --
>>
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.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
>>
>>
>>
>>
>>
>> --
>>
>> Best Regards,
>>
>> Egorenko Denis,
>>
>> Senior Deployment Engineer
>> Mirantis
>>
>> __
>> 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
>>
>> --
>>
>> Kind Regards,
>>
>> Fedor Zhadaev
>>
>>
>>
>> skype: zhadaevfm
>>
>> IRC: fzhadaev
>>
>>
>> __
>> 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, Ivan Berezovskiy
>>
>> MOS Puppet Team Lead
>>
>> at Mirantis 
>>
>>
>>
>> slack: iberezovskiy
>>
>> skype: bouhforever
>>
>> phone: + 7-960-343-42-46
>>
>>
>>
>> __
>> 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] [Networking-vSphere] - changes in nova compute driver

[Gary Kotton]

Hi,
I suggest that the guys who maintain this driver provide you the reasons why 
they maintain the Nova driver like this It is problematic and at times the 
driver can break as it is not in tree.
Thanks
Gary

From: Monotosh Das >
Reply-To: OpenStack List 
>
Date: Tuesday, February 23, 2016 at 1:52 PM
To: OpenStack List 
>
Subject: [openstack-dev] [Networking-vSphere] - changes in nova compute driver

Hi,

In Networking-vSphere (ovsvapp), 'vsphere' is used as nova compute driver. I 
want to know if there is any modification in the default vsphere driver that is 
specific to ovsvapp. If yes, can you give an idea about the changes ?

If not, then how does vsphere driver get to know port group creation is 
complete, as mentioned in the wiki 
(https://wiki.openstack.org/wiki/Neutron/Networking-vSphere) ? In the code 
(nova/virt/vmwareapi/vmops.py : spawn() ), it appears that VM is created first, 
then neutron is updated about the nic, and then VM is powered on. It doesn't 
wait for any event before powering on the VM.

Some clarification about this will be very helpful,


Thanks,
Monotosh



__
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] Questions on template-validate

[Jay Dobies]

On 02/24/2016 02:18 AM, Anant Patil wrote:

On 23-Feb-16 20:34, Jay Dobies wrote:

I am going to bring this up in the team meeting tomorrow, but I figured
I'd send it out here as well. Rather than retype the issue, please look at:

https://bugs.launchpad.net/heat/+bug/1548856

My question is what the desired behavior of template-validate should be,
at least from a historical standpoint of what we've honored in the past.
Before I propose/implement a fix, I want to make sure I'm not violating
any unwritten expectations on how it should work.

On a related note -- and this is going to sound really stupid that I
don't know this answer -- but are there any docs on actually using Heat?
I was looking for docs that may explain what the expectation of
template-validate was but I couldn't really find any.

The wiki links to a number of developer-centric docs (HOT guide,
developer process, etc.). I found the (what I believe to be current)
REST API docs [1] but the only real description is "Validates a template."

Thanks  :D


[1] http://developer.openstack.org/api-ref-orchestration-v1.html

__
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



Sometime back, I too went through this, but got adjusted to the thought
that the template validation is really for validating the syntax and
structure of a template. Whether the values provided are valid or not
will be decided when the stack is validated.


Sorry, one more question. If this is the case, then why does 
template-validate accept -P arguments in the CLI?



The values that depend on
resource plugins to fetch data from other services are not validated,
and to me it makes sense. It helps user to quickly test-develop
templates that are syntactically and structurally valid and they don't
have to depend on resource plugins and services availability. IMO, it
would be better to document the way template validate works, than to
make it a heavy weight request that depends on plugins and services.

__
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] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Sergey Kolekonov]

+1

On Wed, Feb 24, 2016 at 5:49 PM, Moshe Levi  wrote:

> +1 J
>
>
>
> *From:* Ivan Berezovskiy [mailto:iberezovs...@mirantis.com]
> *Sent:* Wednesday, February 24, 2016 4:47 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew
> Mosesohn for Fuel Library Core
>
>
>
> +1 for Matthew!
>
>
>
> 2016-02-24 17:34 GMT+03:00 Fedor Zhadaev :
>
> +1
>
>
>
> On Wed, Feb 24, 2016 at 5:30 PM Julia Aranovich 
> wrote:
>
> +1
>
>
>
> On Wed, Feb 24, 2016 at 4:57 PM Denis Egorenko 
> wrote:
>
> I'm not a fuel core member, but i also would like to vote +1 for Matthew.
> He's doing great job!
>
>
>
> 2016-02-24 16:02 GMT+03:00 Aleksandr Didenko :
>
> +1
>
>
>
> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
> wrote:
>
> Fellow Fuelers
>
>
>
> I would like to kindly ask you to consider voting for Matthew Mosesohn as
> a Fuel Library Core
>
> reviewer.
>
>
>
> Matthew has been working with Fuel since its inception, worked on
> countless amount of features, such as :
>
>
>
> Master Node Upgrades and Backup
>
> Improvements to Fuel Infra
>
> Mitaka, Kilo and Juno Support
>
> Detachable Services Plugins
>
> RHOS Support in Fuel
>
> UCA Support
>
> Refactoring of Haproxy and Firewall pieces
>
>
>
> He has also been known as our Fuel Master node and Docker guru and has
> been continuously working on bugfixing where he scores as a bug squashing
> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
> throughout FL history).
>
>
>
> As you can see, there is not a piece of Fuel Library that he has not yet
> gained experience with.
>
>
>
> And this can easily be fetched with simple statistics of Matt's
> contribution. He is the topmost contributor to all Fuel projects among all
> Fuel Library folks and is the 3rd contributor of Fuel Library.
>
> He also reviews a lot and has a fair amount of -1's (he is not as cruel as
> me, though :-))
>
>
>
> Having that said, I would like to open the vote to promote Matt to
> OpenStack Fuel Library core reviewers.
>
>
>
> --
>
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.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
>
>
>
>
>
> --
>
> Best Regards,
>
> Egorenko Denis,
>
> Senior Deployment Engineer
> Mirantis
>
> __
> 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
>
> --
>
> Kind Regards,
>
> Fedor Zhadaev
>
>
>
> skype: zhadaevfm
>
> IRC: fzhadaev
>
>
> __
> 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, Ivan Berezovskiy
>
> MOS Puppet Team Lead
>
> at Mirantis 
>
>
>
> slack: iberezovskiy
>
> skype: bouhforever
>
> phone: + 7-960-343-42-46
>
>
>
> __
> 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,
Sergey Kolekonov
__
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] [TripleO] Treating the undercloud as a black box

[Dan Prince]

One of the things I like about TripleO is the way you can use the
Undercloud remotely via its APIs to drive everything about your
deployment. We don't prevent you from shelling into your undercloud
though, and more recently with the switch to use instack and python-
tripleoclient our upstream CI documentation has actually moved towards
a model where we use the undercloud as a convenience to "stage" things
like building images, creating ssh keys for deployment. It is okay to
do this to save resources, but it shouldn't be be required. I'd like to
maintain a clear line which maintains the undercloud primarily as a
black box to be used via API's, not as something you shell into to
manage your overcloud.

A couple of examples:

We've actually got code in python-tripleoclient today that requires you
to execute some commands on the undercloud itself. The function to
build images [1] actually copies the IPA ramdisk and kernel in an HTTP
root for the Ironic inspector. This is somewhat optional functionality
(I can build my own images, and avoid the ironic inspector) but it
demonstrates how small feature addition to the client tooling forces
you to execute it on the undercloud rather than using API's. I suppose
I'd like to see us consider alternative approaches to this problem like
perhaps using a Mistral workflow to execute the same code on the
undercloud itself. We could still initiatiate it via python-
tripleoclient but we'd no longer require root shell access to do so.

A second example caught my attention recently was a patch to add
Ansible support to the undercloud here [2]. I really like to idea that
we would integrate with Ansible and provide options to generate or
perhaps auto configure the inventory via our undercloud APIs. What I'm
not as keen on is forcing the user to shell into the undercloud to take
advantage of these features. I happen to create my overcloud remotely
(with my ssh private keys on my laptop), and my use case for Ansible
integration would be much the same. I would likely want to use Ansible
directly from my laptop where my ssh keys reside. This isn't to say
that someone couldn't do the same thing on an undercloud by creating
their own home directory, and using the same client tooling. We could
actually support both models quite well. But where we implement these
types of features does matter, and may force operators and end users
into unwanted workflow changes (storing ssh keys on the undercloud,
etc).

Dan


[1] http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/t
ripleoclient/v1/overcloud_image.py#n792
[2] https://review.openstack.org/#/c/277688/



__
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] [dragonflow] db consistency progress

[Gal Sagie]

Hi Li Ma,

Great job on this!

I think Rally is the correct way to test something like that, what you
could use to check the end to end
solution is try to restart the DF DB server for timeouts during API
configurations.

At this point of time, i think this is really advance testing and i
wouldn't bother too much right now,
we need to make everything else more stable and then get back to this.



On Wed, Feb 24, 2016 at 4:31 PM, Li Ma  wrote:

> Hi all, today I submitted the working patch for review:
>
> https://review.openstack.org/#/c/282290/
>
> I tested it by invoking many concurrent API calls to update a given
> Neutron object, both for standalone and clustering of MySQL. The result is
> that no reported bugs about inconsistency were triggered.
>
> At the current stage, I'd like to discuss about testing. I think it needs
> to be tested at the gate by fullstack or rally. However, due to the
> uncertainty of the problem, even without this patch, the bug is not always
> triggered. How to make sure the test cases are reliable is the problem here.
>
> Any thoughts? Thanks a lot.
>
> --
>
> 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
>
>


-- 
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] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Moshe Levi]

+1 ☺

From: Ivan Berezovskiy [mailto:iberezovs...@mirantis.com]
Sent: Wednesday, February 24, 2016 4:47 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn 
for Fuel Library Core

+1 for Matthew!

2016-02-24 17:34 GMT+03:00 Fedor Zhadaev 
>:
+1

On Wed, Feb 24, 2016 at 5:30 PM Julia Aranovich 
> wrote:
+1

On Wed, Feb 24, 2016 at 4:57 PM Denis Egorenko 
> wrote:
I'm not a fuel core member, but i also would like to vote +1 for Matthew. He's 
doing great job!

2016-02-24 16:02 GMT+03:00 Aleksandr Didenko 
>:
+1

On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
> wrote:
Fellow Fuelers

I would like to kindly ask you to consider voting for Matthew Mosesohn as a 
Fuel Library Core
reviewer.

Matthew has been working with Fuel since its inception, worked on countless 
amount of features, such as :

Master Node Upgrades and Backup
Improvements to Fuel Infra
Mitaka, Kilo and Juno Support
Detachable Services Plugins
RHOS Support in Fuel
UCA Support
Refactoring of Haproxy and Firewall pieces

He has also been known as our Fuel Master node and Docker guru and has been 
continuously working on bugfixing where he scores as a bug squashing monster 
with more than 150 bugfixes to all the parts of Fuel Library (#1 throughout FL 
history).

As you can see, there is not a piece of Fuel Library that he has not yet gained 
experience with.

And this can easily be fetched with simple statistics of Matt's contribution. 
He is the topmost contributor to all Fuel projects among all Fuel Library folks 
and is the 3rd contributor of Fuel Library.
He also reviews a lot and has a fair amount of -1's (he is not as cruel as me, 
though :-))

Having that said, I would like to open the vote to promote Matt to OpenStack 
Fuel Library core reviewers.

--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com
www.mirantis.ru
vkuk...@mirantis.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



--
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
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
--
Kind Regards,
Fedor Zhadaev

skype: zhadaevfm
IRC: fzhadaev

__
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, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46

__
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] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Alex Schultz]

+1

On Wed, Feb 24, 2016 at 5:50 AM, Vladimir Kuklin 
wrote:

> Fellow Fuelers
>
> I would like to kindly ask you to consider voting for Matthew Mosesohn as
> a Fuel Library Core
> reviewer.
>
> Matthew has been working with Fuel since its inception, worked on
> countless amount of features, such as :
>
> Master Node Upgrades and Backup
> Improvements to Fuel Infra
> Mitaka, Kilo and Juno Support
> Detachable Services Plugins
> RHOS Support in Fuel
> UCA Support
> Refactoring of Haproxy and Firewall pieces
>
> He has also been known as our Fuel Master node and Docker guru and has
> been continuously working on bugfixing where he scores as a bug squashing
> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
> throughout FL history).
>
> As you can see, there is not a piece of Fuel Library that he has not yet
> gained experience with.
>
> And this can easily be fetched with simple statistics of Matt's
> contribution. He is the topmost contributor to all Fuel projects among all
> Fuel Library folks and is the 3rd contributor of Fuel Library.
> He also reviews a lot and has a fair amount of -1's (he is not as cruel as
> me, though :-))
>
> Having that said, I would like to open the vote to promote Matt to
> OpenStack Fuel Library core reviewers.
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.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] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Ivan Berezovskiy]

+1 for Matthew!

2016-02-24 17:34 GMT+03:00 Fedor Zhadaev :

> +1
>
> On Wed, Feb 24, 2016 at 5:30 PM Julia Aranovich 
> wrote:
>
>> +1
>>
>> On Wed, Feb 24, 2016 at 4:57 PM Denis Egorenko 
>> wrote:
>>
>>> I'm not a fuel core member, but i also would like to vote +1 for
>>> Matthew. He's doing great job!
>>>
>>> 2016-02-24 16:02 GMT+03:00 Aleksandr Didenko :
>>>
 +1

 On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
 wrote:

> Fellow Fuelers
>
> I would like to kindly ask you to consider voting for Matthew Mosesohn
> as a Fuel Library Core
> reviewer.
>
> Matthew has been working with Fuel since its inception, worked on
> countless amount of features, such as :
>
> Master Node Upgrades and Backup
> Improvements to Fuel Infra
> Mitaka, Kilo and Juno Support
> Detachable Services Plugins
> RHOS Support in Fuel
> UCA Support
> Refactoring of Haproxy and Firewall pieces
>
> He has also been known as our Fuel Master node and Docker guru and has
> been continuously working on bugfixing where he scores as a bug squashing
> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
> throughout FL history).
>
> As you can see, there is not a piece of Fuel Library that he has not
> yet gained experience with.
>
> And this can easily be fetched with simple statistics of Matt's
> contribution. He is the topmost contributor to all Fuel projects among all
> Fuel Library folks and is the 3rd contributor of Fuel Library.
> He also reviews a lot and has a fair amount of -1's (he is not as
> cruel as me, though :-))
>
> Having that said, I would like to open the vote to promote Matt to
> OpenStack Fuel Library core reviewers.
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.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


>>>
>>>
>>> --
>>> Best Regards,
>>> Egorenko Denis,
>>> Senior Deployment Engineer
>>> Mirantis
>>>
>>> __
>>> 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
>>
> --
> Kind Regards,
> Fedor Zhadaev
>
> skype: zhadaevfm
> IRC: fzhadaev
>
> __
> 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, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46
__
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] solving API case sensitivity issues

[Andrew Laski]

On Wed, Feb 24, 2016, at 07:48 AM, Sean Dague wrote:
> We have a specific bug around aggregrate metadata setting in Nova which
> exposes a larger issue with our mysql schema.
> https://bugs.launchpad.net/nova/+bug/1538011
> 
> On mysql the following will explode with a 500:
> 
> > nova aggregate-create agg1
> > nova aggregate-set-metadata agg1 abc=1
> > nova aggregate-set-metadata agg1 ABC=2
> 
> mysql (by default) treats abc == ABC. However the python code does not.
> 
> We have a couple of options:
> 
> 1) make the API explicitly case fold
> 
> 2) update the mysql DB to use latin_bin collation for these columns
> 
> 3) make this a 400 error because duplicates were found
> 
> 
> Options 1 & 2 make all OpenStack environments consistent regardless of
> backend.
> 
> Option 2 is potentially expensive TABLE alter.
> 
> Option 3 gets rid of the 500 error, however at the risk that the
> behavior for this API is different depending on DB backend. Which is
> less than ideal.
> 
> 
> My preference is slightly towards #1. It's taken a long time for someone
> to report this issue, so I think it's an edge case, and people weren't
> think about this being case sensitive. It has the risk of impacting
> someone on an odd db platform that has been using that feature.

#1 is my preference as well. Nova should be the only consumer of this
metadata and it does not need case sensitivity for this.

> 
> There are going to be a few other APIs to clean up in a similar way. I
> don't think this comes in under a microversion because of how deep in
> the db api layer this is, and it's just not viable to keep both paths.
> 
>   -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 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