Re: [openstack-dev] OpenStack Developer Mailing List Digest July 22-28

Mike, Thanks for the summary 2017-08-02 10:03 GMT+08:00 Mike Perez : > HTML version: https://www.openstack.org/blog/2017/08/openstack- > developer-mailing-list-digest-20170728/ > > Summaries > = > * Nova placement/resource providers update 30 [1] > * TC Report 30 [2] >

Re: [openstack-dev] [tripleo] Facilitating automation testing in TripleO UI

About 10 years ago, we were promised a fully semantic version of HTML. No more nested divs to structure your documents. However, all we got was a few generic, and only marginally useful elements like and . On 2017-08-03 18:59, Ana Krivokapic wrote: > Hi TripleO devs, > > In our effort to make

[openstack-dev] [Elections] Candidacy for Senlin PTL (Queens)

Hi all, I'd like to announce my candidacy as Senlin PTL in Queens cycle. I began to contribute to Senlin project since 2016.05 and joined the team as a core reviewer in Ocata cycle. It is my pleasure to work with the great team to make this project better and better, and we will keep moving and

[openstack-dev] [rpm-packaging] ptl for queens

Hi, I announce my candidacy for the PTL of the Packaging RPM project. I have been a contributor to various OpenStack projects since Havana and I'm one of the initial cores of the packaging RPM project. The project goal is to produce a production-ready set of OpenStack packages for RPM-based

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

Michael Johnson wrote: > I was wondering what is the current status of the python-openstacksdk > project. The Octavia team has posted some patches implementing our new > Octavia v2 API [1] in the SDK, but we have not had any reviews. I have also > asked some questions in #openstack-sdks with no

Re: [openstack-dev] [rpm-packaging] ptl for queens

+1 ! On Fri, Aug 04, 2017 at 10:19:20AM +0200, Thomas Bechtold wrote: Hi, I announce my candidacy for the PTL of the Packaging RPM project. I have been a contributor to various OpenStack projects since Havana and I'm one of the initial cores of the packaging RPM project. The project goal is

[openstack-dev] [Blazar] PTL Candidacy for Queens

Dear everyone, I'd like to announce my candidacy as Blazar PTL for the Queens release cycle. I served as PTL for the Blazar project during Pike cycle. And I would like to continue to do in the next cycle. During the Pike cycle, the Blazar team made tons of progress for resolving feedback

[openstack-dev] [tc] Technical Committee Status update, August 4th

Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Pike goals updates: nova, cinder * New repositories: publiccloud-wg,

Re: [openstack-dev] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

> -Original Message- > From: Tony Breeds [mailto:t...@bakeyournoodle.com] > Sent: Freitag, 4. August 2017 05:10 > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] >

[openstack-dev] [cloudkitty] PTL candidacy for Queens

Hello everyone, I would like to announce my candidacy for PTL of Cloudkitty. During the Pike cycle we have been able continue the openess of our community but also the addition of some interesting improvment and bug fixes. Now with Queen cycle approacing fast, my main focus for cloudkitty will

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

Lance Bragstad wrote on 08/04/2017 02:37:40 PM: > Properly fixing this would result in a 403 -> 204 status code, which > requires an API version bump according to the interoperability > guidelines [5] (note that keystone has not implemented microversions at > this point). At

Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

Raildo, I am interested in this topic. PTG session sounds great! Thanks, Dims On Fri, Aug 4, 2017 at 3:34 PM, Raildo Mascena de Sousa Filho < rmasc...@redhat.com> wrote: > Hi all, > > We had a couple of discussions with the Oslo team related to implement > Pluggable drivers for oslo.config[0]

Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

+1. Please keep me in the loop for when the PTG session is. Thanks, Kevin From: Doug Hellmann [d...@doughellmann.com] Sent: Friday, August 04, 2017 12:46 PM To: openstack-dev Subject: Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On 08/04/2017 03:45 PM, Kristi Nikolla wrote: > Is this the case even if we haven’t made any final release with the change > that introduced this issue? [0] > > It was only included in the Pike milestones and betas so far, and was not > part of the Ocata release. > > Therefore the call which now

Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

Excerpts from Fox, Kevin M's message of 2017-08-04 20:21:19 +: > I would really like to see secrets separated from config. Always have... They > are two separate things. > > If nothing else, a separate config file so it can be permissioned differently. > > This could be combined with k8s

Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

I would really like to see secrets separated from config. Always have... They are two separate things. If nothing else, a separate config file so it can be permissioned differently. This could be combined with k8s secrets/configmaps better too. Or make it much easier to version config in git

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On Fri, 2017-08-04 at 12:26 -0700, Boris Pavlovic wrote: > By the way stevedore is really providing very bad plugin experience > and should not be used definitely.  Perhaps entrypointer[1]? ;) [1] https://pypi.python.org/pypi/entrypointer -- Kevin L. Mitchell signature.asc

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, 2017-08-04 at 16:45 -0400, Kristi Nikolla wrote: > Is this the case even if we haven’t made any final release with the change > that introduced this issue? [0] > > It was only included in the Pike milestones and betas so far, and was not > part of the Ocata release. Maybe not, but please

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On Fri, Aug 4, 2017, at 02:37 PM, Kevin L. Mitchell wrote: > On Fri, 2017-08-04 at 12:26 -0700, Boris Pavlovic wrote: > > By the way stevedore is really providing very bad plugin experience > > and should not be used definitely.  > > Perhaps entrypointer[1]? ;) > > [1]

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

Hi Vinh For the `agent idea`, I think it is very good. However, in OpenStack, that idea may be really hard for us. The reason is the same with what Boris think. Thanks. We did a poc and working to integrate it with OSProfiler without affecting any of the services. I understand this will be

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

Ilya, Continuous tracing is a cool story, but before proceeding it would be good > to estimate the overhead. There will be an additional delay introduced by > OSProfiler library itself and delay caused by events transfer to consumer. > OSProfiler overhead is critical to minimize. E.g. VM creation

[openstack-dev] [keystone] [keystone] [ptl] PTL candidacy for Queens

* Hi all, ** I'd like to formally communicate my desire to continue serving as the keystone PTL for the upcoming Queen’s release. Despite some turbulence throughout the Pike development cycle, keystone has managed to make progress on some long standing issues. Even though the pace of

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On Fri, Aug 4, 2017 at 11:52 AM, Monty Taylor wrote: [...] > * Both shade and python-openstackclient have investigated using openstacksdk > as their REST layer but were unable to because it puts some abstractions in > layers that make it impossible to do some of the advanced

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

Is this the case even if we haven’t made any final release with the change that introduced this issue? [0] It was only included in the Pike milestones and betas so far, and was not part of the Ocata release. Therefore the call which now returns a 403 in master, returned a 2xx in Ocata. So we

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, Aug 4, 2017 at 2:43 PM, Kevin L. Mitchell wrote: > On Fri, 2017-08-04 at 16:45 -0400, Kristi Nikolla wrote: >> Is this the case even if we haven’t made any final release with the change >> that introduced this issue? [0] >> >> It was only included in the Pike milestones

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

rage-quit On Fri, Aug 4, 2017 at 11:52 AM, Monty Taylor wrote: > On 08/04/2017 03:24 AM, Thierry Carrez wrote: > >> Michael Johnson wrote: >> >>> I was wondering what is the current status of the python-openstacksdk >>> project. The Octavia team has posted some patches

[openstack-dev] [security] Security Meeting next week

Hi, It was decided that the Security Project meeting would not be held next week, and will instead reconvene on the 17th of August. Regards, Luke __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [keystone][api] Backwards incompatible changes based on config

Keystone had a bug reported [0] recently (that we are targeting to pike-rc1) that exposes an inconsistency in the API based on configuration. The happy path is as follows: - a deployment is configured to store projects (controlled by the resource backend) and users (controlled by the identity

Re: [openstack-dev] [Cinder] string freeze exception for VMAX driver

Hello Sean, For soft string freezes as a translator's view, trying the way you suggested for server projects would be good assuming that: - The volume of changes (e.g., the number of sentences, ratio of changes) needs to be properly limited - The string change needs to be well notified to

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

Also note that this appears to exist: https://github.com/openstack/python-openstackclient/blob/master/requirements.txt#L10 So even if python-openstacksdk is not a top level project, I would assume that it being a requirement would imply that it is? Or perhaps neither the

Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

Excerpts from Raildo Mascena de Sousa Filho's message of 2017-08-04 19:34:25 +: > Hi all, > > We had a couple of discussions with the Oslo team related to implement > Pluggable drivers for oslo.config[0] and use those feature to implement > support to protect plaintext secret on

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, Aug 04, 2017 at 03:35:38PM -0400, William M Edmonds wrote: > > Lance Bragstad wrote on 08/04/2017 02:37:40 PM: > > Properly fixing this would result in a 403 -> 204 status code, which > > requires an API version bump according to the interoperability > > guidelines

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

Monty, * drop stevedore/plugin support. An OpenStack REST client has no need for > plugins. All services are welcome. *note below* Back to 60s style of development? Just copy paste things? no plugins? no architecture? no libs? That's not going to work for dozens of OpenStack projects. It's

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

Awesome Monty. This is a great proposal. I have no preference on which way these merge, but see huge value in straightening this out. Frankly I think some of the tempest plugin work could benefit from having an official and well maintained SDK as well. So, I am in favor of getting the ball

[openstack-dev] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

Hi all, We had a couple of discussions with the Oslo team related to implement Pluggable drivers for oslo.config[0] and use those feature to implement support to protect plaintext secret on configuration files[1]. In another hand, due the containerized support on OpenStack services, we have a

Re: [openstack-dev] [Cinder] string freeze exception for VMAX driver

On Sat, Aug 05, 2017 at 02:52:57AM +0900, Ian Y. Choi wrote: > Hello Sean, > > For soft string freezes as a translator's view, trying the way you suggested > for server projects would be good assuming that: > - The volume of changes (e.g., the number of sentences, ratio of changes) > needs to be

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

>As far as I understand the idea of continuous tracing is to collect as few as possible metrics to get insights of the request (not all tracepoints). >If you keep only API, RPC and Driver calls it is going to drastically reduce amount of metrics collected. Exactly, this is also one of the goals

Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

Yeah, but you still run into stuff like db contact and driver information being mixed up with secret used for contacting that service. Those should be separate fields I think so they can be split/merged with that mechanism. Thanks, Kevin From: Doug

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, Aug 04, 2017 at 03:44:32PM -0700, Joshua Harlow wrote: > Morgan Fainberg wrote: > >On Fri, Aug 4, 2017 at 3:09 PM, Kevin L. Mitchell wrote: > >>On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote: > Maybe not, but please do recall that there are many deployers

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote: > > Maybe not, but please do recall that there are many deployers out > > there > > that track master, not fixed releases, so we need to take that > > level of > > compatibility into account. > > > > I am going to go out on a limb and say

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On 08/04/2017 04:03 PM, Dean Troyer wrote: On Fri, Aug 4, 2017 at 11:52 AM, Monty Taylor wrote: [...] * Both shade and python-openstackclient have investigated using openstacksdk as their REST layer but were unable to because it puts some abstractions in layers that make

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

Morgan Fainberg wrote: On Fri, Aug 4, 2017 at 3:09 PM, Kevin L. Mitchell wrote: On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote: Maybe not, but please do recall that there are many deployers out there that track master, not fixed releases, so we need to take that

Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

On Fri, Aug 4, 2017 at 3:09 PM, Kevin L. Mitchell wrote: > On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote: >> > Maybe not, but please do recall that there are many deployers out >> > there >> > that track master, not fixed releases, so we need to take that >> > level of

Re: [openstack-dev] [elections][security] Candidacy for Security Project PTL (Queens)

+1 Luke has been an excellent contributor to the Security project and would be an excellent PTL to take the project forward. On Tue, Aug 1, 2017 at 8:30 AM, Luke Hinds wrote: > Hello All, > > I would like to announce my candidacy for Security Project PTL for > Queens. > >

Re: [openstack-dev] [oslo][performance] Proposing tail-based sampling in OSProfiler

Hi, Continuous tracing is a cool story, but before proceeding it would be good to estimate the overhead. There will be an additional delay introduced by OSProfiler library itself and delay caused by events transfer to consumer. OSProfiler overhead is critical to minimize. E.g. VM creation

Re: [openstack-dev] VMWare Type Snapshot for Openstack 4.3

Matt That is correct. This is for the IBM ICMO product. Here is the only reference I see in the IBM documentation regarding this. https://www.ibm.com/support/knowledgecenter/SST55W_4.3.0/liaca/liaca_cfg_snapshot.html Is there an Openstack document that shows how to extend openstack to do

[openstack-dev] [cinder][stable] Reverting the deprecation notice: Cinder Driver for NetApp E-Series

Developers and Operators, NetApp had prior provided notification [1] in accordance with community policy [2] of an intention to deprecate the iSCSI and FC Cinder drivers for NetApp E/EF-Series systems [3]. The community notification issued had the effect of introducing us to and engendering

[openstack-dev] [docs][ptl] Candidacy for Docs

Hi all, I'd like to announce my candidacy for PTL of the docs project for Queens. I've been active in various open source documentation and translation projects since 2007 and started contributing to OpenStack docs during the Mitaka cycle, both upstream and in the RDO Project. The docs project

[openstack-dev] [tripleo] CI Squad Meeting Summary (week 31)

If the topics below interest you and you want to contribute to the discussion, feel free to join the next meeting: Time: Thursdays, 14:30-15:30 UTC Place: https://bluejeans.com/4113567798/ Full minutes: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting There are a lot of people on

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On 08/04/2017 03:24 AM, Thierry Carrez wrote: Michael Johnson wrote: I was wondering what is the current status of the python-openstacksdk project. The Octavia team has posted some patches implementing our new Octavia v2 API [1] in the SDK, but we have not had any reviews. I have also asked

[openstack-dev] [magnum] PTL Candidacy for Queens

Hello! I would like to nominate myself as PTL for the Magnum project for the Queens cycle. I have been consistently contributing to Magnum since February 2016 and I am a core reviewer since August 2016. Since then, I have contributed to significant features like cluster drivers, add Magnum tests

Re: [openstack-dev] VMWare Type Snapshot for Openstack 4.3

On 8/4/2017 8:41 AM, Tom Kennedy wrote: Is there an Openstack document that shows how to extend openstack to do something like this? The create snapshot API is this in upstream Nova: https://developer.openstack.org/api-ref/compute/#create-image-createimage-action There is no distinction

Re: [openstack-dev] [Cinder] string freeze exception for VMAX driver

Hello Helen, Thanks a lot for sharing a string freeze exception request to openstack-dev mailing list. With @amotoki's comment [1] and the discussion on the last IRC meeting yesterday [2], I18n team is fine and there will be no problem to accept the requests from I18n team's perspective.

Re: [openstack-dev] [Cinder] string freeze exception for VMAX driver

> > I think the importance of string freeze for server projects (e.g., cinder, > nova, keystone, neutron) might > be less important than previous cycle(s), but sharing the status to all the > teams including release management team > is a good idea to stay on the same page as much as possible :)