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

From:   openstack-dev-requ...@lists.openstack.org
To:     openstack-dev@lists.openstack.org
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 <michal.du...@intel.com>
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers
                 performance tests results
Message-ID: <ca9f10ad-51e4-274c-95bd-247719c89...@intel.com>
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
> <duncan.tho...@gmail.com <mailto:duncan.tho...@gmail.com>> wrote:
>     On 20 September 2016 at 16:24, Nikita Konovalov
>     <nkonova...@mirantis.com <mailto:nkonova...@mirantis.com>> 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:
>     openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>     <
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> ?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]: https://wiki.openstack.org/wiki/CinderBrick
> Thanks,
> John?


Message: 2
Date: Wed, 21 Sep 2016 16:05:08 +0800
From: jun zhong <jun.zhongj...@gmail.com>
To: openstack-dev <openstack-dev@lists.openstack.org>
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 

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
[1] https://review.openstack.org/#/c/362786/
[2] https://review.openstack.org/#/c/312321/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <


Message: 3
Date: Wed, 21 Sep 2016 08:38:53 +0000
From: "Afek, Ifat (Nokia - IL)" <ifat.a...@nokia.com>
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [vitrage] Barcelona design sessions
Message-ID: <cad9e9dc-e55d-4bcc-bc8e-1cacdffa7...@alcatel-lucent.com>
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...
URL: <


Message: 4
Date: Wed, 21 Sep 2016 09:53:06 +0000
From: "Daly, Louise M" <louise.m.d...@intel.com>
To: "openstack-dev@lists.openstack.org"
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 
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 
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact 
sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <


Message: 5
Date: Wed, 21 Sep 2016 12:00:38 +0200
From: Rossella Sblendido <rsblend...@suse.com>
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to the
                 neutron-drivers team
Message-ID: <0ffde713-a31d-9362-9b0d-9d88e7852...@suse.com>
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 <brian.ha...@hpe.com> 
>> 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 
>>> as
>>> stable core, downstream package whisperer, release and oslo liaison (I 
>>> sure I
>>> am forgetting some other capacity he is in) is going to put him at 
>>> 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 
>>> Thursday meetings soon [2], and having Ihar onboard by then will be 
>>> beneficial.
>>> Please, join me in welcome Ihar to the team.
>>> Cheers,
>>> Armando
>>> [1]

>>> <
>>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>>> <https://wiki.openstack.org/wiki/Meetings/NeutronDrivers>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Message: 6
Date: Wed, 21 Sep 2016 15:43:24 +0530
From: Saravanan KR <skram...@redhat.com>
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 

Saravanan KR

[1] https://gist.github.com/krsacme/1234bf024ac917c74913827298840c1c

On Wed, Jul 27, 2016 at 6:52 PM, Saravanan KR <skram...@redhat.com> 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] https://review.openstack.org/#/c/331564/
> [2] 

> [3] 


Message: 7
Date: Wed, 21 Sep 2016 12:49:58 +0200
From: Giulio Fidente <gfide...@redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
                 <openstack-dev@lists.openstack.org>, Emilien Macchi
Subject: Re: [openstack-dev] [tripleo] [puppet] Preparing TripleO
                 agenda for Barcelona - action needed
Message-ID: <ea008395-f1d1-47ca-f7d5-321fa9f7d...@redhat.com>
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.
> https://etherpad.openstack.org/p/ocata-tripleo
> 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 <thie...@openstack.org>
To: OpenStack Development Mailing List
Subject: [openstack-dev] [security] [salt] Removal of Security and
                 OpenStackSalt project teams from the Big Tent
Message-ID: <c7e735c1-bfbf-cfca-c972-b2e019840...@openstack.org>
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 <thin...@gmail.com>
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?
Message-ID: <20160921113257.gj31...@gmail.com>
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 <thie...@openstack.org>
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [stackalytics] [deb] [packaging]
                 OpenStack contribution stats skewed by deb-* projects
Message-ID: <4d62157c-fb5f-5395-3515-e7e564ff6...@openstack.org>
Content-Type: text/plain; charset=windows-1252

Ilya Shakhat wrote:
> Hi,
> tldr; Commits stats are significantly skewed by deb-* projects
> (http://stackalytics.com/?metric=commits&module=packaging-deb-group)
> 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 <amr...@tesora.com>
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 criteria):

-    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 

-    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 help.

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 ideas.

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...
URL: <


OpenStack-dev mailing list

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

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to