[openstack-dev] [new][oslo] taskflow 2.7.0 release (ocata)

[no-reply]

We are gleeful to announce the release of:

taskflow 2.7.0: Taskflow structured state management library.

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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 2.6.0..2.7.0


ce0e962 Changed the home-page link
e680329 Using assertIsNone() instead of assertIs(None, ..)
4877788 Updated from global requirements
a102530 Fix a typo in documentation
86490de Fix typo: remove redundant 'that'
9570bbc Updated from global requirements
554b2fa Fix a typo in logging.py
e34bd5f Use method ensure_tree from oslo.utils
e8b1d58 Make failure formatter configurable for DynamicLoggingListener
74e79a1 Updated from global requirements
e26f09e Some classes not define __ne__() built-in function
b4ab7c4 Add logging around metadata, ignore tallying + history


Diffstat (except docs and test files)
-

requirements.txt  |  2 +-
setup.cfg |  8 +--
taskflow/engines/action_engine/deciders.py| 66 ++-
taskflow/engines/action_engine/runtime.py |  5 ++
taskflow/engines/worker_based/types.py|  3 ++
taskflow/jobs/backends/impl_redis.py  |  3 ++
taskflow/jobs/backends/impl_zookeeper.py  |  3 ++
taskflow/listeners/logging.py | 17 +++---
taskflow/persistence/backends/impl_dir.py |  3 +-
taskflow/storage.py   |  3 ++
taskflow/types/notifier.py|  3 ++
taskflow/utils/misc.py| 19 ---
16 files changed, 87 insertions(+), 59 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 394337a..dbc55ff 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -29 +29 @@ contextlib2>=0.4.0 # PSF License
-stevedore>=1.16.0 # Apache-2.0
+stevedore>=1.17.1 # 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] [new][oslo] oslo.policy 1.16.0 release (ocata)

[no-reply]

We are happy to announce the release of:

oslo.policy 1.16.0: Oslo Policy library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.15.0..1.16.0
-

573c52b Change assertTrue(isinstance()) by optimal assert
a1444fc Perform basic checks on policy definitions
1410296 Enable release notes translation
9bba72c Changed the home-page link
0e691f4 Change assertTrue(isinstance()) by optimal assert


Diffstat (except docs and test files)
-

oslo_policy/policy.py| 71 
releasenotes/source/conf.py  |  3 ++
setup.cfg|  2 +-
5 files changed, 127 insertions(+), 20 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] [new][oslo] futurist 0.19.0 release (ocata)

[no-reply]

We are thrilled to announce the release of:

futurist 0.19.0: Useful additions to futures, from the future.

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

https://pypi.python.org/pypi/futurist

Please report issues through launchpad:

http://bugs.launchpad.net/futurist

For more details, please see below.

Changes in futurist 0.18.0..0.19.0
--

7994eb0 Updated from global requirements
2200490 Updated from global requirements
3b74db5 Update homepage with developer documentation page
4d3d47d Add what the watcher watches to the watcher as a property


Diffstat (except docs and test files)
-

futurist/periodics.py| 112 +--
requirements.txt |   2 +-
setup.cfg|   2 +-
test-requirements.txt|   4 +-
5 files changed, 97 insertions(+), 55 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 3ad5791..effc69c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -10 +10 @@ contextlib2>=0.4.0 # PSF License
-PrettyTable<0.8,>=0.7 # BSD
+PrettyTable<0.8,>=0.7.1 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index b18f71d..631b323 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13,2 +13,2 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.reports 1.15.0 release (ocata)

[no-reply]

We are jubilant to announce the release of:

oslo.reports 1.15.0: oslo.reports library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.14.0..1.15.0
--

f4bc252 Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index a27784d..cc042e8 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9,2 +9,2 @@ oslotest>=1.10.0 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD



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

[openstack-dev] [new][oslo] stevedore 1.18.0 release (ocata)

[no-reply]

We are jazzed to announce the release of:

stevedore 1.18.0: Manage dynamic plugins for Python applications

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.17.1..1.18.0
---

5d633cf Updated from global requirements
c27ce0b Fix typos in exception.py


Diffstat (except docs and test files)
-

stevedore/exception.py | 4 ++--
test-requirements.txt  | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 6b0ae8d..123bda5 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -6 +6 @@ Pillow>=2.4.0 # PIL License
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
@@ -11 +11 @@ oslotest>=1.10.0 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.vmware 2.15.0 release (ocata)

[no-reply]

We are tickled pink to announce the release of:

oslo.vmware 2.15.0: Oslo VMware library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.14.0..2.15.0
-

0eb125a Enable release notes translation
7151383 Updated from global requirements
1709cb5 Updated from global requirements
02ed7f7 Updated from global requirements
a5258aa Updated from global requirements
ae5a215 Update home page link in cfg file
09e3d54 Updated from global requirements
53c7c37 Set pool size for HTTPS connections
4a12a8b Update reno for stable/newton
b32f627 Pass connection timeout so that invoke_api will not wait forever


Diffstat (except docs and test files)
-

oslo_vmware/api.py| 12 +---
oslo_vmware/pbm.py|  7 +--
oslo_vmware/service.py| 17 +
oslo_vmware/vim.py|  7 +--
releasenotes/source/conf.py   |  3 +++
releasenotes/source/index.rst |  1 +
releasenotes/source/newton.rst|  6 ++
requirements.txt  |  6 +++---
setup.cfg |  2 +-
test-requirements.txt |  4 ++--
12 files changed, 75 insertions(+), 25 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 0637801..9634d00 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,2 +7,2 @@ pbr>=1.6 # Apache-2.0
-stevedore>=1.16.0 # Apache-2.0
-netaddr!=0.7.16,>=0.7.12 # BSD
+stevedore>=1.17.1 # Apache-2.0
+netaddr!=0.7.16,>=0.7.13 # BSD
@@ -15 +15 @@ oslo.utils>=3.16.0 # Apache-2.0
-PyYAML>=3.1.0 # MIT
+PyYAML>=3.10.0 # MIT
diff --git a/test-requirements.txt b/test-requirements.txt
index bfa1001..487acf6 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -22,2 +22,2 @@ coverage>=3.6 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD



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

[openstack-dev] [new][oslo] oslo.middleware 3.20.0 release (ocata)

[no-reply]

We are frolicsome to announce the release of:

oslo.middleware 3.20.0: Oslo Middleware library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

3.20.0
^^

Other Notes

* Switch to reno for managing release notes.

Changes in oslo.middleware 3.19.0..3.20.0
-

48ca3bd Limit ssl deprecation warning to external importers
c5de273 Changed the home-page link
beec696 Updated from global requirements
3e5af9f Updated from global requirements
5f7eb04 Updated from global requirements
df01234 make sure we handle the forwarded for headers
e782ca6 Show more healthcheck examples
3b0bd79 Add reno for release notes management
e9c3a23 Deprecated set_latent


Diffstat (except docs and test files)
-

.gitignore|   3 +
oslo_middleware/cors.py   |   4 +
oslo_middleware/healthcheck/__init__.py   | 203 ++--
oslo_middleware/http_proxy_to_wsgi.py |   8 +
oslo_middleware/ssl.py|   5 +-
oslo_middleware/version.py|  18 ++
releasenotes/notes/add_reno-3b4ae0789e9c45b4.yaml |   3 +
releasenotes/source/_static/.placeholder  |   0
releasenotes/source/_templates/.placeholder   |   0
releasenotes/source/conf.py   | 273 ++
releasenotes/source/index.rst |   8 +
releasenotes/source/unreleased.rst|   5 +
requirements.txt  |   4 +-
setup.cfg |   2 +-
test-requirements.txt |   5 +-
tox.ini   |   3 +
18 files changed, 533 insertions(+), 52 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 381e433..db1bfbd 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12,2 +12,2 @@ six>=1.9.0 # MIT
-stevedore>=1.16.0 # Apache-2.0
-WebOb>=1.2.3 # MIT
+stevedore>=1.17.1 # Apache-2.0
+WebOb>=1.6.0 # MIT
diff --git a/test-requirements.txt b/test-requirements.txt
index 5f53419..b241c09 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ mock>=2.0 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+oslosphinx>=4.7.0 # Apache-2.0
@@ -10 +10 @@ oslotest>=1.10.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
@@ -12,0 +13 @@ coverage>=3.6 # Apache-2.0
+reno>=1.8.0 # 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] [new][oslo] oslosphinx 4.8.0 release (ocata)

[no-reply]

We are glowing to announce the release of:

oslosphinx 4.8.0: OpenStack Sphinx Extensions and Theme

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

https://pypi.python.org/pypi/oslosphinx

Please report issues through launchpad:

http://bugs.launchpad.net/oslosphinx

For more details, please see below.

Changes in oslosphinx 4.7.0..4.8.0
--

f57e2e5 Updated from global requirements
030f9ba Update homepage with developer documentation page
c6b55af Support more notice blocks like important, tip and caution
5c765d5 Fixed AttributeError: 'str' object has no attribute 'decode'


Diffstat (except docs and test files)
-

oslosphinx/__init__.py   |  5 ++---
oslosphinx/theme/openstack/static/nature.css | 19 +--
setup.cfg|  2 +-
test-requirements.txt|  2 +-
6 files changed, 54 insertions(+), 7 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 3ee4d7d..00339ac 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ hacking<0.11,>=0.10.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD



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

[openstack-dev] [new][oslo] oslo.versionedobjects 1.18.0 release (ocata)

[no-reply]

We are jubilant to announce the release of:

oslo.versionedobjects 1.18.0: Oslo Versioned Objects library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.17.0..1.18.0
---

0b79285 Changed the home-page link
8dd102e Updated from global requirements
4c4bd65 Changed the home-page link
98b7be2 Updated from global requirements
5b44faf JSON Schema get_schema implementation for last few fields
b9a38b4 Updated from global requirements
f351948 Add ObjectListBase concat methods
f79b434 Fix documentation typo
020dd5d Fix incorrect timestamp comment
7f0edcd Updated from global requirements


Diffstat (except docs and test files)
-

oslo_versionedobjects/_utils.py |   2 +-
oslo_versionedobjects/base.py   |  58 +++
oslo_versionedobjects/fields.py |  60 +++-
requirements.txt|   8 +-
setup.cfg   |   2 +-
test-requirements.txt   |   5 +-
9 files changed, 337 insertions(+), 77 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8e986e4..3cdae51 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ oslo.config>=3.14.0 # Apache-2.0
-oslo.context>=2.6.0 # Apache-2.0
+oslo.context>=2.9.0 # Apache-2.0
@@ -12 +12 @@ iso8601>=0.1.11 # MIT
-oslo.log>=1.14.0 # Apache-2.0
+oslo.log>=3.11.0 # Apache-2.0
@@ -14,2 +14,2 @@ oslo.i18n>=2.1.0 # Apache-2.0
-WebOb>=1.2.3 # MIT
-netaddr!=0.7.16,>=0.7.12 # BSD
+WebOb>=1.6.0 # MIT
+netaddr!=0.7.16,>=0.7.13 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index b30d301..26ef9bc 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8,2 +8,2 @@ testtools>=1.4.0 # MIT
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
@@ -11,0 +12 @@ coverage>=3.6 # Apache-2.0
+jsonschema>=2.0.0,<3.0.0,!=2.5.0  # 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] [new][oslo] oslo.service 1.17.0 release (ocata)

[no-reply]

We are jubilant to announce the release of:

oslo.service 1.17.0: oslo.service library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

1.17.0
^^

Other Notes

* Switch to reno for managing release notes.

Changes in oslo.service 1.16.0..1.17.0
--

93537f2 Changed the home-page link
91fb906 Updated from global requirements
48bebc7 Replace 'MagicMock' with 'Mock'
61b5ef5 Updated from global requirements
da31eee Updated from global requirements
ae4f6fa Updated from global requirements
114041b Stay alive on double SIGHUP
3976008 Add reno for release notes management


Diffstat (except docs and test files)
-

.gitignore|   3 +
oslo_service/service.py   |  22 +-
oslo_service/version.py   |  18 ++
releasenotes/notes/add_reno-3b4ae0789e9c45b4.yaml |   3 +
releasenotes/source/_static/.placeholder  |   0
releasenotes/source/_templates/.placeholder   |   0
releasenotes/source/conf.py   | 274 ++
releasenotes/source/index.rst |   8 +
releasenotes/source/unreleased.rst|   5 +
requirements.txt  |   4 +-
setup.cfg |   2 +-
test-requirements.txt |   5 +-
tox.ini   |   3 +
15 files changed, 376 insertions(+), 15 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 0d7f994..31c80ac 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-WebOb>=1.2.3 # MIT
+WebOb>=1.6.0 # MIT
@@ -12 +12 @@ oslo.config>=3.14.0 # Apache-2.0
-oslo.log>=1.14.0 # Apache-2.0
+oslo.log>=3.11.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index aa6de5e..1291bd4 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11,2 +11,2 @@ oslotest>=1.10.0 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
@@ -13,0 +14 @@ doc8 # Apache-2.0
+reno>=1.8.0 # 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] [new][oslo] oslotest 2.11.0 release (ocata)

[no-reply]

We are jubilant to announce the release of:

oslotest 2.11.0: Oslo test framework

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.10.0..2.11.0
--

f779759 Remove testscenarios from requirements
30b6146 Updated from global requirements
179b18a Updated from global requirements
59a7794 Updated from global requirements


Diffstat (except docs and test files)
-

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


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 7e76ed4..f696c17 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +8,0 @@ testrepository>=0.0.18 # Apache-2.0/BSD
-testscenarios>=0.4 # Apache-2.0/BSD
@@ -13 +12 @@ mox3>=0.7.0 # Apache-2.0
-os-client-config!=1.19.0,!=1.19.1,!=1.20.0,>=1.13.1 # Apache-2.0
+os-client-config!=1.19.0,!=1.19.1,!=1.20.0,!=1.20.1,!=1.21.0,>=1.13.1 # 
Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index b00d5a2..e1740e8 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13,2 +13,2 @@ coverage>=3.6 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.utils 3.17.0 release (ocata)

[no-reply]

We are mirthful to announce the release of:

oslo.utils 3.17.0: Oslo Utility library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.16.0..3.17.0


e4c9a25 Add method is_valid_mac
e988157 Make method import_versioned_module work
31ed2a2 Change assertTrue(isinstance()) by optimal assert
0068712 doc: Fix docstring of method bool_from_string
e38afc1 Change assertTrue(isinstance()) by optimal assert
feb3a1b Add method is_valid_boolstr
e82a560 Add method is_valid_ipv6_cidr
c28347d Updated from global requirements
c95229c Updated from global requirements
676bdb3 Add missing specs_matcher documentation
8345aa0 Update homepage with developer documentation page
32cc400 Updated from global requirements
402a6e6 Updated from global requirements
d1e08f5 Add utils for validating and splitting quotes
06ff3e3 Updated from global requirements
f43d78d Extend specs matcher to support ">" and "<"
c5918ad Remove discover from test-requirements


Diffstat (except docs and test files)
-

oslo_utils/importutils.py  | 22 ++
oslo_utils/netutils.py | 34 +++
oslo_utils/specs_matcher.py|  3 +++
oslo_utils/strutils.py | 42 ++
requirements.txt   |  2 +-
setup.cfg  |  2 +-
test-requirements.txt  |  9 
16 files changed, 256 insertions(+), 20 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index af47d66..94ea957 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -17 +17 @@ pytz>=2013.6 # MIT
-netaddr!=0.7.16,>=0.7.12 # BSD
+netaddr!=0.7.16,>=0.7.13 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index 80a559c..c0c35e1 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +6,0 @@ hacking<0.11,>=0.10.0
-discover # BSD
@@ -21,2 +20,2 @@ coverage>=3.6 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
@@ -28 +27 @@ mock>=2.0 # BSD
-oslo.config>=3.12.0 # Apache-2.0
+oslo.config>=3.14.0 # Apache-2.0
@@ -31 +30 @@ oslo.config>=3.12.0 # Apache-2.0
-bandit>=1.0.1 # Apache-2.0
+bandit>=1.1.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] [new][oslo] oslo.config 3.18.0 release (ocata)

[no-reply]

We are tickled pink to announce the release of:

oslo.config 3.18.0: Oslo Configuration API

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.config 3.17.0..3.18.0
-

8cb3352 Fix wrong usage of DuplicateOptError
a17d135 Enable release notes translation
a8178f5 Updated from global requirements
14aa577 Disable warning for missing oslo.config.opts.defaults
f578e99 Updated from global requirements
236defa Updated from global requirements
0715a15 Add doc about config option name and comment in config file
ae9663a modify the home-page info with the developer documentation
6506d13 Correct nits in Iedf808
214dad4 Updated from global requirements
50cc62d Fix missing option types to config doc
2966f31 Add 'schemes' argument to URIOpt
a45025b Fix repr for tuples in choices
6374819 Add some documentation about option deprecation
539e54e test: add enforce_type test
916fa73 standardize release note page ordering
fcc344d Warn user about enforce_type default change
0dad997 Ensure test_config_dir_doesnt_exist() dir doesn't exist
02dd34d Update reno for stable/newton
b5e745d Add HostnameOpt and URIOpt types to sphinxext
b35606d Add missing exceptions to the documentation
fadf8ee Add IPOpt and PortOpt names for sphinxext
2377612 Updated from global requirements
a3c590e Add Range type


Diffstat (except docs and test files)
-

oslo_config/cfg.py  | 97 +
oslo_config/generator.py|  1 +
oslo_config/sphinxext.py|  4 ++
oslo_config/types.py| 78 ++---
releasenotes/source/conf.py |  3 ++
releasenotes/source/index.rst   |  3 +-
releasenotes/source/newton.rst  |  6 +++
requirements.txt|  6 +--
setup.cfg   |  2 +-
test-requirements.txt   |  4 +-
13 files changed, 298 insertions(+), 30 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 972e955..b8e75e1 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ debtcollector>=1.2.0 # Apache-2.0
-netaddr!=0.7.16,>=0.7.12 # BSD
+netaddr!=0.7.16,>=0.7.13 # BSD
@@ -8 +8 @@ six>=1.9.0 # MIT
-stevedore>=1.16.0 # Apache-2.0
+stevedore>=1.17.1 # Apache-2.0
@@ -10 +10 @@ oslo.i18n>=2.1.0 # Apache-2.0
-rfc3986>=0.2.0 # Apache-2.0
+rfc3986>=0.2.2 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 7c3334a..4795629 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -20,2 +20,2 @@ coverage>=3.6 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.concurrency 3.15.0 release (ocata)

[no-reply]

We are jazzed to announce the release of:

oslo.concurrency 3.15.0: Oslo Concurrency library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.concurrency 3.14.0..3.15.0
--

9f1c2f0 Changed the home-page link
7a4d633 Change assertTrue(isinstance()) by optimal assert
f4f9088 Enable release notes translation
70ff551 Ignore prlimit argument on Windows
5063e92 Updated from global requirements
0ad8246 Updated from global requirements
e27945c Update reno for stable/newton


Diffstat (except docs and test files)
-

oslo_concurrency/processutils.py | 15 ++-
releasenotes/source/conf.py  |  3 +++
releasenotes/source/index.rst|  5 +++--
releasenotes/source/newton.rst   |  6 ++
setup.cfg|  2 +-
test-requirements.txt|  4 ++--
8 files changed, 53 insertions(+), 16 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index e431107..875421c 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12,2 +12,2 @@ fixtures>=3.0.0 # Apache-2.0/BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD



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

[openstack-dev] [new][oslo] oslo.privsep 1.14.0 release (ocata)

[no-reply]

We are frolicsome to announce the release of:

oslo.privsep 1.14.0: OpenStack library for privilege separation

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.privsep 1.13.0..1.14.0
--

9dab411 Enable release notes translation
b5b56db Updated from global requirements
e891746 Updated from global requirements
42e81fd modify the home-page info with the developer documentation
3b53619 Ignore timeout error when receiving message from sockect
af91d7a Update reno for stable/newton
1666d91 Deal with CONF.config_dir correctly
f22a6a1 Report underlying integer for unknown capabilities
21c3007 Add Python 3.5 classifier and venv


Diffstat (except docs and test files)
-

oslo_privsep/comm.py| 11 +++
oslo_privsep/daemon.py  |  2 +-
oslo_privsep/priv_context.py|  3 ++-
releasenotes/source/conf.py |  3 +++
releasenotes/source/index.rst   |  5 +++--
releasenotes/source/newton.rst  |  6 ++
requirements.txt|  2 +-
setup.cfg   |  3 ++-
test-requirements.txt   |  4 ++--
tox.ini |  2 +-
11 files changed, 29 insertions(+), 14 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index eb977e3..bb53246 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-oslo.log>=1.14.0 # Apache-2.0
+oslo.log>=3.11.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index c79d4ef..4bf99a5 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11,2 +11,2 @@ fixtures>=3.0.0 # Apache-2.0/BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD



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

[openstack-dev] [new][oslo] oslo.serialization 2.14.0 release (ocata)

[no-reply]

We are happy to announce the release of:

oslo.serialization 2.14.0: Oslo Serialization library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.13.0..2.14.0


b69beae Add a title to the API Documentation page
e409634 Updated from global requirements
d8aed63 modify the home-page info with the developer documentation


Diffstat (except docs and test files)
-

setup.cfg | 2 +-
test-requirements.txt | 6 +++---
3 files changed, 9 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 0a0d3bf..7fd183e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +7 @@ mock>=2.0 # BSD
-netaddr!=0.7.16,>=0.7.12 # BSD
+netaddr!=0.7.16,>=0.7.13 # BSD
@@ -10,2 +10,2 @@ netaddr!=0.7.16,>=0.7.12 # BSD
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.log 3.17.0 release (ocata)

[no-reply]

We are high-spirited to announce the release of:

oslo.log 3.17.0: oslo.log library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.17.0
^^

Upgrade Notes

* Configuration option *use_stderr*'s default value is False now,
  this will avoid same logs on service log and specific log file by
  option --log-file.

Changes in oslo.log 3.16.0..3.17.0
--

76a1704 Modify use of assertTrue(A in B)
cff5de1 Change assertTrue(isinstance()) by optimal assert
30f2074 Add a json reformatter command
2204e0d Enable release notes translation
e66ddd6 Add support for P and Q release names
adce78c Updated from global requirements
0b9d54c Updated from global requirements
238a14d modify the home-page info with the developer documentation
7d1ef90 Add a filter to rate limit logs
62ba713 Implement FluentFormatter
4506291 Fix races in unit tests
cb39f21 standardize release note page ordering
107241b Use six.wraps instead of functools
d56c3e9 Update reno for stable/newton
ea0b6e9 Updated from global requirements
3fa753d Fix typos
1552647 Default use_stderr to False


Diffstat (except docs and test files)
-

oslo_log/_options.py   |  17 ++-
oslo_log/cmds/__init__.py  |   0
oslo_log/cmds/convert_json.py  | 138 ++
oslo_log/formatters.py |  65 +
oslo_log/log.py|   6 +
oslo_log/rate_limit.py | 157 +
oslo_log/versionutils.py   |  10 +-
.../use_stderr_default_false-50d846b88cf2be90.yaml |   5 +
releasenotes/source/conf.py|   3 +
releasenotes/source/index.rst  |   3 +-
releasenotes/source/newton.rst |   6 +
requirements.txt   |   3 +-
setup.cfg  |   4 +-
test-requirements.txt  |   4 +-
26 files changed, 730 insertions(+), 39 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 7c598d7..3dc12c4 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ oslo.config>=3.14.0 # Apache-2.0
-oslo.context>=2.6.0 # Apache-2.0
+oslo.context>=2.9.0 # Apache-2.0
@@ -14,0 +15 @@ python-dateutil>=2.4.2 # BSD
+monotonic>=0.6 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index d86ad0e..02b0b77 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -20,2 +20,2 @@ coverage>=3.6 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][oslo] tooz 1.44.0 release (ocata)

[no-reply]

We are ecstatic to announce the release of:

tooz 1.44.0: Coordination library for distributed systems.

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.43.0..1.44.0
--

4d48760 Changed the home-page link
d48d8bc file: update .metadata atomically
adbb5bf file: return converted voluptuous data
1ed3c26 file: move _load_and_validate to a method
3bab404 file: move _read_{group,member}_id to staticmethod-s
4f17758 etcd: run tests in clustering mode too
625a54d Use method ensure_tree from oslo.utils
65d8c09 Switch from Python 3.4 to Python 3.5
05c89c0 Install only needed packages
46a1464 Fix a typo in file.py
5ef16e1 Update etcd version in tests


Diffstat (except docs and test files)
-

bindep.txt   |  11 ++
setup-etcd-env.sh|   2 +-
setup.cfg|   6 +--
tooz/drivers/file.py | 106 +--
tooz/utils.py|  16 
tox.ini  |  44 +
6 files changed, 86 insertions(+), 99 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] [new][oslo] oslo.i18n 3.10.0 release (ocata)

[no-reply]

We are glowing to announce the release of:

oslo.i18n 3.10.0: Oslo i18n library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.9.0..3.10.0
--

7f8f771 Updated from global requirements


Diffstat (except docs and test files)
-

test-requirements.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index c372f96..5adf32e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7,2 +7,2 @@ hacking<0.11,>=0.10.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.db 4.14.0 release (ocata)

[no-reply]

We are chuffed to announce the release of:

oslo.db 4.14.0: Oslo Database library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.db 4.13.0..4.14.0
-

21a5c42 standardize release note page ordering
08d5f3b Add a specific exception for 'unknown database' errors
c63f6f8 Enable release notes translation
cc1b05d Updated from global requirements
e79982f Add DBDataError for "Data too long"
2f1944d Updated from global requirements
d798876 Updated from global requirements
b19738a Add additional caution looking for table, info
49eaed4 utils: fix get_unique_keys() when model has no table attached to it
fdf5e45 Update reno for stable/newton
d1c6329 Updated from global requirements
dea700d Correctly detect incomplete sort_keys passed to paginate_query
1f3d509 Fix DBReferenceError and DBNonExistentTable with new PyMySQL version


Diffstat (except docs and test files)
-

oslo_db/exception.py |  12 +++
oslo_db/sqlalchemy/exc_filters.py|  24 -
oslo_db/sqlalchemy/utils.py  |  74 +-
releasenotes/source/conf.py  |   3 +
releasenotes/source/index.rst|   3 +-
releasenotes/source/newton.rst   |   6 ++
requirements.txt |   2 +-
setup.cfg|   8 +-
10 files changed, 346 insertions(+), 51 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index e8dcc28..040e8ce 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -14 +14 @@ sqlalchemy-migrate>=0.9.6 # Apache-2.0
-stevedore>=1.16.0 # Apache-2.0
+stevedore>=1.17.1 # 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] [new][oslo] oslo.messaging 5.11.0 release (ocata)

[no-reply]

We are high-spirited to announce the release of:

oslo.messaging 5.11.0: Oslo Messaging API

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.messaging 5.10.0..5.11.0


4ba1b59 Fix typos in addressing.py and setup.cfg
96b9618 Updated from global requirements
86e779b Record length of queues for ReplyWaiters
c881bae rabbit: Don't prefetch when batch_size is set
bc46e64 [AMQP 1.0] Avoid unnecessary thread switch on ack
c0e941f [zmq] Fix issues with broken messages on proxies
cb3af21 [zmq] Maintain several redis hosts
fa43769 Removed redundant 'the'
ea001a8 Fix a typo in server.py
beb2310 [document] The example which is written in the developer guide of 
'Notification Listener' doesn't work.
7a1694b Enable release notes translation
03ef584 cast() and RPC replies should not block waiting for endpoint to ack
dd8e9fb [simulator] Automatic stopping of rpc-servers
4c67917 Fix whitespace formatting issue
da83001 Properly deserializes built-in exceptions
86f4b80 [zmq] Fix send_cast in AckManager
9775ed3 Remove debug logs from fast path
a5e2a63 [zmq] Routing table refactoring, dynamic direct connections
e491573 Fix simulator bool command line args
d1fe205 Replace 'the' with 'to' in docstring
4b1ac84 Remove default=None when set value in Config
22c93b2 [zmq] Add acks from proxy for PUB/SUB messages
2b47281 [zmq] Refactor consumers and incoming messages
27594bd [zmq] Make second ROUTER socket optional for proxy
ae365cb Use method fetch_current_thread_functor from oslo.utils
fc093c3 [zmq] Fix ZmqSocket.send_string
f3ea04c [zmq] Remove unused methods from executors
64c5e50 [zmq] Added a processing to handle ImportError in Redis plugin of 
Matchmaker
4e38293 modify the home-page info with the developer documentation
e9e1645 Set the valid choices for the rabbit login methods
b3cb65a [zmq] Unify delimeters
c3df59e [zmq] Fix fanout without PUB/SUB
a9814d4 [zmq] Send immediate ack after message receiving
afaa4d9 Corrects documentation typo
eaf433b [zmq] Remove unnecessary subscriptions from SubConsumer
9bc9c0d Fixups to the inline documentation
3f4ce94 Fix consuming from unbound reply queue
9bd4bbe Add configurable serialization to pika
16ce974 [zmq] Remove ZmqSocket.close_linger attribute
b5c82e9 [zmq] Make ZMQ TCP keepalive options configurable
09816f0 [zmq] Fix TestZmqAckManager periodic failure
3aa5982 [zmq] Make ThreadingPoller work with ZmqSocket
3cdfe15 Fix notify filter when data item is None
c2e5645 [zmq] Rename rpc_cast_timeout option
c5d142b [AMQP 1.0] Update setup test environment dispatch router backend
d3a8f28 Allow dispatcher to restrict endpoint methods.
e451a9e [AMQP 1.0] Add Acknowledgement and Batch Notification Topics
e4f22c9 Update reno for stable/newton
204dfa7 [kafka] invoke TypeError exception when 'listen()' method of 
KafkaDriver is called
6866948 [zmq] Proxy has to skip broken multi-part message
799bd0e Add Documentation String for PikaDriver
fab75e7 [zmq] Implement retries for unacknowledged CALLs
6c973da [AMQP 1.0] Make the default settlement behavior configurable
777f520 [zmq] Eliminate GreenPool from GreenPoller
88003cb Avoid sending cast after server shutdown in functional test
6881d14 [zmq] Update ZMQ-driver documentation
e5785f6 [zmq] Add --log-file option to zmq-proxy


Diffstat (except docs and test files)
-

oslo_messaging/_cmd/zmq_proxy.py   |  73 +
oslo_messaging/_drivers/amqp1_driver/addressing.py |   2 +-
oslo_messaging/_drivers/amqp1_driver/controller.py | 108 +++
oslo_messaging/_drivers/amqp1_driver/opts.py   |  18 +-
oslo_messaging/_drivers/amqpdriver.py  |  19 +-
oslo_messaging/_drivers/common.py  |   8 +
oslo_messaging/_drivers/impl_amqp1.py  |  40 +--
oslo_messaging/_drivers/impl_kafka.py  |   2 +-
oslo_messaging/_drivers/impl_pika.py   |  17 +
oslo_messaging/_drivers/impl_rabbit.py |  78 ++---
oslo_messaging/_drivers/impl_zmq.py|  13 +-
.../_drivers/pika_driver/pika_commons.py   |   7 +
oslo_messaging/_drivers/pika_driver/pika_engine.py |   4 +
.../_drivers/pika_driver/pika_message.py   |  49 ++-
.../publishers/dealer/zmq_dealer_publisher_base.py |  64 +---
.../dealer/zmq_dealer_publisher_direct.py  |  63 +++-
.../dealer/zmq_dealer_publisher_proxy.py   |  98 --
.../client/publishers/zmq_publisher_base.py|  59 ++--
.../_drivers/zmq_driver/client/zmq_ack_manager.py  |  93 +++---
.../_drivers/zmq_driver/client/zmq_client.py   |  42 +--
.../_drivers/zmq_driver/client/zmq_client_base.py  |  36 ++-

[openstack-dev] [new][oslo] debtcollector 1.9.0 release (ocata)

[no-reply]

We are grateful to announce the release of:

debtcollector 1.9.0: A collection of Python deprecation patterns and
strategies that help you collect your technical debt in a non-
destructive manner.

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

https://pypi.python.org/pypi/debtcollector

Please report issues through launchpad:

http://bugs.launchpad.net/debtcollector

For more details, please see below.

Changes in debtcollector 1.8.0..1.9.0
-

a44b260 Updated from global requirements
8e1e6e0 Update homepage with developer documentation page
25c3601 Fix a typo in comment


Diffstat (except docs and test files)
-

debtcollector/_utils.py | 2 +-
setup.cfg   | 2 +-
test-requirements.txt   | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 0c903ff..6d0d68e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9,2 +9,2 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0



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

[openstack-dev] [new][oslo] oslo.cache 1.15.0 release (ocata)

[no-reply]

We are frolicsome to announce the release of:

oslo.cache 1.15.0: Cache storage for OpenStack projects.

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.14.0..1.15.0


de45f6d Enable release notes translation
4f9a6df Updated from global requirements
1505b23 Updated from global requirements
7614790 Update reno for stable/newton
8f3b227 Updated from global requirements
92a979b Add usage example to documentation
f29cb97 Fix docstring for get_memoization_decorator


Diffstat (except docs and test files)
-

oslo_cache/core.py |  6 +++---
releasenotes/source/conf.py|  3 +++
releasenotes/source/index.rst  |  5 +++--
releasenotes/source/newton.rst |  6 ++
requirements.txt   |  4 ++--
test-requirements.txt  |  4 ++--
7 files changed, 63 insertions(+), 11 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 49915bf..66fbae4 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-dogpile.cache>=0.6.1 # BSD
+dogpile.cache>=0.6.2 # BSD
@@ -9 +9 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.log>=1.14.0 # Apache-2.0
+oslo.log>=3.11.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 0510e84..836099e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7,2 +7,2 @@ oslotest>=1.10.0 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD



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

[openstack-dev] [new][oslo] oslo.rootwrap 5.2.0 release (ocata)

[no-reply]

We are glowing to announce the release of:

oslo.rootwrap 5.2.0: Oslo Rootwrap

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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

Please report issues through launchpad:

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

For more details, please see below.

5.2.0
^

Other Notes

* Switch to reno for managing release notes.

Changes in oslo.rootwrap 5.1.0..5.2.0
-

e93f837 Update homepage with developer documentation page
04e2cd0 Enhance _program() and _program_path()
5d96b86 Remove discover from test-requirements
1c110e0 Add reno for release notes management


Diffstat (except docs and test files)
-

.gitignore|   3 +
oslo_rootwrap/filters.py  |  59 +++--
oslo_rootwrap/version.py  |  18 ++
releasenotes/notes/add_reno-3b4ae0789e9c45b4.yaml |   3 +
releasenotes/source/_static/.placeholder  |   0
releasenotes/source/_templates/.placeholder   |   0
releasenotes/source/conf.py   | 274 ++
releasenotes/source/index.rst |   8 +
releasenotes/source/unreleased.rst|   5 +
setup.cfg |   2 +-
test-requirements.txt |   3 +-
tox.ini   |   3 +
13 files changed, 381 insertions(+), 42 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 65bf3d1..aee933f 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +6,0 @@ hacking<0.11,>=0.10.0
-discover # BSD
@@ -24,0 +24,2 @@ eventlet!=0.18.3,>=0.18.2 # MIT
+
+reno>=1.8.0 # 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] [new][oslo] oslo.context 2.10.0 release (ocata)

[no-reply]

We are glowing to announce the release of:

oslo.context 2.10.0: Oslo Context library

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

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.9.0..2.10.0
-

b60ab0f Enable release notes translation
91986c6 Updated from global requirements
66e8740 Update reno for stable/newton
1bccf39 Fix typos


Diffstat (except docs and test files)
-

releasenotes/source/conf.py| 3 +++
releasenotes/source/index.rst  | 1 +
releasenotes/source/newton.rst | 6 ++
requirements.txt   | 2 +-
test-requirements.txt  | 4 ++--
7 files changed, 16 insertions(+), 6 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 99569a8..96f90b5 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ pbr>=1.6 # Apache-2.0
-positional>=1.0.1 # Apache-2.0
+positional>=1.1.1 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 830e499..f670605 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11,2 +11,2 @@ coverage>=3.6 # Apache-2.0
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD



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

[openstack-dev] [new][oslo] automaton 1.5.0 release (ocata)

[no-reply]

We are jubilant to announce the release of:

automaton 1.5.0: Friendly state machines for python.

This release is part of the ocata release series.

The source is available from:

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

Download the package from:

https://pypi.python.org/pypi/automaton

Please report issues through launchpad:

http://bugs.launchpad.net/automaton

For more details, please see below.

Changes in automaton 1.4.0..1.5.0
-

be2885f Changed the home-page link
32bc446 Updated from global requirements
a555fff Updated from global requirements


Diffstat (except docs and test files)
-

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


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 0386a6d..4c4d91e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -15 +15 @@ debtcollector>=1.2.0 # Apache-2.0
-PrettyTable<0.8,>=0.7 # BSD
+PrettyTable<0.8,>=0.7.1 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index 958c5dd..52c8528 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10,2 +10,2 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
-sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
+sphinx!=1.3b1,<1.4,>=1.2.1 # BSD
+oslosphinx>=4.7.0 # Apache-2.0



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

Re: [openstack-dev] [Horizon] Meeting this week cancelled

[Richard Jones]

Oh, and the meeting next week (26th) will also not happen due to the summit.


 Richard

On 19 October 2016 at 14:22, Richard Jones  wrote:

> Hi folks,
>
> With the summit almost upon us, and no agenda items or significant
> notices, I'm cancelling this week's team meeting (was scheduled for
> 2016/10/19 20:00UTC).
>
>
> Cheers,
>
>  Richard
>
>
__
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] [nova] Deprecate VMware CI that uses nova-network

[Sihan Wang]

Hi,

We have added Nova upstream CI to use NSX, currently it is non-voting. After we 
test its stability, we will replace the novanet one.

Thanks

Sihan
__
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] [senlin]Cancelling weekly IRC meeting for Oct. 25th

[Yanyan Hu]

Hi, guys, the Senlin IRC meeting on Oct. 25th will be cancelled for
majority of the team will be in travel next week for Barcelona summit.
Thanks and have a good trip.

-- 
Best regards,

Yanyan
__
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] [devstack][CI] Etcd server setuped in devstack script can not be reached in CI unit tests

[Clark Boylan]

On Tue, Oct 18, 2016, at 07:08 PM, Wenzhi Yu (yuywz) wrote:
> Hi all,
> 
> I intended to use etcd as data store for Zun project. So I installed
> docker and started a docker container with an etcd server running in it
> using
> devstack script.  The etcd server listens on 127.0.0.1:2379 for client
> requests. And per CI log [1] the container had been started successfully
> and
> functioned well (I added some test code and etcd server is available on
> 127.0.0.1:2379).
> 
> But during the execution of unit test cases, the connection to
> 127.0.0.1:2379 became inavailable [2], all the cases tried to connect to
> etcd server
> failed. I did some investigation and found that the test cases were
> running in an isolated network environment (maybe within an container?).
> So the etcd server can not be reached via 127.0.0.1:2379 during test run.
> 
> I intended to configure etcd server to listen on an IP address which can
> be reached from the test envrionment, but I realized that even if I did
> that,
> it's not easy to query that IP address in test cases. An alternative
> method is to forward the request sent to 127.0.0.1:2379 of test
> environment to
> corresponding socket of the environment inwhich the etcd container is
> running.
> 
> Now I have no idea how to deal with this issue, please help me out!
> Thanks in advance!
> 
> [1]http://paste.openstack.org/show/586299/
> [2]http://paste.openstack.org/show/586310/

It looks like this is the change [3] in question. I think the problem is
that the unittests expect to run alongside devstack but this is not the
case. Unittests, linting, doc builds, and so on are run on fairly
barebone instances. The process to run these jobs is to fetch the
correct git ref, install any system deps using bindep, then run tox.
More information on how this works can be found at [4].

Etcd is in universe on Ubuntu Xenial so you should be able to add it to
your bindep list and get it for the python2.7 and python3.5 unittest
jobs. Or you can do this testing in your devstack job.

[3] https://review.openstack.org/#/c/364855/28
[4] https://governance.openstack.org/reference/cti/python_cti.html

Clark

__
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][VMT][Security] Glance coresec reorg

[Hemanth Makkapati]

+1 to both Erno and Ian.
Both have made solid contributions to Glance over the past few cycles and are 
very thorough in their approach.
I believe both of them will be great additions to the Glance coresec group.

-Hemanth

From: Brian Rosmaita 
Sent: Tuesday, October 18, 2016 5:22:28 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

Hello everyone,

First, I'd like to thank Flavio Percoco and Kairat Kushaev for their past
service as members of the Glance core security contacts team.
Unfortunately, due to other commitments, they don't have time to continue
on coresec.

Thus, the main point of this email is to propose Ian Cordasco and Erno
Kuvaja as new members of the Glance coresec team.  They've both been
Glance cores for several cycles, have a broad knowledge of the software
and team, contribute high-quality reviews, and are conversant with good
security practices.

Replacing Flavio and Kairat with Ian and Erno will keep the Glance coresec
team at 5 members.

Please cast your vote with +1, 0, or -1, or you can reply back to me.

Please reply before 23:59 UTC on Wednesday, October 26, 2016.

Thank you,
brian



__
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][networking-vpp]Introducing networking-vpp

[Ian Wells]

On 6 October 2016 at 10:43, Jay Pipes  wrote:

> On 10/06/2016 11:58 AM, Naveen Joy (najoy) wrote:
>
>> It’s primarliy because we have seen better stability and scalability
>> with etcd over rabbitmq.
>>
>
> Well, that's kind of comparing apples to oranges. :)
>
> One is a distributed k/v store. The other is a message queue broker.
>
> The way that we (IMHO) over-use the peer-to-peer RPC communication
> paradigm in Nova and Neutron has resulted in a number of design choices and
> awkward code in places like oslo.messaging because of the use of
> broker-based message queue systems as the underlying transport mechanism.
> It's not that RabbitMQ or AMQP isn't scalable or reliable. It's that we're
> using it in ways that don't necessarily fit well.
>
> One might argue that in using etcd and etcd watches in the way you are in
> networking-vpp, that you are essentially using those tools to create a
> simplified pub-sub messaging system and that isn't really what etcd was
> built for and you will end up running into similar fitness issues
> long-term. But, who knows? It might end up being a genius implementation. :)
>
> I'm happy to see innovation flourish here and encourage new designs and
> strategies. Let's just make sure we compare apples to apples when making
> statements about performance or reliability.
>

Sorry to waken an old thread, but I chose a perfect moment to go on
holiday...

So yes: I don't entirely trust the way we use RabbitMQ, and that's largely
because what we're doing with it - distributing state, or copies of state,
or information derived from state - leads to some fragility and odd
situations when using a tool perhaps better suited to listing off tasks.
We've tried to find a different model of working that is closer to the
behaviour we're after.  It is, I believe, similar to the Calico team's
thinking, but not derived from their code.  I have to admit at this point
that it's not been tested at scale in our use of it, and that's something
we will be doing, but I can say that this is working in a way that is in
line with how etcd is intended to be used, we have tested representative
etcd performance, and we don't expect problems.

As mentioned before, Neutron's SQL database is the source of truth - you
need to have one, and that one represents what the client asked for in its
purest form.  In the nature of keeping two datastores in sync, there is a
worker thread outside of the REST call to do the synchronisation (because
we don't want the cloud user to be waiting on our internal workings, and
because consistently committing to two databases is a recipe for disaster)
- etcd lags the Neutron DB commits very slightly, and the Neutron DB is
always right.  This allows the API to be quick while the backend will run
as efficiently as possible.

It does also mean that failures to communicate in the backend don't result
in failed API calls - the call succeeds but state updates don't happen.
This is in line with a 'desired state' model.  A user tells Neutron what
they want to do and Neutron should generally accept the request if it's
well formatted and consistent.  Exceptional error codes like 500s are
annoying to deal with, as you never know if that means 'I failed to save
that' or 'I failed to implement that' or 'I saved and implemented that, but
didn't quite get the answer to you' - having simple frontend code ensures
the answer is highly likely to be 'I will do that it in a moment', in
keeping with with the eventually consistent model OpenStack has.  The
driver will then work its magic and update object states when the work is
finally complete.

Watching changes - and the pub-sub model you end up with - is a means of
being efficient, but should we miss notifications there's a fallback
mechanism to get back into state sync with the most recent version of the
state.  In the worst case, we focus on the currently desired state, and not
the backlog of recent changes to state.

And Jay, you're right.  What we should be comparing here is how well it
works.  Is it easy to use, is it easy to maintain, is it annoyingly
fragile, and does it eat network or CPU?  I believe so (or I wouldn't have
chosen to do it this way), and I hope we've produced something simple to
understand while being easier to operate.  However, the proof of the
pudding is in the eating, so let's see how this works as we continue to
develop and test it.
-- 
Ian.
__
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] [fwaas] Weekly meeting cancelled on Oct 25th due to the Summit.

[Sridar Kandaswamy (skandasw)]

Hi All:

We will cancel the FWaaS meeting next week due to the summit and resume the 
week after on Nov 1 as usual.

Thanks and Safe travels.

Sridar
__
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] [Horizon] Meeting this week cancelled

[Richard Jones]

Hi folks,

With the summit almost upon us, and no agenda items or significant notices,
I'm cancelling this week's team meeting (was scheduled for 2016/10/19
20:00UTC).


Cheers,

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

Re: [openstack-dev] [release][ansible][fuel][kolla][puppet][tripleo] proposed deadlines for cycle-trailing projects

[Steven Dake (stdake)]

Doug,

Kolla rc3 is available in the queue by the hard deadline (more or less).  I 
have a quick Q - would I need to submit another 3.0.0 patch with the same git 
commit id, or does the release team do that automatically?

Regards
-steve





On 10/7/16, 12:16 PM, "Doug Hellmann"  wrote:

>This week we tagged the final releases for projects using the
>cycle-with-milestones release model. Projects using the cycle-trailing
>model have two more weeks before their final release tags are due. In
>the time between now and then, we expect those projects to be preparing
>and tagging release candidates.
>
>Just as with the milestone-based projects, we want to manage the number,
>frequency, and timing of release candidates for cycle-trailing projects.
>With that in mind, I would like to propose the following rough timeline
>(my apologies for not preparing this sooner):
>
>10 Oct -- All cycle-trailing projects tag at least their first RC.
>13 Oct -- Soft deadline for cycle-trailing projects to tag a final RC.
>18 Oct -- Hard deadline for cycle-trailing projects to tag a final RC.
>20 Oct -- Re-tag the final RCs as a final release.
>
>Between the first and later release candidates, any translations and
>bug fixes should be merged.
>
>We want to leave a few days between the last release candidate and
>the final release so that downstream consumers of the projects can
>report issues against stable artifacts. Given the nature of most
>of our trailing projects, and the lateness of starting to discuss
>these deadlines, I don't think we need the same amount of time as
>we usually set aside for the milestone-based projects. Based on
>that assumption, I've proposed a 1 week soft goal and a 2 day hard
>deadline.
>
>Let me know what you think,
>Doug
>
>Newton schedule: https://releases.openstack.org/newton/schedule.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
__
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] [nova][oslo][openstack-ansible] DB deadlocks, Mitaka, and You

[Carter, Kevin]

Hello all,

As some folks may know the OSIC cloud1 just upgraded to Mitaka last
week (I know what's old is new again, sorry). Since the upgrade things
have been running fairly smoothly however there's been one issue that
has left me scratching my head. When attempting a scale out test we've
run into issues where the nova client was returning a message
indicating it had encountered a DB deadlock [0]. In attempting to gain
more information we enabled debug logging and collected the following
[1] (Here is a pretty version for the tracebacks [4]). This is the
command we're using to build all of the VMs [2] which was being used
to build 3 vms per compute node for 242 compute nodes. Once the
instances are all online we grab the nodes IPv6 address and ensure
we're able to SSH to them. While we're happy to report that almost all
of the VMs came online in one shot we did run into a few of these DB
dead lock messages and would like to see if folks out on the interwebs
have seen or experienced such problems. If so we'd love to know if
there's some remediation that we can use to make this all even
happier. It should be noted that this is not a Major issue at this
point, 3 out of 726 VMs didn't come online due to the problem but it
would be amazing if there was something we could do to generally
resolve this.

Other potentially interesting things:
  * DB is MariaDB "mariadb-galera-server-10.0". The replication system
is using xtrabackup from percona with version "2.3.5-1.trusty".
  * The DB is a 3 node cluster however the connection to the cluster
is using a VIP on our loadbalancer and the services are only ever
connected to 1 of the three nodes; this is for both reads and writes.
Should a node become un-happy the load balancer promotes and demotes
always ensuring only 1 node is being connected to.
  * While reproducing this issue repeatedly we've watched wsrep to see
if nodes we're dropping or otherwise having a bad day. To our dismay
there were no un-happy nodes and the wsrep state seemed to remain
OPERATIONAL with minimal latency (Example [3]).
  * For all of the OpenStack Services we use pymsql as it's DB driver
we were using mysql-python but I believe OpenStack-Ansible switched in
kilo due to DB deadlock issues we were experiencing.
  * Cloud1 is running nova at commit
"dd30603f91e6fd3d1a4db452f20a51ba8820e1f4" which was the HEAD of
"stable/mitaka" on 29-09-2016. This code is in production today with
absolutely no modifications.

Any insight would be greatly appreciated. Thanks again everyone!

[0] http://paste.openstack.org/show/586302/
[1] http://paste.openstack.org/show/586309/
[2] http://paste.openstack.org/show/586298/
[3] http://paste.openstack.org/show/586306/
[4] http://paste.openstack.org/show/586307/

__
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] [requirements][lbaas] gunicorn to g-r

[Tony Breeds]

On Mon, Oct 17, 2016 at 08:12:45PM -0600, Doug Wiegley wrote:

> Right, so, we’re dancing around the common problem in openstack lately: what
> the heck is openstack?

Sorry to get here so late.

> This came up because service VMs/data plane implementations, which this is,
> have different requirements than API services. Paths forward:
> 
> 1. Add gunicorn to global requirements.

I'd rather avoid this.  Other have done a great job explaining the runtime vs
deploy dependencies.

> 2. Create a project specific “amphora-requirements.txt” file for the service
> VM packages (this is actually my preference.) It has been pointed out that
> this wouldn’t be kept up-to-date by the bot. We could modify the bot to
> include it in some way, or do it manually, or with a project specific job.
>
> 3. Split our service VM builds into another repo, to keep a clean separation
> between API services and the backend.  But, even this new repo’s standlone
> requirements.txt file will have the g-r issue from #1.

Actually Options 2 and 3 are functionally the same (from my POV).  We'd need a
specific job to update your *requirements.txt files.  I feel like a separate
repo is slightly neater but it has the most impact on the Octavia team.

So I'd suggest you go with one of 2 or 3 and we can work together to make the
tools work with you.

> 4. Boot the backend out of OpenStack entirely.

:(  I really hope this was a joke suggestion.  If it isn't then we have some
problems in our community / tools :(

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

[openstack-dev] [devstack][CI] Etcd server setuped in devstack script can not be reached in CI unit tests

[Wenzhi Yu (yuywz)]

Hi all,

I intended to use etcd as data store for Zun project. So I installed docker and 
started a docker container with an etcd server running in it using
devstack script.  The etcd server listens on 127.0.0.1:2379 for client 
requests. And per CI log [1] the container had been started successfully and
functioned well (I added some test code and etcd server is available on 
127.0.0.1:2379).

But during the execution of unit test cases, the connection to 127.0.0.1:2379 
became inavailable [2], all the cases tried to connect to etcd server
failed. I did some investigation and found that the test cases were running in 
an isolated network environment (maybe within an container?).
So the etcd server can not be reached via 127.0.0.1:2379 during test run.

I intended to configure etcd server to listen on an IP address which can be 
reached from the test envrionment, but I realized that even if I did that,
it's not easy to query that IP address in test cases. An alternative method is 
to forward the request sent to 127.0.0.1:2379 of test environment to
corresponding socket of the environment inwhich the etcd container is running.

Now I have no idea how to deal with this issue, please help me out! Thanks in 
advance!

[1]http://paste.openstack.org/show/586299/
[2]http://paste.openstack.org/show/586310/
2016-10-19



Best Regards,
Wenzhi Yu (yuywz)__
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] Event notification descriptors/schemas (? swagger ?)

[Ruby Loo]

On Fri, Oct 14, 2016 at 7:14 PM, Joshua Harlow 
wrote:

>
>> This is exactly what we are planning to do.  Work is ongoing to add
>> to_json_schema
>> support for every VersionedObject field [1]. Then we would like to add a
>> small
>> tool to nova that makes it possible to generate the json schemas for the
>> versioned
>> notifications [2]. Meanwhile we continue to transform legacy
>> notifications to a versioned
>> format [3].
>>
>> As soon as you have json schema you can find (or create) tools that
>> generate an object
>> model and a parser from the json schema of the notifications in any
>> modern language.
>>
>> I hope this work in nova will servers as an example for other OpenStack
>> project and
>> in the end OpenStack will have well defined and easy to consume
>> notifications.
>>
>> Any feedback on our plans are highly appreciated.
>>
>> Cheers,
>> gibi
>>
>> [1] https://review.openstack.org/#/q/topic:bp/json-schema-for-ve
>> rsioned-object,n,z
>> [2] https://blueprints.launchpad.net/nova/+spec/json-schema-for-
>> versioned-notifications
>> [3] https://vntburndown-gibi.rhcloud.com/index.html
>>
>>
> Great! :)
>
> Any thoughts on the ideas/burndown for the other projects that emit events
> (aka, going and doing similar changes, is there a list of other projects
> that need to have changes, ie glance, neutron, keystone (I think))?
>
> -Josh
>
>
ironic just added notifications (like, the first notifications went in this
week). ironic believes in re-use and that there are smart people in
OpenStack, so it is mostly based on nova's work :) I don't have any other
thoughts on the matter at the moment...

--ruby
(note, these are my opinions, not the ironic community's :))
__
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] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[TommyLike Hu]

Thanks for your explicit explanations，I even misunderstand(maybe
superficial understand) the intentions of the random IP when I set up this
thread :)

Ihar Hrachyshka 于2016年10月19日周三 上午12:05写道：

> (To clarify for those not part of the neutron dev team, ‘fullstack’ in
> neutron gate is not devstack/tempest, and does not involve other openstack
> services, or multiple nodes.)
>
> No, we don’t dump a seed. I don’t think I saw a ‘fullstack’ failure that
> required an exact environment duplication to reproduce a test failure.
>
> For neutron ‘fullstack’ tests, we run complete neutron services, and
> collect all their logs, per test scenario. Basically, every ‘fullstack’
> test case is a tiny openstack setup with just neutron services running,
> using some common resources like amqp bus, or ovs bridge emulating physical
> infrastructure. As long as service logs are sufficient to debug failures,
> it doesn’t differ much from any other failure in neutron f.e. in tempest.
>
> It’s common for neutron to allocate a ‘random’ address from a subnet
> allocation pool for its network and instance ports, in which case we need
> to trace port-ids and whatnot to link related server/agent/tempest logs.
> (If you ask me why we randomize ip address allocation in neutron IPAM code,
> that’s actually for a reason, to reduce database contention when allocating
> addresses for parallel port requests).
>
> Ihar
>
> __
> 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] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting today. The meeting is being held Wednesday
UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Isaku Yamahata]

+1
Thanks for organizing this.

On Fri, Oct 14, 2016 at 01:30:57PM -0500,
Miguel Lavalle  wrote:

> Dear Neutrinos,
> 
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is
> here: http://www.racodelavila.com/en/carta-racodelavila.htm
> 
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get
> a final count.
> 
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> 
> Cheers
> 
> Miguel

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


-- 
Isaku Yamahata 

__
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][VMT][Security] Glance coresec reorg

[Charles Neill]

+1 for Ian, I think he'd be a great addition.

Charles Neill

From: Travis McPeak >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, October 18, 2016 at 17:26
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

+1 for Ian.  He has great security knowledge and will be an awesome asset for 
any security team.

On Tue, Oct 18, 2016, 3:24 PM Brian Rosmaita 
> wrote:
Hello everyone,

First, I'd like to thank Flavio Percoco and Kairat Kushaev for their past
service as members of the Glance core security contacts team.
Unfortunately, due to other commitments, they don't have time to continue
on coresec.

Thus, the main point of this email is to propose Ian Cordasco and Erno
Kuvaja as new members of the Glance coresec team.  They've both been
Glance cores for several cycles, have a broad knowledge of the software
and team, contribute high-quality reviews, and are conversant with good
security practices.

Replacing Flavio and Kairat with Ian and Erno will keep the Glance coresec
team at 5 members.

Please cast your vote with +1, 0, or -1, or you can reply back to me.

Please reply before 23:59 UTC on Wednesday, October 26, 2016.

Thank you,
brian



__
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] [glance][VMT][Security] Glance coresec reorg

[Travis McPeak]

+1 for Ian.  He has great security knowledge and will be an awesome asset
for any security team.

On Tue, Oct 18, 2016, 3:24 PM Brian Rosmaita 
wrote:

> Hello everyone,
>
> First, I'd like to thank Flavio Percoco and Kairat Kushaev for their past
> service as members of the Glance core security contacts team.
> Unfortunately, due to other commitments, they don't have time to continue
> on coresec.
>
> Thus, the main point of this email is to propose Ian Cordasco and Erno
> Kuvaja as new members of the Glance coresec team.  They've both been
> Glance cores for several cycles, have a broad knowledge of the software
> and team, contribute high-quality reviews, and are conversant with good
> security practices.
>
> Replacing Flavio and Kairat with Ian and Erno will keep the Glance coresec
> team at 5 members.
>
> Please cast your vote with +1, 0, or -1, or you can reply back to me.
>
> Please reply before 23:59 UTC on Wednesday, October 26, 2016.
>
> Thank you,
> brian
>
>
>
> __
> 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] [glance][VMT][Security] Glance coresec reorg

[Brian Rosmaita]

Hello everyone,

First, I'd like to thank Flavio Percoco and Kairat Kushaev for their past
service as members of the Glance core security contacts team.
Unfortunately, due to other commitments, they don't have time to continue
on coresec.

Thus, the main point of this email is to propose Ian Cordasco and Erno
Kuvaja as new members of the Glance coresec team.  They've both been
Glance cores for several cycles, have a broad knowledge of the software
and team, contribute high-quality reviews, and are conversant with good
security practices.

Replacing Flavio and Kairat with Ian and Erno will keep the Glance coresec
team at 5 members.

Please cast your vote with +1, 0, or -1, or you can reply back to me.

Please reply before 23:59 UTC on Wednesday, October 26, 2016.

Thank you,
brian



__
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] [osc] bug/design flaw: Clients not cached per region

[Adrian Turjak]

In response to Jamie's comment I've abandoned my patch in favor of this one:

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

It simply removes the ClientCache from the openstackclient code and
replaces it with property().


On 18/10/16 17:10, Adrian Turjak wrote:
>
> On 18/10/16 15:52, Jamie Lennox wrote:
>>
>> A comment from the cheap seats, almost all clients are using a
>> keystoneauth1 session at this point and that's where your
>> authentication information is being cached. There is essentially no
>> cost to creating a client with an existing session as auth happens on
>> demand.
>>
>> The region_name is not part of the authentication request, it's used
>> to lookup the endpoint and so is passed to Client creation.
>>
>> Given this maybe there is no longer any value in a ClientCache? It
>> was mostly useful to prevent clients doing dumb and share auth
>> amongst them. So long as the session/auth is created and saved once,
>> a client can be created per use/request with this information
>> (including region) with no real performance impact.
>>
>> Jamie
>>
> Getting rid of the cache would solve my problem, and considering it's
> all one shared session it shouldn't cause any problems.
>
> Updating region_name would still be a problem for interactive mode,
> although really that is a problem that is present right now anyway.
>
>
> __
> 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] [tripleo] Summit schedule / Final draft

[Emilien Macchi]

Greetings,

This is a final draft of TripleO summit sessions. Please let me know
any feedback or schedule conflict before end of week so maybe we can
still arrange things.

https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=TripleO%3A

TripleO: Containers - Current Status and Roadmap
Wed 26  3:55pm-4:35pm

TripleO: Work Session - Growing the team
Wed 26  5:05pm-5:45pm

TripleO: Work Session - CI - current status and roadmap
Wed 26  5:55pm-6:35pm

TripleO: Upgrades - current status and roadmap
Thu 27  1:50pm-2:30pm

TripleO: Work Session - Composable Undercloud deployment with Heat
Fri 28  9:00am-9:20am

TripleO: Work Session - GUI, CLI, Validations current status, roadmap,
requirements
Fri 28  9:20am-9:40am

TripleO: Work Session - Multiple topics
Fri 28  9:50am-10:30am
Blueprints, specs, tools and Ocata summary.


See you next week, safe travel everyone!
-- 
Emilien Macchi

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

[openstack-dev] [puppet] Summit scheduling

[Emilien Macchi]

Hi,

This time we won't have much topics to discuss but still have 2
working sessions. See schedule:
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Puppet+OpenStack%3A+Work+session

Contributors and non-contributors are welcome to come and work together.
It can be a great time to make bug triage, do pair-reviews, work on
some topics or just talk :-)

Your feedback is important. If you're an user, come say Hi and tell us
how we could improve ourselves.
If you want to start contributing, come by and we'll discuss how we
can make that friendly.

We have some topics on the etherpad:
https://etherpad.openstack.org/p/ocata-puppet

Feel free add more!
I'm looking forward to meeting you there,
-- 
Emilien Macchi

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

[openstack-dev] OpenStack upstream specs - Invitation to edit

[James Penick (via Google Docs)]

I've shared an item with you:

OpenStack upstream specs
https://docs.google.com/document/d/1oZzTLFBASwSydy2NNUXJlBA1nRNB-qvoJF_H49utNc4/edit?usp=sharing=CJOpnqIJ=58069599

It's not an attachment -- it's stored online. To open this item, just click  
the link above.
__
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] [cloudkitty] Proposing Pierre-Alexandre Bardina (pabardina) as core for cloudkitty

[Christophe Sauthier]

Le 2016-10-18 17:30, Shake Chen a écrit :
Thanks for your reply. Hope the Cloudkitty core review team can more 
active


https://review.openstack.org/#/q/project:openstack/cloudkitty+status:open 
[7]

First of all you are more than welcome to come and participate ;)
Meanwhile you can be sure that the queue you are pointing here has been 
really improved for the last few months...As you noticed we are a very 
small team (so far) so it is complicated to have a strong workflow all 
the time...
We are also in the process of waiting some debate during the summit 
about some features/blueprints...


All the best

Christophe


Christophe Sauthier   Mail : 
christophe.sauth...@objectif-libre.com

CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la Pause 
OpenStack

http://olib.re/pause-openstack

__
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] [requirements][lbaas] gunicorn to g-r

[Tom Barron]

On 10/18/2016 03:56 PM, Doug Hellmann wrote:
> Excerpts from Doug Wiegley's message of 2016-10-18 12:53:18 -0600:
>>
>>> On Oct 18, 2016, at 12:42 PM, Doug Hellmann  wrote:
>>>
>>> I expect you could take over a corner of the dev lounge or some
>>> other space to hold a BoF to at least start the discussion and get
>>> some interested folks lined up to lead the WG.
>>
>> Sounds good. In prep to sending an ML invite, what projects use service VMs? 
>>   There’s Octavia, Trove, and Tacker.  What else?
> 
> You hit the main ones I was thinking of. Maybe also Sahara and Magnum?

Manila

> 
> Doug
> 
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Doug Hellmann]

Excerpts from Doug Wiegley's message of 2016-10-18 12:53:18 -0600:
> 
> > On Oct 18, 2016, at 12:42 PM, Doug Hellmann  wrote:
> >
> > I expect you could take over a corner of the dev lounge or some
> > other space to hold a BoF to at least start the discussion and get
> > some interested folks lined up to lead the WG.
> 
> Sounds good. In prep to sending an ML invite, what projects use service VMs?  
>  There’s Octavia, Trove, and Tacker.  What else?

You hit the main ones I was thinking of. Maybe also Sahara and Magnum?

Doug

__
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] [nova][bugs] No Nova Bugs Team Meeting this Week

[Augustina Ragwitz]

So apparently I did not actually send this to the list. Sorry for any
confusion!

On Mon, Oct 17, 2016, at 01:16 PM, Augustina Ragwitz wrote:
> I'm on holiday and unable to host this week's meeting. If you have any
> questions regarding bug maintenance, bug triage, or anything bug team
> related, feel free to email me, message me in irc (auggy), or just ask
> in #openstack-nova.


-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring

Waiting for your change to get through the gate? Clean up some Nova
bugs!
http://45.55.105.55:8082/bugs-dashboard.html
---
email: aragwitz+n...@pobox.com
irc: auggy

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

[openstack-dev] [keystone] meeting canceled next week (oct 25 2016)

[Steve Martinelli]

due to the summit we'll be canceling the meeting next week.

stevemar
__
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] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 12:42 PM, Doug Hellmann  wrote:
> 
> Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600:
>> 
>>> On Oct 18, 2016, at 12:10 PM, Doug Hellmann  wrote:
>>> 
>>> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
 
> On Oct 18, 2016, at 11:30 AM, Doug Hellmann  > wrote:
> 
> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>> 
>>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco >>  >> >> wrote:
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Thierry Carrez >>  >> > >>  >> >> Reply: OpenStack Development Mailing List (not for usage questions) 
>>> >>  
>>> >> > 
>>> >>  
>>> >> >> Date: October 18, 2016 at 03:55:41
>>> To: openstack-dev@lists.openstack.org 
>>>  
>>> >> > 
>>> >>  
>>> >> >> 
>>> >> >>  > 
>>> >>  
>>> >> >> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>>> 
 Doug Wiegley wrote:
> [...] Paths forward:
> 
> 1. Add gunicorn to global requirements.
> 
> 2. Create a project specific “amphora-requirements.txt” file for the
> service VM packages (this is actually my preference.) It has been
> pointed out that this wouldn’t be kept up-to-date by the bot. We could
> modify the bot to include it in some way, or do it manually, or with a
> project specific job.
> 
> 3. Split our service VM builds into another repo, to keep a clean
> separation between API services and the backend. But, even this new
> repo’s standlone requirements.txt file will have the g-r issue from 
> #1.
> 
> 4. Boot the backend out of OpenStack entirely.
 
 All those options sound valid to me, so the requirements team should
 pick what they are the most comfortable with.
 
 My 2c: yes g-r is mostly about runtime dependencies and ensuring
 co-installability. However it also includes test/build-time deps, and
 generally converging dependencies overall sounds like a valid goal. Is
 there any drawback in adding gunicorn to g-r (option 1) ?
>>> 
>>> The drawback (in my mind) is that new projects might start using it 
>>> giving operators yet another thing to learn about when deploying a new 
>>> component (eventlet, gevent, gunicorn, ...).
>>> 
>>> On the flip, what's the benefit of adding it to g-r?
>> 
>> The positive benefit is the same as Octavia’s use case: it provides an 
>> alternative for any non-frontline-api service to run a lightweight 
>> http/wsgi service as needed (service VMs, health monitor agents, etc). 
>> And something better than the built-in debug servers in most of the 
>> frameworks.
>> 
>> On the proliferation point, it is certainly a risk, though I’ve 
>> personally heard pretty strong guidance that all main API services in 
>> our community should be trending towards pecan.
> 
> Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
> them. So they're not mutually exclusive.
 
 Right, agreed.
 
 What we’re trying to convey here is:
 
 - The normal way of making a REST endpoint in OpenStack is to use pecan 
 (or flask or falcon), and let the deployer or packager worry about the 
 runtime wsgi and/or 

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Hellmann]

Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600:
> 
> > On Oct 18, 2016, at 12:10 PM, Doug Hellmann  wrote:
> > 
> > Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
> >> 
> >>> On Oct 18, 2016, at 11:30 AM, Doug Hellmann  >>> > wrote:
> >>> 
> >>> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>  
> > On Oct 18, 2016, at 5:14 AM, Ian Cordasco  >   > >> wrote:
> > 
> > 
> > 
> > -Original Message-
> > From: Thierry Carrez  >   > >  >   >  > Reply: OpenStack Development Mailing List (not for usage questions) 
> >  >  
> >  > > 
> >  >  
> >  >  > Date: October 18, 2016 at 03:55:41
> > To: openstack-dev@lists.openstack.org 
> >  
> >  > > 
> >  >  
> >  > >> 
> >  >  >  > 
> >  >  
> >  >  > Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
> > 
> >> Doug Wiegley wrote:
> >>> [...] Paths forward:
> >>> 
> >>> 1. Add gunicorn to global requirements.
> >>> 
> >>> 2. Create a project specific “amphora-requirements.txt” file for the
> >>> service VM packages (this is actually my preference.) It has been
> >>> pointed out that this wouldn’t be kept up-to-date by the bot. We could
> >>> modify the bot to include it in some way, or do it manually, or with a
> >>> project specific job.
> >>> 
> >>> 3. Split our service VM builds into another repo, to keep a clean
> >>> separation between API services and the backend. But, even this new
> >>> repo’s standlone requirements.txt file will have the g-r issue from 
> >>> #1.
> >>> 
> >>> 4. Boot the backend out of OpenStack entirely.
> >> 
> >> All those options sound valid to me, so the requirements team should
> >> pick what they are the most comfortable with.
> >> 
> >> My 2c: yes g-r is mostly about runtime dependencies and ensuring
> >> co-installability. However it also includes test/build-time deps, and
> >> generally converging dependencies overall sounds like a valid goal. Is
> >> there any drawback in adding gunicorn to g-r (option 1) ?
> > 
> > The drawback (in my mind) is that new projects might start using it 
> > giving operators yet another thing to learn about when deploying a new 
> > component (eventlet, gevent, gunicorn, ...).
> > 
> > On the flip, what's the benefit of adding it to g-r?
>  
>  The positive benefit is the same as Octavia’s use case: it provides an 
>  alternative for any non-frontline-api service to run a lightweight 
>  http/wsgi service as needed (service VMs, health monitor agents, etc). 
>  And something better than the built-in debug servers in most of the 
>  frameworks.
>  
>  On the proliferation point, it is certainly a risk, though I’ve 
>  personally heard pretty strong guidance that all main API services in 
>  our community should be trending towards pecan.
> >>> 
> >>> Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
> >>> them. So they're not mutually exclusive.
> >> 
> >> Right, agreed.
> >> 
> >> What we’re trying to convey here is:
> >> 
> >> - The normal way of making a REST endpoint in OpenStack is to use pecan 
> >> (or flask or falcon), and let the deployer or packager worry about the 
> >> runtime wsgi and/or reverse proxy.
> >> 
> >> - This isn't a “normal” OpenStack endpoint, because it’s a 

[openstack-dev] [tacker] Weekly meeting cancelled for Oct 25th 2016 and Nov 1st 2016

[Sripriya Seetharam]

Hi Tackers,

Tacker weekly meeting is cancelled for the following 2 weeks i.e., Oct 25th 
2016 and Nov 1st 2016 in lieu of the summit and folks travelling back. We will 
resume on Nov 8th 2016.

Have a great summit and safe travels!

-Sripriya

__
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] [all][tc][horizon][ux][qa][release] cleaning up extra-atcs list

[Doug Hellmann]

We have a handful of people listed for ATC status under the
"extra-atcs" lists in the governance repository for whom the
expiration date has passed. I've prepared a patch to clean up the
lists [1] and added the PTLs for the related projects so they can
confirm or indicate their intent to renew the status for those
folks.  I plan to hold the patch as WIP until after the summit.

Please take a few minutes to review the changes if you're the PTL
for one of the affected teams.

Thanks,
Doug

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

__
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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Yep, I believe we did this in the past when we first started down this path
with Octavia, but we may have been too early -- maybe now is a better time
to do it. I will be at the summit and more than happy to attend a related
meeting.
But, I agree with Doug that we shouldn't stall this because of that -- can
we go ahead and vote the official OpenStack way: comments and +1/-1 on
https://review.openstack.org/#/c/386790/ ? I also feel like commenting
there is a better way to keep track of this discussion for posterity, as
the ML feels much more ephemeral to me. I can always go look up a CR as
it's directly linked to the commit. :)

--Adam

On Wed, Oct 19, 2016 at 3:24 AM Doug Wiegley 
wrote:

> On Oct 18, 2016, at 12:10 PM, Doug Hellmann  wrote:
>
> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
>
>
> On Oct 18, 2016, at 11:30 AM, Doug Hellmann  wrote:
>
> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>
>
> On Oct 18, 2016, at 5:14 AM, Ian Cordasco  mailto:sigmaviru...@gmail.com >> wrote:
>
>
>
> -Original Message-
> From: Thierry Carrez  >     Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org <
> mailto:openstack-dev@lists.openstack.org
> > <
> mailto:openstack-dev@lists.openstack.org
>  <
> mailto:openstack-dev@lists.openstack.org
>  Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org <
> mailto:openstack-dev@lists.openstack.org
> > <
> mailto:openstack-dev@lists.openstack.org
>  <
> mailto:openstack-dev@lists.openstack.org
> >>  mailto:openstack-dev@lists.openstack.org
> > <
> mailto:openstack-dev@lists.openstack.org
>  <
> mailto:openstack-dev@lists.openstack.org
>  Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>
> Doug Wiegley wrote:
>
> [...] Paths forward:
>
> 1. Add gunicorn to global requirements.
>
> 2. Create a project specific “amphora-requirements.txt” file for the
> service VM packages (this is actually my preference.) It has been
> pointed out that this wouldn’t be kept up-to-date by the bot. We could
> modify the bot to include it in some way, or do it manually, or with a
> project specific job.
>
> 3. Split our service VM builds into another repo, to keep a clean
> separation between API services and the backend. But, even this new
> repo’s standlone requirements.txt file will have the g-r issue from #1.
>
> 4. Boot the backend out of OpenStack entirely.
>
>
> All those options sound valid to me, so the requirements team should
> pick what they are the most comfortable with.
>
> My 2c: yes g-r is mostly about runtime dependencies and ensuring
> co-installability. However it also includes test/build-time deps, and
> generally converging dependencies overall sounds like a valid goal. Is
> there any drawback in adding gunicorn to g-r (option 1) ?
>
>
> The drawback (in my mind) is that new projects might start using it giving
> operators yet another thing to learn about when deploying a new component
> (eventlet, gevent, gunicorn, ...).
>
> On the flip, what's the benefit of adding it to g-r?
>
>
> The positive benefit is the same as Octavia’s use case: it provides an
> alternative for any non-frontline-api service to run a lightweight
> http/wsgi service as needed (service VMs, health monitor agents, etc). And
> something better than the built-in debug servers in most of the frameworks.
>
> On the proliferation point, it is certainly a risk, though I’ve personally
> heard pretty strong guidance that all main API services in our community
> should be trending towards pecan.
>
>
> Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
> them. So they're not mutually exclusive.
>
>
> Right, agreed.
>
> What we’re trying to convey here is:
>
> - The normal way of making a REST endpoint in OpenStack is to use pecan
> (or flask or falcon), and let the deployer or packager worry about the
> runtime wsgi and/or reverse proxy.
>
> - This isn't a “normal” OpenStack endpoint, because it’s a microservice
> inside a service VM, and thus has different needs, and is much less likely
> to be customized by a non-dev, to boot. And it needs to be “deploy ready”
> as a simple matter of it being a service VM black box. It’s part of the
> data plane, not the control plane.
>
> Thanks,
> 

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Monty Taylor]

On 10/18/2016 12:05 PM, Adam Harwell wrote:
> Inline comments.
> 
> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand  > wrote:
> 
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand"  
> > >> wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >> > Jim, that is exactly my thought -- the main focus of g-r as far
> as I was
> >> > aware is to maintain interoperability between project
> dependencies for
> >> > openstack deploys, and since our amphora image is totally
> separate, it
> >> > should not be restricted to g-r requirements.
> >>
> >> The fact that we have a unified version number of a given lib in
> all of
> >> OpenStack is also because that's a requirement of downstream distros.
> >>
> >> Imagine that someone would like to build the Octavia image using
> >> exclusively packages from ...
> >>
> >> > I brought this up, but
> >> > others thought it would be prudent to go the g-r route anyway.
> >>
> >> It is, and IMO you should go this route.
> >
> > I'm not convinced by your arguments here, Thomas. If the distributor
> > were packaging Octavia for X but the image is using some other
> operating
> > system, say Y, why are X's packages relevant?
> 
> What if operating systems would be the same?
> 
> We still want to install from pypi, because we still want deployers to
> build images for their cloud using our DIB elements. There is absolutely
> no situation in which I can imagine we'd want to install a binary
> packaged version of this. There's a VERY high chance we will soon be
> using a distro that isn't even a supported OpenStack deploy target...
> 
> 
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
> 
> Sure, I love Debian too, but we're investigating things like Alpine and
> Cirros as our base image, and there's pretty much zero chance anyone
> will package ANY of our deps for those distros. Cirros doesn't even have
> a package manager AFAIK. 
> 
> 
> > I would think that if this
> > is something inside an image going to be launched by Octavia that
> > co-installibilty wouldn't really be an issue.
> 
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
> 
> Octavia will not use gunicorn for its main OpenStack API layer. It will
> continue to be packagable regardless of whether gunicorn is available.
> Gunicorn is used for our *amphora image*, which is not part of the main
> deployment layer. It is part of our *dataplane*. It is unrelated to any
> part of Octavia that is deployed as part of the main service layer of
> Openstack. In fact, in production, deployers may completely ignore
> gunicorn altogether and use a different solution, that is up to the way
> they build their amphora image (which, again, is not part of the main
> deployment). We just use gunicorn in the image we use for our gate tests.
> 
> 
> > I don't lean either way right now, so I'd really like to
> understand your
> > point of view, especially since right now it isn't making much
> sense to me.
> 
> Do you understand now? :)
> 
> I see what you are saying, but I assert it does not apply to our case at
> all. Do you see how our case is different? 

I totally understand, and I can see why it would seem very different.
Consider a few things though:

- OpenStack tries its best to not pick favorites for OS, and I think the
same applies to guest VMs, even if they just seem like appliances. While
we as upstream may be looking at using something like alpine as the base
OS for the service VM appliance, that does not necessarily imply that
all deployers _must_ use Alpine in their service VM, for exactly the
reason you mention (you intend for them to run diskimage-builder themselves)

- If a deployer happens to have a strong preference for a given OS (I
know I've been on customer calls where an OpenStack product having a tie
to a particular OS that is not the one that is in the vetted choice
otherwise at that customer was an issue) - then the use of dib by the
deployer allows them to choose to base their service VM on the OS of
their choice. That's pretty awesome.

- If that deployer similarly has an aversion to deploying any software
that didn't come from distro packages, one could imagine that they would
want their diskimage-builder run to install the python code not from pip
but instead from apt/dnf/zypper. There is obviously nothing 

Re: [openstack-dev] [puppet] weekly meeting #94

[Iury Gregory]

We did our meeting, you can read the logs in:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2016/puppet_openstack.2016-10-18-15.00.log.html

2016-10-17 10:48 GMT-03:00 Iury Gregory <iurygreg...@gmail.com>:

> Hello Puppeteers!
>
> We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4
>
> Here is the agenda:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20161018
>
> Feel free to add topics, and any outstanding bug and patch.
>
> See you tomorrow!
> Thanks
>
> --
> ~
>
>
> *Att[]'sIury Gregory Melo Ferreira *
> *Master student in Computer Science at UFCG*
>
> *Part of the puppet-manager-core team in OpenStack*
> *E-mail:  iurygreg...@gmail.com <iurygreg...@gmail.com>*
> ~
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira *
*Master student in Computer Science at UFCG*

*Part of the puppet-manager-core team in OpenStack*
*E-mail:  iurygreg...@gmail.com <iurygreg...@gmail.com>*
~
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 12:10 PM, Doug Hellmann  wrote:
> 
> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
>> 
>>> On Oct 18, 2016, at 11:30 AM, Doug Hellmann >> > wrote:
>>> 
>>> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
 
> On Oct 18, 2016, at 5:14 AM, Ian Cordasco    >> wrote:
> 
> 
> 
> -Original Message-
> From: Thierry Carrez    >     Reply: OpenStack Development Mailing List (not for usage questions) 
>   
>  > 
>   
>   Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org 
>  
>  > 
>   
>  >> 
>    > 
>   
>   Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
> 
>> Doug Wiegley wrote:
>>> [...] Paths forward:
>>> 
>>> 1. Add gunicorn to global requirements.
>>> 
>>> 2. Create a project specific “amphora-requirements.txt” file for the
>>> service VM packages (this is actually my preference.) It has been
>>> pointed out that this wouldn’t be kept up-to-date by the bot. We could
>>> modify the bot to include it in some way, or do it manually, or with a
>>> project specific job.
>>> 
>>> 3. Split our service VM builds into another repo, to keep a clean
>>> separation between API services and the backend. But, even this new
>>> repo’s standlone requirements.txt file will have the g-r issue from #1.
>>> 
>>> 4. Boot the backend out of OpenStack entirely.
>> 
>> All those options sound valid to me, so the requirements team should
>> pick what they are the most comfortable with.
>> 
>> My 2c: yes g-r is mostly about runtime dependencies and ensuring
>> co-installability. However it also includes test/build-time deps, and
>> generally converging dependencies overall sounds like a valid goal. Is
>> there any drawback in adding gunicorn to g-r (option 1) ?
> 
> The drawback (in my mind) is that new projects might start using it 
> giving operators yet another thing to learn about when deploying a new 
> component (eventlet, gevent, gunicorn, ...).
> 
> On the flip, what's the benefit of adding it to g-r?
 
 The positive benefit is the same as Octavia’s use case: it provides an 
 alternative for any non-frontline-api service to run a lightweight 
 http/wsgi service as needed (service VMs, health monitor agents, etc). And 
 something better than the built-in debug servers in most of the frameworks.
 
 On the proliferation point, it is certainly a risk, though I’ve personally 
 heard pretty strong guidance that all main API services in our community 
 should be trending towards pecan.
>>> 
>>> Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
>>> them. So they're not mutually exclusive.
>> 
>> Right, agreed.
>> 
>> What we’re trying to convey here is:
>> 
>> - The normal way of making a REST endpoint in OpenStack is to use pecan (or 
>> flask or falcon), and let the deployer or packager worry about the runtime 
>> wsgi and/or reverse proxy.
>> 
>> - This isn't a “normal” OpenStack endpoint, because it’s a microservice 
>> inside a service VM, and thus has different needs, and is much less likely 
>> to be customized by a non-dev, to boot. And it needs to be “deploy ready” as 
>> a simple matter of it being a service VM black box. It’s part of the data 
>> plane, not the control plane.
>> 

[openstack-dev] [swg] Meeting next week cancelled & Barcelona Summit info

[Colette Alexander]

Hi there SWG-ers & OpenStackers,

This is official notice that our Tues, Oct 25th, 15:00 UTC meeting is
canceled due to the Ocata Summit in Barcelona.

The Stewardship Working Group has two sessions worth attending live if
you'll be in Barcelona.

1) A cross project session Wednesday at 12:15 PM [0][1]
2) A summit panel discussion Wednesday at 3:55 PM  [2]

If you can't attend the sessions, please do check out the etherpad for
the session [1] and feel free to join us at our next IRC meeting in
#openstack-meeting-3 on Nov 6, at 15:00 UTC.

Thanks, and looking forward to seeing you all in Barcelona!

-colette/gothicmindfood



[0] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16923/cross-project-workshops-re-inventing-the-tc-the-stewardship-working-group-discussion
[1] Etherpad is here: https://etherpad.openstack.org/p/Barcelona-SWG-cp
[2] 
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15243/stewardship-bringing-more-leadership-and-vision-to-openstack

__
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] [requirements][lbaas] gunicorn to g-r

[Doug Hellmann]

Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
> 
> > On Oct 18, 2016, at 11:30 AM, Doug Hellmann  wrote:
> > 
> > Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
> >> 
> >>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco  >>> > wrote:
> >>> 
> >>> 
> >>> 
> >>> -Original Message-
> >>> From: Thierry Carrez  >>>   >>> >>
> >>> Reply: OpenStack Development Mailing List (not for usage questions) 
> >>>  >>>  
> >>>  >>> >>
> >>> Date: October 18, 2016 at 03:55:41
> >>> To: openstack-dev@lists.openstack.org 
> >>>  
> >>>  >>> > 
> >>>  >>>  
> >>>  >>> >>
> >>> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
> >>> 
>  Doug Wiegley wrote:
> > [...] Paths forward:
> > 
> > 1. Add gunicorn to global requirements.
> > 
> > 2. Create a project specific “amphora-requirements.txt” file for the
> > service VM packages (this is actually my preference.) It has been
> > pointed out that this wouldn’t be kept up-to-date by the bot. We could
> > modify the bot to include it in some way, or do it manually, or with a
> > project specific job.
> > 
> > 3. Split our service VM builds into another repo, to keep a clean
> > separation between API services and the backend. But, even this new
> > repo’s standlone requirements.txt file will have the g-r issue from #1.
> > 
> > 4. Boot the backend out of OpenStack entirely.
>  
>  All those options sound valid to me, so the requirements team should
>  pick what they are the most comfortable with.
>  
>  My 2c: yes g-r is mostly about runtime dependencies and ensuring
>  co-installability. However it also includes test/build-time deps, and
>  generally converging dependencies overall sounds like a valid goal. Is
>  there any drawback in adding gunicorn to g-r (option 1) ?
> >>> 
> >>> The drawback (in my mind) is that new projects might start using it 
> >>> giving operators yet another thing to learn about when deploying a new 
> >>> component (eventlet, gevent, gunicorn, ...).
> >>> 
> >>> On the flip, what's the benefit of adding it to g-r?
> >> 
> >> The positive benefit is the same as Octavia’s use case: it provides an 
> >> alternative for any non-frontline-api service to run a lightweight 
> >> http/wsgi service as needed (service VMs, health monitor agents, etc). And 
> >> something better than the built-in debug servers in most of the frameworks.
> >> 
> >> On the proliferation point, it is certainly a risk, though I’ve personally 
> >> heard pretty strong guidance that all main API services in our community 
> >> should be trending towards pecan.
> > 
> > Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
> > them. So they're not mutually exclusive.
> 
> Right, agreed.
> 
> What we’re trying to convey here is:
> 
> - The normal way of making a REST endpoint in OpenStack is to use pecan (or 
> flask or falcon), and let the deployer or packager worry about the runtime 
> wsgi and/or reverse proxy.
> 
> - This isn't a “normal” OpenStack endpoint, because it’s a microservice 
> inside a service VM, and thus has different needs, and is much less likely to 
> be customized by a non-dev, to boot. And it needs to be “deploy ready” as a 
> simple matter of it being a service VM black box. It’s part of the data 
> plane, not the control plane.
> 
> Thanks,
> doug

That all seems reasonable.

We have a proliferation of these service VMs. It would be good to
get some of the folks involved together to start a working group
to see if there are some commonalities that can lead to shared
processes or tools.

Doug

> 
> > 
> > Doug
> > 
> >> 
> >> Thanks,
> >> doug
> >> 
> >>> 
> >>> --  
> >>> Ian Cordasco
> >>> 
> >>> 
> >>> __
> >>> 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] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 11:30 AM, Doug Hellmann  wrote:
> 
> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>> 
>>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco >> > wrote:
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Thierry Carrez  
>>> >>
>>> Reply: OpenStack Development Mailing List (not for usage questions) 
>>> >>  
>>> >> >>
>>> Date: October 18, 2016 at 03:55:41
>>> To: openstack-dev@lists.openstack.org 
>>>  
>>> >> > 
>>> >>  
>>> >> >>
>>> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>>> 
 Doug Wiegley wrote:
> [...] Paths forward:
> 
> 1. Add gunicorn to global requirements.
> 
> 2. Create a project specific “amphora-requirements.txt” file for the
> service VM packages (this is actually my preference.) It has been
> pointed out that this wouldn’t be kept up-to-date by the bot. We could
> modify the bot to include it in some way, or do it manually, or with a
> project specific job.
> 
> 3. Split our service VM builds into another repo, to keep a clean
> separation between API services and the backend. But, even this new
> repo’s standlone requirements.txt file will have the g-r issue from #1.
> 
> 4. Boot the backend out of OpenStack entirely.
 
 All those options sound valid to me, so the requirements team should
 pick what they are the most comfortable with.
 
 My 2c: yes g-r is mostly about runtime dependencies and ensuring
 co-installability. However it also includes test/build-time deps, and
 generally converging dependencies overall sounds like a valid goal. Is
 there any drawback in adding gunicorn to g-r (option 1) ?
>>> 
>>> The drawback (in my mind) is that new projects might start using it giving 
>>> operators yet another thing to learn about when deploying a new component 
>>> (eventlet, gevent, gunicorn, ...).
>>> 
>>> On the flip, what's the benefit of adding it to g-r?
>> 
>> The positive benefit is the same as Octavia’s use case: it provides an 
>> alternative for any non-frontline-api service to run a lightweight http/wsgi 
>> service as needed (service VMs, health monitor agents, etc). And something 
>> better than the built-in debug servers in most of the frameworks.
>> 
>> On the proliferation point, it is certainly a risk, though I’ve personally 
>> heard pretty strong guidance that all main API services in our community 
>> should be trending towards pecan.
> 
> Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
> them. So they're not mutually exclusive.

Right, agreed.

What we’re trying to convey here is:

- The normal way of making a REST endpoint in OpenStack is to use pecan (or 
flask or falcon), and let the deployer or packager worry about the runtime wsgi 
and/or reverse proxy.

- This isn't a “normal” OpenStack endpoint, because it’s a microservice inside 
a service VM, and thus has different needs, and is much less likely to be 
customized by a non-dev, to boot. And it needs to be “deploy ready” as a simple 
matter of it being a service VM black box. It’s part of the data plane, not the 
control plane.

Thanks,
doug

> 
> Doug
> 
>> 
>> Thanks,
>> doug
>> 
>>> 
>>> --  
>>> Ian Cordasco
>>> 
>>> 
>>> __
>>> 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] [tripleo][release] Tripleo Newton RC3 available

[Emilien Macchi]

On Tue, Oct 18, 2016 at 10:13 AM, Doug Hellmann  wrote:
> Hello everyone,
>
> A new release candidate for Tripleo for the end of the Newton cycle
> is available. You can find the RC3 source code tarballs at:
>
> https://tarballs.openstack.org/instack-undercloud/instack-undercloud-5.0.0.0rc3.tar.gz
> https://tarballs.openstack.org/puppet-tripleo/puppet-tripleo-5.3.0.tar.gz
> https://tarballs.openstack.org/python-tripleoclient/python-tripleoclient-5.3.0.tar.gz
> https://tarballs.openstack.org/tripleo-common/tripleo-common-5.3.0.tar.gz
> https://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-5.0.0.0rc3.tar.gz
> https://tarballs.openstack.org/tripleo-ui/tripleo-ui-1.0.4.tar.gz
>
> Unless release-critical issues are found that warrant a release
> candidate respin, this RC3 will be formally released as the final
> Newton release on 20 October. You are therefore strongly encouraged
> to test and validate these tarballs!
>
> If you find an issue that could be considered release-critical,
> please file it at:
>
> https://bugs.launchpad.net/tripleo/+filebug
>
> and tag it *newton-rc-potential* to bring it to the Tripleo release
> crew's attention.
>
> Thanks,
> Doug

Thanks Doug.

I moved RC3 bugs that we couldn't finish yet into ocata-1.
Please look https://launchpad.net/tripleo/+milestone/ocata-1
Also 
https://bugs.launchpad.net/tripleo/+bugs?field.tag=newton-backport-potential

To keep track of bugs we want to solve by Ocata-1 milestone, and
eventually backport into stable/newton.

Please let us know any question or feedback,
-- 
Emilien Macchi

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

Re: [openstack-dev] [tripleo][ci] jobs shuffle to add IPv6 coverage

[Emilien Macchi]

On Tue, Oct 18, 2016 at 8:10 AM, Gabriele Cerami  wrote:
> Hello,
>
> after adding coverage in CI for HA IPv6 scenario here
> https://review.openstack.org/363674 we wanted to add IPv6 testing on the
> gates.
> To not use any more resources the first suggestion to add IPv6 to the
> gates was to make all HA jobs IPv6, move network isolation testing for
> IPv4 on non-ha job, and test non-netiso environment on multinode.
> This is almost done here https://review.openstack.org/382515 with one
> exception. Liberty HA IPv6 fails during ping test with the error:
> 503 Service unavailable.

Liberty is EOL next month, so I'm ok with the current proposal, it
sounds like we keep great coverage here.

> I'm partially able to reproduce the error, in my local test the error
> shows, but when I try to issue the same command pingtest uses, it all
> works. I tried to add 10 minutes timeout between deployment and start of
> the ping test, with no success.
> Moreover, swift memecache code in liberty is clearly not IPv6
> compatible, it gives an error on the overcloud, not being able to get
> host and port from a correctly formed IPv6 URL. To make it compatible
> with IPv6 this should be backported https://review.openstack.org/258704
>
> Before continuing the debugging I wanted to be sure that:
> - this is an acceptable shuffle for the gates jobs

IMHO, yes.

> - we are really interested in testing liberty IPv6

No.

> Any feedback would be appreciated.
> Thanks.

Thanks Gabriele to work on this topic, very appreciated!
-- 
Emilien Macchi

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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Hellmann]

Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
> 
> > On Oct 18, 2016, at 5:14 AM, Ian Cordasco  wrote:
> > 
> >  
> > 
> > -Original Message-
> > From: Thierry Carrez >
> > Reply: OpenStack Development Mailing List (not for usage questions) 
> >  > >
> > Date: October 18, 2016 at 03:55:41
> > To: openstack-dev@lists.openstack.org 
> >  
> >  > >
> > Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
> > 
> >> Doug Wiegley wrote:
> >>> [...] Paths forward:
> >>> 
> >>> 1. Add gunicorn to global requirements.
> >>> 
> >>> 2. Create a project specific “amphora-requirements.txt” file for the
> >>> service VM packages (this is actually my preference.) It has been
> >>> pointed out that this wouldn’t be kept up-to-date by the bot. We could
> >>> modify the bot to include it in some way, or do it manually, or with a
> >>> project specific job.
> >>> 
> >>> 3. Split our service VM builds into another repo, to keep a clean
> >>> separation between API services and the backend. But, even this new
> >>> repo’s standlone requirements.txt file will have the g-r issue from #1.
> >>> 
> >>> 4. Boot the backend out of OpenStack entirely.
> >> 
> >> All those options sound valid to me, so the requirements team should
> >> pick what they are the most comfortable with.
> >> 
> >> My 2c: yes g-r is mostly about runtime dependencies and ensuring
> >> co-installability. However it also includes test/build-time deps, and
> >> generally converging dependencies overall sounds like a valid goal. Is
> >> there any drawback in adding gunicorn to g-r (option 1) ?
> > 
> > The drawback (in my mind) is that new projects might start using it giving 
> > operators yet another thing to learn about when deploying a new component 
> > (eventlet, gevent, gunicorn, ...).
> > 
> > On the flip, what's the benefit of adding it to g-r?
> 
> The positive benefit is the same as Octavia’s use case: it provides an 
> alternative for any non-frontline-api service to run a lightweight http/wsgi 
> service as needed (service VMs, health monitor agents, etc). And something 
> better than the built-in debug servers in most of the frameworks.
> 
> On the proliferation point, it is certainly a risk, though I’ve personally 
> heard pretty strong guidance that all main API services in our community 
> should be trending towards pecan.

Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
them. So they're not mutually exclusive.

Doug

> 
> Thanks,
> doug
> 
> > 
> > --  
> > Ian Cordasco
> > 
> > 
> > __
> > 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] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

For the record, it might help if people actually look at how we're
proposing to use the gunicorn python module (remember, this code is
executing inside a *service VM*, not on the main control plane):
https://review.openstack.org/#/c/386758/12/octavia/cmd/agent.py


On Wed, Oct 19, 2016 at 2:05 AM Adam Harwell  wrote:

> Inline comments.
>
> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand  wrote:
>
> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand"  > > wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >> > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> >> > aware is to maintain interoperability between project dependencies for
> >> > openstack deploys, and since our amphora image is totally separate, it
> >> > should not be restricted to g-r requirements.
> >>
> >> The fact that we have a unified version number of a given lib in all of
> >> OpenStack is also because that's a requirement of downstream distros.
> >>
> >> Imagine that someone would like to build the Octavia image using
> >> exclusively packages from ...
> >>
> >> > I brought this up, but
> >> > others thought it would be prudent to go the g-r route anyway.
> >>
> >> It is, and IMO you should go this route.
> >
> > I'm not convinced by your arguments here, Thomas. If the distributor
> > were packaging Octavia for X but the image is using some other operating
> > system, say Y, why are X's packages relevant?
>
> What if operating systems would be the same?
>
> We still want to install from pypi, because we still want deployers to
> build images for their cloud using our DIB elements. There is absolutely no
> situation in which I can imagine we'd want to install a binary packaged
> version of this. There's a VERY high chance we will soon be using a distro
> that isn't even a supported OpenStack deploy target...
>
>
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
>
> Sure, I love Debian too, but we're investigating things like Alpine and
> Cirros as our base image, and there's pretty much zero chance anyone will
> package ANY of our deps for those distros. Cirros doesn't even have a
> package manager AFAIK.
>
>
> > I would think that if this
> > is something inside an image going to be launched by Octavia that
> > co-installibilty wouldn't really be an issue.
>
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
>
> Octavia will not use gunicorn for its main OpenStack API layer. It will
> continue to be packagable regardless of whether gunicorn is available.
> Gunicorn is used for our *amphora image*, which is not part of the main
> deployment layer. It is part of our *dataplane*. It is unrelated to any
> part of Octavia that is deployed as part of the main service layer of
> Openstack. In fact, in production, deployers may completely ignore gunicorn
> altogether and use a different solution, that is up to the way they build
> their amphora image (which, again, is not part of the main deployment). We
> just use gunicorn in the image we use for our gate tests.
>
>
> > I don't lean either way right now, so I'd really like to understand your
> > point of view, especially since right now it isn't making much sense to
> me.
>
> Do you understand now? :)
>
> I see what you are saying, but I assert it does not apply to our case at
> all. Do you see how our case is different?
>
>
> Cheers,
>
> Thomas
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

Inline comments.

On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand  wrote:

> On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> > On Oct 17, 2016 7:27 PM, "Thomas Goirand"  > > wrote:
> >>
> >> On 10/17/2016 08:43 PM, Adam Harwell wrote:
> >> > Jim, that is exactly my thought -- the main focus of g-r as far as I
> was
> >> > aware is to maintain interoperability between project dependencies for
> >> > openstack deploys, and since our amphora image is totally separate, it
> >> > should not be restricted to g-r requirements.
> >>
> >> The fact that we have a unified version number of a given lib in all of
> >> OpenStack is also because that's a requirement of downstream distros.
> >>
> >> Imagine that someone would like to build the Octavia image using
> >> exclusively packages from ...
> >>
> >> > I brought this up, but
> >> > others thought it would be prudent to go the g-r route anyway.
> >>
> >> It is, and IMO you should go this route.
> >
> > I'm not convinced by your arguments here, Thomas. If the distributor
> > were packaging Octavia for X but the image is using some other operating
> > system, say Y, why are X's packages relevant?
>
> What if operating systems would be the same?
>
We still want to install from pypi, because we still want deployers to
build images for their cloud using our DIB elements. There is absolutely no
situation in which I can imagine we'd want to install a binary packaged
version of this. There's a VERY high chance we will soon be using a distro
that isn't even a supported OpenStack deploy target...

>
> As a Debian package maintainer, I really prefer if the underlying images
> can also be Debian (and preferably Debian stable everywhere).
>
Sure, I love Debian too, but we're investigating things like Alpine and
Cirros as our base image, and there's pretty much zero chance anyone will
package ANY of our deps for those distros. Cirros doesn't even have a
package manager AFAIK.

>
> > I would think that if this
> > is something inside an image going to be launched by Octavia that
> > co-installibilty wouldn't really be an issue.
>
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.
>
Octavia will not use gunicorn for its main OpenStack API layer. It will
continue to be packagable regardless of whether gunicorn is available.
Gunicorn is used for our *amphora image*, which is not part of the main
deployment layer. It is part of our *dataplane*. It is unrelated to any
part of Octavia that is deployed as part of the main service layer of
Openstack. In fact, in production, deployers may completely ignore gunicorn
altogether and use a different solution, that is up to the way they build
their amphora image (which, again, is not part of the main deployment). We
just use gunicorn in the image we use for our gate tests.

>
> > I don't lean either way right now, so I'd really like to understand your
> > point of view, especially since right now it isn't making much sense to
> me.
>
> Do you understand now? :)
>
I see what you are saying, but I assert it does not apply to our case at
all. Do you see how our case is different?

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

Re: [openstack-dev] [api] [nova] microversion edge case query

[Ed Leafe]

On Oct 18, 2016, at 11:01 AM, Chris Dent  wrote:
> 
> If the requested microversion is greater than the maximum, a 404 still
> makes some sense (no mapping _now_), but a 406 could as well because it
> provides a signal that if you used a different microversion the
> situation could be different and the time represented by the
> requested microversion has conceptual awareness of its past.
> 
> What do people think?
> 
> I think I recall there was some discussion of this sort of thing
> with regard to some of the proxy APIs at the nova midcycle but I
> can't remember the details of the outcome.

The only way that that could happen (besides a total collapse of the review 
process) is when a method is removed from the API. When that happens, the 
latest version has its max set to the last microversion where that method is 
supported. For microversions after that, 404 is the correct response. For all 
other methods, the latest version should not have a maximum specified.

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

Re: [openstack-dev] [ironic] Core team updates

[Villalovos, John L]

I just want to give a big thank you to Haomeng Wang and Chris Krelle for all 
their contributions to Ironic!

And especially thanks to Chris (NobodyCam) for all of his help while I was 
learning about Ironic. It helps we were in the same timezone, so we overlapped 
in IRC often :)

John

> -Original Message-
> From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
> Sent: Monday, October 17, 2016 3:09 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [ironic] Core team updates
> 
> Hey friends,
> 
> The ironic-core team has done some great things over the last year.
> We've landed a ton of code, grown some new members (and continually
> growing more), and generally stayed pretty well connected.
> 
> However, some folks are clearly reviewing far more than others. While
> I realize that folks may have commitments outside of ironic, I'd like to ask
> everyone to be mindful of their review quantity (and always quality, of
> course). :)
> 
> Reviews for the ironic umbrella in the last 90 days:
> http://stackalytics.com/report/contribution/ironic-group/90
> 
> A good rule of thumb to try to meet is 3 reviews/day, which our top 8
> reviewers are meeting (admittedly I am not).
> 
> There's also a couple people that haven't been active in the project
> for quite a while that I'm dropping today:
> 
> Chris Krelle (NobodyCam)
> Haomeng Wang (haomeng)
> 
> Of course, we welcome both of you back quickly if your activity picks
> back up. :)
> 
> // jim
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [api] [nova] microversion edge case query

[Chris Dent]

On Tue, 18 Oct 2016, Chris Dent wrote:


If the requested microversion is greater than the maximum, a 404 still
makes some sense (no mapping _now_), but a 406 could as well because it
provides a signal that if you used a different microversion the
situation could be different and the time represented by the
requested microversion has conceptual awareness of its past.

What do people think?


The WIP code is now visible in gerrit, the commit message ought to
lead interested parties to the confusing bit:

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

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://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] [nova][scheduler] ResourceProvider design issues

[Ed Leafe]

> On Oct 17, 2016, at 8:45 PM, Jay Pipes  wrote:
> 
> On 10/17/2016 11:14 PM, Ed Leafe wrote:
>> Now that we’re starting to model some more complex resources, it seems that 
>> some of the original design decisions may have been mistaken. One approach 
>> to work around this is to create multiple levels of resource providers. 
>> While that works, it is unnecessarily complicated IMO. I think we need to 
>> revisit some basic assumptions about the design before we dig ourselves a 
>> big design hole that will be difficult to get out of. I’ve tried to 
>> summarize my thoughts in a blog post. I don’t presume that this is the only 
>> possible solution, but I feel it is better than the current approach.
>> 
>> https://blog.leafe.com/virtual-bike-sheds/
> 
> I commented on your blog, but leave it here for posterity:

Likewise, responded on the blog, but following your lead by posting in both 
places.

You didn't include this in your email, but I think you misunderstood my comment 
how "those of us experienced in OOP" might object to having multiple classes 
that differ solely on a single attribute. Since you are the one who is doing 
the objecting to multiple class names, I was merely saying that anyone with 
background in object-oriented programming might have a reflexive aversion to 
having slight variations on something with 'Class' in its name. That was the 
reason I said that if they had been named 'ResourceTypes' instead, the aversion 
might not be as strong. Sorry for the misunderstanding. I was in no way trying 
to minimize your understanding of OOPy things.

Regarding your comments on standardization, I'm not sure that I can see the 
difference between what you've described and what I have. In your design, you 
would have a standard class name for the SR-IOV-VF, and standard trait names 
for the networks. So with a two-network deployment, there would need to be 3 
standardized names. With multiple classes, there would need to be 2 
standardized names: not a huge difference. Now if there might be a more complex 
deployment than simply 'public' and 'private' networks for SR-IOV devices, then 
things are less clear. For things to be standardized across clouds, the way you 
request a resource has to be standardized. How would the various network names 
be constrained across clouds? Let's say there are N network types; the same 
math would apply. Nested providers would need N+1 standard names and multiple 
classes would need N in order to distinguish. If there are no restrictions on 
network names, then both approaches will fail on standardization, since a 
provider could call a network whatever they want.

As far as NUMA cells and their inventory accounting are concerned, that sounds 
like something where a whiteboard discussion will really help. Most of the 
people working on the placement engine, myself included, have only a passing 
understanding of the intricacies of NUMA arrangements. But even without that, I 
don't see the need to have multiple awkward names for the different NUMA 
resource classes. Based on my understanding, a slightly different approach 
would be sufficient. Instead of having multiple classes, we could remove the 
restriction that a ResourceProvider can only have one of any individual 
ResourceClass. In other words, the host would have two ResourceClass records of 
type NUMA_SOCKET (is that the right class?), one for each NUMA cell, and each 
of those would have their individual inventory records. So a request for 
MEMORY_PAGE_1G would involve a ResourceProvider seeing if any of their 
ResourceClass records has enough of that type of inventory available.

I think the same approach applies to the NIC bandwidth example you gave. By 
allowing multiple ResourceClass records representing the different NICs, the 
total bandwidth will also be a simple aggregate.

Finally, regarding the SQL complexity, I spent years as a SQL DBA and yet I am 
always impressed by how much better your SQL solutions are than the ones I 
might come up with. I'm not saying that the SQL is so complex as to be 
unworkable; I'm simply saying that it is more complex than it needs to be.

In any event, I am looking forward to carrying on these discussions in 
Barcelona with you and the rest of the scheduler subteam.


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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 10:41 AM, Thomas Goirand  wrote:
> 
> On 10/18/2016 02:44 AM, Morgan Fainberg wrote:
>> For the record uwsgi was not (at least at one point) allowed in g-r as
>> it was not a "runtime dependency" it was to be installed more like
>> apache mod_wsgi at the time. Gunicorn could fall into the same category,
>> it is meant to be used in conjunction with the runtime but not be a hard
>> requirement for the runtime itself.
> 
> Except that it can be used as a python module.
> 
> If it's only a "binary runner", then I don't think we even need to care,
> as we could replace it by apache or uwsgi, and it's an implementation
> detail that could even be left to package maintainers (I don't know the
> exact details of Octavia here though…).

This is for Octavia’s service VM image, not it’s mainline API service (which 
uses pecan and all the normal stuff.)

It’s true that packagers can create their own service VM images, and run 
whatever they like, but we must do something for the ref implementation that 
runs in the gate. And at present, we’ve chosen gunicorn, because the built-in 
server in flask is flaky in our CI tests.

doug


> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Chris Dent]

On Tue, 18 Oct 2016, Matthew Thode wrote:


On 10/18/2016 11:25 AM, Adam Harwell wrote:

We really don't want bindep IMO -- it's much safer to use the
non-packaged version from pypi for our purposes, since we may not be
running on a system that packages things like this. Again, our use case
may be strange though, as we're really using the python module and not
the binaries.

--Adam


Is there a reason you are not using pecan?


There seems to be some confusion here. pecan is a WSGI application
framework (that uses object dispatch as its conceptual model).
gunicorn is a WSGI server.

One could, if one wanted, hosted a pecan based application with
gunicorn. Or uwsgi. Or apache+mod_wsgi. Or nginx+uwsgi. Or a bunch
of other stuff.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://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] [requirements][lbaas] gunicorn to g-r

[Thomas Goirand]

On 10/18/2016 02:44 AM, Morgan Fainberg wrote:
> For the record uwsgi was not (at least at one point) allowed in g-r as
> it was not a "runtime dependency" it was to be installed more like
> apache mod_wsgi at the time. Gunicorn could fall into the same category,
> it is meant to be used in conjunction with the runtime but not be a hard
> requirement for the runtime itself.

Except that it can be used as a python module.

If it's only a "binary runner", then I don't think we even need to care,
as we could replace it by apache or uwsgi, and it's an implementation
detail that could even be left to package maintainers (I don't know the
exact details of Octavia here though...).

Cheers,

Thomas Goirand (zigo)


__
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] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 10:39 AM, Matthew Thode  wrote:
> 
> On 10/18/2016 11:25 AM, Adam Harwell wrote:
>> We really don't want bindep IMO -- it's much safer to use the
>> non-packaged version from pypi for our purposes, since we may not be
>> running on a system that packages things like this. Again, our use case
>> may be strange though, as we're really using the python module and not
>> the binaries.
>> 
>> --Adam
> 
> Is there a reason you are not using pecan?

Seems a bit heavy for a microservice inside a service VM.

doug


> 
> -- 
> -- Matthew Thode (prometheanfire)
> 
> __
> 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] [requirements][lbaas] gunicorn to g-r

[Matthew Thode]

On 10/18/2016 11:25 AM, Adam Harwell wrote:
> We really don't want bindep IMO -- it's much safer to use the
> non-packaged version from pypi for our purposes, since we may not be
> running on a system that packages things like this. Again, our use case
> may be strange though, as we're really using the python module and not
> the binaries.
> 
> --Adam

Is there a reason you are not using pecan?

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Matthew Thode]

On 10/18/2016 11:35 AM, Thomas Goirand wrote:
> The issue isn't co-instability, but the fact that downstream
> distribution vendors will only package *ONE* version of a given python
> module. If we have Octavia with version X, and another component of
> OpenStack with version Y, then we're stuck with Octavia not being
> packageable in downstream distros.

That's not quite true for but is certainly true for most :P

* www-servers/gunicorn
 Available versions:  19.1.1 ~19.3.0 ~19.4.5 {doc examples test
 PYTHON_TARGETS="pypy python2_7 python3_3 python3_4 python3_5"}

-- 
-- Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Thomas Goirand]

On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> On Oct 17, 2016 7:27 PM, "Thomas Goirand"  > wrote:
>>
>> On 10/17/2016 08:43 PM, Adam Harwell wrote:
>> > Jim, that is exactly my thought -- the main focus of g-r as far as I was
>> > aware is to maintain interoperability between project dependencies for
>> > openstack deploys, and since our amphora image is totally separate, it
>> > should not be restricted to g-r requirements.
>>
>> The fact that we have a unified version number of a given lib in all of
>> OpenStack is also because that's a requirement of downstream distros.
>>
>> Imagine that someone would like to build the Octavia image using
>> exclusively packages from ...
>>
>> > I brought this up, but
>> > others thought it would be prudent to go the g-r route anyway.
>>
>> It is, and IMO you should go this route.
> 
> I'm not convinced by your arguments here, Thomas. If the distributor
> were packaging Octavia for X but the image is using some other operating
> system, say Y, why are X's packages relevant?

What if operating systems would be the same?

As a Debian package maintainer, I really prefer if the underlying images
can also be Debian (and preferably Debian stable everywhere).

> I would think that if this
> is something inside an image going to be launched by Octavia that
> co-installibilty wouldn't really be an issue.

The issue isn't co-instability, but the fact that downstream
distribution vendors will only package *ONE* version of a given python
module. If we have Octavia with version X, and another component of
OpenStack with version Y, then we're stuck with Octavia not being
packageable in downstream distros.

> I don't lean either way right now, so I'd really like to understand your
> point of view, especially since right now it isn't making much sense to me.

Do you understand now? :)

Cheers,

Thomas


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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Adam Harwell]

We really don't want bindep IMO -- it's much safer to use the non-packaged
version from pypi for our purposes, since we may not be running on a system
that packages things like this. Again, our use case may be strange though,
as we're really using the python module and not the binaries.

--Adam

On Wed, Oct 19, 2016 at 1:07 AM Doug Wiegley 
wrote:

> On Oct 18, 2016, at 5:14 AM, Ian Cordasco  wrote:
>
>
>
> -Original Message-
> From: Thierry Carrez 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org 
> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>
> Doug Wiegley wrote:
>
> [...] Paths forward:
>
> 1. Add gunicorn to global requirements.
>
> 2. Create a project specific “amphora-requirements.txt” file for the
> service VM packages (this is actually my preference.) It has been
> pointed out that this wouldn’t be kept up-to-date by the bot. We could
> modify the bot to include it in some way, or do it manually, or with a
> project specific job.
>
> 3. Split our service VM builds into another repo, to keep a clean
> separation between API services and the backend. But, even this new
> repo’s standlone requirements.txt file will have the g-r issue from #1.
>
> 4. Boot the backend out of OpenStack entirely.
>
>
> All those options sound valid to me, so the requirements team should
> pick what they are the most comfortable with.
>
> My 2c: yes g-r is mostly about runtime dependencies and ensuring
> co-installability. However it also includes test/build-time deps, and
> generally converging dependencies overall sounds like a valid goal. Is
> there any drawback in adding gunicorn to g-r (option 1) ?
>
>
> The drawback (in my mind) is that new projects might start using it giving
> operators yet another thing to learn about when deploying a new component
> (eventlet, gevent, gunicorn, ...).
>
> On the flip, what's the benefit of adding it to g-r?
>
>
> The positive benefit is the same as Octavia’s use case: it provides an
> alternative for any non-frontline-api service to run a lightweight
> http/wsgi service as needed (service VMs, health monitor agents, etc). And
> something better than the built-in debug servers in most of the frameworks.
>
> On the proliferation point, it is certainly a risk, though I’ve personally
> heard pretty strong guidance that all main API services in our community
> should be trending towards pecan.
>
> Thanks,
> doug
>
>
> --
> Ian Cordasco
>
>
> __
> 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] [all] indoor climbing break at summit?

[Miles Gould]

On 17/10/16 18:43, Chris Dent wrote:

On Mon, 17 Oct 2016, gordon chung wrote:


you forgot to add disclaimer how you broke every bone in your body a
while back.


\o/ Thanks for paying attention, you get a gold star. But actually
it was only three. And it was outside.

Maybe what you're really looking for here is: Climbing is dangerous. If
you choose to climb, it is at your own risk.


Or as the Union International des Associations d'Alpinisme puts it: 
"Climbing and mountaineering are activities with a danger of personal 
injury or death. Participants in these activities should be aware of and 
accept these risks and be responsible for their own actions and 
involvement".


Speaking of which: woo yeah! I'm totally up for this, schedule permitting.

Miles

__
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] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[Ihar Hrachyshka]

Joshua Harlow  wrote:


Ihar Hrachyshka wrote:

In Neutron, we have a need to allocate random but unique addresses and
such. For that matter, we have a concept of exclusive resources:
https://github.com/openstack/neutron/tree/master/neutron/tests/common/exclusive_resources
that are relying on locks and shared file based resource allocation
storage. This is used in fullstack tests where all allocation is limited
to a single node.

Another place where we randomize addresses is in our NeutronObject tests
where we just want to generate values good enough to pass
oslo.versionedobjects fields constraints:
https://github.com/openstack/neutron/blob/master/neutron/tests/unit/objects/test_base.py#L494
We have some hacks there to guarantee uniqueness where may be needed
(f.e. in case of lists of ip networks), but otherwise it’s just random
addresses. It’s good enough for unit tests because each test has its own
testing environment isolated from others.

Ihar


Ok good/interesting to know, if a test fails and someone wants to  
reproduce it 'at home' what's the recommended way to do that if these are  
all randomized (and the source of the failure say is in one of these  
randomized data 'using' tests)


Do you output the random number gen seed (this seems like it would work,  
although a little PITA) so that people can use the same initially seed  
(and then get the same random numbers as a result)?


(To clarify for those not part of the neutron dev team, ‘fullstack’ in  
neutron gate is not devstack/tempest, and does not involve other openstack  
services, or multiple nodes.)


No, we don’t dump a seed. I don’t think I saw a ‘fullstack’ failure that  
required an exact environment duplication to reproduce a test failure.


For neutron ‘fullstack’ tests, we run complete neutron services, and  
collect all their logs, per test scenario. Basically, every ‘fullstack’  
test case is a tiny openstack setup with just neutron services running,  
using some common resources like amqp bus, or ovs bridge emulating physical  
infrastructure. As long as service logs are sufficient to debug failures,  
it doesn’t differ much from any other failure in neutron f.e. in tempest.


It’s common for neutron to allocate a ‘random’ address from a subnet  
allocation pool for its network and instance ports, in which case we need  
to trace port-ids and whatnot to link related server/agent/tempest logs.  
(If you ask me why we randomize ip address allocation in neutron IPAM code,  
that’s actually for a reason, to reduce database contention when allocating  
addresses for parallel port requests).


Ihar

__
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] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 5:14 AM, Ian Cordasco  wrote:
> 
>  
> 
> -Original Message-
> From: Thierry Carrez >
> Reply: OpenStack Development Mailing List (not for usage questions) 
> >
> Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org 
>   >
> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
> 
>> Doug Wiegley wrote:
>>> [...] Paths forward:
>>> 
>>> 1. Add gunicorn to global requirements.
>>> 
>>> 2. Create a project specific “amphora-requirements.txt” file for the
>>> service VM packages (this is actually my preference.) It has been
>>> pointed out that this wouldn’t be kept up-to-date by the bot. We could
>>> modify the bot to include it in some way, or do it manually, or with a
>>> project specific job.
>>> 
>>> 3. Split our service VM builds into another repo, to keep a clean
>>> separation between API services and the backend. But, even this new
>>> repo’s standlone requirements.txt file will have the g-r issue from #1.
>>> 
>>> 4. Boot the backend out of OpenStack entirely.
>> 
>> All those options sound valid to me, so the requirements team should
>> pick what they are the most comfortable with.
>> 
>> My 2c: yes g-r is mostly about runtime dependencies and ensuring
>> co-installability. However it also includes test/build-time deps, and
>> generally converging dependencies overall sounds like a valid goal. Is
>> there any drawback in adding gunicorn to g-r (option 1) ?
> 
> The drawback (in my mind) is that new projects might start using it giving 
> operators yet another thing to learn about when deploying a new component 
> (eventlet, gevent, gunicorn, ...).
> 
> On the flip, what's the benefit of adding it to g-r?

The positive benefit is the same as Octavia’s use case: it provides an 
alternative for any non-frontline-api service to run a lightweight http/wsgi 
service as needed (service VMs, health monitor agents, etc). And something 
better than the built-in debug servers in most of the frameworks.

On the proliferation point, it is certainly a risk, though I’ve personally 
heard pretty strong guidance that all main API services in our community should 
be trending towards pecan.

Thanks,
doug

> 
> --  
> Ian Cordasco
> 
> 
> __
> 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] [api] [nova] microversion edge case query

[Chris Dent]

I'm in the midst of writing the microversion handling code for the
placement API and I've stumbled across a situation that I'm not sure
how I should resolve. This is not necessarily something that someone
should do with microversion, but since it is possible, I'd like to
make the code behave in the most reasonable way.

The code I'm writing borrows from the nova api_version decorator.
That takes a min_version string and an optional max_version. This
identifies the microversion window in which the decorated function
should be available. When there are multiple decorated functions this
works fine to select one of them assuming the requested function is
inside the lowest minimum and highest maximum version that is set
for those functions.

What I can't decide is what response code should be sent if the
requested microversion is outside that window. If the requested
microversion is outside the available microversions for the entire
service, it is clear: that's a '406 Not Acceptable'.

If the microversion is acceptable but there's no available function,
things become less clear: If the requested version is less than the
absolute minimum for the function, a 404 mostly makes sense because in
the time which the request microversion sort of represents there was no
mapping between any URI and any function.

If the requested microversion is greater than the maximum, a 404 still
makes some sense (no mapping _now_), but a 406 could as well because it
provides a signal that if you used a different microversion the
situation could be different and the time represented by the
requested microversion has conceptual awareness of its past.

What do people think?

I think I recall there was some discussion of this sort of thing
with regard to some of the proxy APIs at the nova midcycle but I
can't remember the details of the outcome.

(Of course one way to avoid this conundrum is to not allow it either
by crook or convention, but that seems to limit the power of
microversions to turn things off. A power that is important to
have.)

thanks


--
Chris Dent   ┬─┬ノ( º _ ºノ)https://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] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[Joshua Harlow]

Ihar Hrachyshka wrote:

In Neutron, we have a need to allocate random but unique addresses and
such. For that matter, we have a concept of exclusive resources:
https://github.com/openstack/neutron/tree/master/neutron/tests/common/exclusive_resources
that are relying on locks and shared file based resource allocation
storage. This is used in fullstack tests where all allocation is limited
to a single node.

Another place where we randomize addresses is in our NeutronObject tests
where we just want to generate values good enough to pass
oslo.versionedobjects fields constraints:
https://github.com/openstack/neutron/blob/master/neutron/tests/unit/objects/test_base.py#L494
We have some hacks there to guarantee uniqueness where may be needed
(f.e. in case of lists of ip networks), but otherwise it’s just random
addresses. It’s good enough for unit tests because each test has its own
testing environment isolated from others.

Ihar



Ok good/interesting to know, if a test fails and someone wants to 
reproduce it 'at home' what's the recommended way to do that if these 
are all randomized (and the source of the failure say is in one of these 
randomized data 'using' tests)


Do you output the random number gen seed (this seems like it would work, 
although a little PITA) so that people can use the same initially seed 
(and then get the same random numbers as a result)?


-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

[openstack-dev] [tripleo] [spec] Feedback wanted on TripleO Tendrl Integration Proposal

[John Fulton]

Hello,

I'd like to post a link to a blueprint I am hoping will be discussed at 
the upcoming summit. Please share any comments you may have in the 
Gerrit review for the spec.


  https://review.openstack.org/#/c/387631/
  https://blueprints.launchpad.net/tripleo/+spec/tripleo-tendrl-integration

This may, as shardy points out, lead to a broader discussion about how 
TripleO should handle interfacing with external tools.


Thanks,
   John

__
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] [cloudkitty] Proposing Pierre-Alexandre Bardina (pabardina) as core for cloudkitty

[Shake Chen]

Thanks for your reply. Hope the Cloudkitty core review team can more active

https://review.openstack.org/#/q/project:openstack/cloudkitty+status:open



On Tue, Oct 18, 2016 at 10:49 PM, Christophe Sauthier <
christophe.sauth...@objectif-libre.com> wrote:

> Ho Shake,
>
> Thanks for your feedback !!!
>
> It is true (that all core so far are from the same company). On the other
> hand there are only 3 cores...
>
> The thing is in the past we haven't been unable to get a contributor on a
> "long period of time" outside the company... Which is the reason why so far
> it is single-vendor...  But I am confident that it will change quite soon :
> I am currently waiting just a few more weeks to propose another
> contributor, from another company this time, who has been active on the
> project for a few monts.
>
> Regarding Pierre-Alexandre proposal, he has been in charge of the
> integration with horizon for whatever we needed (which was more the case on
> the mitaka cycle). That is why I really think it would be a very good idea
> for the project to give him core reviewers rights...
>
> All the best,
>
>  Christophe
>
>
> 
> Christophe Sauthier   Mail :
> christophe.sauth...@objectif-libre.com
> CEO   Mob : +33 (0) 6 16 98 63 96
> Objectif LibreURL : www.objectif-libre.com
> Au service de votre Cloud Twitter : @objectiflibre
>
> Suivez les actualités OpenStack en français en vous abonnant à la Pause
> OpenStack
> http://olib.re/pause-openstack
>
> Le 2016-10-18 15:19, Shake Chen a écrit :
>
>> Hi
>>
>> All the Cores member are same company, seem not good idea.
>>
>> only 5 revew, 1 commit.
>>
>> On Tue, Oct 18, 2016 at 7:27 PM, Guillaume Espanel
>>  wrote:
>>
>> +1
>>>
>>> --
>>> Guillaume Espanel
>>> Objectif Libre www.objectif-libre.com [3]
>>> Infrastructure et Formations Linux
>>>
>>> Le 2016-10-18 13:16, Christophe Sauthier a écrit :
>>>
>>> Hello developer mailing list folks,

 I'd like to propose that we add Pierre-Aexandre Bardina (pabardina)
 as an OpenStack cloudkitty
 core reviewer.

 He has been a member of our community for a long time, contributing
 very seriously in cloudkitty especially on the integration of
 cloudkitty in Horizon (cloudkitty-dashboard)
 He also provided some reviews on that part (well reviews for work
 that he hasn't provided...) [1]

 Overall I think Pierre-Alexandre would make a great addition to the
 core review team.

 Current Cloudkitty cores, please respond with +1/-1.

 All the best,

 Christophe

 http://stackalytics.com/report/contribution/cloudkitty-dashboard/90 [1]

 
 Christophe Sauthier   Mail :
 christophe.sauth...@objectif-libre.com
 CEO   Mob : +33 (0) 6 16 98 63 96
 [2]
 Objectif LibreURL : www.objectif-libre.com
 [3]
 Au service de votre Cloud Twitter : @objectiflibre

 Suivez les actualités OpenStack en français en vous abonnant à la
 Pause OpenStack
 http://olib.re/pause-openstack [4]

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

>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe [5]
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [6]
>>>
>>
>> --
>>
>> Shake Chen
>>
>>
>>
>> Links:
>> --
>> [1] http://stackalytics.com/report/contribution/cloudkitty-dashboard/90
>> [2] tel:%2B33%20%280%29%206%2016%2098%2063%2096
>> [3] http://www.objectif-libre.com
>> [4] http://olib.re/pause-openstack
>> [5] http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> [6] 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:unsubscrib
>> e
>> 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
>



-- 
Shake Chen

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Matthew Thode]

On 10/18/2016 08:07 AM, Adam Harwell wrote:
> If there's no objection to us using gunicorn without it being present in
> g-r, then I don't know if I want to argue strongly for adding it -- the
> only benefit I see to tracking g-r at all is that it lets us continue to
> get free version tracking for our amphora dependencies as they are
> updated in g-r without having to manually tweak them. Once we go away
> from using g-r for our amphora-requirements, our project team has to
> track these dependencies manually. Tweaking the requirements bot to look
> at amphora-requirements.txt as Doug mentioned won't actually do much,
> since the whole point here is that we're including things that aren't in
> g-r so there's no source to update them from.
> 
> So, does everyone at least agree that it's ok for us to *use* gunicorn
> internally on our service-vm image? If so, I'm happy to move forward
> with option #2 if it looks like that'll be the path of least resistance.
> As I said, options 3 and 4 are not really good solutions to this
> particular problem, so in my view we should do whichever is most likely
> to be accepted of options 1 or 2.
> 
> --Adam

Personally I'm happy with it being in gr, it's not the perfect place
though.  (bindep would probably be better I feel, it's packaged on my
distro)

Do you need a specific version (bindep can't handle versions)?

As a packager I'd rather not force the type of server on my users.

-- 
Matthew Thode (prometheanfire)



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

[openstack-dev] Ops Lightning Talks

[David Medberry]

Dear Readers,

We have TWO back-to-back (double sessions) of Lightning Talks for
Operators. And by "for Operators" I mean largely that Operators will be the
audience.

If you have an OpenStack problem, thingamajig, technique, simplification,
gadget, whatzit that readily lends itself to a Lightning talk. please email
me and put it into the etherpad here:

https://etherpad.openstack.org/p/BCN-ops-lightning-talks

There are two sessions... but I'd prefer to fill the first one and cancel
the second one. But if your schedule dictates that you are only available
for the second, we'll hold both.

(And in spite of my natural levity, it can be a serious talk, a serious
problem, or something completely frivolous but there might be tomatoes in
the audience so watch it.)

-dave

David Medberry
OpenStack Guy and your friendly moderator.
__
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] [requirements][lbaas] gunicorn to g-r

[Ian Cordasco]

On Oct 18, 2016 8:09 AM, "Adam Harwell"  wrote:
>
> If there's no objection to us using gunicorn without it being present in
g-r, then I don't know if I want to argue strongly for adding it -- the
only benefit I see to tracking g-r at all is that it lets us continue to
get free version tracking for our amphora dependencies as they are updated
in g-r without having to manually tweak them. Once we go away from using
g-r for our amphora-requirements, our project team has to track these
dependencies manually. Tweaking the requirements bot to look at
amphora-requirements.txt as Doug mentioned won't actually do much, since
the whole point here is that we're including things that aren't in g-r so
there's no source to update them from.
>
> So, does everyone at least agree that it's ok for us to *use* gunicorn
internally on our service-vm image? If so, I'm happy to move forward with
option #2 if it looks like that'll be the path of least resistance. As I
said, options 3 and 4 are not really good solutions to this particular
problem, so in my view we should do whichever is most likely to be accepted
of options 1 or 2.

I don't think any of us are qualified to tell you not to use it in that
image. I also see the benefit clearly for Octavia, I was hoping to
understand the benefits to others (other projects/teams, packagers, and
users).

Cheers,
Ian
__
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] [cloudkitty] Proposing Pierre-Alexandre Bardina (pabardina) as core for cloudkitty

[Christophe Sauthier]

Ho Shake,

Thanks for your feedback !!!

It is true (that all core so far are from the same company). On the 
other hand there are only 3 cores...


The thing is in the past we haven't been unable to get a contributor on 
a "long period of time" outside the company... Which is the reason why 
so far it is single-vendor...  But I am confident that it will change 
quite soon : I am currently waiting just a few more weeks to propose 
another contributor, from another company this time, who has been active 
on the project for a few monts.


Regarding Pierre-Alexandre proposal, he has been in charge of the 
integration with horizon for whatever we needed (which was more the case 
on the mitaka cycle). That is why I really think it would be a very good 
idea for the project to give him core reviewers rights...


All the best,

 Christophe



Christophe Sauthier   Mail : 
christophe.sauth...@objectif-libre.com

CEO   Mob : +33 (0) 6 16 98 63 96
Objectif LibreURL : www.objectif-libre.com
Au service de votre Cloud Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la Pause 
OpenStack

http://olib.re/pause-openstack

Le 2016-10-18 15:19, Shake Chen a écrit :

Hi

All the Cores member are same company, seem not good idea.

only 5 revew, 1 commit. 

On Tue, Oct 18, 2016 at 7:27 PM, Guillaume Espanel
 wrote:


+1

--
Guillaume Espanel
Objectif Libre www.objectif-libre.com [3]
Infrastructure et Formations Linux

Le 2016-10-18 13:16, Christophe Sauthier a écrit :


Hello developer mailing list folks,

I'd like to propose that we add Pierre-Aexandre Bardina (pabardina)
as an OpenStack cloudkitty
core reviewer.

He has been a member of our community for a long time, contributing
very seriously in cloudkitty especially on the integration of
cloudkitty in Horizon (cloudkitty-dashboard)
He also provided some reviews on that part (well reviews for work
that he hasn't provided...) [1]

Overall I think Pierre-Alexandre would make a great addition to the
core review team.

Current Cloudkitty cores, please respond with +1/-1.

All the best,

            Christophe

http://stackalytics.com/report/contribution/cloudkitty-dashboard/90 
[1]



Christophe Sauthier                       Mail :
christophe.sauth...@objectif-libre.com
CEO                                       Mob : +33 (0) 6 16 98 63 
96 [2]
Objectif Libre                            URL : 
www.objectif-libre.com [3]

Au service de votre Cloud                 Twitter : @objectiflibre

Suivez les actualités OpenStack en français en vous abonnant à la
Pause OpenStack
http://olib.re/pause-openstack [4]

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


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

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


--

Shake Chen



Links:
--
[1] 
http://stackalytics.com/report/contribution/cloudkitty-dashboard/90

[2] tel:%2B33%20%280%29%206%2016%2098%2063%2096
[3] http://www.objectif-libre.com
[4] http://olib.re/pause-openstack
[5] 
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[6] 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] [tosca-parser] [heat-translator] cross-project design session with [Tacker] at summit

[Sahdev P Zala]

Qiming, hi, I meant to say Friday Oct 28th (October for Ocata :)) Thanks 
for noticing it. 

Absolutely, I have added it to the agenda and I will cover it. Totally 
understand the overlapping of various sessions. In the Heat Translator we 
have recently added support for translation to Senlin resources and we had 
some discussion on scaling with Tacker team couple weeks back, something 
which is already part of discussion at the summit. 

Thanks! 

Regards, 
Sahdev Zala




From:   Qiming Teng 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   10/18/2016 02:44 AM
Subject:Re: [openstack-dev] [tosca-parser] [heat-translator] 
cross-project design session with [Tacker] at summit



You meant Nov 28th, right?

Also, I'd like to join the discussion because Senlin can help offload
the clustering, auto-scaling and auto-healing work from Tacker so Tacker
can be more focused on the NFV support.

However, the schedule for design summit was ... very packed. There are
many sessions I'll have to miss. For this one, could you please help
bring up this topic? TOSCA-parser was a blocking factor for Tacker to
use Senlin directly. We will need some helps from your team.

Thanks.

Regards,
  Qiming

On Mon, Oct 17, 2016 at 11:58:42AM -0400, Sahdev P Zala wrote:
> Hi team, 
> 
> The TOSCA-Parser/Heat-Translator and Tacker will be having a 
cross-project 
> design session at the Barcelona summit. Sripriya has started etherpad 
doc 
> to collect discussion items. If you have any, please add it there. 
> 
> Friday, Nov 18th, 11:00am - 11:40am - Workroom Session
> Location: CCIB - Centre de Convencions Internacional de Barcelona - P1 - 

> Room 128
> 
> https://etherpad.openstack.org/p/tacker-ocata-summit
> 
> 
> Safe travels. See you there!
> 
> Regards, 
> Sahdev Zala
> 


__
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] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

[Raghunath D]

 Hi ,

How can instance created and deleted information/sample can be retrieved from 
ceilometer.
What entries should be there in pipeline.yaml  to get instance deleted 
information.

I tried to have meters- "instance" in pipeline.yam but it always gives active 
instance details,
and no details of deleted instances.

With Best Regards
 Raghunath Dudyala
 Tata Consultancy Services Limited
 Mailto: raghunat...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.  IT Services
Business Solutions
Consulting
 
 
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
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] Summit schedule is set

[Loo, Ruby]

Hello ironic'ers,

For the design sessions to be as productive as possible, please prepare 
beforehand so that the sessions are spent discussing and coming up with 
solutions/consensus, instead of describing and getting folks up-to-speed on the 
issues.

Feel free to add your comments directly in the etherpads (or as reviews in any 
proposed patches). This will be especially useful for people that cannot attend 
the sessions.

Thanks!

--ruby

From: Jim Rollenhagen 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, October 11, 2016 at 8:53 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [ironic] Summit schedule is set

Hi folks,

We've locked in our summit schedule, that is here (including a bonus
talk at the top due to how the search works):
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Ironic%3A

Please do let me know ASAP if there are any major conflicts.

If you've proposed one of the sessions, please do start filling in the
etherpad with proposals and references.

Thanks!

// jim

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

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

Re: [openstack-dev] [tripleo][ironic] introspection and CI

[Joe Talerico]

With large sets of nodes to introspect we typically avoid using the
bulk introspection. I have written a quick script that introspects a
couple nodes at a time:
https://gist.github.com/jtaleric/fcca3811cd4d8f37336f9532e5b9c9ff

Maybe we can add this sort of logic to bulk introspection, with some retries?

On Tue, Oct 18, 2016 at 8:29 AM, John Trowbridge  wrote:
>
>
> On 10/18/2016 07:20 AM, Wesley Hayutin wrote:
>> See my response inline.
>>
>> On Tue, Oct 18, 2016 at 6:07 AM, Dmitry Tantsur  wrote:
>>
>>> On 10/17/2016 11:10 PM, Wesley Hayutin wrote:
>>>
 Greetings,

 The RDO CI team is considering adding retries to our calls to
 introspection
 again [1].
 This is very handy for bare metal environments where retries may be
 needed due
 to random chaos in the environment itself.

 We're trying to balance two things here..
 1. reduce the number of false negatives in CI
 2. try not to overstep what CI should vs. what the product should do.

 We would like to hear your comments if you think this is acceptable for
 CI or if
 this may be overstepping.

 Thank you


 [1] http://paste.openstack.org/show/586035/

>>>
>>> Hi!
>>>
>>> I probably lack some context of what exactly problems you face. I don't
>>> have any disagreement with retrying it, just want to make sure we're not
>>> missing actual bugs.
>>>
>>
>> I agree, we have to be careful not to paper over bugs while we try to
>> overcome typical environmental delays that come w/ booting, rebooting $x
>> number of random hardware nodes.
>> To make this a little more crystal clear, I'm trying to determine is where
>> progressive delays and retries should be injected into the workflow of
>> deploying an overcloud.
>> Should we add options in the product itself that allow for $x number of
>> retries w/ a configurable set of delays for introspection? [2]  Is the
>> expectation this works the first time everytime?
>> Are we overstepping what CI should do by implementing [1].
>
> IMO, yes, we are overstepping what CI should be doing with [1]. Mostly
> because we are providing a better UX in CI than an actual user will get.
>>
>> Additionally would it be appropriate to implement [1], while [2] is
>> developed for the next release and is it OK to use [1] with older releases?
>>
>
> However, I think it is ok to implement [1] in CI, if the following are true:
>
> 1) There is an in progress bug to make this UX better for non-CI user.
> 2) For older releases if said bug is deemed inappropriate for backport.
>
>> Thanks for your time and responses.
>>
>>
>> [1] http://paste.openstack.org/show/586035/
>> [2]
>> https://github.com/openstack/tripleo-common/blob/master/workbooks/baremetal.yaml#L169
>>
>
> __
> 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] [tripleo][release] Tripleo Newton RC3 available

[Doug Hellmann]

Hello everyone,

A new release candidate for Tripleo for the end of the Newton cycle
is available. You can find the RC3 source code tarballs at:

https://tarballs.openstack.org/instack-undercloud/instack-undercloud-5.0.0.0rc3.tar.gz
https://tarballs.openstack.org/puppet-tripleo/puppet-tripleo-5.3.0.tar.gz
https://tarballs.openstack.org/python-tripleoclient/python-tripleoclient-5.3.0.tar.gz
https://tarballs.openstack.org/tripleo-common/tripleo-common-5.3.0.tar.gz
https://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-5.0.0.0rc3.tar.gz
https://tarballs.openstack.org/tripleo-ui/tripleo-ui-1.0.4.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC3 will be formally released as the final
Newton release on 20 October. You are therefore strongly encouraged
to test and validate these tarballs!

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/tripleo/+filebug

and tag it *newton-rc-potential* to bring it to the Tripleo release
crew's attention.

Thanks,
Doug

__
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] Core team updates

[Loo, Ruby]

Chris and Haomeng, thanks for your past reviews and I look forward to your 
return to the core team.

For the folks that are clearly reviewing far more than others, what do you 
think about asking them not to review so much? I'd vote for that :)

--ruby

From: Jim Rollenhagen 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, October 17, 2016 at 6:09 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [ironic] Core team updates

Hey friends,

The ironic-core team has done some great things over the last year.
We've landed a ton of code, grown some new members (and continually
growing more), and generally stayed pretty well connected.

However, some folks are clearly reviewing far more than others. While
I realize that folks may have commitments outside of ironic, I'd like to ask
everyone to be mindful of their review quantity (and always quality, of
course). :)

Reviews for the ironic umbrella in the last 90 days:
http://stackalytics.com/report/contribution/ironic-group/90

A good rule of thumb to try to meet is 3 reviews/day, which our top 8
reviewers are meeting (admittedly I am not).

There's also a couple people that haven't been active in the project
for quite a while that I'm dropping today:

Chris Krelle (NobodyCam)
Haomeng Wang (haomeng)

Of course, we welcome both of you back quickly if your activity picks
back up. :)

// jim

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

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

Re: [openstack-dev] [oslo] Propose support generate IPv4 and IPv6 random address( or network) for documentation(test?)

[Doug Hellmann]

Excerpts from Joshua Harlow's message of 2016-10-17 20:59:23 -0700:
> I think doug (he can correct me if I am wrong) was more wondering the 
> question of 'why would you want to use random data' in a test vs using 
> known fixed data. When a test fails it can be quite hard to identify the 
> reason if certain data that the test uses is randomized for each run.
> 
> Randomness might be useful, but it has always made me feel like 
> something is off when you see to much of it in tests...
> 
> -Josh

Yes, thanks, Josh, that's what I was trying to ask.

Doug

> 
> TommyLike Hu wrote:
> > Hmm,it's used to generate the ip address for validation or rule
> > checking, Meanwhile add some randomness. Of course it's unreasonable the
> > case you mentioned, please check the existed cases [1] and [2]
> >
> > [1]
> > https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/base.py#L828
> > [2]
> > https://github.com/openstack/manila/blob/master/manila_tempest_tests/tests/api/test_replication.py#L76
> >
> > Doug Hellmann >于
> > 2016年10月18日周二 上午12:01写道：
> >
> > Excerpts from TommyLike Hu's message of 2016-10-17 14:46:36 +:
> >  > It's used in testcase already, and basic codes is from here:
> >  >
> > 
> > https://github.com/openstack/manila/blob/master/manila_tempest_tests/utils.py#L93
> >
> > OK, I guess the real question I had is why use *random* addresses.
> > Because that seems like a way to end up having two tests try to use the
> > same address at the same time. If that did happen, would it cause
> > conflicts or race conditions for the manila tests?
> >
> >  >
> >  > Doug Hellmann  > >于2016年10月17日周一 下午10:13写道：
> >  >
> >  > > Excerpts from TommyLike Hu's message of 2016-10-17 09:56:15 +:
> >  > > > When I handle some stuff related to Manila recently, I found
> > a case which
> >  > > > may be suitable for Oslo, Anyhow I put it in the maillist so
> > it can be
> >  > > > discussed before I put it in action.
> >  > > > In testcase, we need a function(maybe 2) to generate random
> > ip address
> >  > > (or
> >  > > > network), also they should in the range of [1](ipv4
> > documentation range)
> >  > > or
> >  > > > [2](ipv6 documentation range), this is the draft code for ipv4:
> >  > > >
> >  > > > import six
> >  > > > import random
> >  > > >
> >  > > >
> >  > > > def rand_ipv4(network=False):
> >  > > > """This uses the TEST-NET-3 range of reserved IP addresses."""
> >  > > >
> >  > > > test_net_3 = '203.0.113.'
> >  > > > if network:
> >  > > > host_length = random.randint(0, 8)
> >  > > > address_segment = random.randint(0, 8 - host_length)
> >  > > > address_segment <<= host_length
> >  > > > address = test_net_3 + six.text_type(address_segment)
> >  > > > address = '/'.join((address,
> >  > > > six.text_type(32 - host_length)))
> >  > > > else:
> >  > > > address = test_net_3 +
> > six.text_type(random.randint(0, 255))
> >  > > > return address
> >  > > >
> >  > > > The primary use case here is writing testcases,  I am not
> > sure whether it
> >  > > > is suitable here, or maybe I misunderstood the intention of
> > TEST-NET-3,
> >  > > > please leave any comment you like.
> >  > > >
> >  > > >
> >  > > > [1] https://tools.ietf.org/html/rfc5737
> >  > > > [2] https://tools.ietf.org/html/rfc5156
> >  > >
> >  > > In what way are you using random addresses in tests?
> >  > >
> >  > > Doug
> >  > >
> >  > >
> > 
> > __
> >  > > 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
>