[openstack-dev] [sdk][masakari] Need newer version of openstacksdk

Hi SDK team, Few weeks back we have moved "instance_ha" service code from python-masakariclient into openstacksdk project in patch [1] and it got merged. Currently, masakari-monitors is totally broken and it requires newer version of openstacksdk. We have proposed a patch [2] in

Re: [openstack-dev] [openstack-infra] How to take over a project?

Dear Neutron-Release team, I wonder if any of you can add me to the network-onos-release member. It seems that Vikram is busy. :-) Thank you, Sangho > On 19 Apr 2018, at 9:18 AM, Sangho Shin wrote: > > Ian, > > Thank you so much for your help. > I have

[openstack-dev] [all][infra] ubuntu-bionic and legacy nodesets

Greetings, With ubuntu-bionic release around the corner we'll be starting discussions about migrating jobs from ubuntu-xenial to ubuntu-bionic. On topic I'd like to raise, is round job migrations from legacy to native zuulv3. Specifically, I'd like to propose we do not add legacy-ubuntu-bionic

Re: [openstack-dev] [docs] When should we say 'run as root' in the docs?

Matt Riedemann wrote on 04/19/2018 06:11:58 PM: > How loose are we with saying things like, "you should run this as root" > in the docs? > > I was triaging this nova bug [1] which is saying that the docs should > tell you to run nova-status (which implies also nova-manage)

[openstack-dev] [docs] When should we say 'run as root' in the docs?

How loose are we with saying things like, "you should run this as root" in the docs? I was triaging this nova bug [1] which is saying that the docs should tell you to run nova-status (which implies also nova-manage) as root, but isn't running admin-level CLIs implied that you need root, or

[openstack-dev] [infra] Removal of debian-jessie, replaced by debian-stable (stretch)

Greetings, I'd like to propose now that we have debian-stable (stretch) nodesets online for nodepool, that we start the process to remove debian-jessie. As I can see, there really is only 2 projects using debian-jessie: * ARA * ansible-hardening I've already proposed patches to update

Re: [openstack-dev] [all][ptl][release] reminder for rocky-1 milestone deadline

Excerpts from Matt Riedemann's message of 2018-04-19 13:34:44 -0500: > On 4/19/2018 1:15 PM, Doug Hellmann wrote: > > Second, releasing early and often gives us more time to fix issues, > > so we aren't rushing around at deadline trying to solve a problem > > while the gate is full of other last

Re: [openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

Excerpts from Jim Rollenhagen's message of 2018-04-18 13:44:08 -0400: > Hi all, > > We have a number of stable branch jobs failing[0] with an error about pep8 > not being importable[1], when it's clearly installed[2]. We first saw this > when installing networking-generic-switch on queens in our

Re: [openstack-dev] [all][ptl][release] reminder for rocky-1 milestone deadline

Got it thanks a lot, Doug and Matt! On 4/19/18, 11:34 AM, "Matt Riedemann" wrote: >On 4/19/2018 1:15 PM, Doug Hellmann wrote: >> Second, releasing early and often gives us more time to fix issues, >> so we aren't rushing around at deadline trying to solve a problem >> while

Re: [openstack-dev] [all][ptl][release] reminder for rocky-1 milestone deadline

On 4/19/2018 1:15 PM, Doug Hellmann wrote: Second, releasing early and often gives us more time to fix issues, so we aren't rushing around at deadline trying to solve a problem while the gate is full of other last minute patches for other projects. Yup, case in point: I waited too long to

Re: [openstack-dev] [all][ptl][release] reminder for rocky-1 milestone deadline

Libraries do need to release by R-3 so that we have something to use as a branch point for the stable branches. We encourage releases earlier than that, for a couple of reasons. First, because of the way the CI system works, libraries are generally not used in test jobs unless they are released.

Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits

+1 :D hell yeah! On Thu, 19 Apr 2018, 20:05 John Fulton, wrote: > +1 > > On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi > wrote: > > Greetings, > > > > As you probably know mcornea on IRC, Marius Cornea has been contributing > on > > TripleO for a

Re: [openstack-dev] [all][ptl][release] reminder for rocky-1 milestone deadline

Specifically, for client library using the cycle-with-intermediary release model. On 4/19/18, 10:52 AM, "Eric K" wrote: >Thank you, Doug. Question: do we need to do a client library release prior >to R-3? The practice seems to change from cycle to cycle. > >On 4/19/18,

Re: [openstack-dev] [all][ptl][release] reminder for rocky-1 milestone deadline

Thank you, Doug. Question: do we need to do a client library release prior to R-3? The practice seems to change from cycle to cycle. On 4/19/18, 6:15 AM, "Doug Hellmann" wrote: >Today is the deadline for proposing a release for the Rocky-1 milestone. >Please don't forget

[openstack-dev] Project Teams Gathering- Denver September 10-14th

All aboard! Next stop Denver! The fourth Project Teams Gathering [1] will be held September 10-14th back at the Renaissance Stapleton Hotel [2] in Denver, Colorado (3801 Quebec Street, Denver, Colorado 80207). The Project Teams Gathering (PTG) is an event organized by the OpenStack

Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits

+1 On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi wrote: > Greetings, > > As you probably know mcornea on IRC, Marius Cornea has been contributing on > TripleO for a while, specially on the upgrade bits. > Part of the quality team, he's always testing real customer scenarios

[openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits

Greetings, As you probably know mcornea on IRC, Marius Cornea has been contributing on TripleO for a while, specially on the upgrade bits. Part of the quality team, he's always testing real customer scenarios and brings a lot of good feedback in his reviews, and quite often takes care of fixing

Re: [openstack-dev] [osc][swift] Setting storage policy for a container possible via the client?

On Thu, Apr 19, 2018 at 7:51 AM, Doug Hellmann wrote: > Excerpts from Mark Kirkwood's message of 2018-04-19 16:47:58 +1200: >> Swift has had storage policies for a while now. These are enabled by >> setting the 'X-Storage-Policy' header on a container. >> >> It looks to me

Re: [openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

On 04/19/2018 12:27 PM, Matt Riedemann wrote: On 4/19/2018 11:06 AM, Matthew Booth wrote: I'm ambivalent, tbh, but I think it's better to pick one. I thought we'd picked 'evacuate' based on the TODOs from Matt R: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n2985

Re: [openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

On 4/19/2018 10:46 AM, Chris Friesen wrote: From the CLI perspective, it makes no sense that "nova evacuate" operates after a host is already down, but "nova evacuate-live" operates on a running host. http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/

Re: [openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

On 4/19/2018 11:06 AM, Matthew Booth wrote: I'm ambivalent, tbh, but I think it's better to pick one. I thought we'd picked 'evacuate' based on the TODOs from Matt R: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n2985

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, As it was just edleafe and I today, we had a quick meeting and went back to other things. The main actions were to select one guideline to publish and one guideline to freeze. These are listed below. We also briefly discussed that though we have not planned

Re: [openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

On 19 April 2018 at 16:46, Chris Friesen wrote: > On 04/19/2018 08:33 AM, Jay Pipes wrote: >> >> On 04/19/2018 09:15 AM, Matthew Booth wrote: >>> >>> We've had inconsistent naming of recreate/evacuate in Nova for a long >>> time, and it will persist in a couple of

Re: [openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

On 19 April 2018 at 15:33, Jay Pipes wrote: > On 04/19/2018 09:15 AM, Matthew Booth wrote: >> >> We've had inconsistent naming of recreate/evacuate in Nova for a long >> time, and it will persist in a couple of places for a while more. >> However, I've proposed the following

[openstack-dev] [all] Gerrit server replacement scheduled for May 2nd 2018

Hello from Infra. This is our weekly reminder of the upcoming gerrit replacement. We'll continue to send these announcements out up until the day of the migration. We are now 2 weeks away from replacement date. If you have any questions, please contact us in #openstack-infra. --- It's that

Re: [openstack-dev] [nova][placement] Scheduler VM distribution

Привет, Андрей! Comments inline... On 04/19/2018 10:27 AM, Andrey Volkov wrote: Hello, From my understanding, we have a race between the scheduling process and host weight update. I made a simple experiment. On the 50 fake host environment it was asked to boot 40 VMs those should be placed 1

Re: [openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

On 04/19/2018 08:33 AM, Jay Pipes wrote: On 04/19/2018 09:15 AM, Matthew Booth wrote: We've had inconsistent naming of recreate/evacuate in Nova for a long time, and it will persist in a couple of places for a while more. However, I've proposed the following to rename 'recreate' to 'evacuate'

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Thanks to everyone who contributed to this discussion. With just a teeny bit more bikeshedding on the exact syntax [1], we landed on: group_policy={none|isolate} I have proposed this delta to the granular spec [2]. -efried [1]

Re: [openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

Andrea Frittoli writes: > Dear all, > > a quick update on the current status. > > Zuul has been fixed to use the correct branch for roles coming from > different repositories [1]. > The backport of the devstack patches to support multinode jobs is almost > complete.

[openstack-dev] Migration of Bandit

All, Please note that Bandits code and issues / docs will be migrated from OpenStack to PyCQA. This is expected to happen next week. No changes are required in any projects or CI, as Bandit will still be available via pypi and projects / CI are set up to use Bandit in that way via tox. READMEs

[openstack-dev] [nova][placement] Scheduler VM distribution

Hello, >From my understanding, we have a race between the scheduling process and host weight update. I made a simple experiment. On the 50 fake host environment it was asked to boot 40 VMs those should be placed 1 on each host. The hosts are equal to each other in terms of inventory.

Re: [openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

On 04/19/2018 09:15 AM, Matthew Booth wrote: We've had inconsistent naming of recreate/evacuate in Nova for a long time, and it will persist in a couple of places for a while more. However, I've proposed the following to rename 'recreate' to 'evacuate' everywhere with no rpc/api impact here:

Re: [openstack-dev] [Release-job-failures] Pre-release of openstack/freezer-dr failed

Excerpts from zuul's message of 2018-04-19 13:22:40 +: > Build failed. > > - release-openstack-python > http://logs.openstack.org/c9/c9263cde360d37654c4298c496cd9af251f23ce7/pre-release/release-openstack-python/541ad7d/ > : FAILURE in 3m 48s > - announce-release announce-release : SKIPPED >

Re: [openstack-dev] [Release-job-failures][freezer][release] Pre-release of openstack/freezer-dr failed

Excerpts from Doug Hellmann's message of 2018-04-19 09:38:31 -0400: > Excerpts from zuul's message of 2018-04-19 13:22:40 +: > > Build failed. > > > > - release-openstack-python > >

[openstack-dev] [packaging-rpm][meeting] Proposal for new meeting time

Hello fellow packagers, During today's meeting [1], we discussed the schedule conflicts some of us have with the current meeting slot. As a result, I would like to propose a new meeting time: - Wednesdays, 1 PM UTC (3 PM CEST) So far, dirk and jruzicka agreed with the change. If you have an

Re: [openstack-dev] [nova] Default scheduler filters survey

Two different setups, very basic. AggregateInstanceExtraSpecsFilter RetryFilter AvailabilityZoneFilter ComputeFilter ComputeCapabilitiesFilter ImagePropertiesFilter ServerGroupAntiAffinityFilter ServerGroupAffinityFilter RetryFilter AvailabilityZoneFilter RamFilter ComputeFilter

[openstack-dev] [all][ptl][release] reminder for rocky-1 milestone deadline

Today is the deadline for proposing a release for the Rocky-1 milestone. Please don't forget to include your libraries (client or otherwise) as well. Doug __ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [nova] Heads up for out-of-tree drivers: supports_recreate -> supports_evacuate

We've had inconsistent naming of recreate/evacuate in Nova for a long time, and it will persist in a couple of places for a while more. However, I've proposed the following to rename 'recreate' to 'evacuate' everywhere with no rpc/api impact here: https://review.openstack.org/560900 One of the

[openstack-dev] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

Hi, When configuring TripleO deployments with nodes on routed ctlplane networks we need to pass some per-network properties to the NetworkConfig resource[1] in THT. We get the ``ControlPlaneIp`` property using get_attr, but the NIC configs need a couple of more parameters[2], for example:

[openstack-dev] [docs] Documentation meeting minutes for 2018-04-18

=== #openstack-doc: docteam === Meeting started by pkovar at 16:02:48 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/docteam/2018/docteam.2018-04-18-16.02.log.html . Meeting summary --- * Open discussion

Re: [openstack-dev] [osc][swift] Setting storage policy for a container possible via the client?

Excerpts from Mark Kirkwood's message of 2018-04-19 16:47:58 +1200: > Swift has had storage policies for a while now. These are enabled by > setting the 'X-Storage-Policy' header on a container. > > It looks to me like this is not possible using openstack-client (even in > master branch) -

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On Thu, Apr 19, 2018 at 2:27 PM, Eric Fried wrote: gibi- Can the proximity param specify relationship between the un-numbered and the numbered groups as well or only between numbered groups? Besides that I'm +1 about proxyimity={isolate|any} Remembering that the

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Sylvain- > What's the default behaviour if we aren't providing the proximity qparam > ? Isolate or any ? What we've been talking about, per mriedem's suggestion, is that the qparam is required when you specify any numbered request groups. There is no default. If you don't provide the qparam,

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Chris- Thanks for this perspective. I totally agree. > * the common behavior should require the least syntax. To that point, I had been assuming "any fit" was going to be more common than "explicit anti-affinity". But I think this is where we are having trouble agreeing. So since, as you

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

gibi- > Can the proximity param specify relationship between the un-numbered and > the numbered groups as well or only between numbered groups? > Besides that I'm +1 about proxyimity={isolate|any} Remembering that the resources in the un-numbered group can be spread around the tree and sharing

[openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

Dear all, a quick update on the current status. Zuul has been fixed to use the correct branch for roles coming from different repositories [1]. The backport of the devstack patches to support multinode jobs is almost complete. All stable/queens patches are merged, stable/pike patches are almost

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

2018-04-19 10:38 GMT+02:00 Balázs Gibizer : > > > On Thu, Apr 19, 2018 at 12:45 AM, Eric Fried wrote: > >> I have a feeling we're just going to go back and forth on this, as we >>> have for weeks now, and not reach any conclusion that is

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On Wed, 18 Apr 2018, Eric Fried wrote: I have a feeling we're just going to go back and forth on this, as we have for weeks now, and not reach any conclusion that is satisfactory to everyone. And we'll delay, yet again, getting functionality into this release that serves 90% of use cases

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On Thu, Apr 19, 2018 at 12:45 AM, Eric Fried wrote: I have a feeling we're just going to go back and forth on this, as we have for weeks now, and not reach any conclusion that is satisfactory to everyone. And we'll delay, yet again, getting functionality into this

Re: [openstack-dev] [Os-brick][Cinder] NVMe-oF NQN string

Hi Hamdy, Thanks for quick action. Regards Maciej From: Hamdy Khader [mailto:ham...@mellanox.com] Sent: Tuesday, April 17, 2018 12:51 PM To: OpenStack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Os-brick][Cinder] NVMe-oF NQN string Hi, I think you're right, will drop the split and

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

I'm trying so hard to catch up the discussion since I lost few.., it is really hard... In my mind , I'm always thinking the request group is only about binding the trait and the resource class together. Also thinking about whether we need a explicit tree structure to describe the request. So

[openstack-dev] Request for Freezer patch review

Hi szaher, I have updated the patch. Kindly provide the feedback as I am altogether taking the backup of instances with same name https://review.openstack.org/# /c/559665 Thanks and Regards, Vishakha __ OpenStack Development

Re: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project

+1 2018-04-19 8:21 GMT+02:00 Christian Berendt : > +1 > > > On 18. Apr 2018, at 03:51, Jeffrey Zhang > wrote: > > > > Since many of the contributors in the kolla-kubernetes project are moved > to other things. And there is no active

Re: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project

+1 > On 18. Apr 2018, at 03:51, Jeffrey Zhang wrote: > > Since many of the contributors in the kolla-kubernetes project are moved to > other things. And there is no active contributor for months. On the other > hand, there is another comparable project,

[openstack-dev] [qa] QA Office Hours 9:00 UTC is cancelled

Hi All, Today, QA Office Hours @9:00 UTC is canceled due to unavailability of members. Happy Hacking!! -- Masayuki Igawa signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage