Agreed entirely with Travis's points. I think it was a given to anyone within 
the OSSP that Rob would be our PTL going forward. I recognize that the 
community needs feedback to make these decisions, but I am in our IRC channel 5 
days a week, at least 8 hours a day, and I have never seen any attempt to reach 
out to us in that medium. I wouldn't call it babysitting to make some 
reasonable attempt to meet us where we are instead of moralizing on the mailing 
list when we don't respond to OTHER postings on the same mailing list.

I believe kicking OSSP out of the big tent will have these results:

  *   The 5 individuals we have working full-time on Syntribos 
( / as part of OSIC may not be able to 
continue our arrangement if this project is not in the big tent. I can't speak 
for OSIC leadership on this point, but it is certainly a risk
  *   The OSSP has been losing members recently for various reasons not related 
to OpenStack politics. Removing us from the big tent will only accelerate this
  *   Projects like Bandit, Syntribos, and Anchor will atrophy without 
dedicated developer attention, representing a HUGE waste of developer resources 
and potential positive operator impact
  *   It will take longer to wrap up OSSA/OSSN/Threat Analysis for OpenStack 
projects if only the 4 members of the VMT are involved/invested
     *   I want to be clear: the VMT does very important work, and they are 
incredibly responsive for such a small team. Nonetheless, the numbers don't 
lie. We have more people working on one tool (Syntribos) than the entire group 
responsible for vulnerability management throughout all of OpenStack. 
Thankfully, we don't ONLY work on Syntribos - we attended the midcycle where we 
helped on OSSNs and the threat analysis for Barbican.

I would understand this reaction if we were a completely barren group that 
hadn't made any contributions to OpenStack in months, but to the contrary, we 
have been very active on a number of projects. In fact, my team (Syntribos) is 
testing OpenStack projects for security vulnerabilities at this very moment, 
and we have reported several recently.

I think this speaks just as much to a disconnect by the OpenStack community 
from our project, and I would turn your accusation of inactivity back on you. 
If you're completely unaware of the work we're doing, and unwilling to join our 
very active IRC channel to get in touch with us, is it not a bit hypocritical 
to accuse us of negligence for not consuming the entire firehose of the 
OpenStack Dev list?

Charles Neill

From: Travis Mcpeak <<>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
Date: Wednesday, September 21, 2016 at 11:23
Subject: Re: [openstack-dev] [security] [salt] Removal of Security and 
OpenStackSalt project teams from the Big Tent

Ouch.  I'd be among the first to admit I don't keep up with dev ML
as I should.  Missing the PTL elections is certainly embarrassing
for us and it shouldn't be the community's job to baby-sit us and
make sure we're meeting our OpenStack deadlines.

That being said, relegating us to a working group seems like a
knee-jerk and drastic consequence to levy against a project as
vibrant as ours.

In a previous response Rob has highlighted many of our recent
accomplishments, so I won't revisit that here.

What I do want to mention is the work Rob himself has done to
coordinate and secure funding for our fifth consecutive mid-cycle
(and each prior to that).  He has worked consistently to build support
for our initiatives, both within and outside of OpenStack.

Since assuming the PTL role none of our active members have been
inclined to run against him.

So yes, he's dropped the ball on reading the ML (I have too).  If
allowed to keep our project status we'll ensure that these mistakes
don't happen in the future.

Taking away our project status because "we act like a working group"
is an unfair categorization and, in my opinion, a severe reaction to a
relatively minor infraction.

-Travis McPeak

Date:        09/21/2016 05:04 AM
Subject:        OpenStack-dev Digest, Vol 53, Issue 51

Send OpenStack-dev mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."

Today's Topics:

  1. Re: [cinder][sahara] LVM vs BDD drivers performance tests
     results (Micha? Dulko)
  2.  [manila] Enable IPv6 in Manila Ocata (jun zhong)
  3. [vitrage] Barcelona design sessions (Afek, Ifat (Nokia - IL))
  4.  [Kuryr] Kuryr IPVlan Code PoC (Daly, Louise M)
  5. Re: [Neutron] Adding ihrachys to the neutron-drivers team
     (Rossella Sblendido)
  6. Re: [tripleo] Setting kernel args to overcloud nodes
     (Saravanan KR)
  7. Re: [tripleo] [puppet] Preparing TripleO agenda for Barcelona
     - action needed (Giulio Fidente)
  8. [security] [salt] Removal of Security and OpenStackSalt
     project teams from the Big Tent (Thierry Carrez)
  9. Re: [tc]a chance to meet all TCs for Tricircle big-tent
     application in Barcelona summit? (Mike Perez)
 10. Re: [stackalytics] [deb] [packaging] OpenStack contribution
     stats skewed by deb-* projects (Thierry Carrez)
 11. [ptl] code churn and questionable changes (Amrith Kumar)


Message: 1
Date: Wed, 21 Sep 2016 09:57:43 +0200
From: Micha? Dulko <<>>
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers
                performance tests results
Content-Type: text/plain; charset=UTF-8

On 09/20/2016 05:48 PM, John Griffith wrote:
> On Tue, Sep 20, 2016 at 9:06 AM, Duncan Thomas
> <<> 
> <>> wrote:
>     On 20 September 2016 at 16:24, Nikita Konovalov
>     <<> 
> <>> wrote:
>         Hi,
>         From Sahara (and Hadoop workload in general) use-case the
>         reason we used BDD was a complete absence of any overhead on
>         compute resources utilization.
>         The results show that the LVM+Local target perform pretty
>         close to BDD in synthetic tests. It's a good sign for LVM. It
>         actually shows that most of the storage virtualization
>         overhead is not caused by LVM partitions and drivers
>         themselves but rather by the iSCSI daemons.
>         So I would still like to have the ability to attach partitions
>         locally bypassing the iSCSI to guarantee 2 things:
>         * Make sure that lio processes do not compete for CPU and RAM
>         with VMs running on the same host.
>         * Make sure that CPU intensive VMs (or whatever else is
>         running nearby) are not blocking the storage.
>     So these are, unless we see the effects via benchmarks, completely
>     meaningless requirements. Ivan's initial benchmarks suggest
>     that LVM+LIO is pretty much close enough to BDD even with iSCSI
>     involved. If you're aware of a case where it isn't, the first
>     thing to do is to provide proof via a reproducible benchmark.
>     Otherwise we are likely to proceed, as John suggests, with the
>     assumption that local target does not provide much benefit.
>     I've a few benchmarks myself that I suspect will find areas where
>     getting rid of iSCSI is benefit, however if you have any then you
>     really need to step up and provide the evidence. Relying on vague
>     claims of overhead is now proven to not be a good idea.
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     <>
>     <>
> ?Honestly we can have both, I'll work up a bp to resurrect the idea of
> a "smart" scheduling feature that lets you request the volume be on
> the same node as the compute node and use it directly, and then if
> it's NOT it will attach a target and use it that way (in other words
> you run a stripped down c-vol service on each compute node).

Don't we have at least scheduling problem solved [1] already?


> Sahara keeps insisting on being a snow-flake with Cinder volumes and
> the block driver, it's really not necessary.  I think we can
> compromise just a little both ways, give you standard Cinder semantics
> for volumes, but allow you direct acccess to them if/when requested,
> but have those be flexible enough that targets *can* be attached so
> they meet all of the required functionality and API implementations.
> This also means that we don't have to continue having a *special*
> driver in Cinder that frankly only works for one specific use case and
> deployment.
> I've pointed to this a number of times but it never seems to
> resonate... but I never learn so I'll try it once again [1].  Note
> that was before the name "brick" was hijacked and now means something
> completely different.
> [1]:
> Thanks,
> John?


Message: 2
Date: Wed, 21 Sep 2016 16:05:08 +0800
From: jun zhong <<>>
To: openstack-dev 
Subject: [openstack-dev]  [manila] Enable IPv6 in Manila Ocata
Content-Type: text/plain; charset="utf-8"


As agreed by the manila community in IRC meeting,
we try to enable IPv6 in Ocata. Please check the brief spec[1] and code[2]).

The areas affected most are API (access rules) and in the drivers (access
& export locations). This change intends to add the IPv6 format validation
ip access rule type in allow_access API, allowing manila to support IPv6

Hi all of the driver maintainers, could you test the IPv6 feature code[2]
to make sure whether your driver can completely support IPv6.
If there still have something else might not be IPv6-ready, please let me
known. Thanks

-------------- next part --------------
An HTML attachment was scrubbed...


Message: 3
Date: Wed, 21 Sep 2016 08:38:53 +0000
From: "Afek, Ifat (Nokia - IL)" 
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [vitrage] Barcelona design sessions
Content-Type: text/plain; charset="utf-8"


As discussed in our IRC meeting today, you are welcome to suggest topics for 
vitrage design sessions in Barcelona:


-------------- next part --------------
An HTML attachment was scrubbed...


Message: 4
Date: Wed, 21 Sep 2016 09:53:06 +0000
From: "Daly, Louise M" <<>>
Subject: [openstack-dev]  [Kuryr] Kuryr IPVlan Code PoC
Content-Type: text/plain; charset="us-ascii"

Hi everyone,

As promised here is a link to the code PoC for the Kuryr-IPVlan proposal.

Link to specific commit

>From here you can clone the repo and install Kuryr as you normally would with 
>a few additional steps:

1. The IPVlan driver must be installed on the VM/Machine that the PoC will be 
run on. Fedora-Server(not the cloud image) includes the driver by default but 
the likes of the cloud image must be modified to include the driver.
2. You must install Docker experimental.
3. You must use the Kuryr IPAM driver for address management.
4. In order to enable the IPVlan mode you must change the ipvlan option in the 
kuryr.conf file from false to true.
5. You must also change the ifname option to match the interface of the private 
network you wish to run the containers on. (Default is ens3)
6. As listed in the limitations on the README.rst on kuryr "To create Docker 
networks with subnets having same/overlapping cidr, it is expected to pass 
unique pool name for each such network creation Docker command." You will need 
to do this if you are creating a docker network with the same private network 
on another VM.

The IPVlan proposal was sent out to the mailing list - link for those who 
missed it.

Please send any feedback, issues, comments, bugs.


Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...


Message: 5
Date: Wed, 21 Sep 2016 12:00:38 +0200
From: Rossella Sblendido <<>>
Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to the
                neutron-drivers team
Content-Type: text/plain; charset=windows-1252; format=flowed

Congratulations Ihar! You really deserved this, I am sure you'll do great.


On 09/20/2016 10:57 AM, Miguel Angel Ajo Pelayo wrote:
> Congratulations Ihar!, well deserved through hard work! :)
> On Mon, Sep 19, 2016 at 8:03 PM, Brian Haley 
> <<>> wrote:
>> Congrats Ihar!
>> -Brian
>> On 09/17/2016 12:40 PM, Armando M. wrote:
>>> Hi folks,
>>> I would like to propose Ihar to become a member of the Neutron drivers
>>> team [1].
>>> Ihar wide knowledge of the Neutron codebase, and his longstanding duties
>>> as
>>> stable core, downstream package whisperer, release and oslo liaison (I am
>>> sure I
>>> am forgetting some other capacity he is in) is going to put him at great
>>> comfort
>>> in the newly appointed role, and help him grow and become wise even
>>> further.
>>> Even though we have not been meeting regularly lately we will resume our
>>> Thursday meetings soon [2], and having Ihar onboard by then will be highly
>>> beneficial.
>>> Please, join me in welcome Ihar to the team.
>>> Cheers,
>>> Armando
>>> [1]
>>> <>
>>> [2]
>>> <>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 


Message: 6
Date: Wed, 21 Sep 2016 15:43:24 +0530
From: Saravanan KR <<>>
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [tripleo] Setting kernel args to
                overcloud nodes
Content-Type: text/plain; charset=UTF-8

I have been working on the user-data scripts (first-boot) for updating
the kernel args on the overcloud node [1]. The pre-condition is that
the kernel args has to be applied and node has to be restarted before
os-net-config runs.

I got in to problem of provisioning network not getting ip after the
reboot in the user-data script. While investigating, figured out that
network.service starts the nodes on the alpha-numeric order, on which
the first nic is not the one used for provisioning. network.service
initiates a DHCP DISCOVER on it, when it times out, network.service
goes to failed state and all other interfaces are DOWN state. If i
manually bring the interface up (via ipmi console), then all proceeds
fine without any issue.

To overcome this issue, I have written a small script to find out the
provisioning network via metadata (metadata has the mac address of the
provisioning network) and make BOOTPROTO=none on all other interface's
ifcfg files except the provisioning network. There still an issue of
IP not ready at the time of querying metadata, temporarily added a
sleep which solves it. The user-data script [1] has all these fixes
and tested on an baremetal overcloud node.

If anyone has a better way of doing it, you are more than welcome to suggest.

Saravanan KR


On Wed, Jul 27, 2016 at 6:52 PM, Saravanan KR 
<<>> wrote:
> Hello,
> We are working on SR-IOV & DPDK tripleo integration. In which, setting
> the kernel args for huge pages, iommu and cpu isolation is required.
> Earlier we were working on setting of kernel args via IPA [1], reasons
> being:
> 1. IPA is installing the boot loader on the overcloud node
> 2. Ironic knows the hardware spec, using which, we can target specific
> args to nodes via introspection rules
> As the proposal is to change the image owned file '/etc/default/grub',
> it has been suggested by ironic team to use the instance user data to
> set the kernel args [2][3], instead of IPA. In the suggested approach,
> we are planning to update the file /etc/default/grub, update
> /etc/grub2.cfg and then issue a reboot. Reboot is mandatory because,
> os-net-config will configure the DPDK bridges and ports by binding the
> DPDK driver, which requires kernel args should be set for iommu and
> huge pages.
> As discussed on the IRC tripleo meeting, we need to ensure that the
> user data with update of kernel args, does not overlap with any other
> puppet configurations. Please let us know if you have any comments on
> this approach.
> Regards,
> Saravanan KR
> [1]
> [2] 
> [3] 


Message: 7
Date: Wed, 21 Sep 2016 12:49:58 +0200
From: Giulio Fidente <<>>
To: "OpenStack Development Mailing List (not for usage questions)"
Emilien Macchi
Subject: Re: [openstack-dev] [tripleo] [puppet] Preparing TripleO
                agenda for Barcelona - action needed
Content-Type: text/plain; charset=windows-1252; format=flowed

On 09/19/2016 10:49 PM, Emilien Macchi wrote:
> (adding puppet tag for cross project session).
> Let's continue to prepare TripleO sessions.
> For reminder, we have 2 fishbowls and 4 working rooms.
> I looked at the topic proposals and I started to organize some sessions.
> Some actions from you are required:
> - review the session proposal
> - if you want to drive a session, please put your name in "Chair".
> - for each session we need to choose if we want it to be a work room
> or a fishbowl session.
> - 4 topics are still there, please propose a session (concatenate them
> if possible)
> - if you missed this etherpad until now, feel free to propose a
> session with your topic (ex: TripleO UI - roadmap, etc).
> At least but not least, I would propose a cross project session with
> Puppet OpenStack group (using a slot from their schedule) so we might
> have a 7th session.

the cross project session with the puppet group is a nice idea indeed,
thanks Emilien

in that context it would be nice to gather some ideas/feedback on the
status of openstack integration scenarios vs tripleo scenarios and see
if we can optimize resources and/or coverage
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente


Message: 8
Date: Wed, 21 Sep 2016 13:23:32 +0200
From: Thierry Carrez <<>>
To: OpenStack Development Mailing List
Subject: [openstack-dev] [security] [salt] Removal of Security and
                OpenStackSalt project teams from the Big Tent
Content-Type: text/plain; charset=utf-8

Hi everyone,

As announced previously[1][2], there were no PTL candidates within the
election deadline for a number of official OpenStack project teams:
Astara, UX, OpenStackSalt and Security.

In the Astara case, the current team working on it would like to abandon
the project (and let it be available for any new team who wishes to take
it away). A change should be proposed really soon now to go in that

In the UX case, the current PTL (Piet Kruithof) very quickly reacted,
explained his error and asked to be considered for the position for
Ocata. The TC will officialize his nomination at the next meeting,
together with the newly elected PTLs.

That leaves us with OpenStackSalt and Security, where nobody reacted to
the announcement that we are missing PTL candidates. That points to a
real disconnect between those teams and the rest of the community. Even
if you didn't have the election schedule in mind, it was pretty hard to
miss all the PTL nominations in the email last week.

The majority of TC members present at the meeting yesterday suggested
that those project teams should be removed from the Big Tent, with their
design summit space allocation slightly reduced to match that (and make
room for other not-yet-official teams).

In the case of OpenStackSalt, it's a relatively new addition, and if
they get their act together they could probably be re-proposed in the
future. In the case of Security, it points to a more significant
disconnect (since it's not the first time the PTL misses the nomination
call). We definitely still need to care about Security (and we also need
a home for the Vulnerability Management team), but I think the "Security
team" acts more like a workgroup than as an official project team, as
evidenced by the fact that nobody in that team reacted to the lack of
PTL nomination, or the announcement that the team missed the bus.

The suggested way forward there would be to remove the "Security project
team", have the Vulnerability Management Team file to be its own
official project team (in the same vein as the stable maintenance team),
and have Security be just a workgroup rather than a project team.

Thoughts, comments ?


Thierry Carrez (ttx)


Message: 9
Date: Wed, 21 Sep 2016 04:32:57 -0700
From: Mike Perez <<>>
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [tc]a chance to meet all TCs for
                Tricircle big-tent application in Barcelona summit?
Content-Type: text/plain; charset=us-ascii

On 00:48 Sep 21, joehuang wrote:
> Thank you for the message. Will the weekly IRC meeting in that week also be 
> cancelled during
> the summit period according to your experience?

Likely yes.

Mike Perez


Message: 10
Date: Wed, 21 Sep 2016 13:37:18 +0200
From: Thierry Carrez <<>>
Subject: Re: [openstack-dev] [stackalytics] [deb] [packaging]
                OpenStack contribution stats skewed by deb-* projects
Content-Type: text/plain; charset=windows-1252

Ilya Shakhat wrote:
> Hi,
> tldr; Commits stats are significantly skewed by deb-* projects
> (
> By default Stackalytics processes commits from project's master branch.
> For some "old core" projects there is configuration to process stable
> branches as well. If some commit is cherry-picked from master to stable
> it is counted twice in both branches / releases. The configuration for
> stable branch is simple - branch starting with branching point (e.g.
> stable/newton that starts with rc1)
> In deb-* projects master branch corresponds to upstream Debian
> community. All OpenStack-related contribution goes into debian/<release>
> branch. But unlike in the rest of OpenStack, git workflow differs and
> the branch contains merge commits from master. This makes filtering
> "pure" branch commits from those that came from master quite tricky (not
> possible to specify the branch-point). And support of this will require
> changes in Stackalytics code.
> Since currently we are at the time when people may get nervous about
> numbers, I'd suggest to temporary hide all commits from deb-* projects
> and revise stats processing in a month.

Sounds good. Are you working on it ?

Thierry Carrez (ttx)


Message: 11
Date: Wed, 21 Sep 2016 11:56:06 +0000
From: Amrith Kumar <<>>
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [ptl] code churn and questionable changes

Content-Type: text/plain; charset="us-ascii"

Of late I've been seeing a lot of rather questionable changes that appear to be 
getting blasted out across multiple projects; changes that cause considerable 
code churn, and don't (IMHO) materially improve the quality of OpenStack.

I'd love to provide a list of the changes that triggered this email but I know 
that this will result in a rat hole where we end up discussing the merits of 
the individual items on the list and lose sight of the bigger picture. That 
won't help address the question I have below in any way, so I'm at a 
disadvantage of having to describe my issue in abstract terms.

Here's how I characterize these changes (changes that meet one or more of these 

-    Contains little of no information in the commit message (often just a 
single line)

-    Makes some generic statement like "Do X not Y", "Don't use Z", "Make ABC 
better" with no further supporting information

-    Fail (literally) every single CI job, clearly never tested by the developer

-    Gets blasted across many projects, literally tens with often the same kind 
of questionable (often wrong) change

-    Makes a stylistic python improvement that is not enforced by any check 
(causes a cottage industry of changes making the same correction every couple 
of months)

-    Reverses some previous python stylistic improvement with no clear reason 
(another cottage industry)

I've tried to explain it to myself as enthusiasm, and a desire to contribute 
aggressively; I've lapsed into cynicism at times and tried to explain it as 
gaming the numbers system, but all that is merely rationalization and doesn't 

Over time, the result generally is that these developers' changes get ignored. 
And that's not a good thing for the community as a whole. We want to be a 
welcoming community and one which values all contributions so I'm looking for 
some suggestions and guidance on how one can work with contributors to try and 
improve the quality of these changes, and help the contributor feel that their 
changes are valued by the project? Other more experienced PTL's, ex-PTL's, long 
time open-source-community folks, I'm seriously looking for suggestions and 

Any and all input is welcome, do other projects see this, how do you handle it, 
is this normal, ...



-------------- next part --------------
An HTML attachment was scrubbed...


OpenStack-dev mailing list<>

End of OpenStack-dev Digest, Vol 53, Issue 51

OpenStack Development Mailing List (not for usage questions)

Reply via email to