[openstack-dev] Election Season, PTL January 2017

[Kendall Nelson]

Hello all!

Election season is nearly here!

Election details: https://governance.openstack.org/election/

Please read the stipulations and timelines for candidates and electorate
contained in this governance documentation.

Be aware, in the PTL elections if the program only has one candidate, that
candidate is acclaimed and there will be no poll. There will only be a poll
if there is more than one candidate stepping forward for a program's PTL
position.

There will be further announcements posted to the mailing list as action is
required from the electorate or candidates. This email is for information
purposes only.

If you have any questions which you feel affect others please reply to this
email thread. If you have any questions that you which to discuss in
private please email myself Kendall Nelson (diablo_rojo), knelson at
openstack dot org and Tristan Cacqueray (tristanC) email: tdecacqu at
redhat dot com so that we may address your concerns.

Thank you,

Kendall Nelson (diablo_rojo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

[Steven Dake (stdake)]

WFM – I’d be partly in favor of such an approach although I can’t speak for 
others.  I think we should require some larger set then 2 individuals from the 
kolla-policy-core; perhaps a majority of active reviewers for some definition 
of active reviewers.

Regards
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, December 23, 2016 at 3:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

So I agree with you that we need policy established here. What I'm
getting at - which core teams will vote on inclusion of new
deliverable? All of them? Just Kolla? This is grey area I'm referring
to. What's kolla-k8s core team's business if somebody would like to
add saltstack support? What I wouldn't want to have is to establish
new semi-tc in form of our core team that will decide what is and
isn't good orchiestration engine for Kolla. That would seriously
hinder our ability to innovate, experiment. What if we find out this
new orchiestration engine and just want to play with it? But keep it
community from start?

So let me throw an idea there, one which we should vote on:

Prep:
1. We create kolla-policy-core-team which is sum of all core teams of
kolla supported projects
2. We create list of kolla supported projects - today it's kolla,
kolla-ansible and kolla-k8s

Add new project:
1. Everyone is free to create kolla-* deliverable as long as they
follow certain documented standards (action: document these)
2. We create lightweight process to include new deliverable to Kolla,
like just 2* +2 from kolla-policy-core-team to include project like
that
3. If project gets traction, interest and is successful, we vote on
including it's core team to kolla-policy-core-team

This way it would be easy to try and fail fast to run kolla with
whatever. We need this kind of flexibility for people to innovate.

Thoughts?
Michal

On 23 December 2016 at 13:11, Steven Dake (stdake)  wrote:
> Michal,
>
> Really what I was getting at was placing in the governance repository as 
a kolla deliverable.  In days past we *always* voted on additions and removals 
of deliverables.  It doesn’t seem like a gray area to me – we have always 
followed a voting pattern for adding and removal of deliverables.  This repo 
could be added to the git openstack namespace but then not have it as a kolla 
deliverable without a vote I think; this is sort of what Fuel did with Fuel-ccp 
– that proposal is a gray area.  I found when Fuel did  that to be extremely 
odd personally ☺  I’m not sure if there is a trademark policy or something 
similar that affects the use of Kolla and OpenStack together.  I’ve included 
the [tc] in the topic so they can provide guidance on the route you suggested 
(incubation for new kolla deliverables that are not actually deliverables).
>
> I think we really don’t need the tc to intervene here though, we can just 
make new policies on our own via the typical policy voting process we have 
followed in the past.  Before we make any decisions about that though, I think 
we need a vote on the topic. ☺
>
> Regards
> -steve
>
> -Original Message-
> From: Michał Jastrzębski 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

> Date: Friday, December 23, 2016 at 10:08 AM
> To: "OpenStack Development Mailing List (not for usage questions)" 

> Subject: Re: [openstack-dev] [kolla] A new kolla-salt deliverable
>
> Hello,
>
> Ok this is grey area we haven't had proper discussion yet, I agree.
> Since we decided to have separate core teams, I personally don't
> really see *why* we should have any form of vote for projects to use
> kolla containers.
> Things change when we talk about it being kolla deliverable, but what
> exactly does that mean? They can use kolla name? Everybody can. They
> follow Kolla policies, use Kolla irc channel and have Kolla PTL to
> represent them? That's also a choice everybody can make.
>
> In the spirit of inclusiveness, I'd say keep it free and open. I would
> rather have people use kolla name, be open about using kolla
> containers and be part of our community. Maybe some sort of "free to
> add, but incubate" would be in order, but I personally think that
> would be overkill at this stage.
>
> Thoughts?
>
> Cheers Michal
>
> On 23 December 

Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

[Michał Jastrzębski]

So I agree with you that we need policy established here. What I'm
getting at - which core teams will vote on inclusion of new
deliverable? All of them? Just Kolla? This is grey area I'm referring
to. What's kolla-k8s core team's business if somebody would like to
add saltstack support? What I wouldn't want to have is to establish
new semi-tc in form of our core team that will decide what is and
isn't good orchiestration engine for Kolla. That would seriously
hinder our ability to innovate, experiment. What if we find out this
new orchiestration engine and just want to play with it? But keep it
community from start?

So let me throw an idea there, one which we should vote on:

Prep:
1. We create kolla-policy-core-team which is sum of all core teams of
kolla supported projects
2. We create list of kolla supported projects - today it's kolla,
kolla-ansible and kolla-k8s

Add new project:
1. Everyone is free to create kolla-* deliverable as long as they
follow certain documented standards (action: document these)
2. We create lightweight process to include new deliverable to Kolla,
like just 2* +2 from kolla-policy-core-team to include project like
that
3. If project gets traction, interest and is successful, we vote on
including it's core team to kolla-policy-core-team

This way it would be easy to try and fail fast to run kolla with
whatever. We need this kind of flexibility for people to innovate.

Thoughts?
Michal

On 23 December 2016 at 13:11, Steven Dake (stdake)  wrote:
> Michal,
>
> Really what I was getting at was placing in the governance repository as a 
> kolla deliverable.  In days past we *always* voted on additions and removals 
> of deliverables.  It doesn’t seem like a gray area to me – we have always 
> followed a voting pattern for adding and removal of deliverables.  This repo 
> could be added to the git openstack namespace but then not have it as a kolla 
> deliverable without a vote I think; this is sort of what Fuel did with 
> Fuel-ccp – that proposal is a gray area.  I found when Fuel did  that to be 
> extremely odd personally ☺  I’m not sure if there is a trademark policy or 
> something similar that affects the use of Kolla and OpenStack together.  I’ve 
> included the [tc] in the topic so they can provide guidance on the route you 
> suggested (incubation for new kolla deliverables that are not actually 
> deliverables).
>
> I think we really don’t need the tc to intervene here though, we can just 
> make new policies on our own via the typical policy voting process we have 
> followed in the past.  Before we make any decisions about that though, I 
> think we need a vote on the topic. ☺
>
> Regards
> -steve
>
> -Original Message-
> From: Michał Jastrzębski 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: Friday, December 23, 2016 at 10:08 AM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Subject: Re: [openstack-dev] [kolla] A new kolla-salt deliverable
>
> Hello,
>
> Ok this is grey area we haven't had proper discussion yet, I agree.
> Since we decided to have separate core teams, I personally don't
> really see *why* we should have any form of vote for projects to use
> kolla containers.
> Things change when we talk about it being kolla deliverable, but what
> exactly does that mean? They can use kolla name? Everybody can. They
> follow Kolla policies, use Kolla irc channel and have Kolla PTL to
> represent them? That's also a choice everybody can make.
>
> In the spirit of inclusiveness, I'd say keep it free and open. I would
> rather have people use kolla name, be open about using kolla
> containers and be part of our community. Maybe some sort of "free to
> add, but incubate" would be in order, but I personally think that
> would be overkill at this stage.
>
> Thoughts?
>
> Cheers Michal
>
> On 23 December 2016 at 05:34, Steven Dake (stdake)  
> wrote:
> > Michal,
> >
> >
> >
> > I was thinking about kolla-salt and our Wednesday team meeting and the
> > declaration you made about how it should be done.  I personally feel it 
> is
> > mandatory we hold a vote of the core review teams to add a new 
> deliverable.
> > We have voted on the addition of every deliverable we have ever added to
> > kolla including application initially to the big tent.  I’m in favor of 
> the
> > idea of kolla-salt and it would have my +1 vote.  I am not attempting to
> > block the addition.  It’s more a matter of policies we have established 
> over
> > the last several years.  We have also voted to retire deliverables from 
> the
> > Kolla project as well (kolla-mesos and the cli).
> >
> >
> >
> > This was easier when there was one core review team.  Perhaps a 
> 

Re: [openstack-dev] [all] Using \ for multiline statements

[John Villalovos]

On Fri, Dec 23, 2016 at 1:11 PM, Monty Taylor  wrote:

> I think this is the most important point. We have automated style tools.
> Humans should not be doing code review on code style. Humans should be
> doing code review on logic and intent and whether a design is a good
> idea or whether their colleague may have missed an error case or what
> have you.
>
> We have tools for enforcing things like tests running and code style
> conforming. Let the tools do their job so the humans can focus on being
> human.
>
>
I'll somewhat disagree. If code style impacts code readability then I think
it is useful to review that. I don't want unreadable code to land because
the automated style checkers don't complain. Basically use common sense.

This passes code style checks:
if 'f'\
'e'\
'e'\
'l'\
'i'\
'n'\
'g'\
== \
'feeling':
print("hello")
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

[Steven Dake (stdake)]

Michal,

Really what I was getting at was placing in the governance repository as a 
kolla deliverable.  In days past we *always* voted on additions and removals of 
deliverables.  It doesn’t seem like a gray area to me – we have always followed 
a voting pattern for adding and removal of deliverables.  This repo could be 
added to the git openstack namespace but then not have it as a kolla 
deliverable without a vote I think; this is sort of what Fuel did with Fuel-ccp 
– that proposal is a gray area.  I found when Fuel did  that to be extremely 
odd personally ☺  I’m not sure if there is a trademark policy or something 
similar that affects the use of Kolla and OpenStack together.  I’ve included 
the [tc] in the topic so they can provide guidance on the route you suggested 
(incubation for new kolla deliverables that are not actually deliverables).

I think we really don’t need the tc to intervene here though, we can just make 
new policies on our own via the typical policy voting process we have followed 
in the past.  Before we make any decisions about that though, I think we need a 
vote on the topic. ☺

Regards
-steve

-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, December 23, 2016 at 10:08 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] A new kolla-salt deliverable

Hello,

Ok this is grey area we haven't had proper discussion yet, I agree.
Since we decided to have separate core teams, I personally don't
really see *why* we should have any form of vote for projects to use
kolla containers.
Things change when we talk about it being kolla deliverable, but what
exactly does that mean? They can use kolla name? Everybody can. They
follow Kolla policies, use Kolla irc channel and have Kolla PTL to
represent them? That's also a choice everybody can make.

In the spirit of inclusiveness, I'd say keep it free and open. I would
rather have people use kolla name, be open about using kolla
containers and be part of our community. Maybe some sort of "free to
add, but incubate" would be in order, but I personally think that
would be overkill at this stage.

Thoughts?

Cheers Michal

On 23 December 2016 at 05:34, Steven Dake (stdake)  wrote:
> Michal,
>
>
>
> I was thinking about kolla-salt and our Wednesday team meeting and the
> declaration you made about how it should be done.  I personally feel it is
> mandatory we hold a vote of the core review teams to add a new 
deliverable.
> We have voted on the addition of every deliverable we have ever added to
> kolla including application initially to the big tent.  I’m in favor of 
the
> idea of kolla-salt and it would have my +1 vote.  I am not attempting to
> block the addition.  It’s more a matter of policies we have established 
over
> the last several years.  We have also voted to retire deliverables from 
the
> Kolla project as well (kolla-mesos and the cli).
>
>
>
> This was easier when there was one core review team.  Perhaps a solution 
to
> that problem is to make a global core team in gerrit which includes 
everyone
> just for policy decisions (such as adding a deliverable).  Another option 
to
> count whether consensus was reached is to count the core reviewers in each
> deliverable, divide by two, and determine if consensus is reached.
>
>
>
> If we don’t hold a vote, it looks like a BDFL model that PTLs don’t 
operate
> under.  Rather PTLs operate under a service model.
>
>
>
> Regards
>
> -steve
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Using \ for multiline statements

[Monty Taylor]

On 12/22/2016 07:42 PM, Ian Cordasco wrote:
> On Thu, Dec 22, 2016 at 6:02 PM, Sean McGinnis  wrote:
>>>
>>> By the way, can we finally all agree that commit message titles need to be a
>>> proper ('merican) English grammatically correct sentence that begins with a
>>> capital letter and ends with a period. And flavor is flavor, it's not
>>> flavour.
>>>
>>> Happy holidays.
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>
>> Hah, now you're just trying to start the flames! :D
> 
> In my opinion, the Queen's English is imperially better... or is it
> empirically? =P
> 
> As a side note, I could have sworn I remembered pep8/pycodestyle
> warning on using backslashes instead of ()s but I seem to have been
> wrong. All it warns about is using a backslash inside parentheses
> because it's redundant.
> 
> As a maintainer of pycodestyle, I'd be happy to add one, especially
> since the PEP-0008 document's preferred way is ()s [1]. That said,
> it's possible that check was removed at some point and I'm just too
> tired to do the archaeology for it. (It also might have been buggy at
> the time.)
> 
> Either way, -1'ing over style issues is silly if the tool allows it
> (or as is usually the case in OpenStack, is configured to allow it).
> At that point it's subjective and a bit of a waste of people's time to
> argue over it. From a perspective of personal preference, I prefer ()s
> but that's just my $0.02.
> 
> [1]: https://www.python.org/dev/peps/pep-0008/#maximum-line-length
> 


I think this is the most important point. We have automated style tools.
Humans should not be doing code review on code style. Humans should be
doing code review on logic and intent and whether a design is a good
idea or whether their colleague may have missed an error case or what
have you.

We have tools for enforcing things like tests running and code style
conforming. Let the tools do their job so the humans can focus on being
human.

Monty

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Collaboration between kolla and Helm upstream

[Michał Jastrzębski]

Yes, thanks Steve.

I already sent Lachlan this link, I hope recording will appear there:)

Brandon, thank you for that!

Cheers,
Michal

On 23 December 2016 at 08:23, Steven Dake (stdake)  wrote:
> Hey folks,
>
>
>
> Brandon Jozsa was kind enough to get some collaboration going between the
> OpenStack Kolla community and the Helm community within CNCF.  My hope out
> of this effort is to build bridges between the OpenStack foundation and CNCF
> hosted by the Linux Foundation.  We are starting small, by using common
> tools available in each foundation that are inclusive and allow, for
> example, China – which is likely 1/4th of Kolla’s contributor base and
> possibly a larger number of consumers of Kolla’s work product to participate
> by not using tools that are unavailable in China.
>
>
>
> The start of this work is here:
>
> https://etherpad.openstack.org/p/openstack-helm
>
>
>
> Some folks did hold a meeting Wednesday with a few folks from Helm.  The
> meeting was recorded but not yet in the Etherpad.  This meeting doesn’t
> violate the 4 opens because we were operating within Helm’s upstream
> processes which include the use of zoom.us, not google.com.  That said, Helm
> seems receptive and warm to the idea of working within the 4 Opens OpenStack
> operates under.  I expect Michal will post the meeting minutes and a
> recording of the video when it is available.
>
>
>
> I’d also invite those folks interested in crossing the bridge to join the
> #helm channel on slack at http://kubernetes.slack.io (iirc). If that is
> incorrect, I’m sure someone can follow up with the correct location for
> slack.
>
>
>
> Cheers and happy holidays to all that have em J
>
> -steve
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [freezer] No IRC meeting next week

[Mathieu, Pierre-Arthur]

Hi everyone,

There will be no Freezer IRC meeting next week (29/12) because of the holidays. 
Next meeting will be in 2017 (06/01).

I hope you all have very good holidays.

Kind Regards,
Pierre
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] neutron-server high CPU and RAM load when updating DHCP ports

[Mike Dorman]

We noticed an issue in one of our larger clouds (~700 hypervisors and ovs 
agents) where (Liberty) neutron-server CPU and RAM load would spike up quite a 
bit whenever a DHCP agent port was updated.  So much load that processes were 
getting OOM killed on our API servers, and so many queries were going to the 
database that it was affecting performance of other APIs (sharing the same 
database cluster.)

Kris Lindgren determined what was happening: any time a DHCP port is changed, 
Neutron forces a complete refresh of all security group filter rules for all 
ports on the same network as the DHCP port.  We run only provider networks 
which VMs plug directly into, and our largest network has several thousand 
ports.  This was generating an avalanche of RPCs from the OVS agents, thus 
loading up neutron-server with a lot of work.

We only use DHCP has a backup network configuration mechanism in case something 
goes wrong with config-drive, so we are not huge users of it.  But DHCP agents 
are being scheduled and removed often enough, and our networks contain a large 
enough number of ports, that this has begun affecting us quite a bit.

Kevin Benton suggested a minor patch [1] to disable the blanket refresh of 
security group filters on DHCP port changes.  I tested it out in our staging 
environment and can confirm that:

-  Security group filters are indeed not refreshed on DHCP port changes

-  iptables rules generated for regular VM ports still include the 
generic rules to allow the DHCP ports 67 and 68 regardless of the presence of a 
DHCP agent on the network or not.  (This covers the scenario where VM ports are 
created while there are no DHCP agents, and a DHCP agent is added later.)

I think there are some plans to deprecate this behavior.  As far as I know, it 
still exists in master neutron.  I’m happy to put the trivial patch up for 
review if people think this is a useful change to Neutron.

We are a bit of an edge case with such large number of ports per network.  We 
are also considering disabling DHCP altogether since it is really not used.  
But, wanted to share the experience with others in case people are running into 
the same issue.

Thanks,
Mike

[1] https://gist.github.com/misterdorm/37a8997aed43081bac8d12c7f101853b
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] A new kolla-salt deliverable

[Michał Jastrzębski]

Hello,

Ok this is grey area we haven't had proper discussion yet, I agree.
Since we decided to have separate core teams, I personally don't
really see *why* we should have any form of vote for projects to use
kolla containers.
Things change when we talk about it being kolla deliverable, but what
exactly does that mean? They can use kolla name? Everybody can. They
follow Kolla policies, use Kolla irc channel and have Kolla PTL to
represent them? That's also a choice everybody can make.

In the spirit of inclusiveness, I'd say keep it free and open. I would
rather have people use kolla name, be open about using kolla
containers and be part of our community. Maybe some sort of "free to
add, but incubate" would be in order, but I personally think that
would be overkill at this stage.

Thoughts?

Cheers Michal

On 23 December 2016 at 05:34, Steven Dake (stdake)  wrote:
> Michal,
>
>
>
> I was thinking about kolla-salt and our Wednesday team meeting and the
> declaration you made about how it should be done.  I personally feel it is
> mandatory we hold a vote of the core review teams to add a new deliverable.
> We have voted on the addition of every deliverable we have ever added to
> kolla including application initially to the big tent.  I’m in favor of the
> idea of kolla-salt and it would have my +1 vote.  I am not attempting to
> block the addition.  It’s more a matter of policies we have established over
> the last several years.  We have also voted to retire deliverables from the
> Kolla project as well (kolla-mesos and the cli).
>
>
>
> This was easier when there was one core review team.  Perhaps a solution to
> that problem is to make a global core team in gerrit which includes everyone
> just for policy decisions (such as adding a deliverable).  Another option to
> count whether consensus was reached is to count the core reviewers in each
> deliverable, divide by two, and determine if consensus is reached.
>
>
>
> If we don’t hold a vote, it looks like a BDFL model that PTLs don’t operate
> under.  Rather PTLs operate under a service model.
>
>
>
> Regards
>
> -steve
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Collaboration between kolla and Helm upstream

[Steven Dake (stdake)]

Hey folks,

Brandon Jozsa was kind enough to get some collaboration going between the 
OpenStack Kolla community and the Helm community within CNCF.  My hope out of 
this effort is to build bridges between the OpenStack foundation and CNCF 
hosted by the Linux Foundation.  We are starting small, by using common tools 
available in each foundation that are inclusive and allow, for example, China – 
which is likely 1/4th of Kolla’s contributor base and possibly a larger number 
of consumers of Kolla’s work product to participate by not using tools that are 
unavailable in China.

The start of this work is here:
https://etherpad.openstack.org/p/openstack-helm

Some folks did hold a meeting Wednesday with a few folks from Helm.  The 
meeting was recorded but not yet in the Etherpad.  This meeting doesn’t violate 
the 4 opens because we were operating within Helm’s upstream processes which 
include the use of zoom.us, not google.com.  That said, Helm seems receptive 
and warm to the idea of working within the 4 Opens OpenStack operates under.  I 
expect Michal will post the meeting minutes and a recording of the video when 
it is available.

I’d also invite those folks interested in crossing the bridge to join the #helm 
channel on slack at http://kubernetes.slack.io (iirc). If that is incorrect, 
I’m sure someone can follow up with the correct location for slack.

Cheers and happy holidays to all that have em ☺
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Andrey Kurilin]

Proposed revert: https://review.openstack.org/414621

On Fri, Dec 23, 2016 at 4:56 PM, Valeriy Ponomaryov <
vponomar...@mirantis.com> wrote:

> Bug report for problem Andrey and Goutham mentioned is here:
> https://bugs.launchpad.net/python-openstackclient/+bug/1652317
>
> Valeriy
>
> On Fri, Dec 23, 2016 at 4:30 PM, Ravi, Goutham <
> goutham.pachar...@netapp.com> wrote:
>
>> Yes. It’s affecting manila tests as well:
>>
>>
>>
>> Patch: https://review.openstack.org/#/c/414286/
>>
>> Failure: http://logs.openstack.org/86/414286/2/gate/gate-manila-tempe
>> st-minimal-dsvm-lvm-ubuntu-xenial/a79dc50/logs/devstacklo
>> g.txt.gz#_2016-12-23_13_26_11_470
>>
>>
>>
>> Version of OSC: http://logs.openstack.org/86/4
>> 14286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu-
>> xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_04_456 (1.2.0)
>>
>> Version of OpenStackSDK: http://logs.openstack.org/86/4
>> 14286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu-
>> xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_53_450 (0.9.11)
>>
>>
>>
>>
>>
>> *From: *Steve Martinelli 
>> *Reply-To: *"OpenStack Development Mailing List (not for usage
>> questions)" 
>> *Date: *Friday, December 23, 2016 at 9:16 AM
>> *To: *"OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> *Subject: *Re: [openstack-dev] [all] Intermittent gate failures across
>> multiple projects
>>
>>
>>
>> Those look like they were introduced in the latest release, and related
>> to the OpenStackSDK refactoring that hit openstackclient networking
>> commands. We actually released the new version because folks were hitting
>> similar errors, but for more often used commands (like listing security
>> groups or IPs.)
>>
>>
>>
>> Is the latest OSC affecting a gate for you?
>>
>>
>>
>>
>>
>> On Dec 23, 2016 8:33 AM, "Andrey Kurilin"  wrote:
>>
>> Hi eveyone!
>>
>> I found two more failures related to openstackclient which had appeared
>> recently:
>>
>> - "HttpException: Bad Request" while trying to set quotas via
>> openstackclient
>>   http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm-
>> neutron-existing-users-rally/36518f0/console.html#_2016-12-
>> 23_11_31_55_070176
>> - "'SecurityGroup' object has no attribute 'keys'" while creating new
>> security group
>>   http://logs.openstack.org/64/355264/5/check/gate-manila-temp
>> est-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstac
>> klog.txt.gz#_2016-12-23_12_53_44_213
>>
>> State of latest openstackclient doesn't look good to me :(
>>
>>
>>
>>
>>
>> On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds 
>> wrote:
>>
>> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
>> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
>> > pushed today to PyPi
>> >
>> > Thanks to everyone working together on this issue in #openstack-infra !
>> >
>> > A patch is proposed to blacklist that release and we are testing it now.
>>
>> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
>> feel
>> free to recheck without swamping our CI.  I believe that eleastic-recheck
>> should
>> tell you if you match this case.
>>
>> Thanks to those that found the root cause and worked on the fix
>>
>> Yours Tony.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Andrey Kurilin.
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com
> vponomar...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Valeriy Ponomaryov]

Bug report for problem Andrey and Goutham mentioned is here:
https://bugs.launchpad.net/python-openstackclient/+bug/1652317

Valeriy

On Fri, Dec 23, 2016 at 4:30 PM, Ravi, Goutham  wrote:

> Yes. It’s affecting manila tests as well:
>
>
>
> Patch: https://review.openstack.org/#/c/414286/
>
> Failure: http://logs.openstack.org/86/414286/2/gate/gate-manila-
> tempest-minimal-dsvm-lvm-ubuntu-xenial/a79dc50/logs/
> devstacklog.txt.gz#_2016-12-23_13_26_11_470
>
>
>
> Version of OSC: http://logs.openstack.org/86/414286/2/gate/gate-manila-
> tempest-minimal-dsvm-lvm-ubuntu-xenial/a79dc50/logs/
> devstacklog.txt.gz#_2016-12-23_13_19_04_456 (1.2.0)
>
> Version of OpenStackSDK: http://logs.openstack.org/86/
> 414286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-
> ubuntu-xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_53_450
> (0.9.11)
>
>
>
>
>
> *From: *Steve Martinelli 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, December 23, 2016 at 9:16 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [all] Intermittent gate failures across
> multiple projects
>
>
>
> Those look like they were introduced in the latest release, and related to
> the OpenStackSDK refactoring that hit openstackclient networking commands.
> We actually released the new version because folks were hitting similar
> errors, but for more often used commands (like listing security groups or
> IPs.)
>
>
>
> Is the latest OSC affecting a gate for you?
>
>
>
>
>
> On Dec 23, 2016 8:33 AM, "Andrey Kurilin"  wrote:
>
> Hi eveyone!
>
> I found two more failures related to openstackclient which had appeared
> recently:
>
> - "HttpException: Bad Request" while trying to set quotas via
> openstackclient
>   http://logs.openstack.org/43/414543/1/check/gate-rally-
> dsvm-neutron-existing-users-rally/36518f0/console.html#_
> 2016-12-23_11_31_55_070176
> - "'SecurityGroup' object has no attribute 'keys'" while creating new
> security group
>   http://logs.openstack.org/64/355264/5/check/gate-manila-
> tempest-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/
> devstacklog.txt.gz#_2016-12-23_12_53_44_213
>
> State of latest openstackclient doesn't look good to me :(
>
>
>
>
>
> On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds 
> wrote:
>
> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
> > pushed today to PyPi
> >
> > Thanks to everyone working together on this issue in #openstack-infra !
> >
> > A patch is proposed to blacklist that release and we are testing it now.
>
> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
> feel
> free to recheck without swamping our CI.  I believe that eleastic-recheck
> should
> tell you if you match this case.
>
> Thanks to those that found the root cause and worked on the fix
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
>
> Best regards,
> Andrey Kurilin.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Andrey Kurilin]

Hi Steve,

It looks like latest OSC is not the root of issue - the failure appeared
several ours ago(5?!) and
upper-constrains for OSC was updated several days ago(lxml was blocked more
than 5 hours ago).

Possibly, update of openstacksdk(https://review.openstack.org/#/c/414366/ )
causes new issues.

On Fri, Dec 23, 2016 at 4:16 PM, Steve Martinelli 
wrote:

> Those look like they were introduced in the latest release, and related to
> the OpenStackSDK refactoring that hit openstackclient networking commands.
> We actually released the new version because folks were hitting similar
> errors, but for more often used commands (like listing security groups or
> IPs.)
>
> Is the latest OSC affecting a gate for you?
>
>
> On Dec 23, 2016 8:33 AM, "Andrey Kurilin"  wrote:
>
> Hi eveyone!
>
> I found two more failures related to openstackclient which had appeared
> recently:
>
> - "HttpException: Bad Request" while trying to set quotas via
> openstackclient
>   http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm-
> neutron-existing-users-rally/36518f0/console.html#_2016-12-
> 23_11_31_55_070176
> - "'SecurityGroup' object has no attribute 'keys'" while creating new
> security group
>   http://logs.openstack.org/64/355264/5/check/gate-manila-temp
> est-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstac
> klog.txt.gz#_2016-12-23_12_53_44_213
>
> State of latest openstackclient doesn't look good to me :(
>
>
> On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds 
> wrote:
>
>> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
>> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
>> > pushed today to PyPi
>> >
>> > Thanks to everyone working together on this issue in #openstack-infra !
>> >
>> > A patch is proposed to blacklist that release and we are testing it now.
>>
>> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
>> feel
>> free to recheck without swamping our CI.  I believe that eleastic-recheck
>> should
>> tell you if you match this case.
>>
>> Thanks to those that found the root cause and worked on the fix
>>
>> Yours Tony.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Ravi, Goutham]

Yes. It’s affecting manila tests as well:

Patch: https://review.openstack.org/#/c/414286/
Failure: 
http://logs.openstack.org/86/414286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu-xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_26_11_470

Version of OSC: 
http://logs.openstack.org/86/414286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu-xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_04_456
 (1.2.0)
Version of OpenStackSDK: 
http://logs.openstack.org/86/414286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu-xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_53_450
 (0.9.11)


From: Steve Martinelli 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, December 23, 2016 at 9:16 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [all] Intermittent gate failures across multiple 
projects

Those look like they were introduced in the latest release, and related to the 
OpenStackSDK refactoring that hit openstackclient networking commands. We 
actually released the new version because folks were hitting similar errors, 
but for more often used commands (like listing security groups or IPs.)

Is the latest OSC affecting a gate for you?


On Dec 23, 2016 8:33 AM, "Andrey Kurilin" 
> wrote:
Hi eveyone!
I found two more failures related to openstackclient which had appeared 
recently:

- "HttpException: Bad Request" while trying to set quotas via openstackclient
  
http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm-neutron-existing-users-rally/36518f0/console.html#_2016-12-23_11_31_55_070176
- "'SecurityGroup' object has no attribute 'keys'" while creating new security 
group
  
http://logs.openstack.org/64/355264/5/check/gate-manila-tempest-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstacklog.txt.gz#_2016-12-23_12_53_44_213
State of latest openstackclient doesn't look good to me :(


On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds 
> wrote:
On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
> We believe the error is caused by a bad wheel for lxml 3.7.0 that was
> pushed today to PyPi
>
> Thanks to everyone working together on this issue in #openstack-infra !
>
> A patch is proposed to blacklist that release and we are testing it now.
The fix is now merged so if you're jobs failed with 'Illegal Instruction' feel
free to recheck without swamping our CI.  I believe that eleastic-recheck should
tell you if you match this case.

Thanks to those that found the root cause and worked on the fix

Yours Tony.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best regards,
Andrey Kurilin.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Adding a LateServices ResourceChain

[Steven Hardy]

On Thu, Dec 22, 2016 at 02:02:12PM -0500, Lars Kellogg-Stedman wrote:
> I've been working along with a few others on some "opstools"
> composable services for TripleO: that is, services that provide
> things like centralized logging, performance monitoring, or
> availability/health monitoring.
> 
> We've been running into a persistent problem with TripleO's
> architecture: our services in many cases need configuration
> information to be provided by other services in the stack, but there's
> no way to introspect this data from inside a composable service
> template.  This has led to some rather messy and invasive changes to
> things like puppet/services/services.yaml.
> 
> In https://review.openstack.org/#/c/413748/, I've proposed the
> addition of a secondary chain of services called LateServiceChain.
> This is, like the existing ServiceChain resource, just a Heat
> ResourceChain.  Unlike the existing ServiceChain, it receives an
> additional "RoleData" parameter that contains the role_data outputs
> from all the services realized in ServiceChain.

I commented on the bug, I'm not sure about this as it seems to overlap with
our service_config_settings interface, which IIRC landed slightly after
your previous patches for opstools things, and potentially provides a
cleaner way to approach this.

We originally added this because there was a need to wire configuration
data from any node to the nodes running e.g keystone, but it seems like the
use-case you're describing is very similar?

> This permits composable services in the LateServices chain to access
> per-service configuration information provided by the other services,
> leading to much cleaner implementations of these auxiliary services.
> 
> I am attempting to use this right now for a collectd composable
> service implementation, but this model would ultimately allow us to
> remove several of the changes made in services.yaml to support Sensu
> and Fluentd and put them back into the appropriate composable service
> templates.

Perhaps you can point to some examples of this usage, then we can compare
with the service_config_settings approach?

I suspect the main difference is you need to append data for each service
to e.g the collectd configuration?

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Steve Martinelli]

Those look like they were introduced in the latest release, and related to
the OpenStackSDK refactoring that hit openstackclient networking commands.
We actually released the new version because folks were hitting similar
errors, but for more often used commands (like listing security groups or
IPs.)

Is the latest OSC affecting a gate for you?


On Dec 23, 2016 8:33 AM, "Andrey Kurilin"  wrote:

Hi eveyone!

I found two more failures related to openstackclient which had appeared
recently:

- "HttpException: Bad Request" while trying to set quotas via
openstackclient
  http://logs.openstack.org/43/414543/1/check/gate-rally-
dsvm-neutron-existing-users-rally/36518f0/console.html#_
2016-12-23_11_31_55_070176
- "'SecurityGroup' object has no attribute 'keys'" while creating new
security group
  http://logs.openstack.org/64/355264/5/check/gate-manila-
tempest-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/
devstacklog.txt.gz#_2016-12-23_12_53_44_213

State of latest openstackclient doesn't look good to me :(


On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds 
wrote:

> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
> > pushed today to PyPi
> >
> > Thanks to everyone working together on this issue in #openstack-infra !
> >
> > A patch is proposed to blacklist that release and we are testing it now.
>
> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
> feel
> free to recheck without swamping our CI.  I believe that eleastic-recheck
> should
> tell you if you match this case.
>
> Thanks to those that found the root cause and worked on the fix
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Issues with libvirt transition 1.2.7 -> 2.0.0 (CentOS 7.3)

[Neil Jerram]

On Fri, Dec 23, 2016 at 1:37 PM Steve Gordon  wrote:

> - Original Message -
> > From: "Neil Jerram" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >
> > I appreciate that even libvirt 2.0.0 will be ancient history by now, to
> its
> > developers, but I am seeing further issues that look associated with the
> > recent CentOS 7 transition from libvirt 1.2.7 to libvirt 2.0.0, and would
> > appreciate any comments on them that people may have.  I believe these
> > issues are independent of those that have already been discussed on other
> > threads.
> >
> > First, this traceback in nova-compute.log:
> >
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> > 2156, in _build_resources
> > yield resources
> >   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> > 2009, in _build_and_run_instance
> > block_device_info=block_device_info)
> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
> line
> > 2534, in spawn
> > block_device_info=block_device_info)
> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
> line
> > 4620, in _create_domain_and_network
> > xml, pause=pause, power_on=power_on)
> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
> line
> > 4550, in _create_domain
> > guest.launch(pause=pause)
> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py",
> line
> > 142, in launch
> > self._encoded_xml, errors='ignore')
> >   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
> 195,
> > in __exit__
> > six.reraise(self.type_, self.value, self.tb)
> >   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py",
> line
> > 137, in launch
> > return self._domain.createWithFlags(flags)
> >   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in
> > doit
> > result = proxy_call(self._autowrap, f, *args, **kwargs)
> >   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in
> > proxy_call
> > rv = execute(f, *args, **kwargs)
> >   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in
> > execute
> > six.reraise(c, e, tb)
> >   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in
> > tworker
> > rv = meth(*args, **kwargs)
> >   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1065, in
> > createWithFlags
> > if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
> failed',
> > dom=self)
> > libvirtError: Cannot find '' in path: No such file or directory
> >
> > which I believe is caused by the empty path attribute in this part of the
> > XML:
> >
> > 
> >   
> >   
> >   
> >   
> >   
> >> function='0x0'/>
> > 
> >
> > which is in turn caused, I think, by
> >
> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L61
> >
> > Is it plausible that libvirt 1.2.7 would have avoided trying to invoke a
> > script with an empty path, whereas libvirt 2.0.0 does not?
>
> It seems someone filed this as
> https://bugs.launchpad.net/nova/+bug/1649527 from a Nova POV. The Libvirt
> folks helped me narrow this down to this commit being the first one that
> would have exhibited this behavior:
>
>
> https://libvirt.org/git/?p=libvirt.git;a=commit;h=9c17d665fdc5f0ab74500a14c30627014c11b2c0
>
> Michal Privoznik provided some additional context:
>
> "Previously, libvirt merely just appended 'script=' onto qemu cmd line
> according to what  contained letting qemu execute the
> script. That was flawed from security POV (we don't want qemu to be
> allowed to execute anything) thus libvirt is executing the script now.
> However, we obviously forgot about this corner case."
>
> This actually apparently first appeared in v1.3.3-rc1~71, so it's not new
> in Libvirt 2.0.0 *but*:
>
> * The Ubuntu-based gate is apparently running v1.3.1 at the moment.
> * The RHEL 7.2 and aligned CentOS included v1.2.17.
>
> This is at least partially why this was not seen until recently,


Thanks for pinning all of that down!


> but it also seems like it might be specific to certain guest networking
> setup.


Yes, there are only a few networking backends that use , I believe; mine is networking-calico, which uses
VIF_TYPE_TAP; I think (from code reading) that the others are 'ivs',
'iovisor', 'midonet' and 'vrouter'.  (Although another thing to keep in
mind here is that os-vif should soon be taking over this area of code - so
any fixes in nova/virt/libvirt may also be needed in os-vif.)


You mentioned you have multiple interfaces attached to the guest, which VIF
> types and associated Neutron plugins are you using?
>

Note that the multiple interfaces issue is an additional one.  The empty
path issue causes all VIF_TYPE_TAP tests to fail, whether with just 

Re: [openstack-dev] [all] Using \ for multiline statements

[Radomir Dopieralski]

There is a problem with the use of backslash at the end of the line, where
if you also put a space after it, it no longer does what it seemingly
should. Together with the fact, that you can achieve the same thing using
() in pretty much all instances (it used to not be true for imports, but
that has been fixed), it suggests that it should be avoided. However, it
does help to format certain Java-esque constructs (mostly with mox) in a
more readable way, so sometimes it's justified.

On Fri, Dec 23, 2016 at 12:28 AM, Sean McGinnis 
wrote:

> Looking for input from everyone, particularly those with more in-depth
> Python knowledge.
>
> In Cinder for some time we have been trying to enforce using () or
> reformatting code to avoid using \ to have statements span multiple
> lines. I'm not sure when this actually started, but I think it may
> be one of those things where someone got a review disagreement, so
> then that person started downvoting on it, then the next person, etc.
>
> I've seen some allusions to the use of \ having some issues, but I
> can't find any concrete examples where this can cause problems. I do
> seem to remember trying to write a hacking check or a code parsing
> tool to do something that choked on these, but it's long enough ago
> that I don't remember the details, and I could very well be mixing
> that up with something else.
>
> So my question is - is there a technical reason for enforcing this
> rule, or is this just a bad downvote that's gotten out of control?
>
> Thanks!
>
> Sean
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Issues with libvirt transition 1.2.7 -> 2.0.0 (CentOS 7.3)

[Steve Gordon]

- Original Message -
> From: "Neil Jerram" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 
> I appreciate that even libvirt 2.0.0 will be ancient history by now, to its
> developers, but I am seeing further issues that look associated with the
> recent CentOS 7 transition from libvirt 1.2.7 to libvirt 2.0.0, and would
> appreciate any comments on them that people may have.  I believe these
> issues are independent of those that have already been discussed on other
> threads.
> 
> First, this traceback in nova-compute.log:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> 2156, in _build_resources
> yield resources
>   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> 2009, in _build_and_run_instance
> block_device_info=block_device_info)
>   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 2534, in spawn
> block_device_info=block_device_info)
>   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 4620, in _create_domain_and_network
> xml, pause=pause, power_on=power_on)
>   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 4550, in _create_domain
> guest.launch(pause=pause)
>   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line
> 142, in launch
> self._encoded_xml, errors='ignore')
>   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 195,
> in __exit__
> six.reraise(self.type_, self.value, self.tb)
>   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line
> 137, in launch
> return self._domain.createWithFlags(flags)
>   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in
> doit
> result = proxy_call(self._autowrap, f, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in
> proxy_call
> rv = execute(f, *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in
> execute
> six.reraise(c, e, tb)
>   File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in
> tworker
> rv = meth(*args, **kwargs)
>   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1065, in
> createWithFlags
> if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed',
> dom=self)
> libvirtError: Cannot find '' in path: No such file or directory
> 
> which I believe is caused by the empty path attribute in this part of the
> XML:
> 
> 
>   
>   
>   
>   
>   
>function='0x0'/>
> 
> 
> which is in turn caused, I think, by
> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L61
> 
> Is it plausible that libvirt 1.2.7 would have avoided trying to invoke a
> script with an empty path, whereas libvirt 2.0.0 does not?

It seems someone filed this as https://bugs.launchpad.net/nova/+bug/1649527 
from a Nova POV. The Libvirt folks helped me narrow this down to this commit 
being the first one that would have exhibited this behavior:


https://libvirt.org/git/?p=libvirt.git;a=commit;h=9c17d665fdc5f0ab74500a14c30627014c11b2c0

Michal Privoznik provided some additional context:

"Previously, libvirt merely just appended 'script=' onto qemu cmd line
according to what  contained letting qemu execute the
script. That was flawed from security POV (we don't want qemu to be
allowed to execute anything) thus libvirt is executing the script now.
However, we obviously forgot about this corner case."

This actually apparently first appeared in v1.3.3-rc1~71, so it's not new in 
Libvirt 2.0.0 *but*:

* The Ubuntu-based gate is apparently running v1.3.1 at the moment.
* The RHEL 7.2 and aligned CentOS included v1.2.17.

This is at least partially why this was not seen until recently, but it also 
seems like it might be specific to certain guest networking setup. You 
mentioned you have multiple interfaces attached to the guest, which VIF types 
and associated Neutron plugins are you using?

Thanks,

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] A new kolla-salt deliverable

[Steven Dake (stdake)]

Michal,

I was thinking about kolla-salt and our Wednesday team meeting and the 
declaration you made about how it should be done.  I personally feel it is 
mandatory we hold a vote of the core review teams to add a new deliverable.  We 
have voted on the addition of every deliverable we have ever added to kolla 
including application initially to the big tent.  I’m in favor of the idea of 
kolla-salt and it would have my +1 vote.  I am not attempting to block the 
addition.  It’s more a matter of policies we have established over the last 
several years.  We have also voted to retire deliverables from the Kolla 
project as well (kolla-mesos and the cli).

This was easier when there was one core review team.  Perhaps a solution to 
that problem is to make a global core team in gerrit which includes everyone 
just for policy decisions (such as adding a deliverable).  Another option to 
count whether consensus was reached is to count the core reviewers in each 
deliverable, divide by two, and determine if consensus is reached.

If we don’t hold a vote, it looks like a BDFL model that PTLs don’t operate 
under.  Rather PTLs operate under a service model.

Regards
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Andrey Kurilin]

Hi eveyone!

I found two more failures related to openstackclient which had appeared
recently:

- "HttpException: Bad Request" while trying to set quotas via
openstackclient

http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm-neutron-existing-users-rally/36518f0/console.html#_2016-12-23_11_31_55_070176
- "'SecurityGroup' object has no attribute 'keys'" while creating new
security group

http://logs.openstack.org/64/355264/5/check/gate-manila-tempest-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstacklog.txt.gz#_2016-12-23_12_53_44_213

State of latest openstackclient doesn't look good to me :(


On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds 
wrote:

> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
> > pushed today to PyPi
> >
> > Thanks to everyone working together on this issue in #openstack-infra !
> >
> > A patch is proposed to blacklist that release and we are testing it now.
>
> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
> feel
> free to recheck without swamping our CI.  I believe that eleastic-recheck
> should
> tell you if you match this case.
>
> Thanks to those that found the root cause and worked on the fix
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Please use reno for all blueprints

[Steven Dake (stdake)]

Hey folks,

I have seen many reviews hitting the queue without reno release notes.

Its very simple and straightforward to create a reno release note.  Simply run:

reno –n blurb

This creates a file in the releasenotes directory with a hash.  Releasenotes 
should be committed with the commit in question.

Just hand-modify this created releasenote file and everyone’s life is simpler 
to understand what changed in the final release.

Regards
-steve


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Using \ for multiline statements

[Dulko, Michal]

On Thu, 2016-12-22 at 17:52 -0600, Matt Riedemann wrote:
> On 12/22/2016 5:28 PM, Sean McGinnis wrote:
> > 
> > Looking for input from everyone, particularly those with more in-
> > depth
> > Python knowledge.
> > 
> > In Cinder for some time we have been trying to enforce using () or
> > reformatting code to avoid using \ to have statements span multiple
> > lines. I'm not sure when this actually started, but I think it may
> > be one of those things where someone got a review disagreement, so
> > then that person started downvoting on it, then the next person,
> > etc.
> > 
> > I've seen some allusions to the use of \ having some issues, but I
> > can't find any concrete examples where this can cause problems. I
> > do
> > seem to remember trying to write a hacking check or a code parsing
> > tool to do something that choked on these, but it's long enough ago
> > that I don't remember the details, and I could very well be mixing
> > that up with something else.
> > 
> > So my question is - is there a technical reason for enforcing this
> > rule, or is this just a bad downvote that's gotten out of control?
> > 
> > Thanks!
> > 
> > Sean
> > 
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> I wouldn't -1 it. I've noticed \ showing up a bit more in Nova
> recently 
> simply for the exact reason I think people used to -1 it, because it
> was 
> considered ugly to use. But we've also had cases of () gone haywire.
> I 
> typically see \ used in unit tests or in DB API code when chaining 
> sqlalchemy ORM objects together to generate a single query.
> 
> Like most things like this, I'd rather than squabble over it, and
> take 
> it on a case by case basis. If a patch is hard to read and could be 
> improved using one or the other, then I'd comment as such, but
> wouldn't 
> -1 for using \ as a rule.
> 

I'm one of these people that tend to complain about use of backslash in
reviews. To be honest I've simply remembered that rule from the first
time I've read OpenStack Style Guidelines [1]. I think if we want to be
more permissive in this matter, we should indicate it there.

[1] http://docs.openstack.org/developer/hacking/#general

Thanks,
Michal
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev