Re: [openstack-dev] [cinder][puppet][kolla][helm][ansible] Change in Cinder backup driver naming

Thanks Sean! I did a quick sanity check on the backup part in the puppet-cinder module and there is no opinionated default value there which needs to be changed. Best regards On 09/27/2018 08:37 PM, Sean McGinnis wrote: This probably applies to all deployment tools, so hopefully this

Re: [openstack-dev] [placement] The "intended purpose" of traits

On Fri, 28 Sep 2018, melanie witt wrote: I'm concerned about a lot of repetition here and maintenance headache for operators. That's where the thoughts about whether we should provide something like a key-value construct to API callers where they can instead say: * OWNER=CINDER * RAID=10 *

Re: [openstack-dev] [all] Zuul job backlog

On 9/28/2018 3:12 PM, Clark Boylan wrote: I was asked to write a followup to this as the long Zuul queues have persisted through this week. Largely because the situation from last week hasn't changed much. We were down the upgraded cloud region while we worked around a network configuration

[openstack-dev] Airship linux distro support

Hello, I submitted a spec to enable multiple Linux distro capability in Airship and bring in OpenSUSE support in addition to Ubuntu. The spec is at https://review.openstack.org/#/c/601187 and has received positive feedback from the Airship core team on the direction. We wanted to make the

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

Alright - I've worked up the majority of what we have in this thread and proposed a documentation patch for oslo.policy [0]. I think we're at the point where we can finish the rest of this discussion in gerrit if folks are ok with that. [0] https://review.openstack.org/#/c/606214/ On Fri, Sep

[openstack-dev] [goals][upgrade-checkers] Week R-28 Update

There isn't really anything to report this week. There are no new changes up for review that I'm aware of. If your team has posted changes for your project, please update the related task in the story [1]. I'm also waiting for some feedback from glance-minded people about [2]. [1]

Re: [openstack-dev] [placement] The "intended purpose" of traits

On Fri, 28 Sep 2018 15:42:23 -0500, Eric Fried wrote: On 09/28/2018 09:41 AM, Balázs Gibizer wrote: On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried wrote: It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement.

[openstack-dev] [oslo] PTG wrapup

A bit belated, but here goes: Monday: Had a good discussion in the Keystone room about oslo.limit with some Nova developers. There was quite a bit of discussion around how the callbacks should work for resource usage and cleanup, and the Nova developers took an action to do some prototyping.

[openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Update on the previously announced deprecation of neutron-lbaas and neutron-lbaas-dashboard

During the Queens release cycle we announced the deprecation of neutron-lbaas and neutron-lbaas-dashboard[1]. Today we are announcing the expected end date for the neutron-lbaas and neutron-lbaas-dashboard deprecation cycles. During September 2019 or the start of the “U” OpenStack release cycle,

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 09/28/2018 04:42 PM, Eric Fried wrote: On 09/28/2018 09:41 AM, Balázs Gibizer wrote: On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried wrote: It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time

Re: [openstack-dev] [placement] The "intended purpose" of traits

On Fri, Sep 28, 2018 at 7:17 PM Chris Dent wrote: > > On Fri, 28 Sep 2018, melanie witt wrote: > > > I'm concerned about a lot of repetition here and maintenance headache for > > operators. That's where the thoughts about whether we should provide > > something like a key-value construct to API

Re: [openstack-dev] [horizon][plugins] npm jobs fail due to new XStatic-jQuery release (was: Horizon gates are broken)

Hi Ivan, Thank you for your help to our plugins and sorry for bothering you. I found problem on installing horizon in "post-install", e.g. we should install horizon with upper-constraints.txt in "post-install". I proposed patch[1] in zun-ui, please check it. If we can merge this, I will expand it

Re: [openstack-dev] [ironic][edge] Notes from the PTG

Hi Jim, Thanks for sharing your notes. One note about the jumping automomus control plane requirement. This requirement was already identified during the Dublin PTG workshop [1]. This is needed for two reasons

Re: [openstack-dev] [oslo][castellan] Time for a 1.0 release?

Ade Lee wrote: On Tue, 2018-09-25 at 16:30 -0500, Ben Nemec wrote: Doug pointed out on a recent Oslo release review that castellan is still not officially 1.0. Given the age of the project and the fact that we're asking people to deploy a Castellan-compatible keystore as one of the base

[openstack-dev] [rally] How is the docker image of rally-openstack managed?

Hi guys, Last week I posted a commit at rally-openstack to work with mysql and postgres in rally docker image.(c8272e8591f812ced9c2f7ebdad6abca5c160dbf) mysql and postgres. At the docker hub, the latest tag is pushed 3 months ago and is no longer being updated. I would like to use the official

Re: [openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On Fri, Sep 28, 2018 at 12:50 AM melanie witt wrote: > On Thu, 27 Sep 2018 17:23:26 -0500, Matt Riedemann wrote: > > On 9/27/2018 3:02 PM, Jay Pipes wrote: > >> A great example of this would be the proposed "deploy template" from > >> [2]. This is nothing more than abusing the placement traits

Re: [openstack-dev] [placement] Tetsuro Nakamura now core

Hi all, Thank you for putting your trust in me. It's my pleasure to work with you and to support the community. Thanks! On 2018/09/27 18:47, Chris Dent wrote: Since there were no objections and a week has passed, I've made Tetsuro a member of placement-core. Thanks for your willingness and

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

Hello Julia, we will begin formulating an individual spec for each project accordingly. Regarding your question: as you already assumed correctly, the code necessary to handle image decryption is driver specific in our current design as it is very close to the point where the ephemeral storage

Re: [openstack-dev] [release] Release model for feature-complete OpenStack libraries

writes: > How will we handle which versions of libraries work together? > And which combinations will be run thru CI? Dependency management will work the same way it does today. Each component (server or library) lists the versions of the dependencies it is compatible with. That information

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

Adding the operator list back in. On Fri, Sep 28, 2018 at 8:48 AM Lance Bragstad wrote: > Bumping this thread again and proposing two conventions based on the > discussion here. I propose we decide on one of the two following > conventions: > > *::* > > or > > *:_* > > Where is the

Re: [openstack-dev] [qa] [infra] [placement] tempest plugins virtualenv

On Fri, Sep 28, 2018 at 02:39:24PM +0100, Chris Dent wrote: > > I'm still trying to figure out how to properly create a "modern" (as > in zuul v3 oriented) integration test for placement using gabbi and > tempest. That work is happening at https://review.openstack.org/#/c/601614/ > > There was

Re: [openstack-dev] [release] Release model for feature-complete OpenStack libraries

How will we handle which versions of libraries work together? And which combinations will be run thru CI? -Original Message- From: Thierry Carrez Sent: Friday, September 28, 2018 7:17 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [release] Release model for

[openstack-dev] [placement] The "intended purpose" of traits

It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time we have to have the argument about whether that use case satisfies the original "intended purpose" of traits. That's only reason I've ever been

[openstack-dev] OpenStack Summit Forum Submission Process Extended

Hello Everyone We are extended the Forum Submission process through September 30, 11:59pm Pacific (6:59am GMT). We've already gotten a ton of great submissions, but we want to leave the door open through the weekend in case we have any stragglers. Please submit your topics here:

[openstack-dev] [qa] [infra] [placement] tempest plugins virtualenv

I'm still trying to figure out how to properly create a "modern" (as in zuul v3 oriented) integration test for placement using gabbi and tempest. That work is happening at https://review.openstack.org/#/c/601614/ There was lots of progress made after the last message on this topic

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

Bumping this thread again and proposing two conventions based on the discussion here. I propose we decide on one of the two following conventions: *::* or *:_* Where is the corresponding service type of the project [0], and is either create, get, list, update, or delete. I think decoupling

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

On Fri, Sep 28, 2018 at 5:00 AM Jeremy Stanley wrote: > > If memory serves, the biggest challenge around that solution was > determining who approves such proposals since they still need > per-project specs for the project-specific details anyway. Perhaps > someone who has recently worked on a

Re: [openstack-dev] [python3-first] support in stable branches

Hello, I'm specifically referring to branches mentioned in: https://github.com/openstack/goal-tools/blob/4125c31e74776a7dc6a15d2276ab51ff3e73cd16/goal_tools/python3_first/jobs.py#L54 I hope this helps. Best, Dariusz Krol On 09/27/2018 06:04 PM, Ben Nemec wrote: > > > On 9/27/18 10:36

Re: [openstack-dev] [placement] The "intended purpose" of traits

Eric, Very well said, I completely agree with you. We should not hold ourselves back based upon perceptions of original intended purpose. Things do change. We have to accept that. We must normalize this fact in our actions moving forward. That being said, I'm not entirely sure I'm personally

Re: [openstack-dev] [goal][python3] week 7 update

Jeremy Stanley writes: > On 2018-09-28 13:58:52 -0400 (-0400), William M Edmonds wrote: >> Doug Hellmann wrote on 09/26/2018 06:29:11 PM: >> >> > * We do not want to set the override once in testenv, because that >> > breaks the more specific versions used in default environments like >> >

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

On Fri, Sep 28, 2018 at 2:54 PM Lance Bragstad wrote: > > > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote: >> >> On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg >> wrote: >> > >> > Ideally I would like to see it in the form of least specific to most >> > specific. But more importantly in

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

On Fri, Sep 28, 2018 at 01:54:01PM -0500, Lance Bragstad wrote: > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote: > > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg > > wrote: > > > > > > Ideally I would like to see it in the form of least specific to most > > specific. But more

Re: [openstack-dev] [goal][python3] week 7 update

On 2018-09-28 13:58:52 -0400 (-0400), William M Edmonds wrote: > Doug Hellmann wrote on 09/26/2018 06:29:11 PM: > > > * We do not want to set the override once in testenv, because that > > breaks the more specific versions used in default environments like > > py35 and py36 (at least under

Re: [openstack-dev] [all] Zuul job backlog

On Wed, Sep 19, 2018, at 12:11 PM, Clark Boylan wrote: > Hello everyone, > > You may have noticed there is a large Zuul job backlog and changes are > not getting CI reports as quickly as you might expect. There are several > factors interacting with each other to make this the case. The short

Re: [openstack-dev] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs

Doug Hellmann writes: > I think we are ready to go ahead and switch all of the python packaging > jobs to the new set defined in the publish-to-pypi-python3 template > [1]. We still have some cleanup patches for projects that have not > completed their zuul migration, but there are only a few

Re: [openstack-dev] [goal][python3] week 7 update

On 9/28/18 1:38 PM, Jeremy Stanley wrote: On 2018-09-28 13:58:52 -0400 (-0400), William M Edmonds wrote: Doug Hellmann wrote on 09/26/2018 06:29:11 PM: * We do not want to set the override once in testenv, because that breaks the more specific versions used in default environments like

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote: > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg > wrote: > > > > Ideally I would like to see it in the form of least specific to most > specific. But more importantly in a way that there is no additional > delimiters between the service

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 09/28/2018 12:19 PM, Chris Dent wrote: > On Fri, 28 Sep 2018, Jay Pipes wrote: > >> On 09/28/2018 09:25 AM, Eric Fried wrote: >>> It's time somebody said this. > > Yes, a useful topic, I think. > >>> Every time we turn a corner or look under a rug, we find another use >>> case for provider

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 09/28/2018 09:41 AM, Balázs Gibizer wrote: > > > On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried wrote: >> It's time somebody said this. >> >> Every time we turn a corner or look under a rug, we find another use >> case for provider traits in placement. But every time we have to have >> the

Re: [openstack-dev] [placement] The "intended purpose" of traits

Chris Dent 于2018年9月29日周六 上午1:19写道： > On Fri, 28 Sep 2018, Jay Pipes wrote: > > > On 09/28/2018 09:25 AM, Eric Fried wrote: > >> It's time somebody said this. > > Yes, a useful topic, I think. > ++, I'm interesting this topic also, since it confuses me for a long time... > > >> Every time we

Re: [openstack-dev] [placement] The "intended purpose" of traits

Sorry for append another email for something I missed to say. Alex Xu 于2018年9月29日周六 上午10:01写道： > > > Jay Pipes 于2018年9月29日周六 上午5:51写道： > >> On 09/28/2018 04:42 PM, Eric Fried wrote: >> > On 09/28/2018 09:41 AM, Balázs Gibizer wrote: >> >> On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried >> wrote:

Re: [openstack-dev] [placement] The "intended purpose" of traits

Jay Pipes 于2018年9月29日周六 上午5:51写道： > On 09/28/2018 04:42 PM, Eric Fried wrote: > > On 09/28/2018 09:41 AM, Balázs Gibizer wrote: > >> On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried wrote: > >>> It's time somebody said this. > >>> > >>> Every time we turn a corner or look under a rug, we find

Re: [openstack-dev] [qa] [infra] [placement] tempest plugins virtualenv

On Fri, 28 Sep 2018, Matthew Treinish wrote: http://logs.openstack.org/14/601614/21/check/placement-tempest-gabbi/f44c185/job-output.txt.gz#_2018-09-28_11_13_25_798683 Right above this line it shows that the gabbi-tempest plugin is installed in the venv:

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

> On Fri, Sep 28, 2018 at 8:48 AM Lance Bragstad wrote: > > > Bumping this thread again and proposing two conventions based on the > > discussion here. I propose we decide on one of the two following > > conventions: > > > > *::* > > > > or > > > > *:_* > > > > Where is the corresponding

Re: [openstack-dev] [qa] [infra] [placement] tempest plugins virtualenv

On Fri, Sep 28, 2018 at 03:31:10PM +0100, Chris Dent wrote: > On Fri, 28 Sep 2018, Matthew Treinish wrote: > > > > http://logs.openstack.org/14/601614/21/check/placement-tempest-gabbi/f44c185/job-output.txt.gz#_2018-09-28_11_13_25_798683 > > > > Right above this line it shows that the

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 28/09/18 9:25 AM, Eric Fried wrote: It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time we have to have the argument about whether that use case satisfies the original "intended purpose" of

Re: [openstack-dev] [oslo][castellan] Time for a 1.0 release?

On 9/28/18 3:59 AM, Thierry Carrez wrote: Ade Lee wrote: On Tue, 2018-09-25 at 16:30 -0500, Ben Nemec wrote: Doug pointed out on a recent Oslo release review that castellan is still not officially 1.0. Given the age of the project and the fact that we're asking people to deploy a

Re: [openstack-dev] [all][tc][elections] Stein TC Election Results

Emmet Hikory writes: > Please join me in congratulating the 6 newly elected members of the > Technical Committee (TC): > > - Doug Hellmann (dhellmann) > - Julia Kreger (TheJulia) > - Jeremy Stanley (fungi) > - Jean-Philippe Evrard (evrardjp) > - Lance Bragstad (lbragstad) > -

[openstack-dev] [keystone] Keystone Team Update - Week of 24 September 2018

# Keystone Team Update - Week of 24 September 2018 ## News A theme this week was enhancing keystone's federation implementation to better support Edge use cases. We talked about it some on IRC[1] and the mailing list[2]. [1]

[openstack-dev] [tripleo][puppet] clearing the gate and landing patches to help CI

Hey Folks, Currently the tripleo gate is at 21 hours and we're continue to have timeouts and now scenario001/004 (in queens/pike) appear to be broken. Additionally we've got some patches in puppet-openstack that we need to land in order to resolve broken puppet unit tests which is affecting both

Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed

z...@openstack.org writes: > Build failed. > > - release-openstack-python > http://logs.openstack.org/d4/d445ff62676bc5b2753fba132a3894731a289fb9/release/release-openstack-python/629c35f/ > : FAILURE in 3m 57s > - announce-release announce-release : SKIPPED > - propose-update-constraints

Re: [openstack-dev] [placement] The "intended purpose" of traits

On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried wrote: It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time we have to have the argument about whether that use case satisfies the original

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

I don't know if our workflow supports this, but it would be nice to have a place to place cross-projec changes like that (something like, openstack-cross-projects-specs), and use that as a initial point for high level discussions. But for now, you can start creating specs for the projects

[openstack-dev] [release] Release model for feature-complete OpenStack libraries

Hi everyone, In OpenStack, libraries have to be released with a cycle-with-intermediary model, so that (1) they can be released early and often, (2) services consuming those libraries can take advantage of their new features, and (3) we detect integration bugs early rather than late. This

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

Hi, Am 28.09.2018 um 13:51 schrieb Erlon Cruz: > I don't know if our workflow supports this, but it would be nice to > have a place to > place cross-projec changes like that (something like, > openstack-cross-projects-specs),  > and use that as a initial point for high level discussions. But for

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

On 2018-09-28 08:51:46 -0300 (-0300), Erlon Cruz wrote: > I don't know if our workflow supports this, but it would be nice > to have a place to place cross-projec changes like that (something > like, openstack-cross-projects-specs), and use that as a initial > point for high level discussions. But

[openstack-dev] [placement] update 18-39

HTML: https://anticdent.org/placement-update-18-39.html Welcome to a placement update. This week is mostly focused on specs and illuminating some of the pressing issues with extraction. # Most Important Last week's important tasks remain important: * Work on specs and setting

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 09/28/2018 09:25 AM, Eric Fried wrote: It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time we have to have the argument about whether that use case satisfies the original "intended purpose"

[openstack-dev] [nova][stable] Preparing for ocata-em (extended maintenance)

Per the other thread on this [1] I've created an etherpad [2] to track what needs to happen to get nova's stable/ocata branch ready for Extended Maintenance [3] which means we need to flush our existing Ocata backports that we want in the final Ocata release before tagging the branch as

Re: [openstack-dev] [all][tc][elections] Stein TC Election Results

Congrats to newly elected TCs and all people who run. -Original Message- From: Doug Hellmann Sent: Friday, September 28, 2018 10:29 AM To: Emmet Hikory; OpenStack Developers Subject: Re: [openstack-dev] [all][tc][elections] Stein TC Election Results [EXTERNAL EMAIL] Please report any

Re: [openstack-dev] [python3-first] support in stable branches

Dariusz Krol writes: > Hello, > > > I'm specifically referring to branches mentioned in: > https://github.com/openstack/goal-tools/blob/4125c31e74776a7dc6a15d2276ab51ff3e73cd16/goal_tools/python3_first/jobs.py#L54 > I'm still not entirely sure what you're saying is happening that you do not

Re: [openstack-dev] [placement] The "intended purpose" of traits

On Fri, 28 Sep 2018, Jay Pipes wrote: On 09/28/2018 09:25 AM, Eric Fried wrote: It's time somebody said this. Yes, a useful topic, I think. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time we have to have the

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?

On 9/21/2018 9:08 AM, Elõd Illés wrote: Hi, Here is an etherpad with the teams that have stable:follow-policy tag on their repos: https://etherpad.openstack.org/p/ocata-final-release-before-em On the links you can find reports about the open and unreleased changes, that could be a useful

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

Ideally I would like to see it in the form of least specific to most specific. But more importantly in a way that there is no additional delimiters between the service type and the resource. Finally, I do not like the change of plurality depending on action type. I propose we consider *::[:]*

Re: [openstack-dev] [goal][python3] week 7 update

Doug Hellmann wrote on 09/26/2018 06:29:11 PM: > * We do not want to set the override once in testenv, because that > breaks the more specific versions used in default environments like > py35 and py36 (at least under older versions of tox). I assume that something like

Re: [openstack-dev] [all][tc][elections] Stein TC Election Results

++ To what Jeremy said and congratulations. On 9/27/2018 7:19 PM, Jeremy Stanley wrote: On 2018-09-27 20:00:42 -0400 (-0400), Mohammed Naser wrote: [...] A big thank you to our election team who oversees all of this as well :) [...] I wholeheartedly concur! And an even bigger thank you to

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg wrote: > > Ideally I would like to see it in the form of least specific to most > specific. But more importantly in a way that there is no additional > delimiters between the service type and the resource. Finally, I do not like > the change of