[openstack-dev] [new][oslo] oslo.messaging 5.12.0 release (ocata)

[no-reply]

We are exuberant to announce the release of:

oslo.messaging 5.12.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.11.0..5.12.0


b1b3677 Updated from global requirements
3efbdc7 Updated from global requirements
e5aceb3 Using assertIsNone() instead of assertEqual(None)
b28b287 Change assertTrue(isinstance()) by optimal assert
c9732d5 [zmq] Don't fallback to topic if wrong server specified
56c48c6 [TrivialFix] Replace old style assertions with new style assertions
7f2341b [TrivialFix] Fix typo in oslo.messaging
6eb57b4 [simulator] Fix a message length generator usage
998135b Update .coveragerc after the removal of respective directory
d054c31 [sentinels] Fix hosts extracting and slaves usage
1121a6b [zmq] SUB-PUB local proxy


Diffstat (except docs and test files)
-

.coveragerc|  2 +-
.../oslo_messaging_amqp_driver_overview.rst|  2 +-
.../zmq_driver/client/zmq_routing_table.py |  7 +-
.../zmq_driver/matchmaker/zmq_matchmaker_redis.py  | 53 ---
.../zmq_driver/proxy/central/zmq_central_proxy.py  | 58 +++--
.../proxy/central/zmq_publisher_proxy.py   |  4 +-
.../_drivers/zmq_driver/proxy/local/__init__.py|  0
.../zmq_driver/proxy/local/zmq_local_proxy.py  | 63 ++
.../_drivers/zmq_driver/proxy/zmq_base_proxy.py| 76 ++
.../_drivers/zmq_driver/proxy/zmq_proxy.py | 17 -
.../_drivers/zmq_driver/proxy/zmq_sender.py| 15 +
.../server/consumers/zmq_sub_consumer.py   | 30 +++--
oslo_messaging/_drivers/zmq_driver/zmq_address.py  |  4 +-
oslo_messaging/_drivers/zmq_driver/zmq_options.py  | 11 +++-
requirements.txt   |  6 +-
test-requirements.txt  |  4 +-
tools/simulator.py |  6 +-
23 files changed, 286 insertions(+), 124 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 59af9c1..11b5271 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -8 +8 @@ futurist!=0.15.0,>=0.11.0 # Apache-2.0
-oslo.config>=3.14.0 # Apache-2.0
+oslo.config!=3.18.0,>=3.14.0 # Apache-2.0
@@ -11 +11 @@ oslo.log>=3.11.0 # Apache-2.0
-oslo.utils>=3.16.0 # Apache-2.0
+oslo.utils>=3.17.0 # Apache-2.0
@@ -38 +38 @@ amqp<2.0,>=1.4.0 # LGPL
-kombu>=3.0.25 # BSD
+kombu!=4.0.0,>=3.0.25 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index b5a1384..b283a25 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -29 +29 @@ kafka-python<1.0.0,>=0.9.5 # Apache-2.0
-coverage>=3.6 # Apache-2.0
+coverage>=4.0 # Apache-2.0
@@ -34 +34 @@ oslosphinx>=4.7.0 # Apache-2.0
-reno>=1.8.0 # Apache2
+reno>=1.8.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.rootwrap 5.1.1 release (newton)

[no-reply]

We are glad to announce the release of:

oslo.rootwrap 5.1.1: Oslo Rootwrap

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

Changes in oslo.rootwrap 5.1.0..5.1.1
-

36e9592 Fix running unknown commands in daemon mode
be707c9 Update .gitreview for stable/newton


Diffstat (except docs and test files)
-

.gitreview |  1 +
oslo_rootwrap/daemon.py| 28 
3 files changed, 31 insertions(+), 12 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.utils 3.18.0 release (ocata)

[no-reply]

We are psyched to announce the release of:

oslo.utils 3.18.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.

3.18.0
^^

Other Notes

* Introduce reno for deployer release notes.

Changes in oslo.utils 3.17.0..3.18.0


7b7d5b9 Create dictutils and add 'flatten_dict_to_keypairs'
8bbf09e Updated from global requirements
a5a40ac Add reno for release notes management
f77d420 Trivial fixes to the usage doc
d0cd71c Add threading<->eventlet compatible Event
dfefb46 Updated from global requirements
69bf513 [TrivialFix] Replace 'assertEqual(None, ...)' with 'assertIsNone(...)'
797d376 Add __ne__ built-in function


Diffstat (except docs and test files)
-

.gitignore|   3 +
oslo_utils/dictutils.py   |  31 +++
oslo_utils/eventletutils.py   |  35 +++
releasenotes/notes/add-reno-350f5f34f794fb5e.yaml |   3 +
releasenotes/source/_static/.placeholder  |   0
releasenotes/source/_templates/.placeholder   |   0
releasenotes/source/conf.py   | 276 ++
releasenotes/source/index.rst |   9 +
releasenotes/source/newton.rst|   6 +
releasenotes/source/unreleased.rst|   5 +
test-requirements.txt |   6 +-
tox.ini   |   3 +
19 files changed, 449 insertions(+), 6 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index c0c35e1..d9b615f 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -17 +17 @@ oslotest>=1.10.0 # Apache-2.0
-coverage>=3.6 # Apache-2.0
+coverage>=4.0 # Apache-2.0
@@ -27 +27 @@ mock>=2.0 # BSD
-oslo.config>=3.14.0 # Apache-2.0
+oslo.config!=3.18.0,>=3.14.0 # Apache-2.0
@@ -30,0 +31,2 @@ bandit>=1.1.0 # Apache-2.0
+
+reno>=1.8.0 # Apache2
\ No newline at end of file



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

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

[Sam Morrison]

> On 4 Nov. 2016, at 1:33 pm, Emilien Macchi  wrote:
> 
> On Thu, Nov 3, 2016 at 9:10 PM, Sam Morrison  > wrote:
>> Wow I didn’t realise puppet3 was being deprecated, is anyone actually using 
>> puppet4?
>> 
>> I would hope that the openstack puppet modules would support puppet3 for a 
>> while still, at lest until the next ubuntu LTS is out else we would get to 
>> the stage where the openstack  release supports Xenial but the corresponding 
>> puppet module would not? (Xenial has puppet3)
> 
> I'm afraid we made a lot of communications around it but you might
> have missed it, no problem.
> I have 3 questions for you:
> - for what reasons would you not upgrade puppet?

Because I’m a time poor operator with more important stuff to upgrade :-)
Upgrading puppet *could* be a big task and something we haven’t had time to 
look into. Don’t follow along with puppetlabs so didn’t realise puppet3 was 
being deprecated. Now that this has come to my attention we’ll look into it for 
sure.

> - would it be possible for you to use puppetlabs packaging if you need
> puppet4 on Xenial? (that's what upstream CI is using, and it works
> quite well).

OK thats promising, good to know that the CI is using puppet4. It’s all my 
other dodgy puppet code I’m worried about.

> - what version of the modules do you deploy? (and therefore what
> version of OpenStack)

We’re using a mixture of newton/mitaka/liberty/kilo, sometimes the puppet 
module version is newer than the openstack version too depending on where we’re 
at in the upgrade process of the particular openstack project.

I understand progress must go on, I am interested though in how many operators 
use puppet4. We may be in the minority and then I’ll be quiet :-)

Maybe it should be deprecated in one release and then dropped in the next?


Cheers,
Sam





> 
>> My guess is that this would also be the case for RedHat and other distros 
>> too.
> 
> Fedora is shipping Puppet 4 and we're going to do the same for Red Hat
> and CentOS7.
> 
>> Thoughts?
>> 
>> 
>> 
>>> On 4 Nov. 2016, at 2:58 am, Alex Schultz  wrote:
>>> 
>>> Hey everyone,
>>> 
>>> Puppet 3 is reaching it's end of life at the end of this year[0].
>>> Because of this we are planning on dropping official puppet 3 support
>>> as part of the Ocata cycle.  While we currently are not planning on
>>> doing any large scale conversion of code over to puppet 4 only syntax,
>>> we may allow some minor things in that could break backwards
>>> compatibility.  Based on feedback we've received, it seems that most
>>> people who may still be using puppet 3 are using older (< Newton)
>>> versions of the modules.  These modules will continue to be puppet 3.x
>>> compatible but we're using Ocata as the version where Puppet 4 should
>>> be the target version.
>>> 
>>> If anyone has any concerns or issues around this, please let us know.
>>> 
>>> Thanks,
>>> -Alex
>>> 
>>> [0] https://puppet.com/misc/puppet-enterprise-lifecycle
>>> 
>>> ___
>>> OpenStack-operators mailing list
>>> openstack-operat...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
>> 
> 
> 
> 
> -- 
> 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] [cinder] generic volume groups and consistency groups

[yang, xing]

Hi everyone,

Generic volume groups support was added in Cinder in Newton.  We are planning 
to migrate consistency groups to generic volume groups.  I have submitted a dev 
doc patch to explain how to add consistency groups support in generic volume 
groups in a driver.  Let me know if you have any questions or provide comments 
on the patch.

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

As discussed at the summit in Barcelona, drivers already supporting CG should 
add CG support in generic volume groups by Pike-1.  Drivers planning to 
introduce CG support should implement the driver interfaces for generic volume 
groups instead.  Drivers wanting generic volume groups but not CG do not need 
code changes because the default implementation should work for every driver.  
Please see details in the above patch.

Thanks,
Xing

IRC: xyang or xyang1



From: yang, xing [xing.y...@dell.com]
Sent: Tuesday, November 1, 2016 10:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Jason Dillaman
Subject: Re: [openstack-dev] [cinder] consistency groups in ceph

Hi Victor,

Please see my answers inline below.

In Newton, we added support for Generic Volume Groups.  See doc below.  CGs 
will be migrated to Generic Volume Groups gradually.  Drivers should not 
implement CGs any more.  Instead, it can add CG support using Generic Volume 
Group interfaces.  I'm working on a dev doc to explain how to do this and will 
send an email to the mailing list when I'm done.  The Generic Volume Group 
interface is very similar to CG interface, except that the Generic Volume Group 
requires an additional Group Type parameter to be created.  Using Group Type, 
CG can be a special type of Generic Volume Group.  Please feel free to grab me 
on Cinder IRC if you have any questions.  My IRC handle is xyang or xyang1.

http://docs.openstack.org/admin-guide/blockstorage-groups.html

Thanks,
Xing



From: Victor Denisov [vdeni...@mirantis.com]
Sent: Monday, October 31, 2016 11:29 PM
To: openstack-dev@lists.openstack.org
Cc: Jason Dillaman
Subject: [openstack-dev] [cinder] consistency groups in ceph

Hi,

I'm working on consistency groups feature in ceph.
My question is about what kind of behavior does cinder expect from
storage backends.
I'm particularly interested in what happens to consistency groups
snapshots when I remove an image from the group:

Let's imagine I have a consistency group called CG. I have images in
the consistency group:
Im1, Im2, Im3, Im4.
Let's imagine we have snapshots of this consistency group:

CGSnap1
CGSnap2
CGSnap3

Snapshots of individual images in a consistency group snapshot I will call
CGSnap2Im1 - Snapshot of image 1 from consistency group snapshot 2.

Qustion 1:
If consistency group CG has 4 images: Im1, Im2, Im3, Im4.
Can CGSnap1 have more images than it already has: Im1, Im2, Im3, Im4, Im5.

Can CGSnap1 have less images than it already has: Im1, Im2, Im3.

[Xing]  Once a snapshot is taken from a CG, it can no longer be changed.  It is 
a point-in-time copy.  CGSnap1 cannot be modified.

Question 2:
If we remove image2 from the consistency group. Does it mean that
snapshots of this image should be removed from all the CGSnaps.

Example:
We are removing Im2.
CGSnaps look like this:

CGSnap1 - CGSnap1Im1, CGSnap1Im2, CGSnap1Im3
CGSnap2 - CGSnap2Im1, CGSnap2Im2, CGSnap2Im3, CGSnap3Im4
CGSnap3 - CGSnap3Im1, CGSnap3Im2, CGSnap3Im3, CGSnap3Im4

What happens to snapshots: CGSnap1Im2,CGSnap2Im2, CGSnap3Im2? Do we
remove them, do we keep them. Is it important what we do to them at
all?

[Xing] If your CG contains 4 volumes when you take the snapshot of the CG, the 
resulting CGSnap should be associated with 4 snapshots corresponding to the 4 
volumes.  If you add more volumes to the CG or remove volumes from CG after 
CGSnap was taken, it should not affect CGSnap.  It will only affect CG 
snapshots that you take in the future.

Thanks,
Victor.

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

[openstack-dev] [neutron] Barcelona summit neutron-lib session recap

[Henry Gessau]

Ocata neutron-lib session recap
---

tl;dr:
 - Speed up moving common code into neutron-lib
 - Sub-project maintainers must keep up and should contribute

The session consisted of announcing the goals around speeding up the
neutron-lib work so that consuming projects can remove their dependency on
core neutron. No objections to the speed-up were raised during the session.

Updates to policies:
1) No more debtcollector deprecations on neutron core changes when adopting
neutron-lib code (unless it affects projects beyond those that integrate with
neutron). See below for details.
2) Provide unit test base classes and utils in neutron-lib (reverses previous
decision).
3) Spend more effort on rehoming code from neutron, less on tweaking what
is already in lib.
4) All stadium REST APIs must go in the api-ref.

The above will be detailed in the devref[1], but here is a summary:


1. No more deprecations

When a new version of neutron-lib is released the new features should be
adopted immediately by all consuming projects. One month after the release,
code will be removed from neutron core if it is available in neutron-lib.
**NOTE** This will break sub-projects that are not keeping up.
(No one at the session objected to this.)
As part of this effort we are requiring release notes in neutron-lib patches
that impact consuming projects.

2. Unit test framework

Base classes and utility functions will be provided. Some minor refactoring
for cleaner code-reuse will be needed. Base test classes for ml2 will also be
provided.

3. Rehome first, tweak later

Let's de-prioritize the tweaking of code already in neutron-lib until after
all the stadium projects have stopped importing neutron core.

3b. Shed technical debt

Rehoming ugly code will give us a ugly library. Some existing neutron code
needs to be refactored before being made available in neutron-lib.

4. Complete api-ref

All REST API extensions from stadium sub-projects must be documented in the
api-ref. The api definitions must also be added.
The existing api-ref update work will continue. We encourage developers to
look for discrepancies and propose fixes.



The following items were not addressed:
 - Not enough core reviewer attention in neutron-lib.
 - Config options in neutron-lib. There is an email thread[2] about this.


[1] https://review.openstack.org/331338
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-October/106369.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

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

[Emilien Macchi]

On Thu, Nov 3, 2016 at 9:10 PM, Sam Morrison  wrote:
> Wow I didn’t realise puppet3 was being deprecated, is anyone actually using 
> puppet4?
>
> I would hope that the openstack puppet modules would support puppet3 for a 
> while still, at lest until the next ubuntu LTS is out else we would get to 
> the stage where the openstack  release supports Xenial but the corresponding 
> puppet module would not? (Xenial has puppet3)

I'm afraid we made a lot of communications around it but you might
have missed it, no problem.
I have 3 questions for you:
- for what reasons would you not upgrade puppet?
- would it be possible for you to use puppetlabs packaging if you need
puppet4 on Xenial? (that's what upstream CI is using, and it works
quite well).
- what version of the modules do you deploy? (and therefore what
version of OpenStack)

> My guess is that this would also be the case for RedHat and other distros too.

Fedora is shipping Puppet 4 and we're going to do the same for Red Hat
and CentOS7.

> Thoughts?
>
>
>
>> On 4 Nov. 2016, at 2:58 am, Alex Schultz  wrote:
>>
>> Hey everyone,
>>
>> Puppet 3 is reaching it's end of life at the end of this year[0].
>> Because of this we are planning on dropping official puppet 3 support
>> as part of the Ocata cycle.  While we currently are not planning on
>> doing any large scale conversion of code over to puppet 4 only syntax,
>> we may allow some minor things in that could break backwards
>> compatibility.  Based on feedback we've received, it seems that most
>> people who may still be using puppet 3 are using older (< Newton)
>> versions of the modules.  These modules will continue to be puppet 3.x
>> compatible but we're using Ocata as the version where Puppet 4 should
>> be the target version.
>>
>> If anyone has any concerns or issues around this, please let us know.
>>
>> Thanks,
>> -Alex
>>
>> [0] https://puppet.com/misc/puppet-enterprise-lifecycle
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
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] [neutron][networking-vpp] - Status of startup issues

[Feng Pan]

Hi John,

I think the fix that will most likely go in is
https://review.openstack.org/#/c/391523/. Removing local cache should
fairly cleanly make the physnets check work. Currently our CI gate is
broken on a package versioning problem, once the CI fix goes in (
https://review.openstack.org/#/c/392879/) we should be able to push this
through.

Thanks
Feng

On Thu, Nov 3, 2016 at 4:17 PM, Jerome Tollet (jtollet) 
wrote:

> thx
>
>
>
> *De : *"John Joyce (joycej)" 
> *Répondre à : *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date : *jeudi 3 novembre 2016 à 15:23
> *À : *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Objet : *[openstack-dev] [neutron][networking-vpp] - Status of startup
> issues
>
>
>
> Is anyone able to provide a summary of which patches fix the startup
> scenarios. Any startup issues are of interest but the one we specifically
> have bugs around is the phsynets not being discovered by the server
> properly.
>
> I see: https://bugs.launchpad.net/networking-vpp/+bug/1631063 which says
> a fix was committed, but no reference to the what the fix is and I don’t
> think the fix really merged yet as https://review.openstack.org/#
> /c/386280/ is reporting to be fixing it.
>
> Are all these patches associated with the issue:
>
> https://review.openstack.org/#/c/382587/
>
> https://review.openstack.org/#/c/386280/
>
> https://review.openstack.org/#/c/391523/
>
> https://review.openstack.org/#/c/381538/
>
> If not which of the above are required to get a clean start-up.  Does
> anyone have the complete picture?
>
>
> 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
>
>
__
OpenStack Development Mailing 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] [tricircle]Barcelona design summit sessions recap

[joehuang]

Hello,

During the two sessions in Barcelona and the weekly meeting this week, the 
summary is located in 
https://etherpad.openstack.org/p/ocata-tricircle-work-session

Contents also attached here:

Milestones:
Ocata-2: Dec.15
Ocata-3: Jan.26
Release: Feb.22

Topics:

Title: shared vxlan L2 networking across Neutron (ocata-3 or Release? Ocata-3)

  * driver mechanism to support different L2 networking method, first one 
is shared VLAN, the second one could be VxLAN by remote port, the third one 
could be VxLAN by VTEP list...

  * Shared VxLAN support (the implementation of the driver is easy, but we 
rely on some softwares to connect the networks in both OpenStack instances)

  *   (1) "remote port" mechanism (has no dependency and can be developed 
in Tricircle itself), dependency in "Neutron VTEP in Port"

  *   Has dependency on a planned Neutron patch

  *   make sure what VTEP ip is stored in the port, just local ip, or both 
local and remote ip

  *   If there is a bp ready we can jump into it

  *   Due to the short time window of Ocata maybe Tricicle functionality 
implementation have not enough time

  *   Discuss the plan with Neutron team: 
https://etherpad.openstack.org/p/ocata-neutron-agents at 11:00 - 11:40

  *   (2) flooding vtep (patches submitted to the Neutron project but not 
merged yet, hope it will be merged in the Ocata circle)

  *   (3) remote L2 gateway (tested by code not meregd in the upstream)

  *

  *   submit a spec first

Title: routed network support across Neutron (do we need this for ocata 
release?, it'll be good to have, best effort)

  *   Reference: 
https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html

  *   1) new type driver for the routed network

  *   2) update the design document

  *   3) update the user guide and installation guide

  *   submit a spec first

Title: User guide Documentation improvement (ocata-2)

  *   User guide to install Tricircle to DevStack

  *   Not always clear

  *   Contribution is needed to make it better

Title: configuration guide improvement (ocata-2)

  *   A seperate configuration guide for detaile of each configuration items

  *   Configuration for local plugin and central plugin

  *

Title: Installation guide improvement (ocata-2)

  *   not only installation guide for DevStack, but also how to install 
Tricircle manually

  *   both for local plugin and central plugin, Admin API and XJob

  *   api-cfg.conf

  *   tricircle_plugin-cfg.conf

  *   xjob-cfg.conf

Title: Admin api development
Abstract: We are moving the nova/cinder api gateway part  out of Tricircle and 
form a new project called TriO2O, but these project share the admin api for 
manage pod and pod binding. How about the later development of the admin api? 
We maintain the admin api separately in each project, or develop in one project 
then sync to the other project? If users would like to run both Tricircle and 
TriO2O, do they need to run two admin api services?

Title: DB api reconstruction (ocata-3)

Title: Ocata Milestone definition
We are  planning to define less milestone, so that there is some windows to 
adapt the milestone based plan, and next cycle keep align with the same 
milestone.

  *   Milestones:

  *   Ocata-2: Dec.15

  *   Ocata-3: Jan.26

  *   Release: Feb.22

Title: Advanced services? not supported yet

  *   VPNaaS - Best Effort(ocata-3)

  *

Title:  Resouce mapping API +1 (ocata-2)

  *   Code patch

  *   Documentation

  *

Title: Job management API +1 (ocata-3)

  *   List jobs

  *   Redo job

  *   Cancel job

Title: Tempest test cases

  *   #action enable single node devstack first

Title: multi-region gate test environment

  *#action consult infra team how to enable multi-region environment in 
gate and check job

Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing 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] [jjb] Multibranch pipeline/workflow better support?

[Joshua Harlow]

Hi folks using jenkins-job-builder,

I was just looking around for better additions to the 
jenkins-job-builder for multibranch workflows (see 
https://jenkins.io/blog/2015/12/03/pipeline-as-code-with-multibranch-workflows-in-jenkins/) 
and stumbled into the following:


https://github.com/abnamrocoesd/jenkins-job-builder/commits/master

Which seems to have:

https://github.com/abnamrocoesd/jenkins-job-builder/commit/26d0c923d1efee1ca28490ed38e43a2360b257d0

That one seems to be what I am looking for in terms of support and I"m 
wondering if anyone has started to upstream something similar.


Basically I'd like to be able to configure jenkins from jjb yaml files 
to specify that the multi-branch repos and such without having to go 
through the jenkins UI to do so (for all the known reasons).


Anyone else been working on this? (since I would assume I can't be the 
only one, ha)


PS: https://review.openstack.org/#/c/323744/ seems similar but not 
exactly the same as the above commit.


-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] [Docs] Changes to docs speciality teams, meetings, and reporting

[Lana Brindley]

Hi everyone,

There was a long-running and wide-ranging conversation during Summit about 
community engagement in the docs team, most formally at the 'Social Things' 
session[1], and culminating in the 'Ocata Planning' session[2] on the last day. 
I suggest you read those etherpads if you weren't at the sessions. This was a 
major part of my PTL candidacy platform for Ocata, and I'm excited that we had 
so much productive conversation, complete with  some action items that we can 
implement immediately.

First of all, we have seen a drop off in both docs mailing list traffic and 
docs meeting conversation over the past twelve months or so, even though 
contributions have remained steady (for the openstack-manuals repo). This is 
attributed partially to a much-improved Contributor Guide (meaning we spend 
less time on answering the same questions over and over), and but it's also 
apparently because conversation is splintering off into speciality team groups, 
rather than happening in the wider context of the docs group as a whole. 

So, while speciality teams are definitely valued and important, especially when 
it comes to directing and completing specific work items, we have come up with 
a few smaller changes we can make to try and improve our sense of community:

* Speciality team meetings are now going to be restricted to once per month, or 
on an as-needed basis.
* The docs meeting will change to a single Euro/APAC timed meeting, every 
second week, probably around 2100 UTC (to be  confirmed).
* I will no longer be asking speciality team leads for a written report for the 
newsletter. Instead, please attend the docs meeting and report there. If you 
are not able to attend, you will have the option to provide a written report 
ahead of time to be presented by a proxy. 
* The newsletter will go to every second week, timed to be after the docs 
meeting, and will contain speciality team reports and other updates from that 
meeting.

I would like your feedback on these changes, especially if you didn't get a 
chance to  participate in the conversation at Summit.

I will be implementing these changes over the next week or so, and there will 
be further opportunity for you  to express your opinion on these changes as we 
go.

Lana

1: https://etherpad.openstack.org/p/BCN-Docs-Social
2: https://etherpad.openstack.org/p/BCN-Docs-OcataPlanningWG

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

[Sam Morrison]

Wow I didn’t realise puppet3 was being deprecated, is anyone actually using 
puppet4?

I would hope that the openstack puppet modules would support puppet3 for a 
while still, at lest until the next ubuntu LTS is out else we would get to the 
stage where the openstack  release supports Xenial but the corresponding puppet 
module would not? (Xenial has puppet3)

My guess is that this would also be the case for RedHat and other distros too.

Thoughts?



> On 4 Nov. 2016, at 2:58 am, Alex Schultz  wrote:
> 
> Hey everyone,
> 
> Puppet 3 is reaching it's end of life at the end of this year[0].
> Because of this we are planning on dropping official puppet 3 support
> as part of the Ocata cycle.  While we currently are not planning on
> doing any large scale conversion of code over to puppet 4 only syntax,
> we may allow some minor things in that could break backwards
> compatibility.  Based on feedback we've received, it seems that most
> people who may still be using puppet 3 are using older (< Newton)
> versions of the modules.  These modules will continue to be puppet 3.x
> compatible but we're using Ocata as the version where Puppet 4 should
> be the target version.
> 
> If anyone has any concerns or issues around this, please let us know.
> 
> Thanks,
> -Alex
> 
> [0] https://puppet.com/misc/puppet-enterprise-lifecycle
> 
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


__
OpenStack Development Mailing 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] Nova-MultiJob CI (non-voting) request to comment

[Matt Riedemann]

On 11/3/2016 3:45 AM, Lenny Verkhovsky wrote:

Hi,

We would like Mellanox[1] MultiNode CI job  to start commenting as ‘non
voting’ job on partial nova[2] and tempest[3] code.

This Job runs few migration tests[4] and an example of its run can be
seen here[5].



[1] https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI

[2] nova/pci

[3] tempest/ scenario

[4]
http://13.69.151.247/98/348498/6/check-sriov-tempest/Nova-ML2-Sriov-Multinode/46e401e/testr_results.html.gz

[5] https://review.openstack.org/#/c/348498/6





Thanks

Lenny (aka lennyb on irc)













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



What's different about this job configuration from the other Mellanox 
CIs that already run against nova?


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

[Adrian Turjak]

On 04/11/16 01:16, Julien Danjou wrote:
> On Thu, Nov 03 2016, Adrian Turjak wrote:
>
>> I'd need to double check exactly what query it is, but it effectively
>> amounts to:
>> "List all instance metric samples where project_id is  and timestamp
>> is in time range -"
>>
>> The time range is an hour + leadin from last hour to catch the last
>> sample from the previous window.
> You can do exactly the same thing in Gnocchi by listing resources alive
> during the timeframe you are interested in.
>
> The main gain by switching to Gnocchi is that you don't have to "sync
> every hour from Ceilometer". You can just use it as a backend to
> generate your billing directly.
>
Yeah, sounds like it. I've been looking forward to playing with gnocchi
for a while but just had no time and honestly it's about time we switch
to using it. Ceilometer was a pain and it always felt like we were
coding around issues in Ceilometer.

I have a feeling we'll still need to transform the data into our own
system, but it will become much easier. I'll use the switch to gnocchi
as an excuse to refactor most of our billing I think.

Thanks for answering my questions. :)


__
OpenStack Development Mailing 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] [monasca] License for monasca-statsd

[Jeremy Stanley]

On 2016-11-03 18:17:42 -0400 (-0400), Chuck Short wrote:
> I have checked the version on pypi and tarballs.openstack.org and all the
> versions from monasca-statsd from 1.0.0 onwards provide the incorrect
> LICENSE file.

Right, I'm saying I hope the files which have Apache license headers
in them aren't actually derivatives of something which had a Datadog
license, which would be unfortunate from a legal/copyright
standpoint. Ideally that LICENSE file is just wrong and can be
deleted/replaced, but someone from the Monasca team would need to
weigh in on whether that's the case.
-- 
Jeremy Stanley


signature.asc
Description: 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] [monasca] License for monasca-statsd

[Chuck Short]

On Thu, Nov 3, 2016 at 3:55 PM, Jeremy Stanley  wrote:

> On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote:
> > I was looking at packaging monasca-statsd since it is a dependency for
> > designate, however when I look at the license for it,it says Apache-2.
> > However the LICENSE file included in the source  is that the software is
> > provided as is...etc etc. Could we get some clarification please?
>
> It looks like https://review.openstack.org/123315 added that
> LICENSE file when originally setting up the monasca-statsd repo a
> couple years ago. I see a variety of Datadog repositories in
> circulation using that license, and they seem to refer to it as "a
> simplified BSD license" (which is certainly what it looks like to me
> as well). However, all the individual files added in that change
> which declare a license in their headers seem to use Apache License
> 2.0, which I agree is confusing. Hopefully the Datadog license was
> added here in error, and we've not actually been shipping an
> incorrectly-licensed derivative of their software this entire time?
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

Hi,

I have checked the version on pypi and tarballs.openstack.org and all the
versions from monasca-statsd from 1.0.0 onwards provide the incorrect
LICENSE file.

chuck
__
OpenStack Development Mailing 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][dev][python] constructing a deterministic representation of a python data structure

[Clint Byrum]

Excerpts from Amrith Kumar's message of 2016-11-03 20:50:01 +:
> Josh,
> 
> I have the key management part figured out and in actuality I will be
> signing the messages. 
> 
> But step 1 is getting a deterministic representation and step 2 is hashing.
> Step 3 would be signing.
> 
> So, steps 2 and 3 are all set; just need step 1 :) And I'm marveling at the
> link that Morgan provided, it may have what I need.
> 

Please please please do not invent your own home rolled cryptographic
envelope!!

sender.py:


to_send = {
  'fact': 'red is the best color'
}
payload = json.dumps(to_send)
message = gpg_sign(payload, key)
send_message(message)


receiver.py:

message = recv_message()
(payload, key) = gpg_verify_message(message)
if key not in trusted_keys:
  raise Exception('Untrusted sender!')
operate_on_payload(payload)

With all due respect, any of us are almost guaranteed to screw it up
otherwise. Just use a thing known to work. There are plenty already.

__
OpenStack Development Mailing 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] [mistral] Ocata summit summary

[Lingxian Kong]

Thanks for sharing this, Renat!


Cheers,
Lingxian Kong (Larry)

On Thu, Nov 3, 2016 at 8:41 PM, Renat Akhmerov 
wrote:

> Hi,
>
> I’d like to share the summary of activities happened in Barcelona around
> Mistral.
>
> = Presentations =
>
> 1. *Building Self-healing Applications with Aodh, Zaqar and Mistral*
>
> https://www.openstack.org/videos/video/building-self-
> healing-applications-with-aodh-zaqar-and-mistral
>
> It gives pretty interesting info on how to use Mistral in conjunction with
> other technologies like Aodh (alarming system)
> and Zaqar to build something useful.
>
>
> 2. *Nokia: TOSCA & Mistral: Orchestrating End-to-End Telco Grade NFV*
>
> https://www.openstack.org/videos/video/nokia-tosca-and-
> mistral-orchestrating-end-to-end-telco-grade-nfv
>
> This is a quick introduction into Mistral (I believe from a slightly
> different angle than before) and the detailed description
> of one of the main Mistral use cases that we have at Nokia CloudBand.
>
> = Fishbowl =
>
> http://www.slideshare.net/DmitriZimine/mistral-and-stackstorm
>
> We had a very very cool fishbowl this time. Thanks a ton to Dmitri Zimine!
> Dmitri was talking about Mistral and StackStorm and his vision of the
> industry regarding workflow based automation,
> value of workflows and possible strategies on how StackStorm and Mistral
> can become more seamless in the future.
>
> = Design Sessions =
>
> https://etherpad.openstack.org/p/mistral-barcelona-summit-topics-2016
>
> Although we had only 2 design sessions (my fault, I should have asked
> more), we were able to discuss lots of technical
> topics during them and the contributors meetup that we had Friday
> afternoon.
>
> I won’t be repeating here everything what’s in the etherpad but
> summarizing it I would say that we’re now finally taking a
> course on making Mistral more consumable. For example, we have a bunch of
> plans on how to improve our documentation
> (better structure, more examples and cookbooks). We are also willing to
> fix our actions subsystem which is now not very
> mature, to be honest. Specifically, it applies to how we write actions and
> what’s available in Mistral code base to help with
> this, test coverage of OpenStack actions is now very basic and requires a
> more solid approach. We’re making big steps
> now towards it. Generally, I have to admit that actions is one of our
> biggest problems now because existing OpenStack
> actions often go out of sync with underlying APIs and a lot of new people
> start getting familiar with Mistral exactly by
> trying workflows with OpenStack actions, so those workflows often simply
> don’t work and that makes an impression that
> Mistral doesn’t work. Although the core Mistral functionality is now
> pretty robust and performant. We need to improve it
> asap (as a matter of fact, yesterday).
>
>
> Any feedback or comments on what we’re doing in Mistral are very welcome!
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing 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] [Neutron] summit sessions - feedback

[Armando M.]

Hi Neutrinos,

You will be noticing a few emails getting into your inbox with subject
 summit recap or similar.

Watch out for those if you're interested in making sense of the discussions
as captured on etherpads [1].

Many thanks to the session chairs for the effort!

Cheers and happy hacking!
Armando

[1] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Neutron
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking-ovn] restart failure to bring up ovn services

[Murali R]

>
> The OVN packages install systemd units, so you can also start it that way
> and set it up to re-start after a reboot.
>
> $ sudo systemctl enable ovn-northd
> $ sudo systemctl start ovn-northd
>
>
I did install python_networking_ovn & openvswitch-switch. I could not find
any other ovn packages in apt list. But the systemd services are somehow
not getting configured right, so I am doing manual start after restarts. It
probably works with redhat packages, not sure.
__
OpenStack Development Mailing 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][dev][python] constructing a deterministic representation of a python data structure

[Davanum Srinivas]

Amrith,

Please see the older work from 2013:
https://blueprints.launchpad.net/oslo.messaging/+spec/trusted-messaging
https://etherpad.openstack.org/p/HavanaOsloMessaging
https://blog-nkinder.rhcloud.com/?p=62
https://adam.younglogic.com/2014/04/pki-for-oslo-messaging/

-- Dims


On Thu, Nov 3, 2016 at 3:35 PM, Amrith Kumar  wrote:
> Dims, I don't think ovo addresses this issue. It isn't one of versioning that 
> I'm attempting to address but rather as Gordon points out, of signing and 
> verifying authenticity. Please see also my longer response to him on this.
>
> -amrith
>
> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: Thursday, November 3, 2016 3:03 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic 
> representation of a python data structure
>
> Does oslo.versionedobjects solve some of your needs?
>
> http://www.slideshare.net/davanum/ovo-deep-dive
> https://gorka.eguileor.com/learning-something-new-about-oslo-versioned-objects/
> http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/
>
> -- Dims
>
> On Thu, Nov 3, 2016 at 2:24 PM, Amrith Kumar  wrote:
>> TL;DR
>>
>>
>>
>> I want to take a python data structure (see later for details) and
>> represent it in a format that will be stable across python versions,
>> and platforms so that I can construct a stable hash. I’m looking for
>> pointers to some best practices on how to do this.
>>
>>
>>
>> The longer version
>>
>>
>>
>> Assume that there’s some function in python that is:
>>
>>
>>
>> def fn(*args, **kwargs):
>>
>> …
>>
>>
>>
>> I’d like to take (args, kwargs) and construct a hash of some
>> representation that is deterministic. Specifically, assume that fn()
>> is a method in the API (oslo.messaging transport …). I’d like to
>> construct the hash on the sender side and on the RPC server side and
>> make sure that the parameters are the same.
>>
>>
>>
>> So, just before calling call() or cast(), I could compute the hash and
>> stuff it into the dictionary that is being sent over, and I can do the
>> same on the receiving side. But since I cannot guarantee that the
>> representation on the receiving side is necessarily identical to the
>> representation on the sending side, I have issues computing the hash.
>>
>>
>>
>> In IRC, jroll suggested json; can one safely assume that json.dumps()
>> is a deterministic representation?
>>
>>
>>
>> Thanks for any pointers and suggestions.
>>
>>
>>
>> -amrith
>>
>>
>> __
>>  OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing 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][dev][python] constructing a deterministic representation of a python data structure

[Amrith Kumar]

 

 

From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] 
Sent: Thursday, November 3, 2016 4:31 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic 
representation of a python data structure

 

 

On Thu, Nov 3, 2016 at 1:04 PM, Amrith Kumar  > wrote:

Gordon,

You can see a very quick-and-dirty prototype of the kind of thing I'm
looking to do in Trove at
https://gist.github.com/amrith/6a89ff478f81c2910e84325923eddebe

Uncommenting line 51 would simulate a bad hash.

I'd be happy to propose something similar in oslo.messaging if you think
that would pass muster there.

-amrith

-Original Message-
From: gordon chung [mailto:g...@live.ca  ]
Sent: Thursday, November 3, 2016 3:09 PM
To: openstack-dev@lists.openstack.org 
 
Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic
representation of a python data structure




On 03/11/16 02:24 PM, Amrith Kumar wrote:

>
> So, just before calling call() or cast(), I could compute the hash and
> stuff it into the dictionary that is being sent over, and I can do the
> same on the receiving side. But since I cannot guarantee that the
> representation on the receiving side is necessarily identical to the
> representation on the sending side, I have issues computing the hash.
>
>

based on description, you're trying to sign the messages? there was some
effort done in oslo.messaging[1]

we do something similar in Ceilometer to sign IPC messages[2]. it does add
overhead though.

[1] https://review.openstack.org/#/c/205330/
[2]
https://github.com/openstack/ceilometer/blob/ffc9ee99c10ede988769907fdb0594a 

 
512c890cd/ceilometer/publisher/utils.py#L43-L58

cheers,
--
gord

__
OpenStack Development Mailing 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

 

I had to solve a similar issue for deterministic key generation in dogpile (key 
for memcache/etc) when memoizing methods/functions with kwargs. There are a 
couple issues you run into, default args are not represented in **kwargs, and 
non-positional args can come in any order. 

 

[Amrith Kumar] This, as it turns out, is a good thing. In the specific use case 
that I have, the sender of the message may be on one version and the recipient 
may be on a later version which defaults some parameters. Therefore 
intercepting and handing the arguments in a decorator is perfect for me because 
I don’t get to see the impact of the default arguments that are added by the 
new version of the receiver. Also, since this is used in the context of cast() 
and call() in oslo.messaging, all parameters are passed as kwargs and there are 
no positional arguments.

 

Here, for example, is a call to _cast() for the resize_flavor() RPC call in the 
Trove Taskmanager.

 

def resize_flavor(self, instance_id, old_flavor, new_flavor):

…

 

self._cast("resize_flavor", self.version_cap,

   instance_id=instance_id,

   old_flavor=self._transform_obj(old_flavor),

   new_flavor=self._transform_obj(new_flavor))

 

If you want an example of what we did to generate the cache-key programatically 
you can look here:

 

https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/util.py?at=master
 

 =file-view-default#util.py-67:118

 

[Amrith Kumar] Thanks, this is awesome! But, maybe a little more than I need. 
I’ll snag the guts of generate_key() and that should give me what I need (I 
think).

 

You don't need all the namespace and probably not fn/module info, but this can 
look at the call and handle / ensure defaults also match (or be used to extract 
default kwargs if needed) for passing down to RPC.

 

--Morgan



smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing 

Re: [openstack-dev] [glance] draft logo of glance mascot

[Heidi Joy Tretheway]

Thanks for the feedback, Brian! That is always HUGELY helpful. I’ll convey that 
to the design team and I’m hoping you also took a moment to include your 
feedback on the tinyurl.com/OSmascot page  (because it makes it a lot easier 
for us to see all feedback side-by-side). Either way, I’m very appreciative of 
your thoughtful input! 

Best,
Heidi Joy

> On Nov 3, 2016, at 9:55 AM, Brian Rosmaita  
> wrote:
> 
> Hello Heidi Joy,
> 
> First, let me say on behalf of the Glance community that we appreciate the
> hard work you and your team have done in creating all the team
> mascot/logos.
> 
> We discussed the draft logo at the weekly Glance meeting today [0], and
> the general sense of the Glance community is that we'd like to request a
> re-draft.  I'm not sure we conveyed clearly to you how important the
> mouth-full-of-nuts aspect was to our choice of a chipmunk [1].  We could
> tell from the video [2] that you started with the sample picture [3] and
> worked from there to create something more streamlined, but we were really
> hoping for something more like the sample picture.
> 
> The importance of the mouth-full-of-nuts aspect is that Glance curates and
> stores virtual machine images and other services consume images supplied
> from Glance.  Additionally, this would more clearly distinguish our logo
> from that of other projects.
> 
> Thanks for being so willing to consider feedback!
> 
> cheers,
> brian
> 
> [0] 
> http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-11-03-14.00
> .log.html (beginning 14:14:07)
> [1] https://etherpad.openstack.org/p/glance-project-mascot (lines 38-41)
> [2] https://youtu.be/JmMTCWyY8Y4?t=41
> [3] https://www.fortwhyte.org/wp-content/uploads/2014/12/chip2.jpg
> 
> 
> 
> 
> On 10/21/16, 12:43 PM, "Brian Rosmaita" 
> wrote:
> 
>> Hello Glancers,
>> 
>> Heidi Joy Tretheway and Todd Morey from the foundation have sent us the
>> attached sneak preview of the Glance mascot/logo.  (As you may recall, we
>> voted for a chipmunk [0].)
>> 
>> They've set up a handy form [1] so that you can provide individual
>> feedback.  The project logos will be finalized in time for the February
>> PTG, so please provide any feedback before Friday, November 11.
>> 
>> Before providing feedback, you might want to take a look at a short
>> (50-second) video [2] to see how the logos developed and how they present
>> a consistent interface across OpenStack projects.
>> 
>> Since we're looking at light turnout for the Barcelona summit, I've put
>> discussion of the logo on the agenda for the November 3 edition of the
>> Glance weekly meeting [3].
>> 
>> Keep in mind that the logo is still a draft, so please don't tweet it or
>> use it in any promotional materials.
>> 
>> cheers,
>> brian
>> 
>> [0] https://etherpad.openstack.org/p/glance-project-mascot
>> [1] http://tinyurl.com/OSmascot
>> [2] https://youtu.be/JmMTCWyY8Y4
>> [3] https://etherpad.openstack.org/p/glance-team-meeting-agenda
>> 
> 


__
OpenStack Development Mailing 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] [ovn] [[l3-agent] connectivity to external network

[Russell Bryant]

On Thu, Nov 3, 2016 at 3:31 PM, Murali R  wrote:

> The scope of question is using neutron L3 services with OVN. The problem
> is when a router created, there is no implicit internal interface created
> between the router instance and the external bridge.
>

​To be honest, support of the Neutron L3 agent was only a transitional
thing while we bootstrapped OVN.  It was only useful while the
corresponding features were added to OVN.  Once we merge [1], I don't see
any reason to keep support of the L3 agent any longer and plan to remove
support for it and the corresponding CI jobs.  My suggestion would be to
try to do what you need using OVN's L3 support.

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

-- 
Russell Bryant
__
OpenStack Development Mailing 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][dev][python] constructing a deterministic representation of a python data structure

[Amrith Kumar]

Josh,

I have the key management part figured out and in actuality I will be
signing the messages. 

But step 1 is getting a deterministic representation and step 2 is hashing.
Step 3 would be signing.

So, steps 2 and 3 are all set; just need step 1 :) And I'm marveling at the
link that Morgan provided, it may have what I need.

-amrith

-Original Message-
From: Joshua Harlow [mailto:harlo...@fastmail.com] 
Sent: Thursday, November 3, 2016 4:31 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic
representation of a python data structure

I wouldn't recommend this (the basic hash) if you actually want to do any
kind of validation that the contents weren't altered. Is that the purpose?
Or are you trying to ensure bits aren't flipped?

If u want some level of validation that the message wasn't tampered with u
probably at least want https://docs.python.org/2/library/hmac.html and then
you need to start figuring out what to do about key distribution &
management and rotation :-/

Amrith Kumar wrote:
> Gordon,
>
> You can see a very quick-and-dirty prototype of the kind of thing I'm 
> looking to do in Trove at 
> https://gist.github.com/amrith/6a89ff478f81c2910e84325923eddebe
>
> Uncommenting line 51 would simulate a bad hash.
>
> I'd be happy to propose something similar in oslo.messaging if you 
> think that would pass muster there.
>
> -amrith
>
> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Thursday, November 3, 2016 3:09 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][dev][python] constructing a 
> deterministic representation of a python data structure
>
>
>
> On 03/11/16 02:24 PM, Amrith Kumar wrote:
>
>> So, just before calling call() or cast(), I could compute the hash 
>> and stuff it into the dictionary that is being sent over, and I can 
>> do the same on the receiving side. But since I cannot guarantee that 
>> the representation on the receiving side is necessarily identical to 
>> the representation on the sending side, I have issues computing the hash.
>>
>>
>
> based on description, you're trying to sign the messages? there was 
> some effort done in oslo.messaging[1]
>
> we do something similar in Ceilometer to sign IPC messages[2]. it does 
> add overhead though.
>
> [1] https://review.openstack.org/#/c/205330/
> [2]
> https://github.com/openstack/ceilometer/blob/ffc9ee99c10ede988769907fd
> b0594a
> 512c890cd/ceilometer/publisher/utils.py#L43-L58
>
> cheers,
> --
> gord
>
> __
>  OpenStack Development Mailing 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


smime.p7s
Description: S/MIME cryptographic 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] [FaaS] Function as a service in OpenStack

[Fox, Kevin M]

Would Kubernetes be a good fit? It might be possible to hook up a Zaqar queue 
to submit k8s Jobs?

Thanks,
Kevin

From: Lingxian Kong [anlin.k...@gmail.com]
Sent: Wednesday, November 02, 2016 6:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [FaaS] Function as a service in OpenStack

On Thu, Nov 3, 2016 at 10:44 AM, Zane Bitter 
> wrote:
This is a really interesting space. There seems to be two main use cases for 
Lambda that are probably worth talking about separately:

The first is for just Lambda alone. You can use it to provide some glue logic 
between the other AWS services, so you can trigger off various events (e.g. S3 
notifications) and write a little bit of conditioning logic that transforms the 
data and dispatches it to other services (e.g. DynamoDB). This one is 
particularly interesting to me, and in fact we can support parts of this in 
OpenStack already[1] because Mistral's functionality is equivalent to something 
like SWS + parts of Lambda. (Specifically, Mistral can do the data dispatch 
easily enough, but any data transformation has to be done in YAQL, which is a 
pretty high bar compared to just writing some code in a language of your 
choosing.)

​There is still one thing missing in Mistral​ (maybe it should not be). After 
receieving events from Aodh or Zaqar, what if user just wants to trigger some 
scripts under his/her management, rather than just invoking openstack services 
api? Although actions are pluggable in Mistral, but in this case it's 
definitely not an easy thing as just writing an customized action, unless 
Mistral could include such capatility in its scope which I think it too heavy 
for Mistral to mange such things by itself. So, FaaS will be the right answer 
in this case, and it will also be add-on part to empower Mistral to do more 
things.


The second one is Lambda + the API Gateway, which allows you to have web 
requests act as triggers, so that you can effectively treat it as a PaaS and 
build an entire web app by stringing together Lambda functions and the various 
other services (S3, DynamoDB, ). On the face of it this sounds to me like a 
gimmicky way of deploying an unmaintainable mess. Naturally this is the one 
receiving all of the attention, which shows how much I know :D

​I also don't think this one is attractive to me, Lambda is especially powerful 
when it's used together with other AWS services(S3, DynamoDB, Kinesis Streams, 
etc).
​​

I definitely don't think we should try to reimplement this from scratch in 
OpenStack. IMHO if we're going to add FaaS capabilities we should re-use some 
existing project (like OpenWhisk), even if we have to write our own native API 
over the top of it.

The things we'd really want it to do would be:

* Authenticate against Keystone,
* Provide Keystone credentials for the user-supplied functions it runs to 
access (probably using Keystone trusts), and
* Connect to existing OpenStack sources of events, which hopefully means Zaqar 
queues

Which sounds challenging to integrate with an existing standalone project, 
though still not as bad as writing an equivalent from scratch.

TBH I think the appeal, at least for the FaaS-as-a-PaaS (aka #serverless) 
crowd, is going to be pretty limited until such time as we have an equivalent 
of DynamoDB in OpenStack. (i.e. no time soon, since the MagnetoDB project is 
goneburger.) The idea of FaaS is to make the unit of compute power that you're 
paying for (a) as fine-grained as possible, and (b) scalable to infinity. Swift 
provides the same thing for storage (Nova:FaaS::Cinder:Swift). What we don't 
have is the equivalent for a database, there's only Trove where you're paying 
for a VM-sized chunk at a minimum and scaling up in units of VM-sized chunks 
until you reach the limit of how many VMs can communicate with each other and 
still get any work done. Not many web apps can get by without a database, so 
that largely negates the purpose to my mind, since the database will likely 
both dominate costs at the low end and put the upper limit on scale at the high 
end.

​Yeah, I agree with you that more things are needed so that FaaS-like stuff 
could be used appropriately and ideally, we can't get everything ready on day 
1, that's how we do things,  from simple to complex, isn't it?



cheers,
Zane.

[1] 
https://www.openstack.org/videos/video/building-self-healing-applications-with-aodh-zaqar-and-mistral



__
OpenStack Development Mailing 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 

Re: [openstack-dev] [all][dev][python] constructing a deterministic representation of a python data structure

[Morgan Fainberg]

On Thu, Nov 3, 2016 at 1:04 PM, Amrith Kumar  wrote:

> Gordon,
>
> You can see a very quick-and-dirty prototype of the kind of thing I'm
> looking to do in Trove at
> https://gist.github.com/amrith/6a89ff478f81c2910e84325923eddebe
>
> Uncommenting line 51 would simulate a bad hash.
>
> I'd be happy to propose something similar in oslo.messaging if you think
> that would pass muster there.
>
> -amrith
>
> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Thursday, November 3, 2016 3:09 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][dev][python] constructing a
> deterministic
> representation of a python data structure
>
>
>
> On 03/11/16 02:24 PM, Amrith Kumar wrote:
>
> >
> > So, just before calling call() or cast(), I could compute the hash and
> > stuff it into the dictionary that is being sent over, and I can do the
> > same on the receiving side. But since I cannot guarantee that the
> > representation on the receiving side is necessarily identical to the
> > representation on the sending side, I have issues computing the hash.
> >
> >
>
> based on description, you're trying to sign the messages? there was some
> effort done in oslo.messaging[1]
>
> we do something similar in Ceilometer to sign IPC messages[2]. it does add
> overhead though.
>
> [1] https://review.openstack.org/#/c/205330/
> [2]
> https://github.com/openstack/ceilometer/blob/
> ffc9ee99c10ede988769907fdb0594a
> 512c890cd/ceilometer/publisher/utils.py#L43-L58
>
> cheers,
> --
> gord
>
> __
> OpenStack Development Mailing 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
>
>
I had to solve a similar issue for deterministic key generation in dogpile
(key for memcache/etc) when memoizing methods/functions with kwargs. There
are a couple issues you run into, default args are not represented in
**kwargs, and non-positional args can come in any order.

If you want an example of what we did to generate the cache-key
programatically you can look here:

https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/util.py?at=master=file-view-default#util.py-67:118

You don't need all the namespace and probably not fn/module info, but this
can look at the call and handle / ensure defaults also match (or be used to
extract default kwargs if needed) for passing down to RPC.

--Morgan
__
OpenStack Development Mailing 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][dev][python] constructing a deterministic representation of a python data structure

[Joshua Harlow]

I wouldn't recommend this (the basic hash) if you actually want to do 
any kind of validation that the contents weren't altered. Is that the 
purpose? Or are you trying to ensure bits aren't flipped?


If u want some level of validation that the message wasn't tampered with 
u probably at least want https://docs.python.org/2/library/hmac.html and 
then you need to start figuring out what to do about key distribution & 
management and rotation :-/


Amrith Kumar wrote:

Gordon,

You can see a very quick-and-dirty prototype of the kind of thing I'm
looking to do in Trove at
https://gist.github.com/amrith/6a89ff478f81c2910e84325923eddebe

Uncommenting line 51 would simulate a bad hash.

I'd be happy to propose something similar in oslo.messaging if you think
that would pass muster there.

-amrith

-Original Message-
From: gordon chung [mailto:g...@live.ca]
Sent: Thursday, November 3, 2016 3:09 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic
representation of a python data structure



On 03/11/16 02:24 PM, Amrith Kumar wrote:


So, just before calling call() or cast(), I could compute the hash and
stuff it into the dictionary that is being sent over, and I can do the
same on the receiving side. But since I cannot guarantee that the
representation on the receiving side is necessarily identical to the
representation on the sending side, I have issues computing the hash.




based on description, you're trying to sign the messages? there was some
effort done in oslo.messaging[1]

we do something similar in Ceilometer to sign IPC messages[2]. it does add
overhead though.

[1] https://review.openstack.org/#/c/205330/
[2]
https://github.com/openstack/ceilometer/blob/ffc9ee99c10ede988769907fdb0594a
512c890cd/ceilometer/publisher/utils.py#L43-L58

cheers,
--
gord

__
OpenStack Development Mailing 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] [neutron][networking-vpp] - Status of startup issues

[Jerome Tollet (jtollet)]

thx

De : "John Joyce (joycej)" 
Répondre à : "OpenStack Development Mailing List (not for usage questions)" 

Date : jeudi 3 novembre 2016 à 15:23
À : "OpenStack Development Mailing List (not for usage questions)" 

Objet : [openstack-dev] [neutron][networking-vpp] - Status of startup issues

Is anyone able to provide a summary of which patches fix the startup scenarios. 
Any startup issues are of interest but the one we specifically have bugs around 
is the phsynets not being discovered by the server properly.
I see: https://bugs.launchpad.net/networking-vpp/+bug/1631063 which says a fix 
was committed, but no reference to the what the fix is and I don’t think the 
fix really merged yet as https://review.openstack.org/#/c/386280/ is reporting 
to be fixing it.
Are all these patches associated with the issue:
https://review.openstack.org/#/c/382587/
https://review.openstack.org/#/c/386280/
https://review.openstack.org/#/c/391523/
https://review.openstack.org/#/c/381538/
If not which of the above are required to get a clean start-up.  Does anyone 
have the complete picture?

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] [all][dev][python] constructing a deterministic representation of a python data structure

[Amrith Kumar]

Gordon,

You can see a very quick-and-dirty prototype of the kind of thing I'm
looking to do in Trove at
https://gist.github.com/amrith/6a89ff478f81c2910e84325923eddebe

Uncommenting line 51 would simulate a bad hash.

I'd be happy to propose something similar in oslo.messaging if you think
that would pass muster there.

-amrith

-Original Message-
From: gordon chung [mailto:g...@live.ca] 
Sent: Thursday, November 3, 2016 3:09 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic
representation of a python data structure



On 03/11/16 02:24 PM, Amrith Kumar wrote:

>
> So, just before calling call() or cast(), I could compute the hash and 
> stuff it into the dictionary that is being sent over, and I can do the 
> same on the receiving side. But since I cannot guarantee that the 
> representation on the receiving side is necessarily identical to the 
> representation on the sending side, I have issues computing the hash.
>
>

based on description, you're trying to sign the messages? there was some
effort done in oslo.messaging[1]

we do something similar in Ceilometer to sign IPC messages[2]. it does add
overhead though.

[1] https://review.openstack.org/#/c/205330/
[2]
https://github.com/openstack/ceilometer/blob/ffc9ee99c10ede988769907fdb0594a
512c890cd/ceilometer/publisher/utils.py#L43-L58

cheers,
--
gord

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


smime.p7s
Description: S/MIME cryptographic 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] [monasca] License for monasca-statsd

[Jeremy Stanley]

On 2016-11-03 15:03:44 -0400 (-0400), Chuck Short wrote:
> I was looking at packaging monasca-statsd since it is a dependency for
> designate, however when I look at the license for it,it says Apache-2.
> However the LICENSE file included in the source  is that the software is
> provided as is...etc etc. Could we get some clarification please?

It looks like https://review.openstack.org/123315 added that
LICENSE file when originally setting up the monasca-statsd repo a
couple years ago. I see a variety of Datadog repositories in
circulation using that license, and they seem to refer to it as "a
simplified BSD license" (which is certainly what it looks like to me
as well). However, all the individual files added in that change
which declare a license in their headers seem to use Apache License
2.0, which I agree is confusing. Hopefully the Datadog license was
added here in error, and we've not actually been shipping an
incorrectly-licensed derivative of their software this entire time?
-- 
Jeremy Stanley


signature.asc
Description: 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] [all][dev][python] constructing a deterministic representation of a python data structure

[Amrith Kumar]

Dims, I don't think ovo addresses this issue. It isn't one of versioning that 
I'm attempting to address but rather as Gordon points out, of signing and 
verifying authenticity. Please see also my longer response to him on this.

-amrith

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Thursday, November 3, 2016 3:03 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic 
representation of a python data structure

Does oslo.versionedobjects solve some of your needs?

http://www.slideshare.net/davanum/ovo-deep-dive
https://gorka.eguileor.com/learning-something-new-about-oslo-versioned-objects/
http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/

-- Dims

On Thu, Nov 3, 2016 at 2:24 PM, Amrith Kumar  wrote:
> TL;DR
>
>
>
> I want to take a python data structure (see later for details) and 
> represent it in a format that will be stable across python versions, 
> and platforms so that I can construct a stable hash. I’m looking for 
> pointers to some best practices on how to do this.
>
>
>
> The longer version
>
>
>
> Assume that there’s some function in python that is:
>
>
>
> def fn(*args, **kwargs):
>
> …
>
>
>
> I’d like to take (args, kwargs) and construct a hash of some 
> representation that is deterministic. Specifically, assume that fn() 
> is a method in the API (oslo.messaging transport …). I’d like to 
> construct the hash on the sender side and on the RPC server side and 
> make sure that the parameters are the same.
>
>
>
> So, just before calling call() or cast(), I could compute the hash and 
> stuff it into the dictionary that is being sent over, and I can do the 
> same on the receiving side. But since I cannot guarantee that the 
> representation on the receiving side is necessarily identical to the 
> representation on the sending side, I have issues computing the hash.
>
>
>
> In IRC, jroll suggested json; can one safely assume that json.dumps() 
> is a deterministic representation?
>
>
>
> Thanks for any pointers and suggestions.
>
>
>
> -amrith
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Davanum Srinivas :: https://twitter.com/dims

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


smime.p7s
Description: S/MIME cryptographic 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] [oslo][oslo-messaging] [all][dev][python] constructing a deterministic representation of a python data structure

[Amrith Kumar]

Yes, what I'm trying to do is related to this spec.
https://review.openstack.org/#/c/391637/

The basic idea is this, I'd like to make sure that a message sent over
oslo.messaging is actually from the person that we expect that it is from.

So, to that end, I'd like to sign the message on the way out (before I make
the RPC call), and verify the signature when it is received. And with that,
and the understanding that the private keys are secured, I can rely on the
authenticity of the message (or in this case, the RPC call).

The signing side is easy; I can sign the arguments to the RPC call before I
make the RPC call. And I can intercept the arguments with a decorator on the
receiving side. My challenge now is to ensure that I have a deterministic
representation of the arguments on the calling and called side.

Now, if I could interest oslo.messaging to provide an interface into this,
life would be much easier because the message is a deterministic
representation. My issue in trying to do this one level up, in trove, is
that I don' t have access to the message.

Say, for example, I gave the call() or cast() call a callback method which
would be called with the 'msg' that was to be sent, then I could sign the
message and return the signature that oslo could then add to the message and
send along with the rpc call. And on the receiving side, if I provided the
Target with a callback that would construct the signature of a message, we
could do the same thing there.

The reason I asked my question was because I was attempting to solve the
problem in Trove; if on the other hand there's an interest in solving this
in oslo.messaging (I've added oslo and oslo-messaging to the subject line) I
would be happy to contribute the code that would do it similar to the review
you proposed.

Thanks!

-amrith

-Original Message-
From: gordon chung [mailto:g...@live.ca] 
Sent: Thursday, November 3, 2016 3:09 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all][dev][python] constructing a deterministic
representation of a python data structure



On 03/11/16 02:24 PM, Amrith Kumar wrote:

>
> So, just before calling call() or cast(), I could compute the hash and 
> stuff it into the dictionary that is being sent over, and I can do the 
> same on the receiving side. But since I cannot guarantee that the 
> representation on the receiving side is necessarily identical to the 
> representation on the sending side, I have issues computing the hash.
>
>

based on description, you're trying to sign the messages? there was some
effort done in oslo.messaging[1]

we do something similar in Ceilometer to sign IPC messages[2]. it does add
overhead though.

[1] https://review.openstack.org/#/c/205330/
[2]
https://github.com/openstack/ceilometer/blob/ffc9ee99c10ede988769907fdb0594a
512c890cd/ceilometer/publisher/utils.py#L43-L58

cheers,
--
gord

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


smime.p7s
Description: S/MIME cryptographic 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] [ovn] [[l3-agent] connectivity to external network

[Murali R]

The scope of question is using neutron L3 services with OVN. The problem is
when a router created, there is no implicit internal interface created
between the router instance and the external bridge.

The neutron config says "external_network_bridge" and
"gateway_external_network_id" must be set to NULL to use multiple external
networks.

We then have association to define the external network and is populated to
the neutron db accordingly for external network.
Example   neutron net-update providernet --router:external

The association between external bridge and external network when OVN is
present is not clear. Where is that association or how does it get
associated?

Based on this page the steps are
http://docs.openstack.org/developer/networking-ovn/testing.html#provider-networks

ovs-vsctl add-br br-provider

ovs-vsctl set open external-ids:ovn-bridge-mappings=providernet:br-provider

Followed by network create and subnet create.

I am not sure how setting external ids is updated to the L3 agent where the
bridge providing external connection is? Finally, I see no interface
between br-provider and router instance so traffic is not going out. What
am I missing?

Thanks
Murali
__
OpenStack Development Mailing 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] [cinder][stable] Deprecation notice: Driver for NetApp Data ONTAP operating in 7-mode

[Ravi, Goutham]

Developers and Operators,

The NetApp unified driver in Cinder currently provides integration for two 
major generations of the ONTAP operating system: the current “clustered” ONTAP 
and the legacy 7-mode. NetApp’s “full support” for 7-mode ended in August of 
2015 and the current “limited support” period will end in February of 2017 [1].

In accordance with community policy [2], we are initiating the deprecation 
process for the 7-mode components of the Cinder NetApp unified driver set to 
conclude with their removal in the Queens release. This will apply to all three 
protocols currently supported in this driver: iSCSI, FC and NFS.

What is being deprecated: Cinder drivers for NetApp Data ONTAP 7-mode NFS, 
iSCSI, FC
Period of deprecation: 7-mode drivers will be around in stable/ocata and 
stable/pike and will be removed in the Queens release (All milestones of this 
release)
What should users/operators do: Follow the recommended migration path to 
upgrade to Clustered Data ONTAP 
[3] or get in touch 
with your NetApp support representative.

The cinder change for deprecation 
[4]

[1] 
https://mysupport.netapp.com/info/web/ECMP1147223.html#_Data%20ONTAP%20Operating%20System%20Version%20Support%20Policy
[2] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
[3] https://mysupport.netapp.com/info/web/ECMP1658253.html
[4] https://review.openstack.org/#/c/393450/


Thanks,
Goutham
__
OpenStack Development Mailing 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][dev][python] constructing a deterministic representation of a python data structure

[gordon chung]

On 03/11/16 02:24 PM, Amrith Kumar wrote:

>
> So, just before calling call() or cast(), I could compute the hash and
> stuff it into the dictionary that is being sent over, and I can do the
> same on the receiving side. But since I cannot guarantee that the
> representation on the receiving side is necessarily identical to the
> representation on the sending side, I have issues computing the hash.
>
>

based on description, you're trying to sign the messages? there was some 
effort done in oslo.messaging[1]

we do something similar in Ceilometer to sign IPC messages[2]. it does 
add overhead though.

[1] https://review.openstack.org/#/c/205330/
[2] 
https://github.com/openstack/ceilometer/blob/ffc9ee99c10ede988769907fdb0594a512c890cd/ceilometer/publisher/utils.py#L43-L58

cheers,
-- 
gord

__
OpenStack Development Mailing 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] New and next-gen libraries (a BCN followup)

[Joshua Harlow]

Jay Faulkner wrote:

On Nov 3, 2016, at 11:27 AM, Joshua Harlow  wrote:

Just as a followup from the summit,

One of the sessions (the new lib one) had a few proposals:

https://etherpad.openstack.org/p/ocata-oslo-bring-ideas

And I wanted to try to get clear owners for each part (there was some followup 
work for each); so just wanted to start this email to get the thoughts going on 
what to do for next steps.

*A hash ring library*

So this one it feels like we need at least a tiny oslo-spec for and for someone 
to write down the various implementations, what they share, what they do not 
share (talking to swift, nova, ironic and others? to figure this out). I think 
alexis was thinking he might want to work through some of that but I'll leave 
it for him to chime in on that (or others feel free to also).

This one doesn't seem very controversial and the majority of the work is 
probably on doing some analysis of what exists and then picking a library name 
and coding that up, testing it, and then integrating (pretty standard).



Ironic and Nova both share a hash ring implementation currently 
(ironic-conductor and nova-compute driver for ironic). It would be sensible to 
reuse this implementation, oslo-ify it, and have that code shared.

I question the value of re-implementing something like this from scratch though.

Thanks,
Jay Faulkner
OSIC



Right I don't think the intention would be to implement it from scratch, 
but to do some basic analysis of what exists (and think about and 
document the patterns), and try to find the common parts (which likely 
involves renaming some specific nova/ironic methods from what I see); 
especially if we can get swift to perhaps (TBD) also use and contribute 
to this library.


-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] [monasca] License for monasca-statsd

[Chuck Short]

Hi,

I was looking at packaging monasca-statsd since it is a dependency for
designate, however when I look at the license for it,it says Apache-2.
However the LICENSE file included in the source  is that the software is
provided as is...etc etc. Could we get some clarification please?

Thanks
chuck
__
OpenStack Development Mailing 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][dev][python] constructing a deterministic representation of a python data structure

[Davanum Srinivas]

Does oslo.versionedobjects solve some of your needs?

http://www.slideshare.net/davanum/ovo-deep-dive
https://gorka.eguileor.com/learning-something-new-about-oslo-versioned-objects/
http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/

-- Dims

On Thu, Nov 3, 2016 at 2:24 PM, Amrith Kumar  wrote:
> TL;DR
>
>
>
> I want to take a python data structure (see later for details) and represent
> it in a format that will be stable across python versions, and platforms so
> that I can construct a stable hash. I’m looking for pointers to some best
> practices on how to do this.
>
>
>
> The longer version
>
>
>
> Assume that there’s some function in python that is:
>
>
>
> def fn(*args, **kwargs):
>
> …
>
>
>
> I’d like to take (args, kwargs) and construct a hash of some representation
> that is deterministic. Specifically, assume that fn() is a method in the API
> (oslo.messaging transport …). I’d like to construct the hash on the sender
> side and on the RPC server side and make sure that the parameters are the
> same.
>
>
>
> So, just before calling call() or cast(), I could compute the hash and stuff
> it into the dictionary that is being sent over, and I can do the same on the
> receiving side. But since I cannot guarantee that the representation on the
> receiving side is necessarily identical to the representation on the sending
> side, I have issues computing the hash.
>
>
>
> In IRC, jroll suggested json; can one safely assume that json.dumps() is a
> deterministic representation?
>
>
>
> Thanks for any pointers and suggestions.
>
>
>
> -amrith
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing 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] [manila] spec review focus

[Ben Swartzlander]

The following specs were designated as review focus specs for Ocata:
https://etherpad.openstack.org/p/manila-ocata-spec-review-focus

-Ben

On 11/03/2016 12:27 PM, Ben Swartzlander wrote:

As agreed to in the manila spec process spec, the whole core team is
expected to review certain specs and vote before they merge.

The following specs were designed as review focus specs for Ocata:

https://etherpad.openstack.org/p/manila-ocata-spec-review-focus


-Ben Swartzlander



__
OpenStack Development Mailing 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] [neutron] neutron-server retrospective/next steps summit session recap

[Ihar Hrachyshka]

Hi all,

this is a recap for the neutron-server session that was on Fri.

===

tl;dr for Ocata, we proceed with adopting OVO (reviewers needed!),  
push-notifications (now unblocked, Kevin already spins up patches), and  
no-downtime-upgrades (contract alembic migrations will be forbidden for  
Ocata in due course; if you have features that require those, you may need  
to rework your patches). We will also try to make some progress this cycle  
to switch to Pecan by default. There is also next actions list at the end  
of the email.


===

The session was intended to cover things achieved during Newton cycle where  
it
comes to neutron-server design, as well, and more importantly, to walk  
through

the next steps scheduled for Ocata.

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16903/neutron-neutron-server-retrospective-and-next-steps
https://etherpad.openstack.org/p/ocata-neutron-server-next

Retrospectively, it was noted that Newton final release was a bit bumpy,  
and we

need to be more cautious the next time avoiding landing high impact patches
late in the cycle.

Ocata is a short cycle, and the team agreed before that it won't be as  
reach on

new features, instead focusing on closing existing initiatives currently in
flight. Among those server features that are still scheduled for the next
release are:

* switch to oslo.versionedobjects (aka OVO) for remaining plugin code:
  - 
https://blueprints.launchpad.net/neutron/+spec/adopt-oslo-versioned-objects-for-db
  - 
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db

* no API downtime upgrades:
  - https://blueprints.launchpad.net/neutron/+spec/online-upgrades
  - https://review.openstack.org/#/c/386685/

The long term success of the latter feature somewhat depends on the former
effort, though it's not a strict technical dependency, and hence we will
proceed with both in parallel during the cycle.

For the OVO switch, implementation has already started back in
end-of-Mitaka/Newton, and it's an ongoing effort. The effort is staffed with
OSIC folks, though more attention from core reviewers is advised to make
progress.

As for online-upgrades, the main point is to survive the Ocata cycle without
introducing a new contract migration script. The Ocata cycle is not rich on
those in the first place; one of the relevant features is planned changes for
port binding API that should serve nova live migration scenario better; Ihar
and Artur will work with the live migration feature owner (Andreas) on  
defining

the path to avoid contract scripts. Ihar is also to upload a gating test to
forbid contract migrations for Ocata.

Kevin is going to proceed with push-notifications feature started in Newton  
but

blocked by OVO work that should deliver better scaling when messaging between
neutron-server and agents. It's no longer blocked by anything.

Another topic briefly touched on the session is Pecan switch plan that may be
of relevance to the expected Pike goal to switch all API endpoints to running
from inside a web server. Kevin updated about the state of the feature. The
brief state is we need to land a bunch of patches, make the relevant jobs
voting, then switch defaults/deprecate the pecan option.

https://review.openstack.org/#/q/project:openstack/neutron+status:open+message:pecan

Significant work is expected on untangling some 'unit' tests from old API
controller layer. Armando suggested that in lots of those cases we should
instead move affected test cases from unit framework into -api job. This  
effort

may be a good candidate for low-hanging-fruit bugs to report.

Finally, api-ref plans were briefly touched, and how it affects how
neutron-server loads extensions. Armando confirmed that the service will load
its extension definitions from neutron-lib. We may need to consider how it  
may

affect older neutron-server using newer neutron-lib if we somehow introduce
changes to API definitions (should not generally happen, but...)

Next actions:
- core reviewers to boost review velocity on OVO adoption;
- core reviewers to boost review velocity on Pecan migration;
- Ihar to propose forbidding contract migrations in Ocata;
- Artur/Ihar to work with Andreas on modelling data model changes for live
  migration;
- Kevin to proceed with push-notifications effort;
- Kevin (?) to report low-hanging-fruit bugs for unit->api test conversion
  where it makes sense;
- Armando to clarify if using newer neutron-lib api definitions with older
  neutron-server is a valid scenario to consider.

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] [oslo] New and next-gen libraries (a BCN followup)

[Jay Faulkner]

> On Nov 3, 2016, at 11:27 AM, Joshua Harlow  wrote:
> 
> Just as a followup from the summit,
> 
> One of the sessions (the new lib one) had a few proposals:
> 
> https://etherpad.openstack.org/p/ocata-oslo-bring-ideas
> 
> And I wanted to try to get clear owners for each part (there was some 
> followup work for each); so just wanted to start this email to get the 
> thoughts going on what to do for next steps.
> 
> *A hash ring library*
> 
> So this one it feels like we need at least a tiny oslo-spec for and for 
> someone to write down the various implementations, what they share, what they 
> do not share (talking to swift, nova, ironic and others? to figure this out). 
> I think alexis was thinking he might want to work through some of that but 
> I'll leave it for him to chime in on that (or others feel free to also).
> 
> This one doesn't seem very controversial and the majority of the work is 
> probably on doing some analysis of what exists and then picking a library 
> name and coding that up, testing it, and then integrating (pretty standard).
> 

Ironic and Nova both share a hash ring implementation currently 
(ironic-conductor and nova-compute driver for ironic). It would be sensible to 
reuse this implementation, oslo-ify it, and have that code shared. 

I question the value of re-implementing something like this from scratch though.

Thanks,
Jay Faulkner
OSIC

> *Failure capturing/formation/(de)serialization library*
> 
> This one I've just decided to push through, though more comments on the spec 
> are always welcome @ https://review.openstack.org/#/c/229194/ the repo where 
> I started just doing this work (while in the airports traveling back) is @ 
> https://github.com/harlowja/failure
> 
> Ideally once that is in a slightly better state we should be able to start to 
> converge the various (at least 3 similar kinds of implementations) to that 
> one and ideally get less duplicated (or slightly same code) out of the 
> various libraries and projects that have copied/recreated it.
> 
> Anyone desiring to help in that is more than welcome to jump in :)
> 
> *Next-gen oslo.service replacement*
> 
> This one may require a little more of a plan on how to make it work, but the 
> gist is that medhi (and others) has created 
> https://github.com/sileht/cotyledon which is a nice replacement for 
> oslo.service that ceilometer is using (and others?) and the idea was to start 
> to figure out how to move away from (or replace with?) olso.service with that 
> library.
> 
> I'd like to see a spec with some of the details/thoughts on how that could be 
> possible, what changes would still be needed. I think from that session that 
> the following questions were raised:
> 
> - Can multiprocessing (or subprocess?) be used (instead of os.fork)
> - What to do about windows?
> - Is it possible to create a oslo.service compat layer that preserves the 
> oslo.service API but uses cotyledon under the covers to smooth the 
> transition/adoption of other projects to cotyledon
>   - Perhaps in general we should write how an adoption could happen for a 
> consuming project (maybe just writing down how ceilometer made the switch 
> would be a good start, what issues were encountered, how they were 
> resolved...)
> - Something else that people forgot to write down in the etherpad here :-P
> 
> I think that was the majority of thoughts coming out of that session (there 
> were a few others, but those were not especially loud and may have just been 
> me rambling, ha). Anything I forgot feel free to add in :)
> 
> Whose in to make the above happen?!?!
> 
> -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 Development Mailing 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][i18n] how to indicate non-translatable identifiers in translatable strings?

[Doug Hellmann]

Excerpts from Ian Y. Choi's message of 2016-11-04 00:58:30 +0900:
> Hello,
> 
> I am from I18n team. Please see inline for my comments.
> 
> Doug Hellmann wrote on 11/3/2016 2:19 AM:
> > Excerpts from Brian Rosmaita's message of 2016-11-02 16:34:45 +:
> >> This issue came up during a code review; I've asked around a bit but
> >> haven't been able to find an answer.
> >>
> >> Some of the help output for utility scripts associated with Glance aren't
> >> being translated, so Li Wei put up a patch to fix this [0], but there are
> >> at least two problematic cases.
> >>
> >> Case 1:
> >>  parser.add_option('-S', '--os_auth_strategy', dest="os_auth_strategy",
> >>  metavar="STRATEGY",
> >>  help=_("Authentication strategy (keystone or noauth)."))
> >>
> >> For that one, 'keystone' and 'noauth' are identifiers, so we don't want
> >> them translated.  Would putting single quotes around them like this be
> >> sufficient to indicate they shouldn't be translated?  For example,
> >>
> >>  help=_("Authentication strategy ('keystone' or 'noauth').")
> >>
> >>
> >> Andreas Jaeger mentioned that maybe we could use a "translation comment"
> >> [1].  I guess we'd do something like:
> >>
> >>  # NOTE: do not translate the stuff in single quotes
> >>  help=_("Authentication strategy ('keystone' or 'noauth').")
> > The ability to pass comments to the translators like that seems
> > really useful, if it would work with our tools.
> +1 from me and also Daisy (former i18n PTL).
> 
> I18n team quite agrees what adding translation comments can pass more 
> information to translators from developers.
> 
> > It seems like things we put in quotes should not be translated, by
> > convention.
> I agree with Doug, and Brant's suggestion also looks nice.
> 
> To slightly revise from Brant's suggestion, the following original 
> string for translation looks much better:
> 
>   : "Authentication strategy (%(keystone)s or %(noauth)s).")

Yes, that's the sort of thing I was thinking. Do we need to specify that
the string template use named values like that? Do the names convey
information to the translators?

> 
>   -> %(keystone)s and %(noauth)s will be replaced with "'keystone'" and 
> "'noauth'" correspondingly.
> 
> >
> >> What are other people doing for this?
> >>
> >> Case 2:
> >> We've got a big block of usage text, roughly
> >>
> >>  usage = _("""
> >> %prog  [options] [args]
> >>
> >> Commands:
> >>  keyword1what it does
> >>  keyword2what it does
> >>  ...
> >>  keyword8what it does
> >> """)
> >>
> >> We don't want the keywords to be translated, but I'm not sure how to
> >> convey this to the translators.
> > This is a case where using quotes won't work. Using a different
> > tool to build the help text (argparse instead of optparse), or even
> > just building the text from parts inline (put the parts you do or
> > do not want translated into separate variables and then combine the
> > results like a template) might work. Both add a bit of complexity.
> > The second option doesn't require completely rewriting the CLI
> > processing logic.
> I think translators easily capture the context of this kind of command 
> help strings.
> 
> After my brief research on other projects, GNU coreutils also do the 
> same way for extracting translation strings
> (e.g., http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c#n4882 ).
> 
> For command help strings, translators will prefer not to divide one 
> overall string into multiple line-by-line strings,
> for example:_("""%prog  [options] [args]""") + "\n" + 
> _("""Commands:""") + "\n" + _("""  keyword1  what it does""") .

Yes, I'm sure the original authors would not want to write the text
that way either. :-)

> By the way, can i18n team set any rules within the team,
> for example, "don't translate any words in capital.", "If developers 
> don't want to translate some words, write them in capital.", and so on?

I think in most cases it would be reasonable to assume that words
in all capital letters have special meaning and should not be
translated. Sometimes we can't use that convention, though, because
the input value needs to include lower case values. That is the
situation for the example above, and why I think having notes are going
to be helpful in the long run.

Doug

> 
> What do developers think about this idea?
> 
> 
> With many thanks,
> 
> /Ian
> 
> >> Thanks in advance for your help,
> >> brian
> >>
> >>
> >> [0] https://review.openstack.org/#/c/367795/8
> >> [1] http://babel.pocoo.org/en/latest/messages.html#translator-comments
> >>
> > __
> > OpenStack Development Mailing 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-lbaas][octavia] Not be able to ping loadbalancer ip

[Wanjing Xu (waxu)]

Going through the log , I saw the following error on o-hm

2016-11-03 03:31:06.441 19560 ERROR octavia.controller.worker.controller_worker 
request_ids=request_ids)
2016-11-03 03:31:06.441 19560 ERROR octavia.controller.worker.controller_worker 
BadRequest: Unrecognized attribute(s) 'dns_name'
2016-11-03 03:31:06.441 19560 ERROR octavia.controller.worker.controller_worker 
Neutron server returns request_ids: ['req-1daed46e-ce79-471c-a0af-6d86d191eeb2']

And it seemed that I need to upgrade my neutron client.  While I am planning to 
do it, could somebody please send me the document on how this vip is supposed 
to plug into the lbaas vm and what the failover is about ?

Thanks!
Wanjing


From: Cisco Employee >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, November 2, 2016 at 7:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Neutron][neutron-lbaas][octavia] Not be able to ping 
loadbalancer ip

So I bring up octavia using devstack (stable/mitaka).   I created a 
loadbalander and a listener(not create member yet) and start to look at how 
things are connected to each other.  I can ssh to amphora vm and I do see a 
haproxy is up with front end point to my listener.  I tried to ping (from dhcp 
namespace) to the loadbalancer ip, and ping could not go through.  I am 
wondering how packet is supposed to reach this amphora vm.  I can see that the 
vm is launched on both network(lb_mgmt network and my vipnet), but I don't see 
any nic associated with my vipnet:

ubuntu@amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699:~$ ifconfig -a
eth0  Link encap:Ethernet  HWaddr fa:16:3e:b4:b2:45
  inet addr:192.168.0.4  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::f816:3eff:feb4:b245/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2496 errors:0 dropped:0 overruns:0 frame:0
  TX packets:2626 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:307518 (307.5 KB)  TX bytes:304447 (304.4 KB)

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:212 errors:0 dropped:0 overruns:0 frame:0
  TX packets:212 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:18248 (18.2 KB)  TX bytes:18248 (18.2 KB)

localadmin@dmz-eth2-ucs1:~/devstack$ nova list
+--+--+++-+---+
| ID   | Name   
  | Status | Task State | Power State | Networks
  |
+--+--+++-+---+
| 557a3de3-a32e-419d-bdf5-41d92dd2333b | 
amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699 | ACTIVE | -  | Running
 | lb-mgmt-net=192.168.0.4; vipnet=100.100.100.4 |
+--+--+++-+---+

And it seemed that amphora created a port from the vipnet for its vrrp_ip, but 
now sure how it is used and how it is supposed to help packet to reach 
loadbalancer ip

It will be great if somebody can help on this, especially on network side.

Thanks
Wanjing

__
OpenStack Development Mailing 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] [oslo] New and next-gen libraries (a BCN followup)

[Joshua Harlow]

Just as a followup from the summit,

One of the sessions (the new lib one) had a few proposals:

https://etherpad.openstack.org/p/ocata-oslo-bring-ideas

And I wanted to try to get clear owners for each part (there was some 
followup work for each); so just wanted to start this email to get the 
thoughts going on what to do for next steps.


*A hash ring library*

So this one it feels like we need at least a tiny oslo-spec for and for 
someone to write down the various implementations, what they share, what 
they do not share (talking to swift, nova, ironic and others? to figure 
this out). I think alexis was thinking he might want to work through 
some of that but I'll leave it for him to chime in on that (or others 
feel free to also).


This one doesn't seem very controversial and the majority of the work is 
probably on doing some analysis of what exists and then picking a 
library name and coding that up, testing it, and then integrating 
(pretty standard).


*Failure capturing/formation/(de)serialization library*

This one I've just decided to push through, though more comments on the 
spec are always welcome @ https://review.openstack.org/#/c/229194/ the 
repo where I started just doing this work (while in the airports 
traveling back) is @ https://github.com/harlowja/failure


Ideally once that is in a slightly better state we should be able to 
start to converge the various (at least 3 similar kinds of 
implementations) to that one and ideally get less duplicated (or 
slightly same code) out of the various libraries and projects that have 
copied/recreated it.


Anyone desiring to help in that is more than welcome to jump in :)

*Next-gen oslo.service replacement*

This one may require a little more of a plan on how to make it work, but 
the gist is that medhi (and others) has created 
https://github.com/sileht/cotyledon which is a nice replacement for 
oslo.service that ceilometer is using (and others?) and the idea was to 
start to figure out how to move away from (or replace with?) 
olso.service with that library.


I'd like to see a spec with some of the details/thoughts on how that 
could be possible, what changes would still be needed. I think from that 
session that the following questions were raised:


- Can multiprocessing (or subprocess?) be used (instead of os.fork)
- What to do about windows?
- Is it possible to create a oslo.service compat layer that preserves 
the oslo.service API but uses cotyledon under the covers to smooth the 
transition/adoption of other projects to cotyledon
   - Perhaps in general we should write how an adoption could happen 
for a consuming project (maybe just writing down how ceilometer made the 
switch would be a good start, what issues were encountered, how they 
were resolved...)

- Something else that people forgot to write down in the etherpad here :-P

I think that was the majority of thoughts coming out of that session 
(there were a few others, but those were not especially loud and may 
have just been me rambling, ha). Anything I forgot feel free to add in :)


Whose in to make the above happen?!?!

-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] [all][dev][python] constructing a deterministic representation of a python data structure

[Amrith Kumar]

TL;DR

 

I want to take a python data structure (see later for details) and represent
it in a format that will be stable across python versions, and platforms so
that I can construct a stable hash. I'm looking for pointers to some best
practices on how to do this.

 

The longer version

 

Assume that there's some function in python that is:

 

def fn(*args, **kwargs):

.

 

I'd like to take (args, kwargs) and construct a hash of some representation
that is deterministic. Specifically, assume that fn() is a method in the API
(oslo.messaging transport .). I'd like to construct the hash on the sender
side and on the RPC server side and make sure that the parameters are the
same.

 

So, just before calling call() or cast(), I could compute the hash and stuff
it into the dictionary that is being sent over, and I can do the same on the
receiving side. But since I cannot guarantee that the representation on the
receiving side is necessarily identical to the representation on the sending
side, I have issues computing the hash.

 

In IRC, jroll suggested json; can one safely assume that json.dumps() is a
deterministic representation?

 

Thanks for any pointers and suggestions.

 

-amrith



smime.p7s
Description: S/MIME cryptographic 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] [release] Release countdown for week R-15, 7 - 11 Nov

[Doug Hellmann]

Welcome back from summit!

As we did last cycle, the release team will be sending reminder
emails as we count down toward the Ocata release. If all goes as
planned, these emails will be sent just before the week mentioned
in the subject (on my Thursday, but some of you live in the future).

Release liaisons, PTLs, and other interested parties should read
these emails to be aware of process notes, especially as we get
close to significant dates on the schedule. I'll try to keep them
brief, but email is still the best way we have of communicating and
that only works if you actually read them.


Focus
-

Teams should be focusing on wrapping up incomplete work left over
from the end of the Newton cycle, finalizing and announcing plans
from the summit, and completing specs and blueprints.


General Notes
-

Stable and independent releases have resumed.

Keep in mind that one of the places we cut time out of the Ocata
schedule is before the first milestone. Ocata-1 will be during week
R-14.

Release Actions
---

Release liaisons should add their name and contact information to
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

Release liaisons should configure their IRC clients to join
#openstack-release by default.

Release liaisons should review the release models for all deliverables
and make any updates with patches to openstack/governance before the
first milestone.

This is a good time to coordinate with the stable maintenance team on
releases from stable branches.

PTLs should add their acknowledgement of the Ocata series community
goal to 
http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html
with a patch to the openstack/governance repository before the first
milestone.

Important Dates
---

Ocata 1 Milestone: 17 Nov

Ocata release schedule: http://releases.openstack.org/ocata/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-dev] [zaqar] Summary of Barcelona Design Summit

[Fei Long Wang]

Greetings,

Firstly, thank you for everyone joined Zaqar sessions at Barcelona 
summit. We definitely made some great progress for those working 
sessions. Here are the high level summary and those are basically our 
Ocata priorities. I may miss something so please feel free to 
comment/reply this mail.


Performance matters


We got some interests last cycle about deploying Zaqar as messaging 
service in public/private cloud. And performance is one of popular 
questions. Though we have a built-in benchmark tool, there is no way to 
diagnose when the performance can't the meet user's exception in a given 
deployed environment. Besides, there is no good way to grantee a new 
patch won't impact the performance. Hence we discussed this topic in summit.


For the first issue, the solution is osprofiler. The patches are already 
there[1], we just need some review and it would be great if we can merge 
them in Ocata-1.


For the second issue, we would like to introduce a new gate job which 
based on our built-in benchmark tool. The idea is comparing the 
performance before/after current patch.


Subscription confirmation
--

Xiyuan Wang and Hao Wang did a great job in last cycle about 
subscription confirmation. As a result, we have merged the webhook 
confirmation patches. In the design session, we reviewed the design of 
email part, which changed the original design a bit about how to set the 
external URL for confirmation page.


Swift storage driver
--

Based on current design, Zaqar relays on under layer storage backend to 
get the stability and scalability. For example, if you're using MongoDB, 
you have to enable the replicaset to get replicating messages. Since 
Swift has the native support of replication and it's deployment for most 
of the OpenStack environment. So it's would be great if Zaqar can 
support using Swift as the storage backend driver.


Purge queue
-

It's not a new blueprint but seems it's a good time to pick since we do 
have some users asking it. And the conclusion in the session is, the 
feature is safe and good to have. A spec will be posed soon which will 
mainly discuss what the API looks like and how to design it to avoid 
race condition issue.


Notification delivery policy
--

We didn't touch this topic due a stranger in this session. See below for 
more details.


Interest for real deployment
-

A cloud architect from Mirantis joined our design session to discuss 
about using Zaqar as the messaging queue service for their customer. In 
their requirement, purge queue and dead letter queue are on the list 
which are also on our road map. And we had a great discussion about the 
deployment architecture, especially how to get a great scalability.



Please contribute this thread to fill the points/things I missed or pop 
up in #openstack-zaqar channel directly with questions and suggestions.


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

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
OpenStack Development Mailing 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][ironic] Announcing Valence, support for integrating Rack Scale Devices

[Bhandaru, Malini K]

Hello Everyone!
We are very pleased to announce Valence. Please visit our wiki 
at https://wiki.openstack.org/wiki/Valence

Regards,
Malini

__
OpenStack Development Mailing 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] [manila] Access key via the UI?

[Tom Barron]

On 11/03/2016 10:33 AM, Ravi, Goutham wrote:
> Ah. I’d let Tom or Ramana weigh in on that. IIRC, the access key is
> plaintext, so, I thought it can be displayed; that’s what the CLI is doing.
> 
> Reading the spec though, this was an intended part of the feature:
> http://specs.openstack.org/openstack/manila-specs/specs/newton/auth-access-keys.html

Thanks.  I could see going either way - download or display.  Interested
in what Victoria and Ramana think.

-- Tom

> 
> 
>  
> 
>  
> 
> *From: *Arne Wiebalck 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Thursday, November 3, 2016 at 10:15 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)"
> 
> *Subject: *Re: [openstack-dev] [manila] Access key via the UI?
> 
>  
> 
> Hi Goutham,
> 
>  
> 
> It’s already being returned in the manila access-list API as of
> 2.21, if you’re using the latest python-manilaclient, you should
> have it there. However, it’s missing in the UI:
> 
>  
> 
> Yes, I was comparing what I can do on the CLI and what was offered with
> the UI.
> 
> 
> 
> 
> https://github.com/openstack/manila-ui/blob/c986a100eecf46af4b597cdcf59b5bc1edc2d1b0/manila_ui/dashboards/project/shares/shares/tables.py#L278
> 
>  
> 
> Are you suggesting to simply display it? (I was more thinking of a
> one-time download when giving access,
> 
> similar to what is offered for keys for instance creation.)
> 
> 
> 
> Could you open a bug?
> 
>  
> 
> Just did it:
> 
> https://bugs.launchpad.net/manila-ui/+bug/1638934
> 
>  
> 
> Thanks!
> 
>  Arne
> 
>  
> 
>  
> 
> 
> 
> On 11/3/16, 7:32 AM, "Arne Wiebalck"  > wrote:
> 
>Hi,
> 
>As cephx has been added as an access type in the dashboard and an
> access key can now
>be part of the API's response to access list requests, is it
> planned to have the access key to
>be returned when adding a cephx access rule via the UI (for
> instance similar to what ‘Create
>Key Pair’ in the instance panel does)? Couldn’t find any mention
> of such an activity.
> 
>Thanks!
> Arne
> 
>--
>Arne Wiebalck
>CERN IT
> 
>
> __
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org
> ?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>  
> 
> --
> Arne Wiebalck
> CERN IT
> 
> 
> 

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

Re: [openstack-dev] Splitting notifications from rpc (and questions + work around this)

[Davanum Srinivas]

Cheran,

Nova and Neutron already supported this split when we started this
exercise. So yes, they are already shipped :)

https://review.openstack.org/#/c/266960/
https://review.openstack.org/#/c/268335/

-- Dims

On Thu, Nov 3, 2016 at 1:43 PM, Elancheran Subramanian
 wrote:
> Hi Dims,
> Thanks for sharing…
>
> Just wanted to check whether there is any development for Nova and Neutron
> going on, which we can leverage?
>
> Thanks,
> Cheran
>
>
>
>
> On 11/3/16, 12:51 AM, "Davanum Srinivas"  wrote:
>
>>Josh,
>>
>>Kirill Bespalov put together this doc of which components will work
>>with separate rpc and notification configurations:
>>https://docs.google.com/document/d/1CU0KjL9iV8vut76hg9cFuWQGSJawuNq_cK7vRF
>>_KyAA/edit?usp=sharing
>>
> >From my team, Oleksii Zamiatin is trying to scale up ZMQ beyond 200+
>>nodes for RPC.
>>
>>Ilya Tyaptin's review is stuck because Monasca folks have trouble
>>using the newer python-kafka version:
>>https://review.openstack.org/#/c/332105/
>>https://review.openstack.org/#/c/316259/
>>
>>As you can tell, we are trying to offer RabbitMQ or ZMQ for RPC and
>>RabbitMQ or Kafka for Notifications.
>>
>>Hope this helps.
>>
>>Thanks,
>>Dims
>>
>>On Wed, Nov 2, 2016 at 8:11 PM, Joshua Harlow 
>>wrote:
>>> Hi folks,
>>>
>>> There was a bunch of chatter at the summit about how there are really
>>>two
>>> different types of (oslo) messaging usage that exist in openstack and
>>>how
>>> they need not be backed by the same solution type (rabbitmq, qpid,
>>> kafka...).
>>>
>>> For those that were not at the oslo sessions:
>>>
>>> https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Oslo
>>>
>>> The general gist was though that we need to make sure people really do
>>>know
>>> that there are two very different types of messaging usage in openstack
>>>and
>>> to ensure that operators (and developers) are picking the right backing
>>> technology for each type.
>>>
>>> So some questions naturally arise out of this.
>>>
>>> * Where are the best practices with regard to selection of the best
>>>backend
>>> type for rpc (and one for notifications); is this something
>>>oslo.messaging
>>> should work through (or can the docs team and operator group also help
>>>in
>>> making this)?
>>>
>>> * What are the tradeoffs in using the same (or different) technology
>>>for rpc
>>> and notifications?
>>>
>>> * Is it even possible for all oslo.messaging consuming projects to be
>>>able
>>> to choose 2 different backends, are consuming projects consuming the
>>>library
>>> correctly so that they can use 2 different backends?
>>>
>>> * Is devstack able to run with say kafka for notifications and rabbitmq
>>>for
>>> rpc (if not, is there any work item the oslo group can help with to make
>>> this possible) so that we can ensure and test that all projects can work
>>> correctly with appropriate (and possibly different) backends?
>>>
>>> * Any other messaging, arch-wg work that we (oslo or others) can help
>>>out
>>> with to make sure that projects (and operators) are using the right
>>> technology for the right use (and not just defaulting to RPC over
>>>rabbitmq
>>> because it exists, when in reality something else might be a better
>>>choice)?
>>>
>>> * More(?)
>>>
>>> Just wanted to get this conversation started, because afaik it's one
>>>that
>>> has not been widely circulated (and operators have been setting up
>>>rabbitmq
>>> in various HA and clustered and ... modes, when in reality thinking
>>>through
>>> what and how it is used may be more appropriate); this also applies to
>>> developers since some technical solutions in openstack seem to be
>>>created
>>> due to (in-part) rabbitmq shortcomings (cells v1 afaik was *in* part
>>>created
>>> due to scaling issues).
>>>
>>> -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
>>
>>
>>
>>--
>>Davanum Srinivas :: https://twitter.com/dims
>>
>>__
>>OpenStack Development Mailing 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



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] Splitting notifications from rpc (and questions + work around this)

[Elancheran Subramanian]

Hi Dims,
Thanks for sharing… 

Just wanted to check whether there is any development for Nova and Neutron 
going on, which we can leverage?  

Thanks,
Cheran




On 11/3/16, 12:51 AM, "Davanum Srinivas"  wrote:

>Josh,
>
>Kirill Bespalov put together this doc of which components will work
>with separate rpc and notification configurations:
>https://docs.google.com/document/d/1CU0KjL9iV8vut76hg9cFuWQGSJawuNq_cK7vRF
>_KyAA/edit?usp=sharing
>
>From my team, Oleksii Zamiatin is trying to scale up ZMQ beyond 200+
>nodes for RPC.
>
>Ilya Tyaptin's review is stuck because Monasca folks have trouble
>using the newer python-kafka version:
>https://review.openstack.org/#/c/332105/
>https://review.openstack.org/#/c/316259/
>
>As you can tell, we are trying to offer RabbitMQ or ZMQ for RPC and
>RabbitMQ or Kafka for Notifications.
>
>Hope this helps.
>
>Thanks,
>Dims
>
>On Wed, Nov 2, 2016 at 8:11 PM, Joshua Harlow  
>wrote:
>> Hi folks,
>>
>> There was a bunch of chatter at the summit about how there are really 
>>two
>> different types of (oslo) messaging usage that exist in openstack and 
>>how
>> they need not be backed by the same solution type (rabbitmq, qpid,
>> kafka...).
>>
>> For those that were not at the oslo sessions:
>>
>> https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Oslo
>>
>> The general gist was though that we need to make sure people really do 
>>know
>> that there are two very different types of messaging usage in openstack 
>>and
>> to ensure that operators (and developers) are picking the right backing
>> technology for each type.
>>
>> So some questions naturally arise out of this.
>>
>> * Where are the best practices with regard to selection of the best 
>>backend
>> type for rpc (and one for notifications); is this something 
>>oslo.messaging
>> should work through (or can the docs team and operator group also help 
>>in
>> making this)?
>>
>> * What are the tradeoffs in using the same (or different) technology 
>>for rpc
>> and notifications?
>>
>> * Is it even possible for all oslo.messaging consuming projects to be 
>>able
>> to choose 2 different backends, are consuming projects consuming the 
>>library
>> correctly so that they can use 2 different backends?
>>
>> * Is devstack able to run with say kafka for notifications and rabbitmq 
>>for
>> rpc (if not, is there any work item the oslo group can help with to make
>> this possible) so that we can ensure and test that all projects can work
>> correctly with appropriate (and possibly different) backends?
>>
>> * Any other messaging, arch-wg work that we (oslo or others) can help 
>>out
>> with to make sure that projects (and operators) are using the right
>> technology for the right use (and not just defaulting to RPC over 
>>rabbitmq
>> because it exists, when in reality something else might be a better 
>>choice)?
>>
>> * More(?)
>>
>> Just wanted to get this conversation started, because afaik it's one 
>>that
>> has not been widely circulated (and operators have been setting up 
>>rabbitmq
>> in various HA and clustered and ... modes, when in reality thinking 
>>through
>> what and how it is used may be more appropriate); this also applies to
>> developers since some technical solutions in openstack seem to be 
>>created
>> due to (in-part) rabbitmq shortcomings (cells v1 afaik was *in* part 
>>created
>> due to scaling issues).
>>
>> -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
>
>
>
>-- 
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>OpenStack Development Mailing 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] proposal to resolve a rootwrap problem for XenServer

[Bob Ball]

>> Side note: we should first have Xen third-party CI testing running
>
> It already is running

> Oh right. It does not validate the new change though. Would be nice to see  
> the new ‘daemon’-ic mode behaves in real world.

100% agreed.  I'll work with Jianghua to make sure we get automated test 
coverage of this.

Thanks for all your input,

Bob
__
OpenStack Development Mailing 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][api] POST /api-wg/news

[Chris Dent]

Greetings OpenStack community,

This week's meeting of the working group talked about the discussion at the API-WG 
"birds of a feather" at last week's summit in Barcelona. Thanks to everyone who 
showed up for that. I hope it was interesting and useful. Also thanks very much to all 
the people who participated in the API UX feedback sessions[8]. Piet has gathered the raw 
data together and will be producing a digested summary soon. From looking at the raw data 
it is clear people get a lot of value out of the APIs and while we still have work to do 
to make them excellent, the directions we're moving to do so (e.g., consistency, better 
error information) are good.

There are a few new guidelines and newly frozen guidelines this week. See 
below. Thanks to everyone who has helped to create and refine those.

# New guidelines

There are no new guidelines that have been merged this week.

# API guidelines that have been recently merged

No recent guidelines.

  # API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.

* Add guidelines for complex queries
  https://review.openstack.org/#/c/386614/

* Specify time intervals based filtering queries
  https://review.openstack.org/#/c/383862/

* Clarify why CRUD is not a great descriptor
  https://review.openstack.org/#/c/392156/

# Guidelines currently under review [6]

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* WIP Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [3].

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
[6]: https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[8]: 
https://wiki.openstack.org/wiki/UX#Participate_in_a_usability_study_being_conducted_at_the_Barcelona_Summit.21

--
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] [glance] draft logo of glance mascot

[Brian Rosmaita]

Hello Heidi Joy,

First, let me say on behalf of the Glance community that we appreciate the
hard work you and your team have done in creating all the team
mascot/logos.

We discussed the draft logo at the weekly Glance meeting today [0], and
the general sense of the Glance community is that we'd like to request a
re-draft.  I'm not sure we conveyed clearly to you how important the
mouth-full-of-nuts aspect was to our choice of a chipmunk [1].  We could
tell from the video [2] that you started with the sample picture [3] and
worked from there to create something more streamlined, but we were really
hoping for something more like the sample picture.

The importance of the mouth-full-of-nuts aspect is that Glance curates and
stores virtual machine images and other services consume images supplied
from Glance.  Additionally, this would more clearly distinguish our logo
from that of other projects.

Thanks for being so willing to consider feedback!

cheers,
brian

[0] 
http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-11-03-14.00
.log.html (beginning 14:14:07)
[1] https://etherpad.openstack.org/p/glance-project-mascot (lines 38-41)
[2] https://youtu.be/JmMTCWyY8Y4?t=41
[3] https://www.fortwhyte.org/wp-content/uploads/2014/12/chip2.jpg




On 10/21/16, 12:43 PM, "Brian Rosmaita" 
wrote:

>Hello Glancers,
>
>Heidi Joy Tretheway and Todd Morey from the foundation have sent us the
>attached sneak preview of the Glance mascot/logo.  (As you may recall, we
>voted for a chipmunk [0].)
>
>They've set up a handy form [1] so that you can provide individual
>feedback.  The project logos will be finalized in time for the February
>PTG, so please provide any feedback before Friday, November 11.
>
>Before providing feedback, you might want to take a look at a short
>(50-second) video [2] to see how the logos developed and how they present
>a consistent interface across OpenStack projects.
>
>Since we're looking at light turnout for the Barcelona summit, I've put
>discussion of the logo on the agenda for the November 3 edition of the
>Glance weekly meeting [3].
>
>Keep in mind that the logo is still a draft, so please don't tweet it or
>use it in any promotional materials.
>
>cheers,
>brian
>
>[0] https://etherpad.openstack.org/p/glance-project-mascot
>[1] http://tinyurl.com/OSmascot
>[2] https://youtu.be/JmMTCWyY8Y4
>[3] https://etherpad.openstack.org/p/glance-team-meeting-agenda
>


__
OpenStack Development Mailing 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] [manila] spec review focus

[Ben Swartzlander]

As agreed to in the manila spec process spec, the whole core team is 
expected to review certain specs and vote before they merge.


The following specs were designed as review focus specs for Ocata:

https://etherpad.openstack.org/p/manila-ocata-spec-review-focus


-Ben Swartzlander



__
OpenStack Development Mailing 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] important changes to pep8 python jobs

[Paul Belanger]

Greetings,

We (openstack-infra) are proposing a change to the current pep8[1] job for
python jobs, and would like to bring your attention to it.

We'll be removing the extra-index-url field from pip.conf which forces the job
to manually build any missing wheels as dependencies.  The reason for this, is
to force a way for jobs to ensure the proper OS dependencies are installed.

There is a chance your project pep8 job may break, which is why we are sending
out this email.  We encourage each project to be using bindep[2], binary
dependency management tool, to ensure any OS packages are needed. If your
project needs a specific binary to be installed to compile your project, simply
add it to the bindep.txt file in your project repo.

We'll be approving the change on Nov. 16, 2016 and send out another message as
we move closer to the date.

If you have any questions, feel free to reply or use #openstack-infra on
freenode.

---
Paul Belanger

[1] https://review.openstack.org/391875
[2] http://docs.openstack.org/infra/bindep/

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

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

[Rochelle Grober]

a blog post on the OpenStack sore might be good. superuser? there are folks 
reading this who can help

Sent from HUAWEI AnyOffice
From:Lance Bragstad
To:OpenStack Development Mailing List (not for usage 
questions),openstack-operat...@lists.openstack.org,
Date:2016-11-03 08:11:20
Subject:Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing 
default token format

I totally agree with communicating this the best we can. I'm adding the 
operator list to this thread to increase visibility.

If there are any other methods folks think of for getting the word out, outside 
of what we've already done (release notes, email threads, etc.), please let me 
know. I'd be happy to drive those communications.

On Thu, Nov 3, 2016 at 9:45 AM, Alex Schultz 
> wrote:
Hey Steve,

On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli 
> wrote:
> Thanks Alex and Emilien for the quick answer. This was brought up at the
> summit by Adam, but I don't think we have to prevent keystone from changing
> the default. TripleO and Puppet can still specify UUID as their desired
> token format; it is not deprecated or slated for removal. Agreed?
>

My email was not to tell you to stop.I was just letting you know that
your change does not affect the puppet modules because we define our
default as UUID.  It was just as a heads up to others on this email
that this change should not affect anyone consuming the puppet modules
because our default is still UUID and will be even after keystone's
default changes.

Thanks,
-Alex

> On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz 
> > wrote:
>>
>> Hey Steve,
>>
>> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli 
>> >
>> wrote:
>> > As a heads up to some of keystone's consuming projects, we will be
>> > changing
>> > the default token format from UUID to Fernet. Many patches have merged
>> > to
>> > make this possible [1]. The last 2 that you probably want to look at are
>> > [2]
>> > and [3]. The first flips a switch in devstack to make fernet the
>> > selected
>> > token format, the second makes it default in Keystone itself.
>> >
>> > [1] https://review.openstack.org/#/q/topic:make-fernet-default
>> > [2] DevStack patch: https://review.openstack.org/#/c/367052/
>> > [3] Keystone patch: https://review.openstack.org/#/c/345688/
>> >
>>
>> Thanks for the heads up. In puppet openstack we had already
>> anticipated this and attempted to do the same for the
>> puppet-keystone[0] module as well.  Unfortunately after merging it, we
>> found that tripleo wasn't yet prepared to handle the HA implementation
>> of fernet tokens so we had to revert it[1].  This shouldn't impact
>> anyone currently consuming puppet-keystone as we define uuid as the
>> default for now. Our goal is to do something similar this cycle but
>> there needs to be some further work in the downstream consumers to
>> either define their expected default (of uuid) or support fernet key
>> generation correctly.
>>
>> Thanks,
>> -Alex
>>
>> [0] https://review.openstack.org/#/c/389322/
>> [1] https://review.openstack.org/#/c/392332/
>>
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[openstack-dev] [puppet][fuel][packstack][tripleo] puppet 3 end of life

[Alex Schultz]

Hey everyone,

Puppet 3 is reaching it's end of life at the end of this year[0].
Because of this we are planning on dropping official puppet 3 support
as part of the Ocata cycle.  While we currently are not planning on
doing any large scale conversion of code over to puppet 4 only syntax,
we may allow some minor things in that could break backwards
compatibility.  Based on feedback we've received, it seems that most
people who may still be using puppet 3 are using older (< Newton)
versions of the modules.  These modules will continue to be puppet 3.x
compatible but we're using Ocata as the version where Puppet 4 should
be the target version.

If anyone has any concerns or issues around this, please let us know.

Thanks,
-Alex

[0] https://puppet.com/misc/puppet-enterprise-lifecycle

__
OpenStack Development Mailing 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][i18n] how to indicate non-translatable identifiers in translatable strings?

[Ian Y. Choi]

Hello,

I am from I18n team. Please see inline for my comments.


Doug Hellmann wrote on 11/3/2016 2:19 AM:

Excerpts from Brian Rosmaita's message of 2016-11-02 16:34:45 +:

This issue came up during a code review; I've asked around a bit but
haven't been able to find an answer.

Some of the help output for utility scripts associated with Glance aren't
being translated, so Li Wei put up a patch to fix this [0], but there are
at least two problematic cases.

Case 1:
 parser.add_option('-S', '--os_auth_strategy', dest="os_auth_strategy",
 metavar="STRATEGY",
 help=_("Authentication strategy (keystone or noauth)."))

For that one, 'keystone' and 'noauth' are identifiers, so we don't want
them translated.  Would putting single quotes around them like this be
sufficient to indicate they shouldn't be translated?  For example,

 help=_("Authentication strategy ('keystone' or 'noauth').")


Andreas Jaeger mentioned that maybe we could use a "translation comment"
[1].  I guess we'd do something like:

 # NOTE: do not translate the stuff in single quotes
 help=_("Authentication strategy ('keystone' or 'noauth').")

The ability to pass comments to the translators like that seems
really useful, if it would work with our tools.

+1 from me and also Daisy (former i18n PTL).

I18n team quite agrees what adding translation comments can pass more 
information to translators from developers.



It seems like things we put in quotes should not be translated, by
convention.

I agree with Doug, and Brant's suggestion also looks nice.

To slightly revise from Brant's suggestion, the following original 
string for translation looks much better:


 : "Authentication strategy (%(keystone)s or %(noauth)s).")

 -> %(keystone)s and %(noauth)s will be replaced with "'keystone'" and 
"'noauth'" correspondingly.





What are other people doing for this?

Case 2:
We've got a big block of usage text, roughly

 usage = _("""
%prog  [options] [args]

Commands:
 keyword1what it does
 keyword2what it does
 ...
 keyword8what it does
""")

We don't want the keywords to be translated, but I'm not sure how to
convey this to the translators.

This is a case where using quotes won't work. Using a different
tool to build the help text (argparse instead of optparse), or even
just building the text from parts inline (put the parts you do or
do not want translated into separate variables and then combine the
results like a template) might work. Both add a bit of complexity.
The second option doesn't require completely rewriting the CLI
processing logic.
I think translators easily capture the context of this kind of command 
help strings.


After my brief research on other projects, GNU coreutils also do the 
same way for extracting translation strings

(e.g., http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c#n4882 ).

For command help strings, translators will prefer not to divide one 
overall string into multiple line-by-line strings,
for example:_("""%prog  [options] [args]""") + "\n" + 
_("""Commands:""") + "\n" + _("""  keyword1  what it does""") .



By the way, can i18n team set any rules within the team,
for example, "don't translate any words in capital.", "If developers 
don't want to translate some words, write them in capital.", and so on?


What do developers think about this idea?


With many thanks,

/Ian


Thanks in advance for your help,
brian


[0] https://review.openstack.org/#/c/367795/8
[1] http://babel.pocoo.org/en/latest/messages.html#translator-comments


__
OpenStack Development Mailing 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] [keystone][tripleo][ansible][puppet][all] changing default token format

[Lance Bragstad]

I totally agree with communicating this the best we can. I'm adding the
operator list to this thread to increase visibility.

If there are any other methods folks think of for getting the word out,
outside of what we've already done (release notes, email threads, etc.),
please let me know. I'd be happy to drive those communications.

On Thu, Nov 3, 2016 at 9:45 AM, Alex Schultz  wrote:

> Hey Steve,
>
> On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli 
> wrote:
> > Thanks Alex and Emilien for the quick answer. This was brought up at the
> > summit by Adam, but I don't think we have to prevent keystone from
> changing
> > the default. TripleO and Puppet can still specify UUID as their desired
> > token format; it is not deprecated or slated for removal. Agreed?
> >
>
> My email was not to tell you to stop.I was just letting you know that
> your change does not affect the puppet modules because we define our
> default as UUID.  It was just as a heads up to others on this email
> that this change should not affect anyone consuming the puppet modules
> because our default is still UUID and will be even after keystone's
> default changes.
>
> Thanks,
> -Alex
>
> > On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz 
> wrote:
> >>
> >> Hey Steve,
> >>
> >> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli <
> s.martine...@gmail.com>
> >> wrote:
> >> > As a heads up to some of keystone's consuming projects, we will be
> >> > changing
> >> > the default token format from UUID to Fernet. Many patches have merged
> >> > to
> >> > make this possible [1]. The last 2 that you probably want to look at
> are
> >> > [2]
> >> > and [3]. The first flips a switch in devstack to make fernet the
> >> > selected
> >> > token format, the second makes it default in Keystone itself.
> >> >
> >> > [1] https://review.openstack.org/#/q/topic:make-fernet-default
> >> > [2] DevStack patch: https://review.openstack.org/#/c/367052/
> >> > [3] Keystone patch: https://review.openstack.org/#/c/345688/
> >> >
> >>
> >> Thanks for the heads up. In puppet openstack we had already
> >> anticipated this and attempted to do the same for the
> >> puppet-keystone[0] module as well.  Unfortunately after merging it, we
> >> found that tripleo wasn't yet prepared to handle the HA implementation
> >> of fernet tokens so we had to revert it[1].  This shouldn't impact
> >> anyone currently consuming puppet-keystone as we define uuid as the
> >> default for now. Our goal is to do something similar this cycle but
> >> there needs to be some further work in the downstream consumers to
> >> either define their expected default (of uuid) or support fernet key
> >> generation correctly.
> >>
> >> Thanks,
> >> -Alex
> >>
> >> [0] https://review.openstack.org/#/c/389322/
> >> [1] https://review.openstack.org/#/c/392332/
> >>
> >> >
> >> > 
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [manila] propose adding gouthamr to manila core

[Valeriy Ponomaryov]

+2

On Thu, Nov 3, 2016 at 4:36 PM, yang, xing  wrote:

> +1.
>
> Thanks,
> Xing
>
>
>
> 
> From: Tom Barron [whui...@gmail.com]
> Sent: Wednesday, November 2, 2016 8:09 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [manila] propose adding gouthamr to manila core
>
> I hereby propose that we add Goutham Pacha Ravi (gouthamr on IRC) to the
> manila core team.  This is a clear case where he's already been doing
> the review work, excelling both qualitatively and quantitatively, as
> well as being a valuable committer to the project.  Goutham deserves to
> be core and we need the additional bandwidth for the project.  He's
> treated as a de facto core by the community already.  Let's make it
> official!
>
> -- Tom Barron
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

[Alex Schultz]

Hey Steve,

On Thu, Nov 3, 2016 at 8:29 AM, Steve Martinelli  wrote:
> Thanks Alex and Emilien for the quick answer. This was brought up at the
> summit by Adam, but I don't think we have to prevent keystone from changing
> the default. TripleO and Puppet can still specify UUID as their desired
> token format; it is not deprecated or slated for removal. Agreed?
>

My email was not to tell you to stop.I was just letting you know that
your change does not affect the puppet modules because we define our
default as UUID.  It was just as a heads up to others on this email
that this change should not affect anyone consuming the puppet modules
because our default is still UUID and will be even after keystone's
default changes.

Thanks,
-Alex

> On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz  wrote:
>>
>> Hey Steve,
>>
>> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli 
>> wrote:
>> > As a heads up to some of keystone's consuming projects, we will be
>> > changing
>> > the default token format from UUID to Fernet. Many patches have merged
>> > to
>> > make this possible [1]. The last 2 that you probably want to look at are
>> > [2]
>> > and [3]. The first flips a switch in devstack to make fernet the
>> > selected
>> > token format, the second makes it default in Keystone itself.
>> >
>> > [1] https://review.openstack.org/#/q/topic:make-fernet-default
>> > [2] DevStack patch: https://review.openstack.org/#/c/367052/
>> > [3] Keystone patch: https://review.openstack.org/#/c/345688/
>> >
>>
>> Thanks for the heads up. In puppet openstack we had already
>> anticipated this and attempted to do the same for the
>> puppet-keystone[0] module as well.  Unfortunately after merging it, we
>> found that tripleo wasn't yet prepared to handle the HA implementation
>> of fernet tokens so we had to revert it[1].  This shouldn't impact
>> anyone currently consuming puppet-keystone as we define uuid as the
>> default for now. Our goal is to do something similar this cycle but
>> there needs to be some further work in the downstream consumers to
>> either define their expected default (of uuid) or support fernet key
>> generation correctly.
>>
>> Thanks,
>> -Alex
>>
>> [0] https://review.openstack.org/#/c/389322/
>> [1] https://review.openstack.org/#/c/392332/
>>
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

[Ihar Hrachyshka]

Bob Ball  wrote:


Hi Ihar,


I am puzzled. Is Neutron the only component that need to call to dom0?


No it's not.  Nova has similar code to call plugins in dom0[1], and  
Ceilometer will also need to make the calls for some metrics not exposed  
through the formal API.


We don't want code duplication, and are working on a common os-xenapi  
library which will include session management.
It would, of course, make sense for Neutron to use this common library  
when it is available to replace the session management already  
existing[2], but I'd argue that as there is existing XenAPI session  
management code, the refactor to avoid using a per-command rootwrap  
should be independent of using the session code from os-xenapi.


Seems like you are in a position that requires you to hook into neutron  
processes somehow, and it’s either neutron itself (your solution), or a  
library used by neutron (oslo.rootwrap or similar). I understand why you  
picked the first option.




I would think that Neutron is not in business of handling hypervisor  
privilege isolation mechanics, and that
some other components will handle that for Neutron (and other services  
that may need it), that’s why I

suggested to consider oslo.* realm for the proposed code.


This is less about hypervisor privilege isolation and more about the  
location of the logical component being updated.  Neutron is assuming  
that the OVS being updated is running in the same location as Neutron  
itself.  For XenAPI that is not true; the OVS is running in the  
hypervisor, whereas Neutron is running in a VM (or potentially elsewhere  
entirely).


If oslo.* is going to decide whether to run a command using a specific  
abstraction or locally, then it would need some way of making that  
decision - perhaps either command-based (very ugly and fragile) or with  
the caller telling oslo.* what logical component was being affected by  
the call.  The latter sounds to me much more as a Neutron-specific  
decision.


I believe os-xenapi is a nice path forward. I understand it will take some  
time to shape.


As for the dom0/domU routing decision, yes, it’s indeed on Neutron to make  
it. But it does not mean that we could not rely on existing filtering  
mechanisms (oslo.rootwrap ‘.filters’ files) to define that decision. The  
fact that current netwrap script for Xen duplicates filters from rootwrap  
is unfortunate. It should be a single source of truth.


It would probably require some extensive work in the library, and  
considering that oslo folks moved the library into maintenance mode, it  
probably won’t happen. As for oslo.privsep, that would be a better place  
for such a feature, but we won’t get there in Ocata. Bummer…


I guess I will unblock the patch, and we’ll see what others think. I left  
some initial review comments.




Side note: if we are going to make drastic changes to existing Xen-wrap  
script, we should first have Xen
third-party CI testing running against it, not to introduce regressions.  
AFAIK it’s not happening right now.


It already is running, and has been for several months - see "Citrix  
XenServer CI"s "dsvm-tempest-neutron-network" job on  
https://review.openstack.org/#/c/391308/ as an example.  The CI is  
non-voting but if it were added to the neutron-ci group we would be very  
happy to make it voting.


Oh right. It does not validate the new change though. Would be nice to see  
the new ‘daemon’-ic mode behaves in real world.


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] [manila] propose adding gouthamr to manila core

[yang, xing]

+1.

Thanks,
Xing




From: Tom Barron [whui...@gmail.com]
Sent: Wednesday, November 2, 2016 8:09 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [manila] propose adding gouthamr to manila core

I hereby propose that we add Goutham Pacha Ravi (gouthamr on IRC) to the
manila core team.  This is a clear case where he's already been doing
the review work, excelling both qualitatively and quantitatively, as
well as being a valuable committer to the project.  Goutham deserves to
be core and we need the additional bandwidth for the project.  He's
treated as a de facto core by the community already.  Let's make it
official!

-- Tom Barron

__
OpenStack Development Mailing 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] [manila] Barcelona Design Summit summary

[Ben Swartzlander]

Thanks to gouthamr for doing these writeups and for recording!

We had a great turn out at the manila Fishbowl and working sessions. 
Important notes and Action Items are below:


===
Fishbowl 1: Race Conditions
===
Thursday 27th Oct / 11:00 - 11:40 / AC Hotel -Salon Barcelona - P1
Etherpad: https://etherpad.openstack.org/p/ocata-manila-race-conditions
Video: https://www.youtube.com/watch?v=__P7zQobAQw

Gist:
* We've some race conditions that have worsened over time:
  * Deleting a share while snapshotting the share
  * Two simultaneous delete-share calls
  * Two simultaneous create-snapshot calls
* Though the end result of the race conditions is not terrible, we can 
leave resources in untenable states, requiring administrative cleanup in 
the worst scenario
* Any type of resource interaction must be protected in the database 
with a test-and-set using the appropriate status fields

* Any test-and-set must be protected with a lock
* Locks must not be held over long running tasks: i.e, RPC Casts, driver 
invocations etc.
* We need more granular state transitions: micro/transitional states 
must be added per resource and judiciously used for state locking

* Ex: Shares need a 'snapshotting' state
* Ex: Share servers need states to signify setup phases, a la nova 
compute instances


Discussion Item:
* Locks in the manila-api service (or specifically, extending usage of 
locks across all manila services)

* Desirable because:
  * Adding test-and-set logic at the database layer may render code 
unmaintainable complicated as opposed to using locking abstractions 
(oslo.concurrency / tooz)
  * Cinder has evolved an elegant test-and-set solution but we may not 
be able to benefit from that implementation because of the lack of being 
able to do multi-table updates and because the code references OVO which 
manila doesn't yet support.

* Un-desirable because:
  * Most distributors (RedHat/Suse/Kubernetes-based/MOS) want to run 
more than one API service in active-active H/A.
  * If a true distributed locking mechanism isn't used/supported, the 
current file-locks would be useless in the above scenario.
  * Running file locks on shared file systems is a possibility, but 
applies configuration/set-up burden
  * Having all the locks on the share service would allow scale out of 
the API service and the share manager is really the place where things 
are going wrong
  * With a limited form of test-and-set, atomic state changes can still 
be achieved for the API service.


Agreed:
* File locks will not help

Action Items:
(bswartz): Will propose a spec for the locking strategy
(volunteers): Act on the spec ^ and help add more transitional states 
and locks (or test-and-set if any)
(gouthamr): state transition diagrams for shares/share 
instances/replicas, access rules / instance access rules
(volunteers): Review ^ and add state transition diagrams for 
snapshots/snapshot instances, share servers
(mkoderer): will help with determining race conditions within 
manila-share with tests


=
Fishbowl 2: Data Service / Jobs Table
=
Thursday 27th Oct / 11:50 - 12:30 / AC Hotel - Salon Barcelona - P1
Etherpad: 
https://etherpad.openstack.org/p/ocata-manila-data-service-jobs-table

Video: https://www.youtube.com/watch?v=Sajy2Qjqbmk

Gist:
* Currently, a synchronous RPC call is made from the API to the 
share-manager/data-service that's performing a migration to get the 
progress of a migration
* We need a way to record progress of long running tasks: migration, 
backup, data copy etc.
* We need to introduce a jobs table so that the respective service 
performing the long running task can write to the database and the API 
relies on the database


Discussion Items:
* There was a suggestion to extend the jobs table to all tasks on the 
share: snapshotting, creating share from snapshot, extending, shrinking, 
etc.
* We agreed not to do this because the table can easily go out of 
control; and there isn't a solid use case to register all jobs. Maybe 
asynchronous user messages is a better answer to this feature request

* "restartable" jobs would benefit from the jobs table
* service heartbeats could be used to react to services dying while 
running long running jobs
* When running the data service in active-active mode, a service going 
down can pass on its jobs to the other data service


Action Items:
(ganso): Will determine the structure of the jobs table model in his spec
(ganso): Will determine the benefit of the data service reacting to 
additions in the database rather than acting upon RPC requests


=
Working Sessions 1: High Availability
=
Thursday 27th Oct / 14:40 - 15:20 / CCIB - Centre de Convencions 
Internacional de Barcelona - P1 - Room 130

Etherpad: https://etherpad.openstack.org/p/ocata-manila-high-availability
Video: 

Re: [openstack-dev] [manila] Access key via the UI?

[Ravi, Goutham]

Ah. I’d let Tom or Ramana weigh in on that. IIRC, the access key is plaintext, 
so, I thought it can be displayed; that’s what the CLI is doing.
Reading the spec though, this was an intended part of the feature: 
http://specs.openstack.org/openstack/manila-specs/specs/newton/auth-access-keys.html


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

Date: Thursday, November 3, 2016 at 10:15 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [manila] Access key via the UI?

Hi Goutham,

It’s already being returned in the manila access-list API as of 2.21, if you’re 
using the latest python-manilaclient, you should have it there. However, it’s 
missing in the UI:

Yes, I was comparing what I can do on the CLI and what was offered with the UI.


https://github.com/openstack/manila-ui/blob/c986a100eecf46af4b597cdcf59b5bc1edc2d1b0/manila_ui/dashboards/project/shares/shares/tables.py#L278

Are you suggesting to simply display it? (I was more thinking of a one-time 
download when giving access,
similar to what is offered for keys for instance creation.)


Could you open a bug?

Just did it:
https://bugs.launchpad.net/manila-ui/+bug/1638934

Thanks!
 Arne




On 11/3/16, 7:32 AM, "Arne Wiebalck" 
> wrote:

   Hi,

   As cephx has been added as an access type in the dashboard and an access key 
can now
   be part of the API's response to access list requests, is it planned to have 
the access key to
   be returned when adding a cephx access rule via the UI (for instance similar 
to what ‘Create
   Key Pair’ in the instance panel does)? Couldn’t find any mention of such an 
activity.

   Thanks!
Arne

   --
   Arne Wiebalck
   CERN IT

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


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

--
Arne Wiebalck
CERN IT


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

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

[Steve Martinelli]

Thanks Alex and Emilien for the quick answer. This was brought up at the
summit by Adam, but I don't think we have to prevent keystone from changing
the default. TripleO and Puppet can still specify UUID as their desired
token format; it is not deprecated or slated for removal. Agreed?

On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz  wrote:

> Hey Steve,
>
> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli 
> wrote:
> > As a heads up to some of keystone's consuming projects, we will be
> changing
> > the default token format from UUID to Fernet. Many patches have merged to
> > make this possible [1]. The last 2 that you probably want to look at are
> [2]
> > and [3]. The first flips a switch in devstack to make fernet the selected
> > token format, the second makes it default in Keystone itself.
> >
> > [1] https://review.openstack.org/#/q/topic:make-fernet-default
> > [2] DevStack patch: https://review.openstack.org/#/c/367052/
> > [3] Keystone patch: https://review.openstack.org/#/c/345688/
> >
>
> Thanks for the heads up. In puppet openstack we had already
> anticipated this and attempted to do the same for the
> puppet-keystone[0] module as well.  Unfortunately after merging it, we
> found that tripleo wasn't yet prepared to handle the HA implementation
> of fernet tokens so we had to revert it[1].  This shouldn't impact
> anyone currently consuming puppet-keystone as we define uuid as the
> default for now. Our goal is to do something similar this cycle but
> there needs to be some further work in the downstream consumers to
> either define their expected default (of uuid) or support fernet key
> generation correctly.
>
> Thanks,
> -Alex
>
> [0] https://review.openstack.org/#/c/389322/
> [1] https://review.openstack.org/#/c/392332/
>
> > 
> __
> > OpenStack Development Mailing 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] [keystone][tripleo][ansible][puppet][all] changing default token format

[Alex Schultz]

Hey Steve,

On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli  wrote:
> As a heads up to some of keystone's consuming projects, we will be changing
> the default token format from UUID to Fernet. Many patches have merged to
> make this possible [1]. The last 2 that you probably want to look at are [2]
> and [3]. The first flips a switch in devstack to make fernet the selected
> token format, the second makes it default in Keystone itself.
>
> [1] https://review.openstack.org/#/q/topic:make-fernet-default
> [2] DevStack patch: https://review.openstack.org/#/c/367052/
> [3] Keystone patch: https://review.openstack.org/#/c/345688/
>

Thanks for the heads up. In puppet openstack we had already
anticipated this and attempted to do the same for the
puppet-keystone[0] module as well.  Unfortunately after merging it, we
found that tripleo wasn't yet prepared to handle the HA implementation
of fernet tokens so we had to revert it[1].  This shouldn't impact
anyone currently consuming puppet-keystone as we define uuid as the
default for now. Our goal is to do something similar this cycle but
there needs to be some further work in the downstream consumers to
either define their expected default (of uuid) or support fernet key
generation correctly.

Thanks,
-Alex

[0] https://review.openstack.org/#/c/389322/
[1] https://review.openstack.org/#/c/392332/

> __
> OpenStack Development Mailing 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] [neutron][networking-vpp] - Status of startup issues

[John Joyce (joycej)]

Is anyone able to provide a summary of which patches fix the startup scenarios. 
Any startup issues are of interest but the one we specifically have bugs around 
is the phsynets not being discovered by the server properly.
I see: https://bugs.launchpad.net/networking-vpp/+bug/1631063 which says a fix 
was committed, but no reference to the what the fix is and I don’t think the 
fix really merged yet as https://review.openstack.org/#/c/386280/ is reporting 
to be fixing it.
Are all these patches associated with the issue:
https://review.openstack.org/#/c/382587/
https://review.openstack.org/#/c/386280/
https://review.openstack.org/#/c/391523/
https://review.openstack.org/#/c/381538/
If not which of the above are required to get a clean start-up.  Does anyone 
have the complete picture?

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] [neutron] proposal to resolve a rootwrap problem for XenServer

[Bob Ball]

Hi Ihar,

> I am puzzled. Is Neutron the only component that need to call to dom0?

No it's not.  Nova has similar code to call plugins in dom0[1], and Ceilometer 
will also need to make the calls for some metrics not exposed through the 
formal API.

We don't want code duplication, and are working on a common os-xenapi library 
which will include session management.
It would, of course, make sense for Neutron to use this common library when it 
is available to replace the session management already existing[2], but I'd 
argue that as there is existing XenAPI session management code, the refactor to 
avoid using a per-command rootwrap should be independent of using the session 
code from os-xenapi.

> I would think that Neutron is not in business of handling hypervisor 
> privilege isolation mechanics, and that
> some other components will handle that for Neutron (and other services that 
> may need it), that’s why I
> suggested to consider oslo.* realm for the proposed code.

This is less about hypervisor privilege isolation and more about the location 
of the logical component being updated.  Neutron is assuming that the OVS being 
updated is running in the same location as Neutron itself.  For XenAPI that is 
not true; the OVS is running in the hypervisor, whereas Neutron is running in a 
VM (or potentially elsewhere entirely).

If oslo.* is going to decide whether to run a command using a specific 
abstraction or locally, then it would need some way of making that decision - 
perhaps either command-based (very ugly and fragile) or with the caller telling 
oslo.* what logical component was being affected by the call.  The latter 
sounds to me much more as a Neutron-specific decision.

> Side note: if we are going to make drastic changes to existing Xen-wrap 
> script, we should first have Xen
> third-party CI testing running against it, not to introduce regressions. 
> AFAIK it’s not happening right now.

It already is running, and has been for several months - see "Citrix XenServer 
CI"s "dsvm-tempest-neutron-network" job on 
https://review.openstack.org/#/c/391308/ as an example.  The CI is non-voting 
but if it were added to the neutron-ci group we would be very happy to make it 
voting.

Thanks,

[1] 
https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/xenapi/client/session.py#n214
[2] 
https://git.openstack.org/cgit/openstack/neutron/tree/bin/neutron-rootwrap-xen-dom0#n112
__
OpenStack Development Mailing 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] [keystone][tripleo][ansible][puppet][all] changing default token format

[Emilien Macchi]

On Thu, Nov 3, 2016 at 10:11 AM, Steve Martinelli
 wrote:
> As a heads up to some of keystone's consuming projects, we will be changing
> the default token format from UUID to Fernet. Many patches have merged to
> make this possible [1]. The last 2 that you probably want to look at are [2]
> and [3]. The first flips a switch in devstack to make fernet the selected
> token format, the second makes it default in Keystone itself.
>
> [1] https://review.openstack.org/#/q/topic:make-fernet-default
> [2] DevStack patch: https://review.openstack.org/#/c/367052/
> [3] Keystone patch: https://review.openstack.org/#/c/345688/
>

Hey Steve, thanks for the heads-up.
We tried to switch the default in Puppet OpenStack and we broke
TripleO. Our team is currently working on enabling Fernet tokens in
TripleO but it might take some days/weeks.
We hope to solve this problem by ocata-2 milestone.

Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [manila] Access key via the UI?

[Arne Wiebalck]

Hi Goutham,

It’s already being returned in the manila access-list API as of 2.21, if you’re 
using the latest python-manilaclient, you should have it there. However, it’s 
missing in the UI:

Yes, I was comparing what I can do on the CLI and what was offered with the UI.

https://github.com/openstack/manila-ui/blob/c986a100eecf46af4b597cdcf59b5bc1edc2d1b0/manila_ui/dashboards/project/shares/shares/tables.py#L278

Are you suggesting to simply display it? (I was more thinking of a one-time 
download when giving access,
similar to what is offered for keys for instance creation.)

Could you open a bug?

Just did it:
https://bugs.launchpad.net/manila-ui/+bug/1638934

Thanks!
 Arne




On 11/3/16, 7:32 AM, "Arne Wiebalck" 
> wrote:

   Hi,

   As cephx has been added as an access type in the dashboard and an access key 
can now
   be part of the API's response to access list requests, is it planned to have 
the access key to
   be returned when adding a cephx access rule via the UI (for instance similar 
to what ‘Create
   Key Pair’ in the instance panel does)? Couldn’t find any mention of such an 
activity.

   Thanks!
Arne

   --
   Arne Wiebalck
   CERN IT

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


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

--
Arne Wiebalck
CERN IT

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

[openstack-dev] [trove] migration of trove-integration; ci changes

[Amrith Kumar]

Unless you are actively working on Trove, this is something you wouldn't
care about so here's the TL;DR

 

The changes to the Trove CI (including trove, trove-integration, and
python-troveclient) related to the project to get rid of trove-integration
are now complete. Thanks to everyone in infra for the reviews, suggestions,
and help along the way.

 

The details if you care .

 

For some time now we've been working in Trove on a project to get rid of the
trove-integration repository. Now, before you get your expectations up, it
isn't going to be deleted anytime soon. It will continue to be used for the
stable branches (liberty, mitaka and newton) which means that when Queen is
released and Newton gets mothballed, we can finally get rid of the
repository.

 

In the meanwhile, changes to trove-integration will be very limited and only
those things that matter to the stable branches in question. We will
therefore apply the same kind of high bar that we would to changes that
impact the stable branches. Bearing in mind that trove-integration is not
branched, scrutiny will be fairly high.

 

All the things you know and love in trove-integration have been merged into
the trove repository and I'm continue to work on cleaning it up here. This
is an ongoing project, and since the bits now in trove are being used in the
CI, changing it needs to be done with care as it could end up destabilizing
master and making it hard for everyone.

 

If you find some egregious problem in the merge into trove, or if something
has broken that requires immediate attention, please do not hesitate to
contact me. On the other hand, if you find some typos in the artifacts that
came from trove-integration into trove, or you'd like to do something that
is not critical or urgent, I'd request you to let me know so that we don't
end up stomping on each other's changes, and making merge nightmares for
everyone.

 

For the even smaller number of you who read this, and who give a damn about
the trove CI jobs, please note that jobs with the words "integration" or
"legacy" in the name are intended for running only on
stable/(liberty|mitaka|newton) and will likely have a counterpart which does
not have those words in the name. Those jobs are intended for master (i.e.
Ocata and later). There is also a weird name collision that we ended up with
that has resulted in a somewhat awkward change in zuul/layout.yaml which
uses a skip-if in a somewhat peculiar way. If you want to wander near that
and make changes, be warned, there be gotchas there. If in your reviewing,
you notice a job running on trove/master or troveclient/master or a stable
branch Ocata and forward that includes the words legacy or integration, you
can be sure there's a problem.

 

All seems to be good now, several test jobs have done well, let's see if it
holds up. 

 

Thanks!

 

-amrith



smime.p7s
Description: S/MIME cryptographic 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] [keystone][tripleo][ansible][puppet][all] changing default token format

[Steve Martinelli]

As a heads up to some of keystone's consuming projects, we will be changing
the default token format from UUID to Fernet. Many patches have merged to
make this possible [1]. The last 2 that you probably want to look at are
[2] and [3]. The first flips a switch in devstack to make fernet the
selected token format, the second makes it default in Keystone itself.

[1] https://review.openstack.org/#/q/topic:make-fernet-default
[2] DevStack patch: https://review.openstack.org/#/c/367052/
[3] Keystone patch: https://review.openstack.org/#/c/345688/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Christian Berendt]

> On 3 Nov 2016, at 14:33, Mauricio Lima  wrote:
> 
> I Agree. +1

+1

__
OpenStack Development Mailing 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] proposal to resolve a rootwrap problem for XenServer

[Ihar Hrachyshka]

Thierry Carrez  wrote:


Bob Ball wrote:

Oslo.privsep seem try to launch a daemon process and set caps for this

daemon; but for XenAPI, there is no need to spawn the daemon.

I guess I'm lacking some context... If you don't need special rights,  
why use a
rootwrap-like thing at all ? Why go through a separate process to call  
into

XenAPI ? Why not call in directly from Neutron code ?


It does not need to go through a separate process at all, or need  
special rights - see the prototype code at  
https://review.openstack.org/#/c/390931/ which started this thread,  
which is directly calling from Neutron code.


I guess the argument is that we are trying to run "configure something"  
which in some cases is privileged in the same host as is running the  
Neutron code itself, hence the easiest way to do that is to use a  
rootwrap.  To me, the very use of a "rootwrap" or "privsep" implies that  
we're running the commands in the same host.


OK, I think I get it now: Neutron is using its rootwrap call interface
as an indirection layer to route configuration commands either to
execute as root locally (through classic rootwrap) or to execute on dom0
through a XenAPI connection (through rootwrap-xen-dom0). The latter
should really have been called xendom0wrap :)

Arguably we should have a "per logical component" wrapper - in this case  
the network / OVS instance that's being managed - as each component  
could be in a different location.
Mounting a loopback device (which Nova has needed to do in the past)  
clearly needs a rootwrap that runs in the same host as Nova, but when  
managing the OVS in XenServer's dom0 it needs a similar mechanism to  
what we are proposing for Neutron.


For reference, Nova has a XenAPI session similar to the above and will  
invoke plugins that exist in Dom0 directly, to make the required  
modifications.  This is similar in approach to the prototype code above.


The current XenAPI rootwrap for Neutron[1] is stupidly inefficient as it  
was based on the original rootwrap concept (which neutron replaced with  
the daemon mode to improve performance).  As this is a separate  
executable, called once for each command, it will create a new session  
with each call.  There are (as always) multiple ways to fix this:


1) Get Neutron to call XenAPI directly rather than trying to use a  
daemon - the session management would move from  
neutron-rootwrap-xen-dom0 into xen_rootwrap_client.py (perhaps this  
could be better named)


I personally like that option.


I am puzzled. Is Neutron the only component that need to call to dom0? I  
would think that Neutron is not in business of handling hypervisor  
privilege isolation mechanics, and that some other components will handle  
that for Neutron (and other services that may need it), that’s why I  
suggested to consider oslo.* realm for the proposed code.


Side note: if we are going to make drastic changes to existing Xen-wrap  
script, we should first have Xen third-party CI testing running against it,  
not to introduce regressions. AFAIK it’s not happening right now.


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] [manila] Access key via the UI?

[Ravi, Goutham]

Hey Arne,

It’s already being returned in the manila access-list API as of 2.21, if you’re 
using the latest python-manilaclient, you should have it there. However, it’s 
missing in the UI:

https://github.com/openstack/manila-ui/blob/c986a100eecf46af4b597cdcf59b5bc1edc2d1b0/manila_ui/dashboards/project/shares/shares/tables.py#L278

Could you open a bug?

Thanks,
Goutham

On 11/3/16, 7:32 AM, "Arne Wiebalck"  wrote:

Hi,

As cephx has been added as an access type in the dashboard and an access 
key can now
be part of the API's response to access list requests, is it planned to 
have the access key to
be returned when adding a cephx access rule via the UI (for instance 
similar to what ‘Create
Key Pair’ in the instance panel does)? Couldn’t find any mention of such an 
activity.

Thanks!
 Arne

--
Arne Wiebalck
CERN IT

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


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

Re: [openstack-dev] [networking-ovn] restart failure to bring up ovn services

[Russell Bryant]

On Wed, Nov 2, 2016 at 6:48 PM, Murali R  wrote:

> Following the docs online (Newton), the installation was successful.
> However when the VM that has the controller (and ovn-nb) restarted, it
> fails to bring up ovs & ovn. This is ubuntu deployment using
> python-networking-ovn and locally built ovn. Is this a deployment problem?
> Is it possible to recover from here without losing the neutron DB sync? I
> have not configured any networks that I need to save.
>
> NOTE: I did a reboot once before and the services came back fine at that
> time. Not sure if there is a sequence to be followed while shutting down -
> if so can I know what it would be?
>
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn [-] OVS database connection
> to OVN_Northbound failed with error: 'Could not retrieve schema from tcp:
> 192.168.56.102:6641: Connection refused'. Verify that the OVS and OVN
> services are available and that the 'ovn_nb_connection' and
> 'ovn_sb_connection' configuration options are correct.
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn Traceback (most recent call
> last):
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn   File
> "/usr/lib/python2.7/dist-packages/networking_ovn/ovsdb/impl_idl_ovn.py",
> line 84, in __init__
> 
> 
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn 'err': os.strerror(err)})
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn Exception: Could not
> retrieve schema from tcp:192.168.56.102:6641: Connection refused
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn
>

​As you noted, it looks like the OVN services were not started.  If you
installed from source, you should run:

$ sudo /usr/share/openvswitch/scripts/ovn-ctl start_northd

The OVN packages install systemd units, so you can also start it that way
and set it up to re-start after a reboot.

$ sudo systemctl enable ovn-northd
$ sudo systemctl start ovn-northd

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Mauricio Lima]

I Agree. +1

2016-11-03 10:21 GMT-03:00 Paul Bourke :

> Kolleagues,
>
> How do people feel above removing the requirement of having TrivialFix in
> commit messages where a bug/bp is not required?
>
> I'm seeing a lot of valid and important commits being held up because of
> this, in my opinion, unnecessary requirement. It also causes friction for
> new contributers to the project.
>
> Are there any major benefits we're getting from the use of this tag that
> I'm missing?
>
> Cheers,
> -Paul
>
> __
> OpenStack Development Mailing 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] [kolla] Propose removal of TrivialFix requirement

[Paul Bourke]

Kolleagues,

How do people feel above removing the requirement of having TrivialFix 
in commit messages where a bug/bp is not required?


I'm seeing a lot of valid and important commits being held up because of 
this, in my opinion, unnecessary requirement. It also causes friction 
for new contributers to the project.


Are there any major benefits we're getting from the use of this tag that 
I'm missing?


Cheers,
-Paul

__
OpenStack Development Mailing 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] [ironic][tempest][openwhisk] Notes from the Barcelona summit

[Miles Gould]

Capsule rec.juggling-style review
-

**High:** Impossible to pick out one moment in particular, but in
general it was getting to chat informally over dinner/drinks/climbing
with other Stackers.  Thanks everyone for making me feel welcome!
**Low:** Spending four hours unable to get the keys for our AirBnB on
Monday, after barely sleeping the night before.
**Goal:** Meet people on the Ironic team, and put faces to IRC nicks.
This was a success, and it was great to meet everyone IRL.
**Bane:** The way most of the coffee stations ran out within minutes.
Was the intention that only the coffee in the marketplace and the
developer lounge would be replenished throughout the day? If so, this
wasn't communicated to me.

Tuesday
===

Speed-mentoring
---
This was definitely worth getting up early for, and I am Not A Morning
Person. One concern: there were separate "technical" and "career"
tracks. A slight problem for those who are interested in both; but
also I noticed the "technical" track was heavily male-dominated and
the "career" track was heavily female-dominated. Not sure what that
says about us as an industry, but I doubt it's anything good.

Keynotes

These were fun. I was particularly impressed by Rosie Bolton's use of
"zettabyte": I'm pretty sure that's the first time I've heard that
term used in anger.

Coffee break

No coffee!

Design Summit 101
-
https://etherpad.openstack.org/p/ocata-design-summit-101
This was my first summit, so this session was really useful. Told me
what to expect and how to contribute effectively (which I hope I
managed to some extent).

Networking Approaches in a container world
--
(Antoni Segura Puimedon, Flavio Castelli, Neil Jerram)
https://www.youtube.com/watch?v=ePEXxbQ1fes
Gave a decent overview of the problem (providing logical networks
connecting ephemeral containers on different hosts), the two major
solutions (either tunnelling, or creating subnets for the containers
running on each host and using IP routing), the tradeoffs involved,
and which tools take which approach.

Baremetal Deployment work session
-
https://etherpad.openstack.org/p/BCN-ops-baremetal-deploy
I wasn't able to contribute anything, but it was interesting and
useful to hear what approaches people are using.

Climbing

https://etherpad.openstack.org/p/ocata-climb
The perfect conclusion to a tiring conference day! Huge thanks to
Chris Dent for organising this.

Wednesday
=

Serverless: How to Build an Event-Driven, Polyglot Serverless 
Microservices Framework on OpenStack (Animesh Singh)

--
https://www.youtube.com/watch?v=7yA38yiUxig
This was honestly pretty horrifying. 15vCPUs, 26GB RAM, and 192 GB
disk footprint per invocation/s, so you can run snippets of
JavaScript? See the video at 7:08 for where I get these figures - I'd
love to be told I've misunderstood.

Empowering Ironic with Redfish support (Bruno Cornec)
-
https://www.youtube.com/watch?v=KxRo5cRpj6k
Adding support to Ironic for talking to Redfish, a young but exciting
JSON/REST-based protocol for managing baremetal servers. Unfortunately
some crucial features are missing from the 1.0 release of the spec, so
we're already seeing incompatible vendor extensions: I asked a few
questions at the end about how we could avoid the nightmare scenario
described in http://esr.ibiblio.org/?p=801.

Ironic API Evolution work session
-
https://etherpad.openstack.org/p/ironic-ocata-summit-api-evolution
Fixing our API to make it more consistent, useful and
standards-compliant.  Devananda had already done a great job of
structuring this discussion, so it all went very smoothly, and it's
great to see patches already appearing.

Thursday


Ironic Work Session: Task framework
---
https://etherpad.openstack.org/p/ironic-ocata-summit-task-framework
I think we mostly managed to resist the temptation to spec out
something all-singing and all-dancing here.

Ironic Work Session: QA/CI
--
https://etherpad.openstack.org/p/ironic-ocata-summit-qa
I appear to have volunteered to help on splitting out our API tests
from our functional tests and to create a PoC for using property-based
unit tests, possibly using Hypothesis.

Tempest plugins roadmap
---
https://etherpad.openstack.org/p/ocata-qa-tempest-plugin-repos
Turns out the core purpose of Tempest is not what I'd thought. I'd
thought of it as a tool for end-to-end testing, for use in CI; the
project cores think of it as a standalone tool that can be used to
smoke-test an existing OpenStack cloud. Install OpenStack on your
data-center, via any means; install Tempest on your laptop; run the
one against the other. The "Tempest as 

[openstack-dev] [Keystone] Token Verify Role Check

[Adam Young]

There has been a lot of talk about Policy this past summit and release.  
Based on feedback, we've come up with the following spec to address it.



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


The idea is that we are going to split the role check off from the 
existing policy checks. The role check will happen at token validation 
time.  The existing policy checks will still be executed in the body of 
the code bases where they are now, as they confirm additional attributes 
about the operations and resources.



It is the amalgamation of work by many people, and I've attempted to 
list them all at the bottom.



Comments highly appreciated, either in the review or in this thread.


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

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

[gordon chung]

On 02/11/16 08:10 PM, Adrian Turjak wrote:
>
> On 03/11/16 03:01, gordon chung wrote:
>> gnocchi captures the state of a resource and it's history. this is
>> accessible by looking at resource history. i'm not entirely sure if that
>> handles your case, may you could provide the queries you use and we
>> could figure out equivalent gnocchi queries. i built a ceilometer vs
>> gnocchi usage deck[1] that may help but it's more focused on metrics
>> rather than resource history.
>>
>> [1] http://www.slideshare.net/GordonChung/ceilometer-to-gnocchi
>>
>> cheers,
>
> I'd need to double check exactly what query it is, but it effectively
> amounts to:
> "List all instance metric samples where project_id is  and timestamp
> is in time range -"
>
> The time range is an hour + leadin from last hour to catch the last
> sample from the previous window.
>
> We then group by resource id, and for each instance check the metadata.
> If a sample exists, then the instance exists, and depending on what
> states the metadata shows it was in we know for how much of that hour we
> will be billing. Basically, we don't care about the actual volume/data
> of the metric, just the sample metadata from the resource at that point
> in time.
>
> The above is what our billing aggregation service does ever hour against
> ceilometer. So we're not using ceilometer directly for billing, just are
> a source for the data we wish to aggregate and transform into something
> we can bill.
>
> It looks like we can still achieve the same thing in gnocchi with any
> instance metric that has resource metadata (cpu_util) since gnocchi
> stores the changes in the metadata over time. Can we though bypass the
> metric and look at changes in resource metadata directly?
>

yeah, as jd mentioned, it seems like Gnocchi covers your use case and 
makes it a bit easier. yes, you can look at resource data and history 
without considering metrics (that's actually how it's designed, resource 
and metric data separate). you can search for resources or get it's 
history[1]. there's an equivalent client call if needed.


[1] http://gnocchi.xyz/rest.html#searching-for-resources


cheers,
-- 
gord

__
OpenStack Development Mailing 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] proposal to resolve a rootwrap problem for XenServer

[Thierry Carrez]

Bob Ball wrote:
>>> Oslo.privsep seem try to launch a daemon process and set caps for this
>> daemon; but for XenAPI, there is no need to spawn the daemon.
>>
>> I guess I'm lacking some context... If you don't need special rights, why 
>> use a
>> rootwrap-like thing at all ? Why go through a separate process to call into
>> XenAPI ? Why not call in directly from Neutron code ?
> 
> It does not need to go through a separate process at all, or need special 
> rights - see the prototype code at https://review.openstack.org/#/c/390931/ 
> which started this thread, which is directly calling from Neutron code.
> 
> I guess the argument is that we are trying to run "configure something" which 
> in some cases is privileged in the same host as is running the Neutron code 
> itself, hence the easiest way to do that is to use a rootwrap.  To me, the 
> very use of a "rootwrap" or "privsep" implies that we're running the commands 
> in the same host.

OK, I think I get it now: Neutron is using its rootwrap call interface
as an indirection layer to route configuration commands either to
execute as root locally (through classic rootwrap) or to execute on dom0
through a XenAPI connection (through rootwrap-xen-dom0). The latter
should really have been called xendom0wrap :)

> Arguably we should have a "per logical component" wrapper - in this case the 
> network / OVS instance that's being managed - as each component could be in a 
> different location.
> Mounting a loopback device (which Nova has needed to do in the past) clearly 
> needs a rootwrap that runs in the same host as Nova, but when managing the 
> OVS in XenServer's dom0 it needs a similar mechanism to what we are proposing 
> for Neutron.
> 
> For reference, Nova has a XenAPI session similar to the above and will invoke 
> plugins that exist in Dom0 directly, to make the required modifications.  
> This is similar in approach to the prototype code above.
> 
> The current XenAPI rootwrap for Neutron[1] is stupidly inefficient as it was 
> based on the original rootwrap concept (which neutron replaced with the 
> daemon mode to improve performance).  As this is a separate executable, 
> called once for each command, it will create a new session with each call.  
> There are (as always) multiple ways to fix this:
> 
> 1) Get Neutron to call XenAPI directly rather than trying to use a daemon - 
> the session management would move from neutron-rootwrap-xen-dom0 into 
> xen_rootwrap_client.py (perhaps this could be better named) 

I personally like that option.

> 2) Get Neutron to call a local rootwrap daemon (as per the current 
> implementation) which maintains a pool of connections and can efficiently 
> call through to XenAPI

That is an option, yes. Basically rootwrap-xen-dom0 was created after
rootwrap, so it's doable to evolve it into a rootwrap-xen-dom0-daemon,
created after rootwrap-daemon. It is slightly more costly/complex than
running in-process, but would make it more reusable I guess.

> 3) Extend oslo.rootwrap (and I presume also privsep) to know that some 
> commands can run in different places, and put the logic for connecting to 
> those different places in there.

We don't really evolve rootwrap itself anymore, to focus on privsep. I
guess privsep could in the future grow beyond pure privilege separation
toward a more generic interface for executing code over security
boundaries... But that sounds pretty far away (time for neutron to adopt
privsep, time for privsep to grows desired features). So other options
are a more immediate fix to an immediate performance issue.

> We did have a prototype implementation of #2 but it was messy, and #1 seemed 
> architecturally cleaner.

All 3 options are valid. I have a slight preference for #1 over #2 over
#3. Also code for #1 is already up.

Thanks for taking the time to explain it to me :)

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing 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] possible backports for stable/newton

[Brent Eagles]

Hi Michele, vous autres,

On Thu, Nov 3, 2016 at 4:50 AM, Michele Baldessari 
wrote:

> Hi Brent ;)
>
> On Thu, Nov 03, 2016 at 01:20:12AM -0230, Brent Eagles wrote:
> > puppet-tripleo
> >
> > https://review.openstack.org/#/c/389583/ Set redis file descriptor limit
> > when run via pacemaker
>
> Yes, this one I will backport this week.
>
> > https://review.openstack.org/#/c/380414/ Only run ceilometer::db::sync
> on
> > bootstrap node
> > https://review.openstack.org/#/c/386042/ pacemaker/mysql: wait step 2 to
> > remove default accounts
> >
> > tripleo-heat-templates
> >
> > https://review.openstack.org/#/c/380979/ Change rabbitmq queues HA mode
> > from ha-all to ha-exactly
>
> We decided against it in the end. We merged it for Ocata and will
> implement it only there (i.e. we thought it was a bit too risky this
> close to the release)
>
> > https://review.openstack.org/#/c/381869/ Include redis/mongo hiera when
> > using pacemaker
> > https://review.openstack.org/#/c/387266/ Enable proxy headers parsing
> for
> > Neutron (not sure about this one... there are similar patches that landed
> > to stable/newton so maybe)
> > https://review.openstack.org/#/c/385058/ Remove duplicate metadata keys
> > from nova-api.yaml (probably not critical - the big related bug was the
> > worker count = 0 thing for nova)
>
> regards,
> Michele
>

​Thanks Michele! With respect to the other patches, I'll set the backports
up and make sure the original authors are added as reviewers. If you feel
they shouldn't be backported, just nix them on gerrit.

Cheers,

Brent​
__
OpenStack Development Mailing 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] [vitrage] FW: Your draft logo & sneak peek

[Afek, Ifat (Nokia - IL)]

Hi,

Please find below the draft for the Vitrage Giraffe.
If you would like to provide feedback on the design, you can use: 
http://tinyurl.com/OSmascot
Note that the original idea was to have a colourful Giraffe, with a skin that 
looks like a Vitrage.

Here's a 50-second "sneak peek" at how they came together: 
https://youtu.be/JmMTCWyY8Y4

Ifat.


[cid:E6D0B55F-1676-4FC2-8275-CBBC19802BEE]

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

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

[Julien Danjou]

On Thu, Nov 03 2016, Maxime Belanger wrote:

Hi Maxime,

> We had this project of our own for a couple years and it was not meant to
> replace Ceilometer at all. For our billing use case, yes it did replace
> Ceilometer because scaling issues. We just wanted to propose it to the
> community as a matter of sharing knowledge.

Yeah, and that's cool. :)

> So currently I'm not sure there is a project that does the same thing in
> Telemetry unless I'm mistaken. Yes there was Ceilometer, but for reason of api
> performance issue when hitting a huge DB with a lot of historic data. It was
> not scalling at all. Right now, not sure where Ceilometer is going in terms of
> dev and there is Aodh, but from what I read, it's for alerting purposes.

Today, Ceilometer is in charge of the polling + notification listening,
and feeds that into the system you want, in our case, Gnocchi.

It seems you have only one project for all of that, where we have built
2 projects that can be reused in different context, but coupled do the
same thing (and probably more) than what Almanach does.

I swiftly encourage you to take a look at what Ceilometer+Gnocchi can
do, as it may be a good surprise for you. And if it does not cover your
use case(s), it'd be very interesting to us to know where it fails.

Cheers,
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

[Julien Danjou]

On Thu, Nov 03 2016, Adrian Turjak wrote:

> I'd need to double check exactly what query it is, but it effectively
> amounts to:
> "List all instance metric samples where project_id is  and timestamp
> is in time range -"
>
> The time range is an hour + leadin from last hour to catch the last
> sample from the previous window.

You can do exactly the same thing in Gnocchi by listing resources alive
during the timeframe you are interested in.

The main gain by switching to Gnocchi is that you don't have to "sync
every hour from Ceilometer". You can just use it as a backend to
generate your billing directly.

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


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

Re: [openstack-dev] [all][release] Release announcements

[ChangBo Guo]

2016-11-03 1:28 GMT+08:00 Davanum Srinivas :

> On Wed, Nov 2, 2016 at 1:21 PM, Doug Hellmann 
> wrote:
> > Excerpts from Thierry Carrez's message of 2016-11-02 17:33:51 +0100:
> >> Hi everyone,
> >>
> >> In Barcelona the release team has been discussing how to improve release
> >> announcements. Posting them on openstack-dev (for libs) and
> >> openstack-announce (for main services) has proven to be pretty noisy,
> >> especially for projects which publish lots of components, like OpenStack
> >> Puppet or OpenStack Ansible. This actively discouraged people to follow
> >> openstack-announce, which was really not the goal.
> >>
> >> At the same time, we can't just stop making announcements. Some people
> >> (especially on the downstream side) still want to receive release
> >> announces. And we still want to archive a trace of the release and
> >> provide a starting point for discussing immediate issues on a given
> >> release, especially for libraries.
> >>
> >> The proposed solution is to create a specific mailing-list for OpenStack
> >> release announcements (proposed name is "release-announces") where we'd
> >
> > How about either "release-announce" or "release-announcements"?
>
> slightly prefer "release-announce" over "release-announcements" to be
> in line with openstack-announce
>
+1 for "release-announce",  and thanks release management team for making
release work better :-)

>
> Thanks,
> Dims
>
> >
> >> post the automated release announcements. Only the release bot and
> >> release managers would be able to post to it. The "reply-to" field would
> >> be set to openstack-dev, in case someone wanted to start a thread about
> >> a given release. By default, it would be set to send in daily digest
> >> mode, to reduce noise and encourage people to subscribe to it.
> >>
> >> The -announce list would get back to low-noise, and be limited to
> >> highly-important announcements (one email for the final release, emails
> >> about events, elections...).
> >>
> >> Please let us know if you have comments or questions. We'll start
> >> implementing this plan next week if no objection is raised.
> >>
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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] [UI] Adding a new job to the gate

[Emilien Macchi]

On Thu, Nov 3, 2016 at 6:24 AM, Julie Pichon  wrote:
> Hi,
>
> At the end of Newton we had a few issues where the packaged UI in DLRN
> didn't work at all. To try and avoid similar problems happening again,
> I've been working on a simple sanity check to be run on CI at [1]. All
> the necessary patches are up, this is just a heads-up for folks working
> in the tripleo-ui repository that a new job will be added to the
> tripleo-ui gate once [2] merges. This job (the undercloud job) usually
> takes about 30mn to complete so it will take slightly longer before
> patches merge.
>
> In the same patch I also proposed to run the undercloud job in
> puppet-tripleo, as changes there can affect the UI configuration.
>
> Let me know if there is any questions or concerns.

+1, looks excellent to me.
Thanks!

> Thanks,
>
> Julie
>
> [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-basic-ci-check
> [2] https://review.openstack.org/#/c/392215/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[Maxime Belanger]

Hi Emilien,


We had this project of our own for a couple years and it was not meant to 
replace Ceilometer at all. For our billing use case, yes it did replace 
Ceilometer because scaling issues. We just wanted to propose it to the 
community as a matter of sharing knowledge.


This system just collects events that we/you care about and store them as a 
stream so you could reuse them later (in our case billing). And by the way 
Almanach doesn't do billing at all. You could even plug it to Cloud Kitty as a 
data source if you want.

So currently I'm not sure there is a project that does the same thing in 
Telemetry unless I'm mistaken. Yes there was Ceilometer, but for reason of api 
performance issue when hitting a huge DB with a lot of historic data. It was 
not scalling at all. Right now, not sure where Ceilometer is going in terms of 
dev and there is Aodh, but from what I read, it's for alerting purposes.


So now you know the "Why we are here now"...


Max




From: Emilien Macchi 
Sent: November 2, 2016 6:02:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and deletion 
metrics in ceilometer !

On Wed, Nov 2, 2016 at 2:33 PM, Maxime Belanger  wrote:
> Hi Raghunath,
>
>
> We are usign Almanach : https://github.com/openstack/almanach. I think your
[https://avatars0.githubusercontent.com/u/324574?v=3=400]

openstack/almanach
github.com
almanach - Record the utilization of OpenStack resources for each tenant



> use case pretty much fits what this project does.
> We implemented this as a replacement of Ceilometer to gather usage on
> instances and volumes. We query it to do our billing calculation.

I am failing to understand why we create projects to replace official
projects that would have the same mission statement or common
technical goals.  We saw it with Monasca and AFIK it didn't work very
well.
Have you engaged collaboration with Telemetry team to work together as
a community and propose your use-case to the roadmap if some feature
was missing?

I'm very interested to know from "Almanach" developers why we're here
now.  I personally like to think OpenStack contributors work as a
community and meet common goals by communicating on the appropriate
channels.
Please correct me if I'm wrong in the case this project is totally
doing something else, my knowledge in Telemetry is limited from my
user perspective.

> It is of course a less complete solution than CloudKitty + Gnocchi but
> suites our needs for now.
>
> Maxime
>
> 
> From: Raghunath D 
> Sent: October 25, 2016 5:32:13 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and deletion
> metrics in ceilometer !
>
> Hi ,
>
> Can some one please suggest how to instance notifications in ceilometer.
>
> With Best Regards
> Raghunath Dudyala
> Tata Consultancy Services Limited
> Mailto: raghunat...@tcs.com
> Website: http://www.tcs.com
TCS: IT Services, Consulting and Business Solutions
www.tcs.com
Tata Consultancy Services’ IT services, consulting and business solutions 
deliver real results to global businesses to help them experience certainty.



> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -Raghunath D/HYD/TCS wrote: -
> To: openstack-dev@lists.openstack.org
> From: Raghunath D/HYD/TCS
> Date: 10/18/2016 08:01PM
> Subject: [openstack-dev] [Ceilometer]: Instance creation and deletion
> metrics in ceilometer !
>
> 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
TCS: IT Services, Consulting and Business Solutions
www.tcs.com
Tata Consultancy Services’ IT services, consulting and business solutions 
deliver real results to global businesses to help them experience certainty.



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

[openstack-dev] [manila] Access key via the UI?

[Arne Wiebalck]

Hi,

As cephx has been added as an access type in the dashboard and an access key 
can now
be part of the API's response to access list requests, is it planned to have 
the access key to
be returned when adding a cephx access rule via the UI (for instance similar to 
what ‘Create
Key Pair’ in the instance panel does)? Couldn’t find any mention of such an 
activity.

Thanks!
 Arne

--
Arne Wiebalck
CERN IT

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

Re: [openstack-dev] [manila] propose adding gouthamr to manila core

[nidhi.hada]

Wow!! Great idea.


From: Thomas Bechtold 
Sent: Thursday, November 3, 2016 11:16:41 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [manila] propose adding gouthamr to manila core

** This mail has been sent from an external source **

Great idea! +1!

Tom
On Wed, Nov 02, 2016 at 08:09:27AM -0400, Tom Barron wrote:
> I hereby propose that we add Goutham Pacha Ravi (gouthamr on IRC) to the
> manila core team.  This is a clear case where he's already been doing
> the review work, excelling both qualitatively and quantitatively, as
> well as being a valuable committer to the project.  Goutham deserves to
> be core and we need the additional bandwidth for the project.  He's
> treated as a de facto core by the community already.  Let's make it
> official!
>
> -- Tom Barron
>
> __
> OpenStack Development Mailing 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
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] next notification subteam meeting

[Balázs Gibizer]

Hi, 

The next notification subteam meeting will be held on 2016.11.08 17:00 UTC [1] 
on #openstack-meeting-4. Also I proposed [2] to change the meeting frequency 
from biweekly to weekly until the feature freeze of Ocata.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20161108T17
[2] https://review.openstack.org/#/c/393223/ 

__
OpenStack Development Mailing 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] [searchlight] Discrepancies between nova server notifications and API response

[Balázs Gibizer]

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: October 31, 2016 14:01
> 
> On 10/28/2016 4:32 PM, McLellan, Steven wrote:
> > Hi,
> >
> > I was unfortunately unable to make the summit but I'm told there were
> > some good discussions around possible integration with searchlight to
> > help some scaling cases with nova cells. One issue we've had with
> > Searchlight is differences between the notifications and API
> > representation of server state, and Travis asked me to file some bug
> > reports against Nova to get a conversation started. I've filed four
> > bugs at https://bugs.launchpad.net/nova/+bugs?field.tag=searchlight
> > (the reason for separating them is that some may not be
> > straightforward/possible) to that end. I am out next week, but it
> > would be great to get some time at one of the nova weekly meetings the
> > following weeks to discuss it further.
> >
> > Thanks, and safe travels for those returning home from the summit,
> >
> > Steve
> >
> >
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> Thanks, I'll start going through these. Some of them might be covered by
> specs that are being worked in Ocata.

I checked all the three bug reports tagged with searchlight and left some
questions in them. We can discuss them on the next notification subteam
meeting [1] if needed.

Cheers,
gibi

[1] https://wiki.openstack.org/wiki/Meetings/NovaNotification#Next_Meeting 

> 
> Also note that others that are for resources which get proxied from nova, like
> security groups in this bug:
> 
> https://bugs.launchpad.net/nova/+bug/1637635
> 
> Won't be fixed because nova is deprecating the APIs to perform CRUD
> operations on proxy resources, like network resources. You'd get that
> information from Neutron.
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [UI] Adding a new job to the gate

[Julie Pichon]

Hi,

At the end of Newton we had a few issues where the packaged UI in DLRN
didn't work at all. To try and avoid similar problems happening again,
I've been working on a simple sanity check to be run on CI at [1]. All
the necessary patches are up, this is just a heads-up for folks working
in the tripleo-ui repository that a new job will be added to the
tripleo-ui gate once [2] merges. This job (the undercloud job) usually
takes about 30mn to complete so it will take slightly longer before
patches merge.

In the same patch I also proposed to run the undercloud job in
puppet-tripleo, as changes there can affect the UI configuration.

Let me know if there is any questions or concerns.

Thanks,

Julie

[1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-basic-ci-check
[2] https://review.openstack.org/#/c/392215/

__
OpenStack Development Mailing 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][ironic] Instance can "migrate" to another node?

[c1]

Hi al,

Now, nova’s ironic driver can allow multiple compute services.

I am not sure that, when a compute node is down. 

The instances running in it, whether can “migrate” to another compute node(use 
ironic driver)?



Thanks

C1dx 

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

Re: [openstack-dev] [kuryr][magnum] Notes from Summit fishbowl session

[Antoni Segura Puimedon]

On Thu, Nov 3, 2016 at 4:29 AM, Vikas Choudhary
 wrote:
>
>
> On Thu, Nov 3, 2016 at 12:33 AM, Antoni Segura Puimedon 
> wrote:
>>
>> Hi magna and kuryrs!
>>
>> Thank you all for joining last week meetings. I am now writing a few
>> emails to have persistent notes of what was talked about and discussed
>> in the Kuryr work sessions. In the Magnum joint session the points
>> were:
>>
>> Kuryr - Magnum joint work session
>> =
>>
>> Authentication
>> ==
>>
>> * Consensus on using Keystone trust tokens.
>> - We should follow closely the Keystone effort into scoping the
>> allowed
>>   actions per token to limit those to the minimal required set of
>> verbs
>>   that the COE and Kuryr need.
>>
>> * It was deemed unnecessary to pursue a proxying approach to access
>>   Neutron. This means VM applications should be able to reach Neutron
>> and
>>   Keystone but the only source of credentials they should have is the
>>   Keystone tokens.
>>
>>
>> Tenancy and network topology
>> 
>>
>> Two approaches should be made available to users:
>>
>> Full Neutron networking
>> ~~~
>>
>> Under this configuration, containers running inside the nova instances
>> would get networking via Neutron vlan-aware-VMs feature. This means
>> the COE
>> driver (either kuryr-libnetwork or kuryr-kubernetes) would request a
>> Neutron subport for the container. In this way, there can be multiple
>> isolated networks running on worker nodes.
>>
>> The concerns about this solution are about the performance when
>> starting
>> big amounts of containers and the latency introduced when starting
>> them due
>> to going all the way to Neutron to request the subport.
>>
>> Minimal Neutron networking
>> ~~
>>
>
> Is this ipvlan/macvlan approach?

Yes. This will use ipvlan/macvlan.

>
>>
>> In order to address the concerns with the 'Full Neutron networking'
>> approach, and as a trade-off between features and minimalism, this way
>> of
>> networking the containers would all be in the same Neutron network as
>> the
>> ports of their VMs.
>>
>> The problem with this solution is that allowing multiple isolated
>> networks
>> like CNM and Kubernetes with policy have is quite complicated.
>>
>>
>> Regards,
>>
>> Toni
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] Nova-MultiJob CI (non-voting) request to comment

[Lenny Verkhovsky]

Hi,
We would like Mellanox[1] MultiNode CI job  to start commenting as 'non voting' 
job on partial nova[2] and tempest[3] code.
This Job runs few migration tests[4] and an example of its run can be seen 
here[5].

[1] https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI
[2] nova/pci
[3] tempest/ scenario
[4] 
http://13.69.151.247/98/348498/6/check-sriov-tempest/Nova-ML2-Sriov-Multinode/46e401e/testr_results.html.gz
[5] https://review.openstack.org/#/c/348498/6


Thanks
Lenny (aka lennyb on irc)





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