[openstack-dev] [masakari]I submitted a patch that fixes py27 unit tests of Masakari.

Hello, I submitted a patch that fixes py27 unit tests of Masakari. https://review.openstack.org/#/c/516517/ This is a 2nd solution which we discussed in today's IRC meeting.[1] http://eavesdrop.openstack.org/meetings/masakari/2017/masakari.2017-10-31-04.00.log.html#l-54 Please check it. [1]

Re: [openstack-dev] [Openstack-operators] [skip-level-upgrades][fast-forward-upgrades] PTG summary

See you there Eric. From: Erik McCormick [mailto:emccorm...@cirrusseven.com] Sent: Monday, October 30, 2017 10:58 AM To: Matt Riedemann Cc: OpenStack Development Mailing List ; openstack-operators

Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

Excerpts from Richard.Pioso's message of 2017-10-30 23:11:31 +: > > From: Dmitry Tantsur [mailto:dtant...@redhat.com] > > > Cons: > > 1. more work for both the requirements team and the vendor teams > > Please elaborate on the additional work you envision for the vendor teams. > > > 2.

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

On Mon, Oct 30, 2017 at 6:07 PM, Brian Haley wrote: > On 10/30/2017 05:46 PM, Matthew Treinish wrote: >> >> From a quick glance at the logs my guess is that the issue is related to >> this stack trace in the l3 agent logs: >> >> >>

Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

> From: Dmitry Tantsur [mailto:dtant...@redhat.com] > Cons: > 1. more work for both the requirements team and the vendor teams Please elaborate on the additional work you envision for the vendor teams. > 2. inability to use ironic release notes to explain driver requirements > changes Where

Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

On 17-10-30 20:48:37, arkady.kanev...@dell.com wrote: > The second seem to be better suited for per driver requirement handling and > per HW type per function. > Which option is easier to handle for container per dependency for the future? > > > Thanks, > Arkady > > -Original Message-

Re: [openstack-dev] [tripleo] rh1 outage today

On 10/30/2017 05:14 PM, Ben Nemec wrote: It turns out this wasn't _quite_ resolved yet. I was still seeing some excessively long stack creation times today and it turns out one of our compute nodes had virtualization turned off. This caused all of its instances to fail and need a retry.

Re: [openstack-dev] [tripleo] rh1 outage today

It turns out this wasn't _quite_ resolved yet. I was still seeing some excessively long stack creation times today and it turns out one of our compute nodes had virtualization turned off. This caused all of its instances to fail and need a retry. Once I disabled the compute service on it

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

On 10/30/2017 05:46 PM, Matthew Treinish wrote: From a quick glance at the logs my guess is that the issue is related to this stack trace in the l3 agent logs:

[openstack-dev] Developer Mailing List Digest September 30 – October 6

Thanks to Thierry Carrez and Jeremy Stanley for summarizing this issue of the Dev Digest! Contribute to the Dev Digest by summarizing OpenStack Dev List thread: * https://etherpad.openstack.org/p/devdigest * http://lists.openstack.org/pipermail/openstack-dev/ HTML Version:

Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

On 17-10-30 20:48:37, arkady.kanev...@dell.com wrote: > The second seem to be better suited for per driver requirement handling and > per HW type per function. > Which option is easier to handle for container per dependency for the future? > > > Thanks, > Arkady > > -Original Message-

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

From a quick glance at the logs my guess is that the issue is related to this stack trace in the l3 agent logs:

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

Hi everyone, I'm looking for some help regarding an issue that we're having with the Puppet OpenStack modules, we've had very inconsistent failures in the Xenial with the following error:

[openstack-dev] [ironic] this week's priorities and subteam reports

Hi, We are glad to present this week's priorities and subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. This Week's Priorities (as of the weekly ironic meeting) 1. CI migration to

Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

The second seem to be better suited for per driver requirement handling and per HW type per function. Which option is easier to handle for container per dependency for the future? Thanks, Arkady -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Monday,

Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

Excerpts from Dmitry Tantsur's message of 2017-10-30 17:51:49 +0100: > Hi all, > > So far driver requirements [1] have been managed outside of > global-requirements. > This was mostly necessary because some dependencies were not on PyPI. This is > no > longer the case, and I'd like to

Re: [openstack-dev] [keystone][nova] Persistent application credentials

Big +1 to re-evaluating this. In my environment we have many users deploying and managing a number of different apps in different tenants. Some of our users, such as Yahoo Mail service engineers could be in up to 40 different tenants. Those service engineers may change products as their careers

Re: [openstack-dev] [ironic] Scheduling error with RamFilter ... on integrating ironic into our OpenStack Distribution

On 10/30/2017 01:37 PM, Waines, Greg wrote: Thanks Jay ... i’ll try this out and let you know. BTW ... i should have mentioned that i am currently @Newton ... and will eventually move to @PIKE Does that change anything you suggested below ?

Re: [openstack-dev] [ironic] Scheduling error with RamFilter ... on integrating ironic into our OpenStack Distribution

Thanks Jay ... i’ll try this out and let you know. BTW ... i should have mentioned that i am currently @Newton ... and will eventually move to @PIKE Does that change anything you suggested below ? Greg. From: Jay Pipes

Re: [openstack-dev] [ironic] Scheduling error with RamFilter ... on integrating ironic into our OpenStack Distribution

You need to set the node's resource_class attribute to the custom resource class you will use for that chassis/hardware type. Then you need to add a specific extra_specs key/value to a flavor to indicate that that flavor is requesting that specific hardware type: openstack flavor set

Re: [openstack-dev] [tc] [all] TC Report 43

On 11:17 Oct 25, Flavio Percoco wrote: > On 24/10/17 19:26 +0100, Chris Dent wrote: > >It's clear that anyone and everyone _could_ write their own blogs and > >syndicate to the [OpenStack planet](http://planet.openstack.org/) but > >this doesn't have the same panache and potential cadence as an >

[openstack-dev] [ironic] Scheduling error with RamFilter ... on integrating ironic into our OpenStack Distribution

Hey, We are in the process of integrating OpenStack Ironic into our own OpenStack Distribution. Still pulling all the pieces together ... have not yet got a successful ‘nova boot’ yet, so issues below could be configuration or setup issues. We have ironic node enrolled ... and corresponding

[openstack-dev] [neutron] reusable code moving to neutron-lib

Just a quick update on the neutron-lib workstream. Although there hasn't been many "neutron-lib impact" emails lately, the effort is still active. The reason for decreased email volume is that rather than just updating stadium consumers during consumption [1], all (stadium/non-stadium) consumers

[openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

Hi all, So far driver requirements [1] have been managed outside of global-requirements. This was mostly necessary because some dependencies were not on PyPI. This is no longer the case, and I'd like to consider managing them just like any other dependencies. Pros: 1. making these

[openstack-dev] [keystone] tomorrow's meeting and queens-1 retrospective

Hey all, Just a reminder that tomorrow's team meeting will be dedicated to our queens-1 retrospective. Harry and I cleared the board from the Pike retrospective [0] and it should be ready to go. Given the last retrospective took longer than an hour, we want to try and jump start the process.

Re: [openstack-dev] [EXTERNAL] Re: [TripleO] roles_data.yaml equivalent in containers

Hi Steven, I was out of the town and hence couldn’t reply to the email. I will take a look at the examples you have shared and get back with the results tomorrow. Thanks, Abhishek On 10/25/17, 2:21 PM, "Steven Hardy" wrote: On Wed, Oct 25, 2017 at 6:41 AM, Abhishek

Re: [openstack-dev] [Openstack-operators] [skip-level-upgrades][fast-forward-upgrades] PTG summary

On Oct 30, 2017 11:53 AM, "Matt Riedemann" wrote: On 9/20/2017 9:42 AM, arkady.kanev...@dell.com wrote: > Lee, > I can chair meeting in Sydney. > Thanks, > Arkady > Arkady, Are you actually moderating the forum session in Sydney because the session says Eric McCormick is

Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary

On 9/20/2017 9:42 AM, arkady.kanev...@dell.com wrote: Lee, I can chair meeting in Sydney. Thanks, Arkady Arkady, Are you actually moderating the forum session in Sydney because the session says Eric McCormick is the session moderator:

Re: [openstack-dev] [ironic] [Openstack-operators] replace node "tags" with node "traits"

Hi, Thanks for your 3 votes. Every vote counts; you've convinced me of the usefulness of having both tags and traits as separate features. I shall advocate for you all :) --ruby On Fri, Oct 27, 2017 at 5:41 AM, Vladyslav Drok wrote: > > > On Fri, Oct 27, 2017 at 12:19 AM,

Re: [openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

Sorry! A little late to the discussion with how busy I was last week. Replies/thoughts in-line with trimmed text. >> When I tried it I got this >> [ 370.704896] dracut-initqueue[387]: Warning: iscistart: Could not >> get list of targets from firmware. >> >> perhaps we could alter iscistart to

Re: [openstack-dev] [infra][all][stable] Zuul v3 changes and stable branches

Boden Russell writes: > On 10/27/17 6:35 PM, James E. Blair wrote: >> >> We're rolling out a new version of Zuul that corrects the issues, and >> the migration doc has been updated. The main things to know are: >> >> * If your project has stable branches, we recommend

Re: [openstack-dev] [devstack][zuul] About devstack plugin orders and the log to contain the running local.conf

"gong_ys2004" writes: > Hi, everyone > I am trying to migrate tacker's functional CI job into new zuul v3 framework, > but it seems: > 1. the devstack plugin order is not the one I specified in the .zuull.yaml > https://review.openstack.org/#/c/516004/4/.zuul.yaml:I

Re: [openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

On 10/30/2017 9:32 AM, Dmitry Tantsur wrote: the same bluejeans. Forever in bluejeans? -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

It seems that the new time works for the most of key people, so let's move it to tomorrow (Tue), the same time, the same bluejeans. Apologies to those who won't be able to attend, and sorry for the late notice. On 10/30/2017 03:13 PM, Jay Pipes wrote: I'd prefer to have you on the call, Dima.

Re: [openstack-dev] [ironic] [nova] traits discussion call

It's a holiday here tomorrow, but I don't have any specific plans, so I think I'll be able to make it. On 10/30/2017 03:13 PM, Jay Pipes wrote: I'd prefer to have you on the call, Dima. How about we push it back to tomorrow at the same time? Can everyone make it then? -jay On 10/30/2017

Re: [openstack-dev] [ironic] [nova] traits discussion call

I'd prefer to have you on the call, Dima. How about we push it back to tomorrow at the same time? Can everyone make it then? -jay On 10/30/2017 10:11 AM, Dmitry Tantsur wrote: Aaaand sorry again, but due to sudden errands I won't be able to attend. Please feel free to use my bluejeans room

Re: [openstack-dev] [ironic] [nova] traits discussion call

Aaaand sorry again, but due to sudden errands I won't be able to attend. Please feel free to use my bluejeans room anyway. I think my position on traits is more or less clear from previous discussions with John, Sam and Eric. 2017-10-24 18:07 GMT+02:00 Dmitry Tantsur : >

Re: [openstack-dev] [security] Security SIG

Luke Hinds wrote: > On Fri, Oct 27, 2017 at 6:08 PM, Jeremy Stanley > wrote: > >> On 2017-10-27 15:30:34 +0200 (+0200), Thierry Carrez wrote: >>> [...] >>> I think the Security project team would benefit from becoming a >>> proper SIG. >>> [...] >> I

[openstack-dev] [nova] Notification update week 44

Hi, Here is the status update / focus settings mail for w44. Bugs [Undecided] https://bugs.launchpad.net/nova/+bug/1535254 illustration of 'notify_on_state_change' are different from implementation As the behavior is unchanged in the last 5 years a patch is proposed to update the

[openstack-dev] [neutron] q-agt failed to start with ovs firevalldriver

Hi, Perhaps this is my fault but this morning I wanted to start devstack (master) with q-trunk enabled, and got this error: Oct 30 08:59:22 horizon neutron-openvswitch-agent[24556]:   File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 65, in _launch Oct 30 08:59:22 horizon

Re: [openstack-dev] [infra][all][stable] Zuul v3 changes and stable branches

On 10/27/17 6:35 PM, James E. Blair wrote: > > We're rolling out a new version of Zuul that corrects the issues, and > the migration doc has been updated. The main things to know are: > > * If your project has stable branches, we recommend backporting the Zuul > config along with all the

[openstack-dev] [Dragonflow]Weekly meeting is canceled today

Hi, Sorry for the very late notice. The weekly scheduled for today is canceled. Next one will be next week, as planned. Thanks, and sorry again, Omer. __ OpenStack Development Mailing List (not for usage questions)