settingsLogin | Registersettings

[openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

0 votes

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

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103939.html

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 21, 2016 in openstack-dev by Thierry_Carrez (57,480 points)   3 8 13
retagged Jan 26, 2017 by admin

52 Responses

0 votes

For my part, I missed the elections, that's my bad. I normally put a
calendar item in for that issue. I don't think that my missing the election
date should result in the group being treated in this way. Members of the
TC have contacted me about unrelated things recently, I have always been
available however my schedule has made it hard for me to sift through -dev
recently and I missed the volley of nomination emails. This is certainly a
failing on my part.

It's certainly true that the security team, and our cores tend not to pay
as much attention to the -dev mailing list as we should. The list is pretty
noisy and traditionally we always had a separate list that we used for
security and since moving away from that we tend to focus on IRC or direct
emails. Though as can be seen with our core announcements etc, we do try to
do things the "openstack way"

However, to say we're not active I think is a bit unfair. Theirry and
others regularly mail me directly about things like rooms for the summit
and I typically respond in good time, I think what's happened here is more
an identification of the fact that we need to focus more on doing things
"the openstack way" rather than being kicked out of the big tent.

We regularly work with the VMT on security issues, we issue large amounts
of guidance on our own, we have been working hard on an asset based threat
analysis process for OpenStack teams who are looking to be security
managed, we've reviewed external TA documentation and recently in our
midcycle (yes, we're dedicated enough to fly to Texas and meet up to work
on such issues) we created the first real set of security documents for an
OpenStack project, we worked with Barbican to apply the asset based threat
analysis that we'd like to engage other teams in [1], [2]

Here's a couple of the things that we've been doing in this cycle:
* Issuing Security Notes for Glance, Nova, Horizon, Bandit, Neutron and
Barbican[3]
* Updating the security guide (the book we wrote on securing OpenStack)[4]
* Hosting a midcycle and inducting new members
* Supporting the VMT with several embargoed and complex vulnerabilities
* Building up a security blog[5]
* Making OpenStack the biggest open source project to ever receive the Core
Infrastructure Initative Best Practices Badge[6][7]
* Working on the OpenStack Security Whitepaper [8]
* Developing CI security tooling such as Bandit [9]

We are a very active team, working extremely hard on trying to make one
OpenStack secure. This is often a thankless task, we provide a lot of what
customers are asking for from OpenStack but as we don't drive individual
flagship features our contributions are often overlooked. However, above is
just a selection of what we've been doing throughout the last cycle.

If it's too late for these comments to have an influence then sobeit but
this is failure of appropriate levels of email filtering and perhaps a
highlight of how we need to alter our culture somewhat to partipate more in
-dev in general than it is any indication of a lack of dedication, time,
effort or contribution on the part of the Security Project. We have
dedicate huge amounts of efforts to OpenStack and to relegate us to a
working group would be massively detrimental for one reason above all
others. We get corporate participation, time and effort in terms of
employee hours and contributions because we're an official part of
OpenStack, we've had to build this up over time. If you remove the Security
Project from the big tent I believe that participation in Security for
OpenStack will drop off significantly.

We are active, we are helping to make OpenStack secure and we (I) suck at
keeping ontop of email. Don't kick us out for that. If needs be we can find
another PTL or otherwise take special steps to ensure that missing
elections doesn't happen.

Apart from missing elections, I think we do a huge amount for the community
and removing us from OpenStack would in no way be beneficial to either the
Security Project or OpenStack as a whole.

-Rob

[1] https://review.openstack.org/#/c/357978/5
[2] https://etherpad.openstack.org/p/barbican-threat-analysis
[3] https://wiki.openstack.org/wiki/Security_Notes
[4] http://docs.openstack.org/sec/
[5] https://openstack-security.github.io/
[6] https://bestpractices.coreinfrastructure.org/
[7]
http://www.businesswire.com/news/home/20160725005133/en/OpenStack-Earns-Core-Infrastructure-Initiative-Practices-Badge
[8] https://www.openstack.org/software/security/
[9] https://wiki.openstack.org/wiki/Security/Projects/Bandit

On Wed, Sep 21, 2016 at 12:23 PM, Thierry Carrez thierry@openstack.org
wrote:

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

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103939.html

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 21, 2016 by Rob_C (1,240 points)   1
0 votes

Hello,

it's definately our bad that we missed elections in OpenStackSalt
project. Reason is similar to Rob's - we are active on different
channels (mostly IRC as we keep regular meetings) and don't used to
reading mailing lists with lots of generic topics (it would be good to
have separate mailing list for such calls and critical topics or
individual mails to project's core members).

Our project is very active [1], trying to do things the Openstack way
and I think it would be a pitty to remove it from Big Tent just because
we missed mail and therefore our first PTL election.

Of course I don't want to excuse our fault. In case it's not too late,
we will try to be more active in mailing lists like openstack-dev and
not miss such important events next time.

[1] http://stackalytics.com/?module=openstacksalt-group

-Filip

On Wed, Sep 21, 2016 at 12:23 PM, Thierry Carrez thierry@openstack.org
wrote:

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

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103939.html

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 21, 2016 by Filip_Pytloun (260 points)  
0 votes

-----Original Message-----
From: Rob C hyakuhei@gmail.com
Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Date: September 21, 2016 at 07:19:40
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject:  Re: [openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

For my part, I missed the elections, that's my bad. I normally put a
calendar item in for that issue. I don't think that my missing the election
date should result in the group being treated in this way. Members of the
TC have contacted me about unrelated things recently, I have always been
available however my schedule has made it hard for me to sift through -dev
recently and I missed the volley of nomination emails. This is certainly a
failing on my part.

It's certainly true that the security team, and our cores tend not to pay
as much attention to the -dev mailing list as we should. The list is pretty
noisy and traditionally we always had a separate list that we used for
security and since moving away from that we tend to focus on IRC or direct
emails. Though as can be seen with our core announcements etc, we do try to
do things the "openstack way"

However, to say we're not active I think is a bit unfair. Theirry and
others regularly mail me directly about things like rooms for the summit
and I typically respond in good time, I think what's happened here is more
an identification of the fact that we need to focus more on doing things
"the openstack way" rather than being kicked out of the big tent.

We regularly work with the VMT on security issues, we issue large amounts
of guidance on our own, we have been working hard on an asset based threat
analysis process for OpenStack teams who are looking to be security
managed, we've reviewed external TA documentation and recently in our
midcycle (yes, we're dedicated enough to fly to Texas and meet up to work
on such issues) we created the first real set of security documents for an
OpenStack project, we worked with Barbican to apply the asset based threat
analysis that we'd like to engage other teams in [1], [2]

Here's a couple of the things that we've been doing in this cycle:
* Issuing Security Notes for Glance, Nova, Horizon, Bandit, Neutron and
Barbican[3]
* Updating the security guide (the book we wrote on securing OpenStack)[4]
* Hosting a midcycle and inducting new members
* Supporting the VMT with several embargoed and complex vulnerabilities
* Building up a security blog[5]
* Making OpenStack the biggest open source project to ever receive the Core
Infrastructure Initative Best Practices Badge[6][7]
* Working on the OpenStack Security Whitepaper [8]
* Developing CI security tooling such as Bandit [9]

We are a very active team, working extremely hard on trying to make one
OpenStack secure. This is often a thankless task, we provide a lot of what
customers are asking for from OpenStack but as we don't drive individual
flagship features our contributions are often overlooked. However, above is
just a selection of what we've been doing throughout the last cycle.

If it's too late for these comments to have an influence then sobeit but
this is failure of appropriate levels of email filtering and perhaps a
highlight of how we need to alter our culture somewhat to partipate more in
-dev in general than it is any indication of a lack of dedication, time,
effort or contribution on the part of the Security Project. We have
dedicate huge amounts of efforts to OpenStack and to relegate us to a
working group would be massively detrimental for one reason above all
others. We get corporate participation, time and effort in terms of
employee hours and contributions because we're an official part of
OpenStack, we've had to build this up over time. If you remove the Security
Project from the big tent I believe that participation in Security for
OpenStack will drop off significantly.

We are active, we are helping to make OpenStack secure and we (I) suck at
keeping ontop of email. Don't kick us out for that. If needs be we can find
another PTL or otherwise take special steps to ensure that missing
elections doesn't happen.

Apart from missing elections, I think we do a huge amount for the community
and removing us from OpenStack would in no way be beneficial to either the
Security Project or OpenStack as a whole.

-Rob

[1] https://review.openstack.org/#/c/357978/5
[2] https://etherpad.openstack.org/p/barbican-threat-analysis
[3] https://wiki.openstack.org/wiki/Security_Notes
[4] http://docs.openstack.org/sec/
[5] https://openstack-security.github.io/
[6] https://bestpractices.coreinfrastructure.org/
[7]
http://www.businesswire.com/news/home/20160725005133/en/OpenStack-Earns-Core-Infrastructure-Initiative-Practices-Badge
[8] https://www.openstack.org/software/security/
[9] https://wiki.openstack.org/wiki/Security/Projects/Bandit




On Wed, Sep 21, 2016 at 12:23 PM, Thierry Carrez
wrote:

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

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103939.html

For my part, I do participate on this mailing list and try to read it daily (last week was abnormal for me because I was moving house). I'd like to think I would have seen http://lists.openstack.org/pipermail/openstack-dev/2016-September/103904.html but again, I wasn't around.

Thierry, you're right, this is certainly not the first time since I've been involved in the Security Project that we have missed the PTL nomination deadline. Perhaps that means that the Security Project needs more people interested in being PTL because Rob clearly has more on his plate than allows him to follow those things closely.

Rob, perhaps it would be good to start grooming someone to take over as PTL? Maybe it would be good to find someone with "the OpenStack way" experience who can help guide the project in that direction this cycle and after that.

--
Ian Cordasco


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 21, 2016 by sigmavirus24_at_gmai (8,720 points)   1 2 3
0 votes

Hi,

So I am recent elected core to the security group, so while obviously
pro OSSG-Sec, I also have a fairly fresh perspective of the group.

I would first off all not agree on disengagement with the community.
Well at least not from my perspective.

Since I joined I have found the group welcoming to new members, with
well run with meetings never starting late or failing to achieve
actions from before. While I may be a new core, I am not new to open
source, so there is no way I would have joined if I felt the group was
waning in enthusiasm, disconnected or not moving forward.

The team are actively working on several projects which have found
vulnerabilities in openstack, namely Bandit and syntribos, threat
analysis and I was inspired to start on my own new proposal project
from seeing the enthusiasm in the group. There is also lots of
engagement between other cores and the security group in OSSN's
(security notes). I recently took over covering these, and have
enjoyed working immensely with cores in keystone, trove, nova,
neutron, and horizon etc. I did not see any disconnect there myself.

On the matter of elections, I understand people are upset that the PTL
nomination period was missed, but I understand there was a genuine
reason for this which I will leave for the PTL to cover. For me Robert
did a really great job of welcoming and mentoring me into the security
group, so I personally have nothing but respect there.

So if the decision is made to demote(?) the group, I guess so be it,
but it will be a big downer and disappointment for me as someone that
is proud and enthusiastic to be a new OSSG-core sec member.

Regards,

Luke


From: Thierry Carrez thierry@openstack.org
Date: Wed, Sep 21, 2016 at 12:23 PM
Subject: [openstack-dev] [security] [salt] Removal of Security and
OpenStackSalt project teams from the Big Tent
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org

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

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103939.html

--
Thierry Carrez (ttx)


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

--
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhinds@redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 |
t: +44 12 52 36 2483


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 21, 2016 by Luke_Hinds (1,500 points)   1
0 votes

Excerpts from Rob C's message of 2016-09-21 13:17:07 +0100:

For my part, I missed the elections, that's my bad. I normally put a
calendar item in for that issue. I don't think that my missing the election
date should result in the group being treated in this way. Members of the
TC have contacted me about unrelated things recently, I have always been
available however my schedule has made it hard for me to sift through -dev
recently and I missed the volley of nomination emails. This is certainly a
failing on my part.

It's certainly true that the security team, and our cores tend not to pay
as much attention to the -dev mailing list as we should. The list is pretty
noisy and traditionally we always had a separate list that we used for
security and since moving away from that we tend to focus on IRC or direct
emails. Though as can be seen with our core announcements etc, we do try to
do things the "openstack way"

However, to say we're not active I think is a bit unfair. Theirry and
others regularly mail me directly about things like rooms for the summit
and I typically respond in good time, I think what's happened here is more
an identification of the fact that we need to focus more on doing things
"the openstack way" rather than being kicked out of the big tent.

We regularly work with the VMT on security issues, we issue large amounts
of guidance on our own, we have been working hard on an asset based threat
analysis process for OpenStack teams who are looking to be security
managed, we've reviewed external TA documentation and recently in our
midcycle (yes, we're dedicated enough to fly to Texas and meet up to work
on such issues) we created the first real set of security documents for an
OpenStack project, we worked with Barbican to apply the asset based threat
analysis that we'd like to engage other teams in [1], [2]

Here's a couple of the things that we've been doing in this cycle:
* Issuing Security Notes for Glance, Nova, Horizon, Bandit, Neutron and
Barbican[3]
* Updating the security guide (the book we wrote on securing OpenStack)[4]
* Hosting a midcycle and inducting new members
* Supporting the VMT with several embargoed and complex vulnerabilities
* Building up a security blog[5]
* Making OpenStack the biggest open source project to ever receive the Core
Infrastructure Initative Best Practices Badge[6][7]
* Working on the OpenStack Security Whitepaper [8]
* Developing CI security tooling such as Bandit [9]

We are a very active team, working extremely hard on trying to make one
OpenStack secure. This is often a thankless task, we provide a lot of what
customers are asking for from OpenStack but as we don't drive individual
flagship features our contributions are often overlooked. However, above is
just a selection of what we've been doing throughout the last cycle.

If it's too late for these comments to have an influence then sobeit but
this is failure of appropriate levels of email filtering and perhaps a
highlight of how we need to alter our culture somewhat to partipate more in
-dev in general than it is any indication of a lack of dedication, time,
effort or contribution on the part of the Security Project. We have
dedicate huge amounts of efforts to OpenStack and to relegate us to a
working group would be massively detrimental for one reason above all
others. We get corporate participation, time and effort in terms of
employee hours and contributions because we're an official part of
OpenStack, we've had to build this up over time. If you remove the Security
Project from the big tent I believe that participation in Security for
OpenStack will drop off significantly.

We are active, we are helping to make OpenStack secure and we (I) suck at
keeping ontop of email. Don't kick us out for that. If needs be we can find
another PTL or otherwise take special steps to ensure that missing
elections doesn't happen.

While it's admirable of you to take responsibility, there's no
reason to think this is an individual team member's fault. The
team is responsible as a group for ensuring that it is meeting its
responsibilities to the rest of the community. In this case, the
election officials and TC had no reason to assume that you would
or would not run again. Any contributor could have entered the race.
When no one at all did, that lack of engagement reflected on the
entire team, not only you.

Apart from missing elections, I think we do a huge amount for the community
and removing us from OpenStack would in no way be beneficial to either the
Security Project or OpenStack as a whole.

Based on the list above, the team is doing far more than I was aware
of. I'm glad to hear that, as it looks like there is a considerable
amount of work going into those contributions. I hope we can find
a way to increase the team's participation in community operations
outside of coding so they meet the minimum expectations.

Doug

-Rob

[1] https://review.openstack.org/#/c/357978/5
[2] https://etherpad.openstack.org/p/barbican-threat-analysis
[3] https://wiki.openstack.org/wiki/Security_Notes
[4] http://docs.openstack.org/sec/
[5] https://openstack-security.github.io/
[6] https://bestpractices.coreinfrastructure.org/
[7]
http://www.businesswire.com/news/home/20160725005133/en/OpenStack-Earns-Core-Infrastructure-Initiative-Practices-Badge
[8] https://www.openstack.org/software/security/
[9] https://wiki.openstack.org/wiki/Security/Projects/Bandit

On Wed, Sep 21, 2016 at 12:23 PM, Thierry Carrez thierry@openstack.org
wrote:

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

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103939.html

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 21, 2016 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

On Sep 21, 2016, at 8:58 AM, Filip Pytloun filip.pytloun@tcpcloud.eu wrote:

Hello,

it's definately our bad that we missed elections in OpenStackSalt
project. Reason is similar to Rob's - we are active on different
channels (mostly IRC as we keep regular meetings) and don't used to
reading mailing lists with lots of generic topics (it would be good to
have separate mailing list for such calls and critical topics or
individual mails to project's core members).

With 59 separate teams, even emailing the PTLs directly is becoming impractical. I can’t imagine trying to email all of the core members directly.

A separate mailing list just for “important announcements” would need someone to decide what is “important”. It would also need everyone to be subscribed, or we would have to cross-post to the existing list. That’s why we use topic tags on the mailing list, so that it is possible to filter messages based on what is important to the reader, rather than the sender.

Our project is very active [1], trying to do things the Openstack way
and I think it would be a pitty to remove it from Big Tent just because
we missed mail and therefore our first PTL election.

I don’t see any releases listed on https://releases.openstack.org/independent.html either. Are you tagging releases, yet?

I see no emails tagged with [salt] on the mailing list since March of this year, aside from this thread. Are you using a different communication channel for team coordination? You mention IRC, but how are new contributors expected to find you?

Of course I don't want to excuse our fault. In case it's not too late,
we will try to be more active in mailing lists like openstack-dev and
not miss such important events next time.

[1] http://stackalytics.com/?module=openstacksalt-group

-Filip

On Wed, Sep 21, 2016 at 12:23 PM, Thierry Carrez thierry@openstack.org
wrote:

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

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103939.html

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 21, 2016 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

On 09/21/2016 05:17 AM, Rob C wrote:
Apart from missing elections, I think we do a huge amount for the community and removing us from OpenStack would in no way be beneficial to either the Security Project or OpenStack as a whole.

I definitely agree with Rob here and I support keeping the Security team in the big tent.

Although I'm not an active contributor there (but I want to be), I've joined some of their meetings and they've provided guidance on some of the work I've done with OpenStack-Ansible's (OSA) security hardening role. The OSSN's they produce are helpful and the information contained within them is used when we improve OSA. The Security Guide is also extremely useful for deployers who need advice on configuring OpenStack in a secure way.

--
Major Hayden


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

responded Sep 21, 2016 by Major_Hayden (3,560 points)   6 6
0 votes

Hello,

With 59 separate teams, even emailing the PTLs directly is becoming impractical. I can’t imagine trying to email all of the core members directly.

A separate mailing list just for “important announcements” would need someone to decide what is “important”. It would also need everyone to be subscribed, or we would have to cross-post to the existing list. That’s why we use topic tags on the mailing list, so that it is possible to filter messages based on what is important to the reader, rather than the sender.

So maybe call it openstack-organization or openstack-teams or something
to focus on organizational topics.
Using tags and filters is also a way but may not be suitable for
everyone.

I don’t see any releases listed on https://releases.openstack.org/independent.html either. Are you tagging releases, yet?

Yes, we've done a few releases, see eg. openstack/salt-formula-nova
releases here: https://github.com/openstack/salt-formula-nova/releases

I don't know why it's not listed on releases.openstack.org page.

I see no emails tagged with [salt] on the mailing list since March of this year, aside from this thread. Are you using a different communication channel for team coordination? You mention IRC, but how are new contributors expected to find you?

Yes, we are using openstack-salt channel and openstack meetings over
IRC. This channel is mentioned eg. in readme here [1] and community
meetings page [2] which are on weekly basis (logs [3]).

We also had a couple of people comming to team IRC talking to us about project
so I believe they can find the way to contact us even without our heavy
activity at openstack-dev (which should be better as I admitted).

[1] https://github.com/openstack/openstack-salt
[2] https://wiki.openstack.org/wiki/Meetings/openstack-salt
[3] http://eavesdrop.openstack.org/meetings/openstack_salt/2016/

Of course I don't want to excuse our fault. In case it's not too late,
we will try to be more active in mailing lists like openstack-dev and
not miss such important events next time.

[1] http://stackalytics.com/?module=openstacksalt-group

-Filip

On Wed, Sep 21, 2016 at 12:23 PM, Thierry Carrez thierry@openstack.org
wrote:

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

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103904.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-
September/103939.html

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Filip Pytloun
Cloud Architect

[tcp ◕ cloud]

tcp cloud a.s.
Thamova 16, 180 00 Prague 8

Mobile: +420 776 004 323
E-mail: filip.pytloun@tcpcloud.eu
GPG: 3802 93B1 6CA8 C7A0 695B 8B28 6808 239B 9C72 E61B
Web: http://www.opentcpcloud.org/


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

responded Sep 21, 2016 by Filip_Pytloun (260 points)  
0 votes

Excerpts from Filip Pytloun's message of 2016-09-21 14:58:52 +0200:

Hello,

it's definately our bad that we missed elections in OpenStackSalt
project. Reason is similar to Rob's - we are active on different
channels (mostly IRC as we keep regular meetings) and don't used to
reading mailing lists with lots of generic topics (it would be good to
have separate mailing list for such calls and critical topics or
individual mails to project's core members).

Our project is very active [1], trying to do things the Openstack way
and I think it would be a pitty to remove it from Big Tent just because
we missed mail and therefore our first PTL election.

Of course I don't want to excuse our fault. In case it's not too late,
we will try to be more active in mailing lists like openstack-dev and
not miss such important events next time.

[1] http://stackalytics.com/?module=openstacksalt-group

Seems like we need a bit added to this process which makes sure big tent
projects have their primary IRC channel identified, and a list of core
reviewer and meeting chair IRC nicks to ping when something urgent comes
up. This isn't just useful for elections, but is probably something the
VMT would appreciate as well, and likely anyone else who has an urgent
need to make contact with a team.

I think it might also be useful if we could make the meeting bot remind
teams of any pending actions they need to take such as elections upon

startmeeting.

Seems like all of that could be automated.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 21, 2016 by Clint_Byrum (40,940 points)   4 5 9
0 votes

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-request@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
openstack-dev@lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
openstack-dev-request@lists.openstack.org

You can reach the person managing the list at
openstack-dev-owner@lists.openstack.org

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)

    1. Re: [stackalytics] [deb] [packaging] OpenStack contribution
      stats skewed by deb-* projects (Thierry Carrez)
    2. [ptl] code churn and questionable changes (Amrith Kumar)

Message: 1
Date: Wed, 21 Sep 2016 09:57:43 +0200
From: Micha? Dulko michal.dulko@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-247719c89b48@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.thomas@gmail.com duncan.thomas@gmail.com> wrote:

On 20 September 2016 at 16:24, Nikita Konovalov
<nkonovalov@mirantis.com <mailto:nkonovalov@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-request@lists.openstack.org?subject:unsubscribe
<

http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
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?

[1]
https://github.com/openstack/cinder/blob/master/cinder/scheduler/filters/instance_locality_filter.py

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.zhongjun2@gmail.com
To: openstack-dev openstack-dev@lists.openstack.org
Subject: [openstack-dev] [manila] Enable IPv6 in Manila Ocata
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi,

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
rules
& export locations). This change intends to add the IPv6 format validation
for
ip access rule type in allow_access API, allowing manila to support IPv6
ACL.

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/

Thanks,
Jun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/880e28e8/attachment-0001.html
>


Message: 3
Date: Wed, 21 Sep 2016 08:38:53 +0000
From: "Afek, Ifat (Nokia - IL)" ifat.afek@nokia.com
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: [openstack-dev] [vitrage] Barcelona design sessions
Message-ID: CAD9E9DC-E55D-4BCC-BC8E-1CACDFFA7E09@alcatel-lucent.com
Content-Type: text/plain; charset="utf-8"

Hi,

As discussed in our IRC meeting today, you are welcome to suggest topics
for vitrage design sessions in Barcelona:
https://etherpad.openstack.org/p/vitrage-barcelona-design-sessions

Thanks,
Ifat.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/3b999def/attachment-0001.html
>


Message: 4
Date: Wed, 21 Sep 2016 09:53:06 +0000
From: "Daly, Louise M" louise.m.daly@intel.com
To: "openstack-dev@lists.openstack.org"

Subject: [openstack-dev] [Kuryr] Kuryr IPVlan Code PoC
Message-ID:

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

Hi everyone,

As promised here is a link to the code PoC for the Kuryr-IPVlan proposal.
https://github.com/lmdaly/kuryr-libnetwork

Link to specific commit
https://github.com/lmdaly/kuryr-libnetwork/commit/1dc895a6d8bfaa03c0dd5cfb2d3e23e2e948a67c

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.
http://osdir.com/ml/openstack-dev/2016-09/msg00816.html

Please send any feedback, issues, comments, bugs.

Thanks,
Louise


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...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/e8c695c3/attachment-0001.html
>


Message: 5
Date: Wed, 21 Sep 2016 12:00:38 +0200
From: Rossella Sblendido rsblendido@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-9d88e78528fc@suse.com
Content-Type: text/plain; charset=windows-1252; format=flowed

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

Rossella

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.haley@hpe.com
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]

http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject: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 skramaja@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [tripleo] Setting kernel args to
overcloud nodes
Message-ID:

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.

Regards,
Saravanan KR

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

On Wed, Jul 27, 2016 at 6:52 PM, Saravanan KR skramaja@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]
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#appending-kernel-parameters-to-boot-instances

[3]
http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/extra_config.html#firstboot-extra-configuration


Message: 7
Date: Wed, 21 Sep 2016 12:49:58 +0200
From: Giulio Fidente gfidente@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-321fa9f7d9f9@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 thierry@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-b2e019840579@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
direction.

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 ?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103904.html

[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103939.html

--
Thierry Carrez (ttx)


Message: 9
Date: Wed, 21 Sep 2016 04:32:57 -0700
From: Mike Perez thingee@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.GJ31426@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 thierry@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-e7e564ff66d2@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/
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 amrith@tesora.com
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: [openstack-dev] [ptl] code churn and questionable changes
Message-ID:

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

Thanks!

-amrith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/c3bc37fe/attachment-0001.html
>



OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 21, 2016 by tmcpeak_at_us.ibm.co (140 points)  
...