Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 09:01 PM, Chris Friesen wrote: On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of backported fixes is expected to be a direct (and only?) interest of those new teams of new cores, coming from users and operators and vendors. I'm not assuming bad intentions, not at

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 11:17 PM, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2017-11-14 15:50:08 -0600: On 11/14/2017 02:10 PM, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of

Re: [openstack-dev] [tripleo] removing zuul v3 legacy jobs

On 2017-11-15 01:18, Emilien Macchi wrote: > Hi, > > I'm working on migrating all TripleO CI jobs to be in-tree, I'm also > refactoring the layout and do some cleanup. Please don't move *all* in tree - only the legacy ones. There's a specific set of jobs we (infra, release team) like to keep in

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

On 11/14/2017 10:58 AM, Davanum Srinivas wrote: Let's focus our energy on the etherpad please https://etherpad.openstack.org/p/LTS-proposal On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas wrote: Saverio, Please see this :

Re: [openstack-dev] [Openstack-operators] [LTS] Upstream LTS Releases

Well, moving this discussion is easy. All that takes is everyone posting responses to the openstack-...@lists.openstack.org mailing list instead of dev and ops lists. I've cc'ed all here. I've also added [LTS] to the subject (sorry to break all the threaders). So that the sig list knows what

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On 14 Nov 2017, at 16:08, Davanum Srinivas wrote: > On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson wrote: >> >> >> On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: >> >>> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: The pressure for #2 comes from

Re: [openstack-dev] [OpenStack-docs] [docs] Next documentation meeting

All, Please consider today's meeting canceled. Thanks, pk > From: "Petr Kovar" > To: openstack-dev@lists.openstack.org > Cc: "enstack.org" > Sent: Tuesday, November 14, 2017 11:37:39 AM > Subject: [OpenStack-docs] [docs] Next

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

I can think of a few ideas, though some sound painful on paper Not really recommending anything, just thinking out loud... One idea is that at the root of chaos monkey. If something is hard, do it frequently. If upgrading is hard, we need to be doing it constantly so the pain gets largely

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On Tue, Nov 14, 2017 at 4:10 PM, Rochelle Grober wrote: > Folks, > > This discussion and the people interested in it seem like a perfect > application of the SIG process. By turning LTS into a SIG, everyone can > discuss the issues on the SIG mailing list and the

[openstack-dev] [tripleo] removing zuul v3 legacy jobs

Hi, I'm working on migrating all TripleO CI jobs to be in-tree, I'm also refactoring the layout and do some cleanup. It's a bit of work, that can be followed here: https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3 The only thing I ask from our team is to let me know any change in

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On Tue, Nov 14, 2017 at 6:44 PM, John Dickinson wrote: > > > On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > >> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: >>> The pressure for #2 comes from the inability to skip upgrades and the fact >>> that upgrades

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson wrote: > > > On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > >> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: >>> The pressure for #2 comes from the inability to skip upgrades and the fact >>> that

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On Tue, Nov 14, 2017 at 6:44 PM, John Dickinson wrote: > > > On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > >> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: >>> The pressure for #2 comes from the inability to skip upgrades and the fact >>> that upgrades

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

For those wondering why operators can’t always upgrade sooner, I can add a little bit of color: In our clouds, we have a couple vendors (one network plugin, one cinder driver) and those vendors typically are 1-3 releases behind ‘cutting edge’. By the time they support the version we want to

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: >> The pressure for #2 comes from the inability to skip upgrades and the fact >> that upgrades are hugely time consuming still. >> >> If you want to reduce the push for

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote: > The pressure for #2 comes from the inability to skip upgrades and the fact > that upgrades are hugely time consuming still. > > If you want to reduce the push for number #2 and help developers get their > wish of getting

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

The pressure for #2 comes from the inability to skip upgrades and the fact that upgrades are hugely time consuming still. If you want to reduce the push for number #2 and help developers get their wish of getting features into users hands sooner, the path to upgrade really needs to be much

Re: [openstack-dev] Upstream LTS Releases

Excerpts from Chris Friesen's message of 2017-11-14 15:50:08 -0600: > On 11/14/2017 02:10 PM, Doug Hellmann wrote: > > Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: > >> On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: > >> > The quality of backported fixes is expected to

Re: [openstack-dev] [ironic] automatic migration from classic drivers to hardware types?

On Tue, Nov 14, 2017 at 8:10 AM, Dmitry Tantsur wrote: > Hi folks! > > This was raised several times, now I want to bring it to the wider audience. > We're planning [1] to deprecate classic drivers in Queens and remove them in > Rocky. It was pointed at the Forum that we'd

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 02:10 PM, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of backported fixes is expected to be a direct (and only?) interest of those new teams of new cores, coming from users and

[openstack-dev] [keystone] Sydney Summit Recap

Hey all, I just finished dumping everything from the summit into a blog post [0]. If you have a summary or feedback - we can use this thread to advertise it and discuss. Thanks, Lance [0] https://www.lbragstad.com/blog/openstack-summit-sydney-recap signature.asc Description: OpenPGP

Re: [openstack-dev] [neutron] multiple agents with segment access

In general, you should be able to run both regular l2 agent (ovs) and sriov agent. If you have problems with it, we should probably assume it's a bug. Please report. On Tue, Nov 14, 2017 at 8:02 AM, Legacy, Allain wrote: > Is it a known limitation that the ML2 plugin

Re: [openstack-dev] [Release-job-failures][release][trove][infra] Pre-release of openstack/trove failed

On Tue, Nov 14, 2017, at 12:15 PM, Doug Hellmann wrote: > Excerpts from Clark Boylan's message of 2017-11-14 09:04:07 -0800: > > > > On Tue, Nov 14, 2017, at 09:01 AM, Doug Hellmann wrote: > > > Excerpts from zuul's message of 2017-11-14 16:24:33 +: > > > > Build failed. > > > > > > > > -

Re: [openstack-dev] Upstream LTS Releases

Folks, This discussion and the people interested in it seem like a perfect application of the SIG process. By turning LTS into a SIG, everyone can discuss the issues on the SIG mailing list and the discussion shouldn't end up split. If it turns into a project, great. If a solution is found

Re: [openstack-dev] [Release-job-failures][neutron] Tag of openstack/networking-midonet failed

Excerpts from zuul's message of 2017-11-14 20:13:45 +: > Unable to freeze job graph: Unable to modify final job publish-openstack-releasenotes branches: None source: > openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute > required_projects={'openstack/neutron':

Re: [openstack-dev] [Release-job-failures][release][trove][infra] Pre-release of openstack/trove failed

Excerpts from Clark Boylan's message of 2017-11-14 09:04:07 -0800: > > On Tue, Nov 14, 2017, at 09:01 AM, Doug Hellmann wrote: > > Excerpts from zuul's message of 2017-11-14 16:24:33 +: > > > Build failed. > > > > > > - release-openstack-python-without-pypi > > >

Re: [openstack-dev] Upstream LTS Releases

Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: > On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: > > >> The quality of backported fixes is expected to be a direct (and only?) > >> interest of those new teams of new cores, coming from users and operators > >> and > >> vendors.

Re: [openstack-dev] Upstream LTS Releases

On Wed, Nov 15, 2017 at 7:01 AM, Chris Friesen wrote: > On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: > >>> The quality of backported fixes is expected to be a direct (and only?) >>> interest of those new teams of new cores, coming from users and operators >>> and >>>

Re: [openstack-dev] Upstream LTS Releases

On Tue, Nov 14, 2017 at 11:25:03AM -0500, Doug Hellmann wrote: > Excerpts from Bogdan Dobrelya's message of 2017-11-14 17:08:31 +0100: > > >> The concept, in general, is to create a new set of cores from these > > >> groups, and use 3rd party CI to validate patches. There are lots of > > >>

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of backported fixes is expected to be a direct (and only?) interest of those new teams of new cores, coming from users and operators and vendors. I'm not assuming bad intentions, not at all. But there is a lot of involved in a decision

Re: [openstack-dev] Upstream LTS Releases

On Tue, Nov 14, 2017 at 11:28 AM, Dmitry Tantsur wrote: > On 11/14/2017 05:08 PM, Bogdan Dobrelya wrote: The concept, in general, is to create a new set of cores from these groups, and use 3rd party CI to validate patches. There are lots of details to be

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

Thanks for sending this out. I would vote for Option 1. Thanks, John From: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com] Sent: Tuesday, November 14, 2017 8:16 AM To: OpenStack Development Mailing List (not for usage questions) Subject:

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On 11/14/2017 06:21 PM, Erik McCormick wrote: On Tue, Nov 14, 2017 at 11:30 AM, Blair Bethwaite wrote: Hi all - please note this conversation has been split variously across -dev and -operators. One small observation from the discussion so far is that it seems as

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 05:08 PM, Bogdan Dobrelya wrote: The concept, in general, is to create a new set of cores from these groups, and use 3rd party CI to validate patches. There are lots of details to be worked out yet, but our amazing UC (User Committee) will be begin working out the details. What

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 10:25 AM, Doug Hellmann wrote: Why would we have third-party jobs on an old branch that we don't have on master, for instance? One possible reason is to test the stable version of OpenStack against a stable version of the underlying OS distro. (Where that distro may not meet

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

Jens, That's quite an interesting catch. I'm reaching out to the author of this change to get some more information. Thanks, Mohammed On Tue, Nov 14, 2017 at 2:02 PM, Jens Harbott wrote: > 2017-11-14 16:29 GMT+00:00 Mohammed Naser : >> Hi everyone, >>

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

2017-11-14 16:29 GMT+00:00 Mohammed Naser : > Hi everyone, > > Thank you so much for the work on this, I'm sure we can progress with > this together. I have noticed that this only occurs in master and > never in the stable branches. Also, it only occurs under Ubuntu (so >

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

Hi! Thanks for raising this. On 11/14/2017 05:16 PM, Pavlo Shchelokovskyy wrote: Hi all, as this topic it was recently brought up in ironic IRC meeting, I'd like to start a discussion on the subject. A quick recap - networking-generic-switch project (n-g-s) was born out of necessity to do

[openstack-dev] [ironic][inspector] HA Demo

Folks, I'd like to share the progress of the HA Inspector effort with you. TL;DR I'm able to run 2 instances of ironic inspector in an active-active fashion in a modified devstack deployment. I've uploaded a Github repo containing my config[1] to take to reproduce as well as a video[2] of me

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On Tue, Nov 14, 2017 at 11:30 AM, Blair Bethwaite wrote: > Hi all - please note this conversation has been split variously across > -dev and -operators. > > One small observation from the discussion so far is that it seems as > though there are two issues being

Re: [openstack-dev] [Release-job-failures][release][trove][infra] Pre-release of openstack/trove failed

On Tue, Nov 14, 2017, at 09:01 AM, Doug Hellmann wrote: > Excerpts from zuul's message of 2017-11-14 16:24:33 +: > > Build failed. > > > > - release-openstack-python-without-pypi > >

Re: [openstack-dev] [Release-job-failures][release][trove][infra] Pre-release of openstack/trove failed

Excerpts from zuul's message of 2017-11-14 16:24:33 +: > Build failed. > > - release-openstack-python-without-pypi > http://logs.openstack.org/17/175bd53e7b18a9dc4d42e60fe9225a5748eded34/pre-release/release-openstack-python-without-pypi/7a9474c/ > : POST_FAILURE in 14m 47s > -

Re: [openstack-dev] Upstream LTS Releases

Blair, Please add #2 as a line proposal in: https://etherpad.openstack.org/p/LTS-proposal So far it's focused on #1 Thanks, Dims On Wed, Nov 15, 2017 at 3:30 AM, Blair Bethwaite wrote: > Hi all - please note this conversation has been split variously across > -dev

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

Let's focus our energy on the etherpad please https://etherpad.openstack.org/p/LTS-proposal On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas wrote: > Saverio, > > Please see this : > https://docs.openstack.org/project-team-guide/stable-branches.html for > current policies. >

Re: [openstack-dev] [octavia] amphora fails to send request to members

Yipei, Yeah, we have clearly identified the problem. Those two default route lines should not be different. See my devstack: sudo: unable to resolve host amphora-20a717b4-eb97-4b5c-a11a-0633fe61f135 default via 10.0.0.1 dev eth1 table 1 onlink default via 10.0.0.1 dev eth1 onlink So the issue

Re: [openstack-dev] [Release-job-failures][zuul][infra][trove] Tag of openstack/trove-dashboard failed

Excerpts from Clark Boylan's message of 2017-11-14 08:31:15 -0800: > On Tue, Nov 14, 2017, at 08:09 AM, Doug Hellmann wrote: > > Excerpts from zuul's message of 2017-11-14 16:01:20 +: > > > Unable to freeze job graph: Unable to modify final job > > publish-openstack-releasenotes branches:

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

On Tue, Nov 14, 2017 at 9:16 AM, Pavlo Shchelokovskyy wrote: > As a core in n-g-s myself I'm happy with either 1) or 2), but not really > fond of 3) as it kind of stretches the networking-baremetal scope too much > IMHO. Personally, I'm happy with 1 or 2. I

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

Saverio, Please see this : https://docs.openstack.org/project-team-guide/stable-branches.html for current policies. On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto wrote: >> Which stable policy does that patch violate? It's clearly a bug >> because the wrong information

Re: [openstack-dev] Need help with Openstack Swift Installation and configuration with S3

To do this you want to use the `swift3` middleware, available at https://github.com/openstack/swift3. Its `README.md` file has installation instructions. Also note that the Swift community is currently integrating the `swift3` middleware into Swift's code repo. In the future, you will not need

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

> Which stable policy does that patch violate? It's clearly a bug > because the wrong information is being logged. I suppose it goes > against the string freeze rule? Except that we've stopped translating > log messages so maybe we don't need to worry about that in this case, > since it isn't an

Re: [openstack-dev] [Release-job-failures][zuul][infra][trove] Tag of openstack/trove-dashboard failed

On Tue, Nov 14, 2017, at 08:09 AM, Doug Hellmann wrote: > Excerpts from zuul's message of 2017-11-14 16:01:20 +: > > Unable to freeze job graph: Unable to modify final job > publish-openstack-releasenotes branches: None source: > > openstack-infra/project-config/zuul.d/jobs.yaml@master#26>

Re: [openstack-dev] Upstream LTS Releases

Hi all - please note this conversation has been split variously across -dev and -operators. One small observation from the discussion so far is that it seems as though there are two issues being discussed under the one banner: 1) maintain old releases for longer 2) do stable releases less

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

Hi everyone, Thank you so much for the work on this, I'm sure we can progress with this together. I have noticed that this only occurs in master and never in the stable branches. Also, it only occurs under Ubuntu (so maybe something related to mod_wsgi version?) Given that we don't have any

Re: [openstack-dev] Upstream LTS Releases

Excerpts from Bogdan Dobrelya's message of 2017-11-14 17:08:31 +0100: > >> The concept, in general, is to create a new set of cores from these > >> groups, and use 3rd party CI to validate patches. There are lots of > >> details to be worked out yet, but our amazing UC (User Committee) will > >>

Re: [openstack-dev] Upstream LTS Releases

Bogdan, Team, So i got this etherpad started. Please add policy ideas at the top and volunteer for the team too., https://etherpad.openstack.org/p/LTS-proposal Thanks, Dims On Wed, Nov 15, 2017 at 3:08 AM, Bogdan Dobrelya wrote: >>> The concept, in general, is to create a

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

Excerpts from Davanum Srinivas (dims)'s message of 2017-11-15 03:04:38 +1100: > Flavio, Saverio, > > Agree, that review may be a good example of what could be done. More info > below. > > Saverio said - "with the old Stable Release thinking this patch would > not be accepted on old stable

[openstack-dev] [ironic] Summary of ironic sessions from Sydney

Greetings ironic folk! Like many other teams, we had very few ironic contributors make it to Sydney. As such, I wanted to go ahead and write up a summary that covers takeaways, questions, and obvious action items for the community that were raised by operators and users present during the

[openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

Hi all, as this topic it was recently brought up in ironic IRC meeting, I'd like to start a discussion on the subject. A quick recap - networking-generic-switch project (n-g-s) was born out of necessity to do two things: - test the "network isolation for baremetal nodes" (a.k.a. multi-tenancy)

Re: [openstack-dev] [Release-job-failures][zuul][infra][trove] Tag of openstack/trove-dashboard failed

Excerpts from zuul's message of 2017-11-14 16:01:20 +: > Unable to freeze job graph: Unable to modify final job publish-openstack-releasenotes branches: None source: > openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute > required_projects={'openstack/horizon':

Re: [openstack-dev] Upstream LTS Releases

The concept, in general, is to create a new set of cores from these groups, and use 3rd party CI to validate patches. There are lots of details to be worked out yet, but our amazing UC (User Committee) will be begin working out the details. What is the most worrying is the exact "take over"

Re: [openstack-dev] [api] APIs schema consumption discussion

Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100: > Hi, > > Follow-up conversation from our last "API SIG feedback and discussion > session" at Sydney Summit [1], about APIs schema consumption. > > Let's summarize the current situation. > > Each OpenStack project has an

Re: [openstack-dev] [Release-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

On 2017-11-14 17:03, Doug Hellmann wrote: > Excerpts from Andreas Jaeger's message of 2017-11-14 09:31:48 +0100: >> On 2017-11-13 22:09, Doug Hellmann wrote: >>> Excerpts from zuul's message of 2017-11-13 20:37:18 +: Unable to freeze job graph: Unable to modify final job >>>

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

Flavio, Saverio, Agree, that review may be a good example of what could be done. More info below. Saverio said - "with the old Stable Release thinking this patch would not be accepted on old stable branches." My response - "Those branches are still under stable policy. That has not changed just

Re: [openstack-dev] [Release-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

Excerpts from Andreas Jaeger's message of 2017-11-14 09:31:48 +0100: > On 2017-11-13 22:09, Doug Hellmann wrote: > > Excerpts from zuul's message of 2017-11-13 20:37:18 +: > >> Unable to freeze job graph: Unable to modify final job >> publish-openstack-releasenotes branches: None source: >

[openstack-dev] [neutron] multiple agents with segment access

Is it a known limitation that the ML2 plugin and associated drivers do not properly handle cases where there are multiple agents running on the same host? That is, two or more agents that reside on the same host and both report device/interface mappings for physical networks?One such

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

On 14/11/17 22:33 +1100, Davanum Srinivas wrote: Saverio, This is still under the stable team reviews... NOT LTS. Your contacts for the Nova Stable team is ... https://review.openstack.org/#/admin/groups/540,members Let's please be clear, we need new people to help with LTS plans. Current

[openstack-dev] [cinder] Weekly Meeting Back-on 11/15/2017 ...

Team, Just a reminder that we will now return to our regularly scheduled weekly Cinder meetings starting 11/15/2017. I hope you all enjoyed a little break and thank you to whoever updated the etherpad for 11/8.  :-) An important reminder to everyone in the US (and possibly elsewhere) that

[openstack-dev] [ironic] automatic migration from classic drivers to hardware types?

Hi folks! This was raised several times, now I want to bring it to the wider audience. We're planning [1] to deprecate classic drivers in Queens and remove them in Rocky. It was pointed at the Forum that we'd better provide an automatic migration. I'd like to hear your opinion on the

Re: [openstack-dev] [puppet][ci][infra] PTI jobs for Puppet modules

On 2017-11-13 14:26:38 -0500 (-0500), Mohammed Naser wrote: [...] > Given that Puppet OpenStack has a large number of modules, in addition > to Infra's puppet modules, it would be good to have a project-template > specific for build and release of Puppet modules. [...] Coming up with something

[openstack-dev] Need help with Openstack Swift Installation and configuration with S3

Hi, We just started with Openstack Swift which we intend to use as a replacement for an API which was written to work with AWS S3. We know that Swift is S3 compatible and our API should work out of the box with it. We have not been able to get Swift running with S3 plugins. I was wondering if

Re: [openstack-dev] LTS pragmatic example

Saverio, This is still under the stable team reviews... NOT LTS. Your contacts for the Nova Stable team is ... https://review.openstack.org/#/admin/groups/540,members Let's please be clear, we need new people to help with LTS plans. Current teams can't scale, they should not have to and it's

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

Yea, I've been scavenging the logs for any kind of indicator on what might have gone wrong but I can't see anything related to a deadlock even though I'm very certain that's the issue but don't know what's causing it. Perhaps we will need to manually recreate this issue and then troubleshoot it

Re: [openstack-dev] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)

As discussed in IRC, I have collated all the important discussions to the etherpad (gdoc was not publicly shareable). https://etherpad.openstack.org/p/tripleo-derive-parameters-v2 Lets continue discussion on the etherpad to finalize. Regards, Saravanan KR On Thu, Nov 9, 2017 at 11:05 AM,

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

2017-11-14 8:24 GMT+00:00 Tobias Urdin : > Trying to trace this, tempest calls the POST /servers//action > API endpoint for the nova compute api. > > https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/floating_ips_client.py#L82 > > Nova then

[openstack-dev] [neutron][classifier] CCF Meeting

Hi everyone. Reminder that the Common Classification Framework meeting is at 14:00 UTC. The Agenda can be found here: https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#All_Meetings.27_Agendas Regards. David.

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

Am I actually hallucinating or is it the nova API that cannot communicate with Keystone? Cannot substantiate this with any logs for keystone. 2017-10-29 23:12:35.521 17800 ERROR nova.api.openstack.compute.floating_ips [req-7f810cc7-a498-4bf4-b27e-8fc80d652785 42526a28b1a14c629b83908b2d75c647

Re: [openstack-dev] [Neutron] Infiniband & Melanox OFED 4.2 eIPoIB support

This more question to mellanox then to neutron community. I suggest that you will send me private mail regarding this issue and we can take it with the relevant people in Mellanox. My email is mosh...@mellanox.com. > -Original Message- > From: Massimo Benini [mailto:ben...@cscs.ch] >

[openstack-dev] [Neutron] Infiniband & Melanox OFED 4.2 eIPoIB support

Dear Neutron developers, we are building up an OpenStack (Pike) cluster based on CentOS 7.4 and Mellanox Ofed 4.2. As far as we understand Neutron rely on eIPoIB in order to manage Infiniband networks but unfortunately Mellanox dropped this feature for the new OFED versions. Here below the

[openstack-dev] LTS pragmatic example

Hello, here an example of a trivial patch that is important for people that do operations, and they have to troubleshoot stuff. with the old Stable Release thinking this patch would not be accepted on old stable branches. Let's see if this gets accepted back to stable/newton

[openstack-dev] [openstack-meteos] Meteos Project Weekly Meeting

Hi All, I am starting meteos project meeting from coming thursday. Meteos meeting will be held every thursday 4:30 am UTC. Please go through the meeting plan: https://wiki.openstack.org/wiki/Meetings/meteos Thanks, Digambar

Re: [openstack-dev] [infra] support graphviz in document publishing

On Tue, Nov 14, 2017 at 5:05 AM Antoine Musso wrote: > Hello, > > I had some success with http://blockdiag.com/ which, IIRC, is pure > python. It supports various kind of graphs (block, sequences, network ...). > > The few I did were for Zuul: >

Re: [openstack-dev] [Release-job-failures][neutron][infra] Tag of openstack/neutron-fwaas-dashboard failed

On 2017-11-13 22:09, Doug Hellmann wrote: > Excerpts from zuul's message of 2017-11-13 20:37:18 +: >> Unable to freeze job graph: Unable to modify final job > publish-openstack-releasenotes branches: None source: >> openstack-infra/project-config/zuul.d/jobs.yaml@master#26> attribute >>

Re: [openstack-dev] [infra] support graphviz in document publishing

On Mon, Nov 13, 2017 at 5:41 PM Andreas Jaeger wrote: > You can easily include them for any repository - add the python > requirements to test-requirments and add the binary requirements to > bindep.txt - as explained in >

Re: [openstack-dev] [octavia] amphora fails to send request to members

Hi, Michael, Please ignore my last two mails. Sorry about that. The results of the two commands are as follows. ubuntu@amphora-a0621f0e-d27f-4f22-a4ee-05b695e2b71f:~$ sudo ip netns exec amphora-haproxy ip route show table all sudo: unable to resolve host

Re: [openstack-dev] [puppet][qa][ubuntu][neutron] Xenial Neutron Timeouts

Trying to trace this, tempest calls the POST /servers//action API endpoint for the nova compute api. https://github.com/openstack/tempest/blob/master/tempest/lib/services/compute/floating_ips_client.py#L82 Nova then takes the requests and tries to do this floating ip association using the