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

[Kyle Mestery]

On Wed, Sep 21, 2016 at 3:35 PM, Thierry Carrez  wrote:
> Chivers, Doug wrote:
>> My concern is with the original wording “The suggested way forward there 
>> would be to remove the "Security project team"”.
>>
>> This seems like a move to instantly reduce investment in OpenStack security, 
>> because the majority of members of the Security Project are corporately 
>> funded, which will be significantly impacted by the removal of the security 
>> project. I have no knowledge over the difference between a working group and 
>> a project, like everyone else on the project we are simply here to 
>> contribute to OpenStack security, drive innovation in security, deliver 
>> documentation like OSSNs, etc, rather than get involved in the politics of 
>> OpenStack.
>>
>> In response to the various questions of why no-one from our project noticed 
>> that we didn’t have a nomination for the PTL, we assumed that was taken care 
>> of. Realistically maybe two or three people on the security project have the 
>> availability to be PTL, one being our current PTL, for all the rest of us 
>> its simply not a concern until we need to vote.
>>
>> On a personal note, reading –dev is unfortunately a lower priority than 
>> designing architectures, responding to customers and sales teams, closing 
>> tickets, writing decks and on the afternoon or so I can spend each week, 
>> working on my upstream projects (this week it was: 
>> https://review.openstack.org/#/c/357978/5 - thanks to the Barbican team for 
>> all their work). Possibly this is wrong, but I didn’t sign up as a 
>> contributor to spend all my spare time reading mailing lists.
>
> So while I still think there is a slight disconnect (like, members of
> the security team are less often involved in other teams) that results
> in the Security team being more likely to miss the very few process
> deadlines that apply to them, I'm not convinced it justifies removing
> the "official" status of the team and make it a workgroup.
>
> I privately received information that explains why the PTL was not on
> top of things during election weeks. With ~60 teams around there will
> always be one or two that miss and that we must check on. It /always/ is
> symptomatic of /some/ disconnect. But here I'm not sure it passes the
> bar of "non-alignment with the community" that would make the Security
> team unfit to be an official OpenStack team...
>
I agree, and in times like this, it's best to use common sense rather
than trying to have a rule to fit everything into. In this case, Rob
and the security team have put forth an explanation of what happened,
I fail to see how removing them after this does anything other than
foster bad will. I would vote to keep the security team around at this
point.

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

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

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Kyle Mestery]

On Tue, Jun 14, 2016 at 9:15 AM, Doug Hellmann  wrote:
> Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
>> Hi everyone,
>>
>> I just proposed a new requirement for OpenStack "official" projects,
>> which I think is worth discussing beyond the governance review:
>>
>> https://review.openstack.org/#/c/329448/
>>
>>  From an upstream perspective, I see us as being in the business of
>> providing open collaboration playing fields in order to build projects
>> to reach the OpenStack Mission. We collectively provide resources
>> (infra, horizontal teams, events...) in order to enable that open
>> collaboration.
>>
>> An important characteristic of these open collaboration grounds is that
>> they need to be a level playing field, where no specific organization is
>> being given an unfair advantage. I expect the teams that we bless as
>> "official" project teams to operate in that fair manner. Otherwise we
>> end up blessing what is essentially a trojan horse for a given
>> organization, open-washing their project in the process. Such a project
>> can totally exist as an unofficial project (and even be developed on
>> OpenStack infrastructure) but I don't think it should be given free
>> space in our Design Summits or benefit from "OpenStack community" branding.
>>
>> So if, in a given project team, developers from one specific
>> organization benefit from access to specific knowledge or hardware
>> (think 3rd-party testing blackboxes that decide if a patch goes in, or
>> access to proprietary hardware or software that the open source code
>> primarily interfaces with), then this project team should probably be
>> rejected under the "open community" rule. Projects with a lot of drivers
>> (like Cinder) provide an interesting grey area, but as long as all
>> drivers are in and there is a fully functional (and popular) open source
>> implementation, I think no specific organization would be considered as
>> unfairly benefiting compared to others.
>>
>> A few months ago we had the discussion about what "no open core" means
>> in 2016, in the context of the Poppy team candidacy. With our reading at
>> the time we ended up rejecting Poppy partly because it was interfacing
>> with proprietary technologies. However, I think what we originally
>> wanted to ensure with this rule was that no specific organization would
>> use the OpenStack open source code as crippled bait to sell their
>> specific proprietary add-on.
>>
>> I think taking the view that OpenStack projects need to be open, level
>> collaboration playing fields encapsulates that nicely. In the Poppy
>> case, nobody in the Poppy team has an unfair advantage over others, so
>> we should not reject them purely on the grounds that this interfaces
>> with non-open-source solutions (leaving only the infrastructure/testing
>> requirement to solve). On the other hand, a Neutron plugin targeting a
>> specific piece of networking hardware would likely give an unfair
>> advantage to developers of the hardware's manufacturer (having access to
>> that gear for testing and being able to see and make changes to its
>> proprietary source code) -- that project should probably live as an
>> unofficial OpenStack project.
>>
>> Comments, thoughts ?
>>
>
> I think external device-specific drivers are a much clearer case than
> Poppy or Cinder. It's a bit unfortunate that the dissolution of some
> projects into "core" and "driver" repositories is raising this issue,
> but we've definitely had better success with some project teams than
> others when it comes to vendors collaborating on core components.
>

I don't see this as the "core and driver" problem bringing this issue
up, as it exists out side of that. But it's true that in the case of
Neutron, something had to give when we had 40+ drivers and a handful
of cores maintaining both the neutron code itself and those drivers.

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

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

Re: [openstack-dev] [neutron][networking-ovn] OVN vs. OpenDayLight

[Kyle Mestery]

On Thu, Jun 9, 2016 at 4:19 PM, Assaf Muller <as...@redhat.com> wrote:
> On Thu, Jun 9, 2016 at 5:06 PM, Kyle Mestery <mest...@mestery.com> wrote:
>> On Thu, Jun 9, 2016 at 2:11 PM, Assaf Muller <as...@redhat.com> wrote:
>>> On Thu, Jun 9, 2016 at 1:48 PM, Ben Pfaff <b...@ovn.org> wrote:
>>>> On Thu, Jun 09, 2016 at 10:28:31AM -0700, rezroo wrote:
>>>>> I'm trying to reconcile differences and similarities between OVN and
>>>>> OpenDayLight in my head. Can someone help me compare these two 
>>>>> technologies
>>>>> and explain if they solve the same problem, or if there are fundamental
>>>>> differences between them?
>>>>
>>>> OVN implements network virtualization for clouds of VMs or containers or
>>>> a mix.  Open Daylight is a platform for managing networks that can do
>>>> anything you want.
>>>
>>> That is true, but when considering a Neutron backend for OpenStack
>>> deployments, people choose a subset of OpenDaylight projects and the
>>> end result is a solution that is comparable in scope and feature set.
>>> There are objective differences in where the projects are in their
>>> lifetime, the HA architecture, the project's consistency model between
>>> the neutron-server process and the backend, the development velocity,
>>> the community size and the release model.
>>>
>> Fundamentally, the main difference is that OVN does one thing: It does
>> network virtualization. OpenDaylight _MAY_ do network virtualization,
>> among other things, and it likely does network virtualization in many
>> different ways. Like Ben said:
>>
>> "Open Daylight is a platform for managing networks that can do
>> anything you want."
>
> I agree, but I don't think that was what was asked or makes for an
> interesting discussion. I think the obvious comparison is OVN to
> ML2/ODL using the ovsdb ODL project.
>
OK, I'll bite. :)

Fundamentally, a project's focus is absolutely important, especially
when a comparison is asked. When you ask the question: "How can OVN or
ODL solve being a backend layer for Neutron?", for example, the answer
with OVN is simple: You do it this way, and it works. For ODL, the
question is much more nuanced, as it depends on *what* components in
ODL you are using.

Also, yes, the comparison between "ML2+python agents" vs. "ML2+OVN" is
much more relevant IMHO.

Thanks!
Kyle

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

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

Re: [openstack-dev] [neutron][networking-ovn] OVN vs. OpenDayLight

[Kyle Mestery]

On Thu, Jun 9, 2016 at 2:11 PM, Assaf Muller  wrote:
> On Thu, Jun 9, 2016 at 1:48 PM, Ben Pfaff  wrote:
>> On Thu, Jun 09, 2016 at 10:28:31AM -0700, rezroo wrote:
>>> I'm trying to reconcile differences and similarities between OVN and
>>> OpenDayLight in my head. Can someone help me compare these two technologies
>>> and explain if they solve the same problem, or if there are fundamental
>>> differences between them?
>>
>> OVN implements network virtualization for clouds of VMs or containers or
>> a mix.  Open Daylight is a platform for managing networks that can do
>> anything you want.
>
> That is true, but when considering a Neutron backend for OpenStack
> deployments, people choose a subset of OpenDaylight projects and the
> end result is a solution that is comparable in scope and feature set.
> There are objective differences in where the projects are in their
> lifetime, the HA architecture, the project's consistency model between
> the neutron-server process and the backend, the development velocity,
> the community size and the release model.
>
Fundamentally, the main difference is that OVN does one thing: It does
network virtualization. OpenDaylight _MAY_ do network virtualization,
among other things, and it likely does network virtualization in many
different ways. Like Ben said:

"Open Daylight is a platform for managing networks that can do
anything you want."

Thanks,
Kyle

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

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

Re: [openstack-dev] [Neutron][Release] Changing release model for *-aas services

[Kyle Mestery]

On Tue, May 31, 2016 at 1:12 PM, Armando M.  wrote:
> Hi folks,
>
> Having looked at the recent commit volume that has been going into the *-aas
> repos, I am considering changing the release model for neutron-vpnaas,
> neutron-fwaas, neutron-lbaas from release:cycle-with-milestones [1] to
> release:cycle-with-intermediary [2]. This change will allow us to avoid
> publishing a release at fixed times when there's nothing worth releasing.
>
> I'll follow up with a governance change, as I know of the imminent deadline
> [3].
>
> Thoughts?
> Armando
>
+1, I've voted as such on the reivew as well [4].

[4] https://review.openstack.org/#/c/323522/

> [1]
> https://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
> [2]
> https://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html
> [3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095490.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Kyle Mestery]

On Wed, May 25, 2016 at 3:55 PM, Armando M. <arma...@gmail.com> wrote:
>
>
> On 25 May 2016 at 13:31, Elzur, Uri <uri.el...@intel.com> wrote:
>>
>> Kyle
>>
>> Thx for your comment. I think these are orthogonal discussions. The heart
>> of this one, for me, and in the Neutron context, is plotting a road forward
>> on new technologies INDEPENDENT of external (even if related) open source
>> projects. I like Armando's direction.
>>
>> The best of my understanding (granted, limited) is that the OvS official
>> position is not supportive of gpe and NSH as long as the Linux Kernel
>> doesn't have them. So we are in a nice little spiral for >2 years, which is
>> really long time if we want to have a reasonable pace of new technology
>> adoption
>>
>
> It would be nice to understand what the concerns are and how to resolve them
> in order to try and find a path where things can be reconciled later on.
> Technology adoption will always be hindered by the potential risk of dealing
> with fork down the road.
>
Fundamentally, I think we just need to draw a hard line in the sand
that we won't be testing things in the gate which carry patches for
downstream components. Once these things land in the kernel and OVS,
they can easily be supported upstream. We've done this for OVS
features for years. Uri is bringing an argument to the wrong place,
IMHO.

>>
>> The IETF is already last call and open source support ???
>>
>> Thx
>>
>> Uri (“Oo-Ree”)
>> C: 949-378-7568
>>
>>
>> -Original Message-
>> From: Kyle Mestery [mailto:mest...@mestery.com]
>> Sent: Wednesday, May 25, 2016 1:00 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>>
>> On Wed, May 25, 2016 at 2:29 PM, Elzur, Uri <uri.el...@intel.com> wrote:
>> > Armando
>> >
>> >
>> >
>> > I’m asking for a clear answer “I think the position here is as
>> > follows: if a technology is not mainstream, i.e. readily available via
>> > distros and the various channels, it can only be integrated via an
>> > experimental path”
>> >
>> >
>> >
>> > If we can allow for the EXPERIMENTAL path for NSH, then we can stand
>> > up the whole stack in EXPERIMENTAL mode and quickly move to mainstream
>> > when other pieces outside of Neutron fall in place.
>> >
>> >
>> >
>> > As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret
>> > your response correctly, that unlike their future intention for OVN,
>> > OvS is not willing to signal interest in integrating NSH
>> >
>> Would this be a better thing to discuss on the ovs-dev list [1] rather
>> than the openstack-dev list? I'm sure the OVS devs would be happy to
>> continue a discussion about the possibility of using VXLAN+NSH over GENEVE
>> there.
>>
>> [1] http://mail.openvswitch.org/mailman/listinfo/dev
>>
>> >
>> >
>> > Thx
>> >
>> >
>> >
>> > Uri (“Oo-Ree”)
>> >
>> > C: 949-378-7568
>> >
>> >
>> >
>> > From: Armando M. [mailto:arma...@gmail.com]
>> > Sent: Wednesday, May 25, 2016 9:33 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > <openstack-dev@lists.openstack.org>
>> >
>> > Subject: Re: [openstack-dev] [Neutron] support of NSH in
>> > networking-SFC
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:
>> >
>> > Hi Tim
>> >
>> > Sorry for the delay due to travel...
>> >
>> > This note is very helpful!
>> >
>> > We are in agreement that the team including the individuals cited
>> > below are supportive. We also agree that SFC belongs in the
>> > networking-SFC project (with proper API adjustment)
>> >
>> > It seems networking-sfc still holds the position that without OvS
>> > accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying
>> > to get a clear read on where is this stated as requirement
>> >
>> >
>> >
>> > I think the position here is as follows: if a technology is not
>> > mainstream, i.e. readily available via distros and the various
>> > channels, it can only be integrated via an experimen

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Kyle Mestery]

On Wed, May 25, 2016 at 2:29 PM, Elzur, Uri  wrote:
> Armando
>
>
>
> I’m asking for a clear answer “I think the position here is as follows: if a
> technology is not mainstream, i.e. readily available via distros and the
> various channels, it can only be integrated via an experimental path”
>
>
>
> If we can allow for the EXPERIMENTAL path for NSH, then we can stand up the
> whole stack in EXPERIMENTAL mode and quickly move to mainstream when other
> pieces outside of Neutron fall in place.
>
>
>
> As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret your
> response correctly, that unlike their future intention for OVN,  OvS is not
> willing to signal interest in integrating NSH
>
Would this be a better thing to discuss on the ovs-dev list [1] rather
than the openstack-dev list? I'm sure the OVS devs would be happy to
continue a discussion about the possibility of using VXLAN+NSH over
GENEVE there.

[1] http://mail.openvswitch.org/mailman/listinfo/dev

>
>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> From: Armando M. [mailto:arma...@gmail.com]
> Sent: Wednesday, May 25, 2016 9:33 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
>
>
>
>
>
>
> On 24 May 2016 at 21:53, Elzur, Uri  wrote:
>
> Hi Tim
>
> Sorry for the delay due to travel...
>
> This note is very helpful!
>
> We are in agreement that the team including the individuals cited below are
> supportive. We also agree that SFC belongs in the networking-SFC project
> (with proper API adjustment)
>
> It seems networking-sfc still holds the position that without OvS accepting
> VXLAN-gpe and NSH patches they can't support NSH. I'm trying to get a clear
> read on where is this stated as requirement
>
>
>
> I think the position here is as follows: if a technology is not mainstream,
> i.e. readily available via distros and the various channels, it can only be
> integrated via an experimental path. No-one is preventing anyone from
> posting patches and instructions to compile kernels and kernel modules, but
> ultimately as an OpenStack project that is suppose to produce commercial and
> production grade software, we should be very sensitive in investing time and
> energy in supporting a technology that may or may not have a viable path
> towards inclusion into mainstream (Linux and OVS in this instance).
>
>
>
> One another clear example we had in the past was DPDK (that enabled fast
> path processing in Neutron with OVS) and connection tracking (that enabled
> security groups natively build on top of OVS). We, as a project have
> consistently avoided endorsing efforts until they mature and show a clear
> path forward.
>
>
>
>
> Like you, we are closely following the progress of the patches and honestly
> I have hard time seeing OpenStack supporting NSH in production even by the
> end of 2017. I think this amounts to slowing down the market...
>
> I think we need to break the logjam.
>
>
>
> We are not the ones (Neutron) you're supposed to break the logjam with. I
> think the stakeholders here go well beyond the Neutron team alone.
>
>
>
>
> I've reviewed
> (https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and found nowhere a guideline suggesting that before a backend has fully
> implemented and merged upstream a technology (i.e. another project outside
> of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2
> years to support NSH using patches, yet to be accepted into Linux Kernel
> (almost done) and OvS (preliminary) - as you stated. Otherwise we create a
> serialization, that gets worse and worse over time and with additional
> layers.
>
> No one suggests the such code needs to be PRODUCTION, but we need a way to
> roll out EXPERIMENTAL functions and later merge them quickly when all layers
> are ready, this creates a nice parallelism and keeps a decent pace of
> rolling out new features broadly supported elsewhere.
>
>
>
> I agree with this last statement; this is for instance what is happening
> with OVN which, in order to work with Neutron, needs patching and stay close
> to trunk etc. The technology is still maturing and the whole Neutron
> integration is in progress, but at least there's a clear signal that the it
> will eventually become mainstream. If it did not, I would bet that
> priorities would be focused elsewhere.
>
>
>
> You asked in a previous email whether Neutron wanted to kept itself hostage
> of OVS. My answer to you is NO: we have many technology stack options we can
> rely on in order to realize abstractions so long as they are open, and have
> a viable future.
>
>
>
>
> Thx
>
> Uri (“Oo-Ree”)
> C: 949-378-7568
>
> -Original Message-
> From: Tim Rozet [mailto:tro...@redhat.com]
> Sent: Friday, May 20, 2016 7:01 PM
> To: OpenStack Development Mailing List (not for 

Re: [openstack-dev] [neutron][stable] proposing Brian Haley for neutron-stable-maint

[Kyle Mestery]

+1 (Also +1 for Cedric).

On Tue, May 17, 2016 at 6:07 AM, Ihar Hrachyshka  wrote:
> Hi stable-maint-core and all,
>
> I would like to propose Brian for neutron specific stable team.
>
> His stats for neutron stable branches are (last 120 days):
>
> mitaka: 19 reviews; liberty: 68 reviews (3rd place in the top); kilo: 16 
> reviews.
>
> Brian helped the project with stabilizing liberty neutron/DVR jobs, and with 
> other L3 related stable matters. In his stable reviews, he shows attention to 
> details.
>
> If Brian is added to the team, I will make sure he is aware of all stable 
> policy intricacies.
>
> Side note: recently I added another person to the team (Cedric Brandilly), 
> and now I realize that I haven’t followed the usual approval process. That 
> said, the person also has decent stable review stats, and is aware of the 
> policy. If someone has doubts about that addition to the team, please ping me 
> and we will discuss how to proceed.
>
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][devstack] State of the refactor

[Kyle Mestery]

On Thu, May 5, 2016 at 11:12 AM, Monty Taylor  wrote:
> On 05/05/2016 10:57 AM, Sean M. Collins wrote:
>>
>> During the Austin summit, there was a discussion in the QA meetings
>> about the future of Neutron's support in DevStack. It's been an ongoing
>> effort, and I'd like to step back and give everyone a view of the Big
>> Picture.
>>
>> https://etherpad.openstack.org/p/newton-qa-devstack-roadmap
>>
>> A year ago at the NYC QA midcycle, consensus was reached that in order
>> to get Neutron to become the default deployment model for Devstack and
>> finally deprecate Nova-Network, some grunt work would need to be done to
>> clean up the DevStack code.
>>
>> Dean wrote about the experience in his blog:
>>
>> http://hackstack.org/x/blog/2015/03/30/qa-code-sprint
>>
>>> DevStack's Neutron code is in bad shape. It has been continually
>>> updated by many people who do not understand the Big Picture. I blame
>>> myself for not staying on top of this code and allowing it to diverge
>>> from the rest of DevStack's style and implementation. Other Sean found
>>> a number of inconsistencies in variable names and uses as he tried to
>>> get the single interface work done and we came to the inevitable
>>> conclusion that it was time to start over.
>>
>>
>> So we did.
>>
>> https://review.openstack.org/168438
>>
>> The new lib/neutron is an attempt to only have the *bare minimum*
>> configured for either an OVS or Linux Bridge deployment of Neutron. My
>> strategy was - start from scratch and build up enough Neutron
>> configuration to get everything to launch, and have the network plumbed
>> correctly. Everything else was left on the cutting room floor.
>>
>> There are still some things that I did for the sake of expediency, that
>> I am sure will need to be improved in the future. However, the code is
>> very close to completion - there's still some work that needs to be
>> done, but I see the light at the end of the tunnel.
>>
>> For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
>> share this view:
>>
>>> But what about the plugins? What about the advanced services? What
>>> about the vendors? I can't do it all at once. The first priority is to
>>> get a 'minimum viable Neutron' configuration to use as the default.
>>> The old code was renamed not removed, and exactly zero of the
>>> configuration variables and service names have changed. Nothing should
>>> be directly importing lib/neutron* so that change is handled in
>>> DevStack and Grenade already. After we have working linuxbridge and
>>> ovs configurations we can look at what else needs to be included.
>>
>>
>> Sean Dague and I have also been kicking around some ideas about adding
>> another hook to the DevStack plugin contract so that DevStack plugins
>> that do network things have a chance to create networks and wire
>> everything during installation and configuration, as part of a DevStack
>> plugin call.
>>
>> The basic reasoning for this is, the current lib/neutron-legacy has tons
>> of knobs for plugging veths into things, creating provider networks,
>> etc.. - those things are very specific to a deployment or networking
>> type, so they should be moved into a plugin so they don't gunk up the
>> main code path and also avoid trampling one another (like they do
>> today).
>>
>> The current lib/neutron weighs in around 500 lines of code, and the l3
>> setup code (which was the nastiest) is 300 lines, split out into a
>> separate file. Partially to allow other plugins to call this code, and
>> partially because of a divide-and-conquer strategy I am employing for
>> the refactor.
>>
>> If you haven't read my post about eliminating the DevStack layer, this
>> is also part of my thought process for the refactor, and how to support
>> other configurations in DevStack.
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html
>>
>> So, take a look at what I've done so far, take it for a spin, and if you
>> have any thoughts or ideas please share them!
>
>
> Everything about this is the best thing that has ever happened since the
> dawn of time.
>

<3

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

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

Re: [openstack-dev] [neutron][tc] Neutron stadium evolution from Austin

[Kyle Mestery]

On Mon, May 2, 2016 at 12:22 PM, Armando M.  wrote:
>
>
> On 30 April 2016 at 14:24, Fawad Khaliq  wrote:
>>
>> Hi folks,
>>
>> Hope everyone had a great summit in Austin and got back safe! :)
>>
>> At the design summit, we had a Neutron stadium evolution session, which
>> needs your immediate attention as it will impact many stakeholders of
>> Neutron.
>
>
> It's my intention to follow up with a formal spec submission to
> neutron-specs as soon as I recover from the trip. Then you'll have a more
> transparent place to voice your concern.
>
>>
>>
>> To summarize for everyone, our Neutron leadership made the following
>> proposal for the “greater-good” of Neutron to improve and reduce burden on
>> the Neutron PTL and core team to avoid managing more Neutron drivers:
>
>
> It's not just about burden. It's about consistency first and foremost.
>
>>
>>
>> Quoting the etherpad [1]
>>
>> "No request for inclusion are accepted for projects focussed solely on
>> implementations and/or API extensions to non-open solutions."
>
>
> By the way, this was brought forward and discussed way before the Summit. In
> fact this is already implemented at the Neutron governance level [1].
>
>>
>> To summarize for everyone what this means is that all Neutron drivers,
>> which implement non open source networking backends are instantly out of the
>> Neutron stadium and are marked as "unofficial/unsupported/remotely
>> affiliated" and rest are capable of being tagged as "supported/official”.
>
>
> Totally false.
>
> All this means is that these projects do not show up in list [1] (minus [2],
> which I forgot): ie. these projects are the projects the Neutron team
> vouches for. Supportability is not a property tracked by this list. You,
> amongst many, should know that it takes a lot more than being part of a list
> to be considered a supported solution, and I am actually even surprised that
> you are misled/misleading by bringing 'support' into this conversation.
>
> [1] http://governance.openstack.org/reference/projects/neutron.html
> [2] https://review.openstack.org/#/c/309618/
>
>>
>>
>> This eliminates all commercial Neutron drivers developed for many service
>> providers and enterprises who have deployed OpenStack successfully with
>> these drivers. It’s unclear how the OpenStack Foundation will communicate
>> its stance with all the users but clearly this is a huge set back for
>> OpenStack and Neutron. Neutron will essentially become closed to all
>> existing, non-open drivers, even if these drivers have been compliant with
>> Neutron API for years and users have them deployed in production, forcing
>> users to re-evaluate their options.
>
>
> Again, totally false.
>
> The Neutron team will continue to stand behind the APIs and integration
> mechanisms in a way that made the journey of breaking down the codebase as
> we know it today possible. Any discussion of evolving these has been done
> and will be done in the open and with the support of all parties involved,
> non-open solutions included.
>
>>
>>
>> Furthermore, this proposal will erode confidence in Neutron and OpenStack,
>> and destroy much of the value that the community has worked so hard to build
>> over the years.
>>
>>
>> As a representative and member of the OpenStack community and maintainer
>> of a Neutron driver (since Grizzly), I am deeply disappointed and disagree
>> with this statement [2]. Tossing out all the non-open solutions is not in
>> the best interest of the end user companies that have built working
>> OpenStack clusters. This proposal will lead OpenStack end users who deployed
>> different drivers to think twice about OpenStack communities’ commitment to
>> deliver solutions they need. Furthermore, this proposal punishes OpenStack
>> companies who developed commercial backend drivers to help end users bring
>> up OpenStack clouds.
>
>
> What? Now you're just spreading FUD.
>
> What is being discussed in that etherpad is totally in line with [1], which
> you approved and stood behind, by the way! No-one is breaking anything,
> we're simply better reflecting what initiatives the Neutron core team is
> supposed to be accountable for and, as a result, empower the individual core
> teams of those vendor drivers. I appreciate there might be a gap in where to
> describe the effort of these initiatives in [2], but I believe there's
> something like the marketplace [3] that's better suited for what you're
> after. IMO, [2] was never intended to be that place, and I stand corrected
> if not.
>
> [1] https://review.openstack.org/#/c/309618/
> [2] http://governance.openstack.org/
> [3] https://www.openstack.org/marketplace/drivers/
>
To further support Armando here, I agree that the marketplace is the
best place to host these drivers. In fact, Thierry and I briefly
discussed this, and I think advocating for the Foundation to help put
in place more of a specific drivers program and manage it makes a lot
of sense, 

Re: [openstack-dev] [neutron] Social at the summit

[Kyle Mestery]

Folks, unfortunately this will have to be postponed. I was too busy doing a 
standup routine with Armando to find another place. Apologies.

Thanks,
Kyle

> On Apr 28, 2016, at 12:02 PM, Darek Smigiel <smigiel.dari...@gmail.com> wrote:
> 
> Unfortunately, I’ve got response from Bangers, that they’re fully booked for 
> Today
> 
> "Thank you for your interest in hosting a business dinner with us at Banger's 
> tonight. Unfortunately we are booked with reservations this evening, so I am 
> unable to accommodate your request. I wish you all the best in finding the 
> perfect venue for your event.”
> 
> Are we trying to find some other spot, or just keep Bangers and we will see?
> 
> Darek
> 
>> On Apr 26, 2016, at 8:27 PM, Kyle Mestery <mest...@mestery.com> wrote:
>> 
>> I propose we meet at Bangers on Rainey St. at 6PM. I don't have a 
>> reservation but it should be able to hold 50+ people. See y'all at 6PM 
>> Thursday!
>> 
>> Kyle
>> 
>>> On Apr 25, 2016, at 1:07 PM, Kyle Mestery <mest...@mestery.com> wrote:
>>> 
>>> OK, there is enough interest, I'll find a place on 6th Street for us
>>> and get a reservation for Thursday around 7 or so.
>>> 
>>> Thanks folks!
>>> 
>>>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han <hzh...@ebay.com> wrote:
>>>> +1 :)
>>>> 
>>>> Han Zhou
>>>> Irc: zhouhan
>>>> 
>>>> 
>>>> On Monday, April 25, 2016, Korzeniewski, Artur
>>>> <artur.korzeniew...@intel.com> wrote:
>>>>> 
>>>>> Sign me up :)
>>>>> 
>>>>> Artur
>>>>> IRC: korzen
>>>>> 
>>>>> -Original Message-
>>>>> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>>>>> Sent: Monday, April 25, 2016 7:19 PM
>>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>>> <openstack-dev@lists.openstack.org>
>>>>> Subject: Re: [openstack-dev] [neutron] Social at the summit
>>>>> 
>>>>> Count me in!
>>>>> Will be good to meet all you guys!
>>>>> 
>>>>> Darek (dasm) Smigiel
>>>>> 
>>>>>> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>>>>>> <doug...@parksidesoftware.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka <ihrac...@redhat.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> WAT???
>>>>>>> 
>>>>>>> It was never supposed to be core only. Everyone is welcome!
>>>>>> 
>>>>>> +2
>>>>>> 
>>>>>> irony intended.
>>>>>> 
>>>>>> Socials are not controlled by gerrit ACLs.  :-)
>>>>>> 
>>>>>> doug
>>>>>> 
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>>> On 25 Apr 2016, at 11:56, Edgar Magana <edgar.mag...@workday.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Would you extend it to ex-cores?
>>>>>>>> 
>>>>>>>> Edgar
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 4/25/16, 10:55 AM, "Kyle Mestery" <mest...@mestery.com> wrote:
>>>>>>>>> 
>>>>>>>>> Ihar, Henry and I were talking and we thought Thursday night makes
>>>>>>>>> sense for a Neutron social in Austin. If others agree, reply on this 
>>>>>>>>> thread
>>>>>>>>> and we'll find a place.
>>>>>>>>> 
>>>>>>>>> Thanks!
>>>>>>>>> Kyle
>>>>>>>>> 
>>>>>>>>> ___
>>>>>>>>> ___ OpenStack Development Mailing List (not for usage
>>>>>>>>> questions)
>>>>>>>>> Unsubscribe:
>>>>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

Re: [openstack-dev] [neutron] Social at the summit

[Kyle Mestery]

I propose we meet at Bangers on Rainey St. at 6PM. I don't have a reservation 
but it should be able to hold 50+ people. See y'all at 6PM Thursday!

Kyle

> On Apr 25, 2016, at 1:07 PM, Kyle Mestery <mest...@mestery.com> wrote:
> 
> OK, there is enough interest, I'll find a place on 6th Street for us
> and get a reservation for Thursday around 7 or so.
> 
> Thanks folks!
> 
>> On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han <hzh...@ebay.com> wrote:
>> +1 :)
>> 
>> Han Zhou
>> Irc: zhouhan
>> 
>> 
>> On Monday, April 25, 2016, Korzeniewski, Artur
>> <artur.korzeniew...@intel.com> wrote:
>>> 
>>> Sign me up :)
>>> 
>>> Artur
>>> IRC: korzen
>>> 
>>> -Original Message-
>>> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>>> Sent: Monday, April 25, 2016 7:19 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> <openstack-dev@lists.openstack.org>
>>> Subject: Re: [openstack-dev] [neutron] Social at the summit
>>> 
>>> Count me in!
>>> Will be good to meet all you guys!
>>> 
>>> Darek (dasm) Smigiel
>>> 
>>>> On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>>>> <doug...@parksidesoftware.com> wrote:
>>>> 
>>>> 
>>>>> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka <ihrac...@redhat.com>
>>>>> wrote:
>>>>> 
>>>>> WAT???
>>>>> 
>>>>> It was never supposed to be core only. Everyone is welcome!
>>>> 
>>>> +2
>>>> 
>>>> irony intended.
>>>> 
>>>> Socials are not controlled by gerrit ACLs.  :-)
>>>> 
>>>> doug
>>>> 
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On 25 Apr 2016, at 11:56, Edgar Magana <edgar.mag...@workday.com>
>>>>>> wrote:
>>>>>> 
>>>>>> Would you extend it to ex-cores?
>>>>>> 
>>>>>> Edgar
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 4/25/16, 10:55 AM, "Kyle Mestery" <mest...@mestery.com> wrote:
>>>>>>> 
>>>>>>> Ihar, Henry and I were talking and we thought Thursday night makes
>>>>>>> sense for a Neutron social in Austin. If others agree, reply on this 
>>>>>>> thread
>>>>>>> and we'll find a place.
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> Kyle
>>>>>>> 
>>>>>>> ___
>>>>>>> ___ OpenStack Development Mailing List (not for usage
>>>>>>> questions)
>>>>>>> Unsubscribe:
>>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>> 
>>>>>> __ OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> 
>>>>> _
>>>>> _ OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>>> 
>>>> __
>>>>  OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 

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

Re: [openstack-dev] [neutron] Social at the summit

[Kyle Mestery]

OK, there is enough interest, I'll find a place on 6th Street for us
and get a reservation for Thursday around 7 or so.

Thanks folks!

On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han <hzh...@ebay.com> wrote:
> +1 :)
>
> Han Zhou
> Irc: zhouhan
>
>
> On Monday, April 25, 2016, Korzeniewski, Artur
> <artur.korzeniew...@intel.com> wrote:
>>
>> Sign me up :)
>>
>> Artur
>> IRC: korzen
>>
>> -Original Message-
>> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>> Sent: Monday, April 25, 2016 7:19 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron] Social at the summit
>>
>> Count me in!
>> Will be good to meet all you guys!
>>
>> Darek (dasm) Smigiel
>>
>> > On Apr 25, 2016, at 12:13 PM, Doug Wiegley
>> > <doug...@parksidesoftware.com> wrote:
>> >
>> >
>> >> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka <ihrac...@redhat.com>
>> >> wrote:
>> >>
>> >> WAT???
>> >>
>> >> It was never supposed to be core only. Everyone is welcome!
>> >
>> > +2
>> >
>> > irony intended.
>> >
>> > Socials are not controlled by gerrit ACLs.  :-)
>> >
>> > doug
>> >
>> >>
>> >> Sent from my iPhone
>> >>
>> >>> On 25 Apr 2016, at 11:56, Edgar Magana <edgar.mag...@workday.com>
>> >>> wrote:
>> >>>
>> >>> Would you extend it to ex-cores?
>> >>>
>> >>> Edgar
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>> On 4/25/16, 10:55 AM, "Kyle Mestery" <mest...@mestery.com> wrote:
>> >>>>
>> >>>> Ihar, Henry and I were talking and we thought Thursday night makes
>> >>>> sense for a Neutron social in Austin. If others agree, reply on this 
>> >>>> thread
>> >>>> and we'll find a place.
>> >>>>
>> >>>> Thanks!
>> >>>> Kyle
>> >>>>
>> >>>> ___
>> >>>> ___ OpenStack Development Mailing List (not for usage
>> >>>> questions)
>> >>>> Unsubscribe:
>> >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>> 
>> >>> __ OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe:
>> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >> _
>> >> _ OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> > __
>> >  OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [neutron] Social at the summit

[Kyle Mestery]

Ihar, Henry and I were talking and we thought Thursday night makes sense for a 
Neutron social in Austin. If others agree, reply on this thread and we'll find 
a place.

Thanks!
Kyle

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

Re: [openstack-dev] [neutron][api] advanced search criteria

[Kyle Mestery]

On Mon, Apr 4, 2016 at 7:36 PM, Armando M.  wrote:
>
>
> On 4 April 2016 at 17:08, Jay Pipes  wrote:
>>
>> On 04/04/2016 06:57 PM, Ihar Hrachyshka wrote:
>>>
>>> - why do we even need to control those features with configuration
>>> options? can we deprecate and remove them?
>>
>>
>> This would be my choice. Configuration options that make the Neutron API
>> behave differently from one deployment to another should be put out to
>> pasture.
>
>
> So long as we figure out a way to provide support these capabilities
> natively, I agree that we should stop using config options to alter API
> behavior. This is undiscoverable by the end user, who is left with the only
> choice of poking at the API to see how it responds.
>
Which is at best an awful user experience.

So +1 to removing them.

Kyle

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

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

Re: [openstack-dev] [Neutron][networking-ovn] Changing OVN plugin release model for Newton

[Kyle Mestery]

On Mon, Apr 4, 2016 at 8:15 AM, Russell Bryant  wrote:
> Hello, everyone.
>
> While bootstrapping networking-ovn, the release model has been
> "release:independent" [1], though we haven't actually made any releases.
> This follows the state of OVN itself, which is still fast moving and
> developed in OVS master.
>
> On the OVN side, we're now targeting a first production release in time for
> the OpenStack Newton release.  We aim to branch OVS (which includes OVN) in
> July and release by September or so.
>
> I think it's time to start making releases of the Neutron plugin.  I suggest
> we adopt "release:cycle-with-milestones" [2] to match the primary Neutron
> repositories.
>
> Thoughts?
>
+1, this makes sense to me. As you say, the eminent release of an OVN
release itself should trigger changes in the release model for the
plugin as well.

Are you going to propose a governance patch to reflect this?

Thanks!
Kyle

> [1] http://governance.openstack.org/reference/tags/release_independent.html
> [2]
> http://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron] Mitaka Mid-Cycle Coding Sprint Registration

[Kyle Mestery]

On Mon, Feb 15, 2016 at 10:33 AM, Anita Kuno <ante...@anteaya.info> wrote:
> On 02/15/2016 04:06 PM, Kyle Mestery wrote:
>> Hi folks!
>>
>> The mid-cycle is almost upon us. IBM, as the sponsor company, is
>> requesting some information from everyone is registered (name, email,
>> company, US citizen or not), so please make sure to register on the
>> Eventbrite site I've created here [1]. If everyone who's attending
>> could please do that by tomorrow that would help our sponsors a lot!
>>
>> Thank you!
>> Kyle
>>
>> [1] 
>> https://www.eventbrite.com/e/neutron-mitaka-mid-cycle-coding-sprint-tickets-21634783219
>>
>> __
>> 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
>>
>
> I just registered using this link and was asked for my email and first
> and last name.
>
> I wasn't asked for my country of citizenship nor was I asked for the
> name of the folks who send me paycheques.
>
I've updated the eventbrite to acquire both of those bits of information.

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

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

[openstack-dev] [neutron] Mitaka Mid-Cycle Coding Sprint Registration

[Kyle Mestery]

Hi folks!

The mid-cycle is almost upon us. IBM, as the sponsor company, is
requesting some information from everyone is registered (name, email,
company, US citizen or not), so please make sure to register on the
Eventbrite site I've created here [1]. If everyone who's attending
could please do that by tomorrow that would help our sponsors a lot!

Thank you!
Kyle

[1] 
https://www.eventbrite.com/e/neutron-mitaka-mid-cycle-coding-sprint-tickets-21634783219

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

Re: [openstack-dev] [neutron][stable] Request to do stable point releases more often if there are going to be a lot of backports

[Kyle Mestery]

On Tue, Feb 9, 2016 at 10:10 AM, Matt Riedemann
 wrote:
> While reviewing the neutron 7.0.2 stable/liberty point release, I noticed
> there were a lot of changes since 7.0.1. [1]
>
> There are 48 non-merge commits by my count.
>
> While there is no rule about how many backports should land before we cut a
> point release, it would be helpful on reviewers for the release request if
> it was fewer than 48. :)
>
Absolutely, and in fact I have 7.0.3 out for review now [1] with far
fewer changes.

[1] https://review.openstack.org/274880

> I think the Neutron team is by far the most active in backporting changes to
> stable, which is good. We might want to consider releasing more often though
> if the backport rate is going to be this high.
>
++

> I'd also be interested in hearing from deployers/operators (if any are
> reading this) to know how frequently they are picking up stable point
> releases, or if they are taking an approach of waiting to upgrade from kilo
> to liberty until there have at least been a few stable/liberty point
> releases across the projects.
>
> [1]
> http://logs.openstack.org/88/272688/2/check/gate-releases-tox-list-changes/aa8e270/console.html.gz
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

[Kyle Mestery]

On Fri, Feb 5, 2016 at 10:50 AM, John Belamaric  wrote:
> Hi all,
>
> Back in November, there was a discussion [1] on the mailing list around 
> release:independent projects, which was wrapped up by Thierry in [2]. 
> However, I have a couple lingering questions that have come up.
>
> In networking-infoblox, we have a 1.0.0 version of our driver that we 
> released a few months ago, and it is maintained in a the stable/liberty 
> branch. We just released 2.0.0 out of master, but 2.0.0 is compatible with 
> Liberty and Mitaka. So, from a branching perspective, is it permissible to 
> push all the 2.0.0 changes into stable/liberty? Those would be largely 
> functional changes, not simple bug fixes. If not, should we even *have* a 
> stable/liberty branch?
>
If you're in the Neutron Stadium, and thus following OpenStack stable
backport rules, you cannot backport functional features like you want.
If you remove yourself from the stadium, you don't have that issue and
can backport whatever you want to whatever branch you want. This is
why for some vendor networking sub-projects it may make more sense to
be outside the stadium, because it would align with how you want to do
your own releases.

> The primary reason this is important is to ensure that users and distributors 
> pull the correct version of the driver. The 1.0.0 version is pretty limited 
> and we definitely want the 2.0.0 to be the one packaged with Liberty 
> distributions. So, ideally we would be able to push all the 2.0.0 code into 
> stable/liberty since it is completely compatible - that would make it simple 
> for distributors to get the right driver.
>
> John
>
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/thread.html#78676
> [2] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Kyle Mestery]

On Thu, Feb 4, 2016 at 1:33 AM, Gal Sagie  wrote:
> As i have commented on the patch i will also send this to the mailing list:
>
> I really dont see why Dragonflow is not part of this list, given the
> criteria you listed.
>
> Dragonflow is fully developed under Neutron/OpenStack, no other
> repositories. It is fully Open source and already have a community of people
> contributing and interest from various different companies and OpenStack
> deployers. (I can prepare the list of active contributions and of interested
> parties) It also puts OpenStack Neutron APIs and use cases as first class
> citizens and working on being an integral part of OpenStack.
>
> I agree that OVN needs to be part of the list, but you brought up this
> criteria in regards to ODL, so: OVN like ODL is not only Neutron and
> OpenStack and is even running/being implemented on a whole different
> governance model and requirements to it.
>
> I think you also forgot to mention some other projects as well that are
> fully open source with a vibrant and diverse community, i will let them
> comment here by themselves.
>
> Frankly this approach disappoints me, I have honestly worked hard to make
> Dragonflow fully visible and add and support open discussion and follow the
> correct guidelines to work in a project. I think that Dragonflow community
> has already few members from various companies and this is only going to
> grow in the near future. (in addition to deployers that are considering it
> as a solution)  we also welcome anyone that wants to join and be part of the
> process to step in, we are very welcoming
>
> I also think that the correct way to do this is to actually add as reviewers
> all lieutenants of the projects you are now removing from Neutron big
> stadium and letting them comment.
>
Hi Gal:

I don't think it's a completely fair characterize this as anything
other than an attempt to accurately reflect what the Neutron team can
stand behind. Most of these other open source projects (like
Dragonflow, networking-odl, even networking-ovn) can quite easily
apply for Big Tent admission, and would make the grade pretty easily.
This was not done to hurt anyones feelings or anything, and I know
Russell spent a lot of time on this. We knew this conversation would
be difficult, so I applaud him for sticking his neck out here and
moving things forward.

Thanks!
Kyle

> Gal.
>
>
> On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant  wrote:
>>
>> On 11/30/2015 07:56 PM, Armando M. wrote:
>> > I would like to suggest that we evolve the structure of the Neutron
>> > governance, so that most of the deliverables that are now part of the
>> > Neutron stadium become standalone projects that are entirely
>> > self-governed (they have their own core/release teams, etc).
>>
>> After thinking over the discussion in this thread for a while, I have
>> started the following proposal to implement the stadium renovation that
>> Armando originally proposed in this thread.
>>
>> https://review.openstack.org/#/c/275888
>>
>> --
>> Russell Bryant
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

[Kyle Mestery]

On Tue, Jan 19, 2016 at 10:14 AM, Ihar Hrachyshka  wrote:
> Rossella Sblendido  wrote:
>
>>
>>
>> On 01/19/2016 04:36 PM, Miguel Angel Ajo Pelayo wrote:
>>>
>>> Thinking of this, I had another idea, a bit raw yet.
>>>
>>> But how does it sound to have two meetings a week, one in a EU/ASIA
>>> friendlier
>>> timezone, and another for USA/AU (current one), with different chairs.
>>>
>>> We don't impose unnatural-working hours (too early, too late for family,
>>> etc..)
>>> to anyone, we encourage gathering as a community (may be split by
>>> timezones, but
>>> it feels more human and faster than ML conversations..) and also people
>>> able
>>> to make to both, could serve as bridges for both meetings.
>>>
>>>
>>> Thoughts?
>>
>>
>> I think that is what Kyle was proposing and if I am not wrong that's what
>> they do in nova.
>
>
> My understanding is that Kyle proposed to switch back to bi-weekly
> alternating meetings, and have a separate chair for each.
>
> I think Kyle’s suggestion is wiser since it won’t leave the community split
> into two separate parts, and it won’t waste two hours each week where we
> could make it with just one.
>
Yes, I was proposing two bi-weekly meetings with different chairs. We
could even have kept the existing schedule and just had a different
chair for the 1400UTC meeting on Tuesday.

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

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

Re: [openstack-dev] [release] Release countdown for week R-11, Jan 18-22, Mitaka-2 milestone

[Kyle Mestery]

On Fri, Jan 15, 2016 at 7:55 AM, Doug Hellmann 
wrote:

> Excerpts from Doug Hellmann's message of 2016-01-14 16:20:54 -0500:
> > Focus
> > -
> >
> > Next week is the second milestone for the Mitaka cycle. Major feature
> > work should be making good progress or be re-evaluated to see whether
> > it will really land this cycle.
> >
> > Release Actions
> > ---
> >
> > Liaisons should submit tag requests to the openstack/releases
> > repository for all projects following the cycle-with-milestone
> > release model before the end of the day on Jan 21.
> >
>

One question I have is, what should the version for projects be? For
example, for Neutron, M1 was set to 8.0.0.0b1. Should the M2 Neutron
milestone be 8.0.0.0c1? Or 8.0.0.0b2?

Thanks!
Kyle


> > We're working on updating the documented responsibilities for release
> > liaisons. Please have a look at https://review.openstack.org/#/c/262003/
> > and leave comments if you have questions or concerns.
> >
> > Important Dates
> > ---
> >
> > Mitaka 2: Jan 19-21
> >
> > Deadline for Mitaka 2 tag: Jan 21
> >
> > Mitaka release schedule:
> > http://docs.openstack.org/releases/schedules/mitaka.html
>
> One important reminder I left out: As Thierry described on this
> list earlier [1], we will be freezing changes to the release model
> tags for projects after the Mitaka 2 tags are in place. If you've
> been considering submitting patches to change the release tags for
> your project, please do that between now and next week.
>
> Doug
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083726.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

[Kyle Mestery]

On Wed, Jan 13, 2016 at 12:01 PM, Armando M. <arma...@gmail.com> wrote:

>
>
> On 12 January 2016 at 20:07, Kyle Mestery <mest...@mestery.com> wrote:
>
>> On Tue, Jan 12, 2016 at 5:28 PM, Doug Wiegley <
>> doug...@parksidesoftware.com> wrote:
>>
>>> I don’t think it ninja merged. It had plenty of reviews, and was open
>>> during international hours. I don’t have any issue there.
>>>
>>> I don’t like the crazy early meeting, so I set out to prove it didn’t
>>> matter:
>>>
>>> Average attendance before rotating: 20.7 people
>>> Average attendance on Monday afternoons (U.S. time): 20.9
>>> Average attendance on Tuesday morning (U.S. time): 23.7
>>>
>>> Stupid data, that’s not what I wanted to see.
>>>
>>> I haven’t yet correlated people to which meeting time yet, but
>>> attendance was slightly up during the crazy early hated time, across the
>>> 1.25 years it was running (started 9/9/14). This is just people saying
>>> something; lurkers can just read the logs.
>>>
>>> Data is from eavesdrop meeting logs, if anyone else wants to crunch it.
>>>
>>> Since it's ridiculous to assume people are required to attend this
>> meeting, one easy solution to this would be to go back to the rotating
>> meeting and have a different chair for the Tuesday morning PST meeting. I
>> think rotating chairs for this meeting would be a good idea for a multitude
>> of reasons (spreads the pain, lets others have a chance at the pulpit,
>> grooms future meeting leaders, etc.).
>>
>
> With this suggestion you seem to imply that I only dropped the biweekly
> schedule because I didn't want to run the Tuesday ones, and that's unfair :)
>
> I would never imply such a thing, whether or not it would be true. :)


> Albeit I am not overly happy to wake up at 5.30am (in my timezone), I have
> done it so far because I believe it's my duty. That said, when I see that
> the nearly the same people show up (and meaningfully contribute) at both,
> then I'd rather have the majority of us have a "simpler" life.
>
> I have never been a fan of the biweekly schedule because it incentivises
> people not to turn up half the time (I certainly wouldn't have an incentive
> to wake up at ~6am if I didn't have to chair the meeting), however certain
> topics are only discussed once, and missing a meeting is a missed
> opportunity to actively contribute during meeting hours.
>
> Bear in mind that no-one is taking away the opportunity from people to
> contribute in the openstack-neutron channel and/or offline on the ML. I
> personally rely on it quite a bit.
>
> Absolutely. My main point was that spreading the load of things by perhaps
letting someone else run it may not be a bad idea.


> Cheers,
> Armando
>
>
>>
>> Thanks,
>> Kyle
>>
>>
>>> Thanks,
>>> doug
>>>
>>>
>>> > On Jan 12, 2016, at 4:32 PM, Tony Breeds <t...@bakeyournoodle.com>
>>> wrote:
>>> >
>>> > On Tue, Jan 12, 2016 at 01:27:30PM +0100, Ihar Hrachyshka wrote:
>>> >> Agreed with Gary on behalf of my European compatriots. (Note that I
>>> >> *personally* +1’d the patch because I don’t mind, doing late hours
>>> anyway;
>>> >> but it’s sad it was ninja merged without giving any chance for those
>>> from
>>> >> affected timezones to express their concerns).
>>> >
>>> > So Ninja merged has a negative connotation that I refute.
>>> >
>>> > I merged it.  It was judgment error, and I apologise for that.
>>> >
>>> > * I found and read through the list thread.
>>> > * Saw only +1's yours included
>>> >- known you'd be affected I used your +1 as a barometer
>>> >
>>> > My mistake was not noticing your request to leave the review open for
>>> longer.
>>> >
>>> > I also noted in my review that reverting it is pretty low cost to back
>>> it out
>>> > if needed.
>>> >
>>> > I understand that the 'root cause' for this change was the yaml2ical
>>> issue that
>>> > stemmed from having 2 odd week in a row.  We've fixed that [1]. I'm
>>> also
>>> > working a a more human concept of biweekly meeting in yaml2ical.
>>> >
>>> > Tony
>>> > [1] the next time it could have been a problem is 2020/2021 ;P
>>> >
>>> 

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

[Kyle Mestery]

On Tue, Jan 12, 2016 at 5:28 PM, Doug Wiegley 
wrote:

> I don’t think it ninja merged. It had plenty of reviews, and was open
> during international hours. I don’t have any issue there.
>
> I don’t like the crazy early meeting, so I set out to prove it didn’t
> matter:
>
> Average attendance before rotating: 20.7 people
> Average attendance on Monday afternoons (U.S. time): 20.9
> Average attendance on Tuesday morning (U.S. time): 23.7
>
> Stupid data, that’s not what I wanted to see.
>
> I haven’t yet correlated people to which meeting time yet, but attendance
> was slightly up during the crazy early hated time, across the 1.25 years it
> was running (started 9/9/14). This is just people saying something; lurkers
> can just read the logs.
>
> Data is from eavesdrop meeting logs, if anyone else wants to crunch it.
>
> Since it's ridiculous to assume people are required to attend this
meeting, one easy solution to this would be to go back to the rotating
meeting and have a different chair for the Tuesday morning PST meeting. I
think rotating chairs for this meeting would be a good idea for a multitude
of reasons (spreads the pain, lets others have a chance at the pulpit,
grooms future meeting leaders, etc.).

Thanks,
Kyle


> Thanks,
> doug
>
>
> > On Jan 12, 2016, at 4:32 PM, Tony Breeds 
> wrote:
> >
> > On Tue, Jan 12, 2016 at 01:27:30PM +0100, Ihar Hrachyshka wrote:
> >> Agreed with Gary on behalf of my European compatriots. (Note that I
> >> *personally* +1’d the patch because I don’t mind, doing late hours
> anyway;
> >> but it’s sad it was ninja merged without giving any chance for those
> from
> >> affected timezones to express their concerns).
> >
> > So Ninja merged has a negative connotation that I refute.
> >
> > I merged it.  It was judgment error, and I apologise for that.
> >
> > * I found and read through the list thread.
> > * Saw only +1's yours included
> >- known you'd be affected I used your +1 as a barometer
> >
> > My mistake was not noticing your request to leave the review open for
> longer.
> >
> > I also noted in my review that reverting it is pretty low cost to back
> it out
> > if needed.
> >
> > I understand that the 'root cause' for this change was the yaml2ical
> issue that
> > stemmed from having 2 odd week in a row.  We've fixed that [1]. I'm also
> > working a a more human concept of biweekly meeting in yaml2ical.
> >
> > Tony
> > [1] the next time it could have been a problem is 2020/2021 ;P
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

[Kyle Mestery]

On Mon, Jan 11, 2016 at 12:57 PM, Kyle Mestery <mest...@mestery.com> wrote:

> On Mon, Jan 11, 2016 at 12:45 PM, Armando M. <arma...@gmail.com> wrote:
>
>> Disregard the email subject.
>>
>> I stand corrected. Let's meet today.
>>
>>
> Something is wrong, I have the meeting on my google calendar, and it shows
> up as tomorrow for this week. I've had these setup as rotating for a while
> now, so something is fishy with the .ics files.
>

If you look here [1], the meeting cadence was:

12-15-2015: Tuesday
12-21-2015: Monday
12-29-2015: Tuesday (skipped)
01-04-2016: Monday (skipped)
01-12-2016 Tuesday

The meeting is tomorrow.

[1] http://eavesdrop.openstack.org/meetings/networking/2015/

>
>
>> On 11 January 2016 at 10:24, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>
>>> Armando M. <arma...@gmail.com> wrote:
>>>
>>> Hi neutrinos,
>>>>
>>>> A kind reminder for tomorrow's meeting at 1400UTC.
>>>>
>>>> Cheers,
>>>> Armando
>>>>
>>>> [1] https://wiki.openstack.org/wiki/Network/Meetings
>>>>
>>>> __
>>>> 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
>>>>
>>>
>>> Is it just me, or when you use .ics file from eavesdrop, it says the
>>> meeting is today?
>>>
>>> http://eavesdrop.openstack.org/calendars/neutron-team-meeting.ics
>>>
>>> Is it the same issue as described in:
>>>
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082902.html
>>>
>>> and that is suggested to fix by readding your events from updated .ics
>>> file:
>>>
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html
>>>
>>> Ihar
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

[Kyle Mestery]

On Mon, Jan 11, 2016 at 12:45 PM, Armando M.  wrote:

> Disregard the email subject.
>
> I stand corrected. Let's meet today.
>
>
Something is wrong, I have the meeting on my google calendar, and it shows
up as tomorrow for this week. I've had these setup as rotating for a while
now, so something is fishy with the .ics files.


> On 11 January 2016 at 10:24, Ihar Hrachyshka  wrote:
>
>> Armando M.  wrote:
>>
>> Hi neutrinos,
>>>
>>> A kind reminder for tomorrow's meeting at 1400UTC.
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://wiki.openstack.org/wiki/Network/Meetings
>>>
>>> __
>>> 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
>>>
>>
>> Is it just me, or when you use .ics file from eavesdrop, it says the
>> meeting is today?
>>
>> http://eavesdrop.openstack.org/calendars/neutron-team-meeting.ics
>>
>> Is it the same issue as described in:
>>
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082902.html
>>
>> and that is suggested to fix by readding your events from updated .ics
>> file:
>>
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html
>>
>> Ihar
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] [neutron] Procedure for back-porting a bug fix to stable/liberty branch of a Neutron script in DevStack?

[Kyle Mestery]

On Sun, Jan 3, 2016 at 5:22 PM, Mike Spreitzer <mspre...@us.ibm.com> wrote:

> > From: Kyle Mestery <mest...@mestery.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Date: 01/03/2016 02:15 PM
> > Subject: Re: [openstack-dev] [devstack] [neutron] Procedure for
> > back-porting a bug fix to stable/liberty branch of a Neutron script
> > in DevStack?
> >
> > On Sun, Jan 3, 2016 at 4:01 PM, Mike Spreitzer <mspre...@us.ibm.com>
> wrote:
> > I would like to back-port https://review.openstack.org/#/c/242721/
> > --- which fixed https://bugs.launchpad.net/devstack/+bug/1469596---
> > to stable/liberty.  I have contributed to main line development
> > before, but not stable branches.  I see that http://
> > docs.openstack.org/infra/manual/developers.htmldoes not specifically
> > address this case.  What is the procedure to follow?
>
> > The best place to look is in the project team guide [1],
> > specifically the section on proposing fixes.
> >
> > [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> > [2] http://docs.openstack.org/project-team-guide/stable-
> > branches.html#proposing-fixes
>
> Regarding the mechanics, I was given the following alternate recipe in a
> discussion on #openstack-neutron; I assume it is pretty much equivalent.
>
> "do something like 'git checkout -b libery/backport/###
> remotes/origin/stable/liberty' then 'git pull' then 'git review -X ###'
> then push it for review"
>
> I think it is, but honestly, "git cherry-pick -x" is pretty simple as well
and the way I've always done these.


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

Re: [openstack-dev] [devstack] [neutron] Procedure for back-porting a bug fix to stable/liberty branch of a Neutron script in DevStack?

[Kyle Mestery]

On Sun, Jan 3, 2016 at 4:01 PM, Mike Spreitzer  wrote:

> I would like to back-port https://review.openstack.org/#/c/242721/---
> which fixed https://bugs.launchpad.net/devstack/+bug/1469596--- to
> stable/liberty.  I have contributed to main line development before, but
> not stable branches.  I see that
> http://docs.openstack.org/infra/manual/developers.htmldoes not
> specifically address this case.  What is the procedure to follow?
>
> The best place to look is in the project team guide [1], specifically the
section on proposing fixes.

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2]
http://docs.openstack.org/project-team-guide/stable-branches.html#proposing-fixes


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

Re: [openstack-dev] [neutron][taas] neutron ovs-agent deletes taas flows

[Kyle Mestery]

On Tue, Dec 15, 2015 at 9:11 AM, Assaf Muller  wrote:

> SFC are going to hit this issue as well. Really any out of tree
> Neutron project that extends the OVS agent and expects things to work
> :)
>
>
Yes, this is the case.


> On Tue, Dec 15, 2015 at 9:30 AM, Ihar Hrachyshka 
> wrote:
> > Soichi Shigeta  wrote:
> >
> >>
> >>  Hi,
> >>
> >>   We find a problem that neutron ovs-agent deletes taas flows.
> >>
> >>   o) Problem description:
> >>
> >>  Background:
> >>   At Liberty, a bug fix to drop only old flows was merged
> >>   to Neutron.
> >>   When ovs-agent is restarted, the cleanup logic drops flow
> >>   entries unless they are stamped by agent_uuid (recorded as
> >>   a cookie).
> >>
> >>   bug: #1383674
> >>"Restarting neutron openvswitch agent causes network
> >> hiccup by throwing away all flows"
> >>https://bugs.launchpad.net/neutron/+bug/1383674
> >>
> >>   commit: 73673beacd75a2d9f51f15b284f1b458d32e992e (patch)
> >>
> >>
> https://git.openstack.org/cgit/openstack/neutron/commit/?id=73673beacd75a2d9f51f15b284f1b458d32e992e
> >>
> >>
> >>  Problem:
> >>   Cleanup will be done only once, but it seems not to work
> >>   until port configuration is changed.
> >>
> >>   Therefore, taas flows will be deleted as follows:
> >>1. Start a new compute node or restart an existing compute node.
> >>2. Start taas agent on the compute node.
> >>   --> taas agent creates flows
> >>   (these flows are not stamped by using ovs-agent's uuid)
> >>3. Deploy a vm on the compute node.
> >>   --> 1. neutron changes port configuration
> >>   2. subsequently, the cleanup logic is invoked
> >>   3. ovs-agent drops taas flows
> >>
> >>  Specifically, following taas flows in br_tun are dropped:
> >>  -
> >>   table=35, priority=2,reg0=0x0 actions=resubmit(,36)
> >>   table=35, priority=1,reg0=0x1 actions=resubmit(,36)
> >>   table=35, priority=1,reg0=0x2 actions=resubmit(,37)
> >>  -
> >>
> >>  log in q-agt.log
> >>  -
> >>
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
> >> req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
> >> cookie=0x0, duration=434.59s, table=35, n_packets=0, n_bytes=0,
> >> idle_age=434, priority=2,reg0=0x0 actions=resubmit(,36)
> >>
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
> >> req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
> >> cookie=0x0, duration=434.587s, table=35, n_packets=0, n_bytes=0,
> >> idle_age=434, priority=1,reg0=0x1 actions=resubmit(,36)
> >>
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl.ofswitch
> >> req-e5739280-7116-4802-b5ba-d6964b4c5557 Deleting flow
> >> cookie=0x0, duration=434.583s, table=35, n_packets=0, n_bytes=0,
> >> idle_age=434, priority=1,reg0=0x2 actions=resubmit(,37)
> >>  -
> >>
> >>
> >>   o) Impact for TaaS:
> >>
> >>  Because flows in br_tun are dropped by the cleanup logic, mirrored
> >>  packets will not send to a monitoring vm running on another host.
> >>
> >>  Note: Mirrored packets are sent in case of both source vm and
> >>monitoring vm are running on the same host. (not affected by
> >>flows in br_tun)
> >>
> >>
> >>   o) How to reproduce:
> >>
> >>  1. Start a new compute node or restart an existing compute node.
> >> (Actually, restarting ovs-agent is enough.)
> >>  2. Start (or restart) taas agent on the compute node.
> >>  3. Deploy a vm on the compute node.
> >> --> The cleanup logic drops taas flows.
> >>
> >>
> >>   o) Workaround:
> >>
> >>  After a vm is deployed on a (re)started compute node, restart taas
> >>  agent before creating a tap-service or tap-flow.
> >>  That is, create taas flows after cleanup has been done.
> >>
> >>  Note that cleanup will be done only once during an ovs-agent is
> >>  running.
> >>
> >>
> >>   o) An idea to fix:
> >>
> >>  1. Set "taas" stamp(*) to taas flows.
> >>  2. Modify the cleanup logic in ovs-agent not to delete entries
> >> stamped as "taas".
> >>
> >>  * Maybe a static string.
> >>If we need to use a string which generated dynamically
> >>(e.g. uuid), API to interact with ovs-agent is required.
> >
> >
> > API proposal with some consideration for flow cleanup not dropping flows
> for
> > external code is covered in the following email thread:
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html
> >
> > I believe you would need to adopt the extensions API once it’s in, moving
> > from setup with a separate agent for your feature to l2 agent extension
> for
> > taas that will run inside OVS agent.
> >
>

This is 

[openstack-dev] [kuryr] Release Notes for Kuryr

[Kyle Mestery]

Howdy Kuryr developers!

Like other OpenStack projects, I've added the functionality to use release
notes with Kuryr. Once [1] merges, we can add release notes in the
"releasenotes/notes" directory. I encourage everyone who has added a
feature item to Kuryr to please add a release note for that feature. Reno
has some nice documentation on how to add a release note here [2], if you
have further questions let me know.

Thanks!
Kyle

[1] https://review.openstack.org/#/c/257450/
[2]
http://docs.openstack.org/developer/reno/usage.html#creating-new-release-notes
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: [Neutron] Team meeting this Monday at 2100 UTC

[Kyle Mestery]

On Tue, Dec 8, 2015 at 1:54 AM, Smigiel, Dariusz 
wrote:

>
> > -Original Message-
> > From: Kevin Benton [mailto:blak...@gmail.com]
> >
> > I liked using the meeting for it because it was a nice way for everyone
> to get
> > a snapshot of where each thing was at.
>
> +1
> The idea of discussing everything on meeting is very good.
> Everyone interested is  on the same page.
>
>
The meeting works nice, so I'm +1 for this type of usage.


> Cheers,
> Darek Smigiel (dasm)
> ITP
>
> >
> > On Dec 7, 2015 3:14 PM, "Armando M."  >  > wrote:
> >
> >
> >   Hi neutrinos,
> >
> >   During today's meeting [1] we went through the outstanding
> > blueprints, but we only managed to look at a little over half of them.
> >
> >   Would you guys like to continue the conversation during next week's
> > meeting or shall we ask for people's status updates offline? An update on
> > the BP's whiteboard like done in [2] would suffice.
> >
> >   Cheers,
> >   Armando
> >
> >   [1]
> > http://eavesdrop.openstack.org/meetings/networking/2015/networking.20
> > 15-12-07-21.00.html
> >   [2] https://blueprints.launchpad.net/neutron/+spec/external-dns-
> > resolution
> >
> >   -- Forwarded message --
> >   From: Armando M.  >  >
> >   Date: 4 December 2015 at 12:50
> >   Subject: [Neutron] Team meeting this Monday at 2100 UTC
> >   To: "OpenStack Development Mailing List (not for usage questions)"
> >  > d...@lists.openstack.org> >
> >
> >
> >
> >   Hi neutrinos,
> >
> >   A kind reminder for next week's meeting.
> >
> >   Being the meeting right after the milestone was cut, I'd like to
> take
> > most of the hour to talk about blueprints/specs, i.e. the beefy workload
> that
> > has merged, and has yet to merge.
> >
> >   We'll be brief on announcements and bugs, and skip the other
> > sections, docs and open agenda. More details on [1].
> >
> >   We'll run this specially focussed meetings throughout the release,
> > and we'll have meetings focussed on Docs and Bugs alone too in the
> future.
> > Stay tuned.
> >
> >   Cheers,
> >   Armando
> >
> >   [1] https://wiki.openstack.org/wiki/Network/Meetings
> > 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Kyle Mestery]

On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau  wrote:

> Kevin Benton  wrote:
> > So obviously the stuff in the client can be updated since most of that is
> > user-facing. However, on the server side maybe we can start out by
> keeping all
> > of the internal code and DB tables the same. Then all we need to worry
> about
> > is the API translation code to start.
> >
> > Once our public-facing stuff is done, we can just start the transition to
> > project_id internally at our own pace and in much less invasive chunks.
>
> I agree with Kevin's suggestion.
>
>
++, and this is what Salvatore has previously suggested as well.


> > On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz <
> dariusz.smig...@intel.com
> > > wrote:
> >
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in
> Mitaka
> > [6], and probably forever. It will stay at least four releases, but
> we
> > need to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of
> 'tenant' to
> > 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013
> [4][5] but
> > unfortunately, no one finished it. Although Keystone V3 API is
> already
> > supported in Neutron client [2], there are still some unknowns about
> > Neutron server side. Monty Taylor is trying to address necessary (if
> any)
> > changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has
> 3021 of
> > it. Some of them are just documentation and docstrings, but there
> are a
> > lot of places, where variables are tangled: defined in DB, used in
> server,
> > accessed by client. Most of places are just internal usages. The only
> > thing where I've found 'public' information about tenants is 'help'
> > command in neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> > amount of code to look through, update all places and be successful
> :)
> > 2. Bigger challenge will be to change server side code. I'd suggest
> to
> > start with renaming db columns. It affects a lot of places, so when
> > finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> > start this job.
> > - one way to describe the same thing, instead of:
> tenant/account/project.
> > Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot
> of
> > patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all
> changes?
> > Is this change necessary?
> > Did I forget about something?
> >
> > I'll be grateful for any kind of feedback.
> >
> > Thanks,
> >  Dariusz Smigiel (dasm)
> >  Intel Technology Poland
> >
> > [1]
> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
> > [2]
> >
> https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> > [3] https://bugs.launchpad.net/neutron/+bug/1503428
> > [4]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> > [5]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> > [6]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

[Kyle Mestery]

On Thu, Dec 3, 2015 at 7:59 AM, Akihiro Motoki  wrote:

> Hi,
>
> python-neutronclient still has XML support of Neutron API.
> I would like to discuss when we drop XML support in neutronclient.
>
> Neutron API XML suppoort was marked as deprecated in Icehouse and Juno
> and was dropped in Kilo. Juno is now EOL and we have no gate testing which
> requires XML support. This is a minimum requirement.
> From this point, we can drop XML support now.
>
> Another point is users who are OpenStack clouds using Juno or older
> versions
> may use the latest python-neutronclient.
> XML support in Neutron was deprecated since Icehouse, and if our
> deprecation
> notice works, XML API is used only in cloud deployed before Icehouse.
> In addition, older versions of neutronclient are available from
> various distributions and PyPI.
> Do we need to continue XML support for users of such cloud?
> Note that we no longer have a way to test XML API support is functional.
>
>
I'm in favor of dropping XML support.


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

Re: [openstack-dev] [neutron] Release Notes for *aaS projects

[Kyle Mestery]

OK, thanks for the input. I'll get the patches out to enable this by Friday
this week, once Mitaka-1 is cut for Neutron.

On Wed, Dec 2, 2015 at 11:34 AM, Brandon Logan <brandon.lo...@rackspace.com>
wrote:

> Makes complete sense.
>
> On Wed, 2015-12-02 at 10:38 -0600, Kyle Mestery wrote:
> > We're hoping to cut Neutron M-1 this week [1]. We have implemented
> > release notes in the main Neutron repository [2] , but not in the *aaS
> > repositories. At the time, I thought this was a good approach and we
> > could collect all releasenotes there. But I think it makes sense to
> > have releasenotes in the *aaS repositories as well.
> >
> > What I'm going to propose is we cut Neutron M-1 as-is now, with any
> > *aaS releasenotes done in the main repository. Once Neutron M-1 is
> > cut, I'll add the releasenotes stuff into the *aaS repositories, and
> > we can start using releasenotes independently in those repositories.
> >
> > If anyone has issues with this approach please reply on this thread.
> >
> > Thanks!
> > Kyle
> >
> > [1] https://review.openstack.org/#/c/251959/
> > [2] https://review.openstack.org/241758
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

[Kyle Mestery]

On Wed, Nov 25, 2015 at 1:06 AM, Armando M.  wrote:

>
>
> On 24 November 2015 at 21:46, Akihiro Motoki  wrote:
>
>> Hi,
>>
>> Neutron has now various subprojects and some of them would like to
>> implement Horizon supports. Most of them are additional features.
>> I would like to start the discussion where we should have horizon support.
>>
>> [Background]
>> Horizon team introduced a plugin mechanism and we can add horizon panels
>> from external repositories. Horizon team is recommending external repos
>> for
>> additional services for faster iteration and features.
>> We have various horizon related repositories now [1].
>>
>> In Neutron related world, we have neutron-lbaas-dashboard and
>> horizon-cisco-ui repos.
>>
>> [Possible options]
>> There are several possible options for neutron sub-projects.
>> My current vote is (b), and the next is (a). It looks a good balance to
>> me.
>> I would like to gather broader opinions,
>>
>> (a) horizon in-tree repo
>> - [+] It was a legacy approach and there is no initial effort to setup a
>> repo.
>> - [+] Easy to share code conventions.
>> - [-] it does not scale. Horizon team can be a bottleneck.
>>
>> (b) a single dashboard repo for all neutron sub-projects
>> - [+] No need to set up a repo by each sub-project
>> - [+] Easier to share the code convention. Can get horizon reviewers.
>> - [-] who will be a core reviewer of this repo?
>>
>> (c) neutron sub-project repo
>>
>
> All circumstances considered, I think c) is the only viable one.
>
>
+1


> - [+] Each sub-project can develop a dashboard fast.
>> - [-] It is doable, but the directory tree can be complicated.
>>
>
> why? do you envision something else other than /horizon directory in the
> tree?
>
>
>> - [-] Lead to too many repos and the horizon team/liaison cannot cover
>> all.
>>
>
> If that's true for horizon, shouldn't the same be true for the neutron
> team :)? IMO, the level of feedback/oversight provided is always going to
> be constant (you can't clone people) no matter how the efforts are
> distributed. I'd rather empower the individual projects.
>
>
+1000

Option C seems like the way forward here.


>
>> (d) a separate repo per neutron sub-project
>> Similar to (c)
>> - [+] A dedicate repo for dashboard simplifies the directory tree.
>> - [-] Need to setup a separate repo.
>> - [-] Lead to too many repos and the horizon team/liaison cannot cover
>> all.
>>
>
>> Note that this mail is not intended to move the current neutron
>> support in horizon
>> to outside of horizon tree. I would like to discuss Horizon support of
>> additional features.
>>
>> Akihiro
>>
>> [1] http://docs.openstack.org/developer/horizon/plugins.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Call for review focus

[Kyle Mestery]

On Wed, Nov 18, 2015 at 8:14 PM, Armando M.  wrote:

> Hi Neutrites,
>
>
Neutrinos?


> We are nearly two weeks away from the end of Mitaka 1.
>
> I am writing this email to invite you to be mindful to what you review,
> especially in the next couple of weeks. Whenever you have the time to
> review code, please consider giving priority to the following:
>
>- Patches that target blueprints targeted for Mitaka
>;
>- Patches that target bugs that are either critical
>
> 
>or high
>
> 
>;
>- Patches that target rfe-approved
>
> 
> 'bugs';
>- Patches that target specs
>
> 
>  that
>have followed the most current submission process
>;
>
> Everything else should come later, no matter how easy or interesting it is
> to review; remember that as a community we have the collective duty to work
> towards a common (set of) target(s), as being planned in collaboration with
> the Neutron Drivers
>  team and the
> larger core  team.
>
> I would invite submitters to ensure that the Launchpad resources
> (blueprints, and bug report) capture the most updated view in terms of
> patches etc. Work with your approver to help him/her be focussed where it
> matters most.
>
> Finally, we had plenty of discussions at the design summit
> ,
> and some of those discussions will have to be followed up with actions (aka
> code in OpenStack lingo). Even though, we no longer have deadlines for
> feature submission, I strongly advise you not to leave it last minute. We
> can only handle so much work for any given release, and past experience
> tells us that we can easily hit a breaking point at around the ~30
> blueprint mark.
>
> Once we reached it, it's likely we'll have to start pushing back work for
> Mitaka and allow us some slack; things are fluid as we all know, and the
> random gate breakage is always lurking round the corner! :)
>
>
Thanks for sending this out Armando. Keeping focus is important, and your
occasional emails reminding people are super useful. I find them useful,
and as the previous PTL, I can backup the fact that the team should be
focusing on specific reviews.

Thanks!
Kyle


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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Kyle Mestery]

On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant  wrote:

> On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> > On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
> >> This is a challenge. Personally, I haven't been able to get it all
> working
> >> yet. But we're in a dilemma because we want to get good reviews of the
> code
> >> before merging. Since the full functionality is quite a lot of code we
> >> wanted to chop it into more easily reviewable chunks. Unfortunately that
> >> makes it more difficult to pull it all in at once to test the whole
> thing
> >> prior to completing the review and merge.
> >
> > I would be concerned about that. I am sympathetic to the chicken and egg
> > problem of a new repo and new code, but I briefly looked at both of
> > those reviews and they both are quite large. 1K LOC is usually the upper
> > limit for a sane patch set. It may be worth trying to break into
> > smaller, more manageable pieces - even if the initial commits just
> > create some empty classes and stubbed methods, and then later start
> > introducing the actual method bodies in small pieces with good unit
> > tests for each one. Small pieces. Tiny steps.
>
> Another thing I've been thinking about is the difference between having
> a repo like networking-sfc where a sub-group is able to try out new
> things while also managing expectations with consumers of Neutron.  How
> does someone know the difference between something a bit more
> experimental vs. when an API is established and can be considered stable
> and maintained with backwards copmatibility like any other OpenStack
> REST API?
>
> In the case of SFC, consumers of the API should know it's tagged as
"release:independent" [1], and also it should be clear there is no release
made and the code isn't stable in the docs, but that isn't currently the
case looking here [2]. Thus, I've submitted [3] to make this a bit more
clear, comments welcome.

[1] http://governance.openstack.org/reference/projects/neutron.html
[2] http://docs.openstack.org/developer/networking-sfc/
[3] https://review.openstack.org/246001


> I think networking-sfc should be able to keep merging code, including
> the proposed API, but I think it should be clearly marked as
> experimental and subject to change.  That's based on my experience so
> far studying this proposal, SFC more generally, and watching other
> efforts happening within Neutron that affect this.
>
> How can we manage these expectations more clearly?
>
> Well, since it hasn't released yet, I agree, lets experiment and let other
backends try this out, and at the same time not lock things down. We just
need to be clear about the intent here.

Thanks,
Kyle


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

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Kyle Mestery]

On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali  wrote:

> Neutron community,
>
> During the past several releases, while leading the VPNaaS project, I've
> seen many great enhancements and features added to the VPNaaS project by
> the community, including support for StrongSwan, Libreswan, completion of
> the project split out, functional and rally tests, endpoint groups,
> multiple local subnets, vendor drivers, etc.
>
> There is still work needed (certificate support the most important,
> followed by documentation and scale testing), but there is a solid (in my
> bias and subjective opinion :) foundation in place for people to play with
> this capability.
>
> As I mentioned to Armando at the summit, it's time for me to move on to
> other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
> wrapping up work on the project over the next few weeks. I'll still try to
> review VPNaaS commits as much as possible, and be available to advise in
> this area.
>
> Towards that end, I've updated the VPNaaS wiki page (
> https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are
> outstanding work that can be done in this area, from important to wish
> items.  Meetings have transitioned to on-demand, and future meetings can
> either be done as an on-demand topic in the Neutron IRC meeting, or as an
> on-demand special meeting.
>
> I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my
> opinion of importance, priority, relevance, etc.
>
> Regards,
>
>
Thanks for all your hard work over the previous releases Paul! Looking
forward to what you'll be doing next in Neutron.

Thanks,
Kyle


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

Re: [openstack-dev] [Neutron] Priority management for new features

[Kyle Mestery]

On Wed, Nov 11, 2015 at 4:19 PM, Armando M.  wrote:

> Hi neutronians,
>
> Whilst I recover from the gate failure binge eating...I wanted to put out
> there a couple of process changes that should help the drivers team and the
> PTL to improve their ability to justify priority assignments for new
> features.
>
> Comments welcome.
>
>
I commented in the review, but I thought I'd reply here as well. I don't
understand the reason to move to only using "High" and "Low" priority, it
seems somewhat arbitrary. Of course, you could argue our current system for
prioritizing is arbitrary as well, but I'd argue that utilizing all 4
priorities makes sense. Ultimately though, this is all mostly arbitrary
anyways, and we all likely understand the stuff which is important (e.g.
Essential). We have done a bad job at getting that stuff into a release in
the past though.

And now I feel like Salvatore and I'll stop pedantically meandering.


> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/244302/
> [2] https://review.openstack.org/#/c/244313/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [networking-powervm] Please create networking-powervm on PyPI

[Kyle Mestery]

Thanks Adam, that should be all that's required. I unblocked [1] after
verifying the PyPI config.

[1] https://review.openstack.org/#/c/233466/

On Mon, Nov 9, 2015 at 4:15 PM, Adam D Reznechek <adrez...@us.ibm.com>
wrote:

> Hi Kyle,
>
> The networking-powervm pypi project is now up [1] with the openstackci
> user set
> appropriately. Let me know if you need anything else.
>
> [1] https://pypi.python.org/pypi/networking-powervm
>
> Regards,
>
> Adam Reznechek
>
>
> From:   Kyle Mestery <mest...@mestery.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date:   11/03/2015 10:09 PM
> Subject:[openstack-dev] [neutron] [networking-powervm] Please
> create  networking-powervm on PyPI
>
>
>
> I'm reaching out to whoever owns the networking-powervm project [1]. I
> have a review out [2] which updates the PyPI publishing jobs so we can
> push releases for networking-powervm. However, in looking at PyPI, I don't
> see a networking-powervm project, but instead a neutron-powervm project.
> Is there a reason for the PyPI project to have a different name? I believe
> this will not allow us to push releases, as the name of the projects need
> to match. Further, the project creation guide recommends naming them the
> same [4].
>
> Can someone from the PowerVM team look at registering networking-powervm
> on PyPI and correcting this please?
>
> Thanks!
> Kyle
>
> [1] https://launchpad.net/neutron-powervm
> [2] https://review.openstack.org/#/c/233466/
> [3] https://pypi.python.org/pypi/neutron-powervm/0.1.0
> [4] http://docs.openstack.org/infra/manual/creators.html#pypi
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking-onos]: Proposing new cores for networking-onos

[Kyle Mestery]

+1 for both.

On Thu, Nov 5, 2015 at 7:00 AM, Gal Sagie  wrote:

> +1 for both from me
>
> On Thu, Nov 5, 2015 at 2:53 PM, Vikram Choudhary 
> wrote:
>
>> Hi All,
>>
>> I would like to propose Mr. Ramanjaneya Reddy Palleti and Mr. Dongfeng as
>> new cores for networking-onos project. Their contribution was significant
>> in the last Liberty cycle w.r.t to this project.
>>
>> *Facts:*
>> http://stackalytics.com/?metric=loc=networking-onos=all
>>
>> Request existing cores to vote for this proposal.
>>
>> Thanks
>> Vikram
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Kyle Mestery]

On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes  wrote:

> On 11/04/2015 04:21 PM, Shraddha Pandhe wrote:
>
>> Hi Salvatore,
>>
>> Thanks for the feedback. I agree with you that arbitrary JSON blobs will
>> make IPAM much more powerful. Some other projects already do things like
>> this.
>>
>
> :( Actually, though "powerful" it also leads to implementation details
> leaking directly out of the public REST API. I'm very negative on this and
> would prefer an actual codified REST API that can be relied on regardless
> of backend driver or implementation.
>

I agree with Jay here. We've had people propose similar things in Neutron
before, and I've been against them. The entire point of the Neutron REST
API is to not leak these details out. It dampens the strength of the
logical model, and it tends to have users become reliant on backend
implementations.


>
> e.g. In Ironic, node has driver_info, which is JSON. it also has an
>> 'extras' arbitrary JSON field. This allows us to put any information in
>> there that we think is important for us.
>>
>
> Yeah, and this is a bad thing, IMHO. Public REST APIs should be
> structured, not a Wild West free-for-all. The biggest problem with using
> free-form JSON blobs in RESTful APIs like this is that you throw away the
> ability to evolve the API in a structured, versioned way. Instead of
> evolving the API using microversions, instead every vendor just jams
> whatever they feel like into the JSON blob over time. There's no way for
> clients to know what the server will return at any given time.
>
> Achieving consensus on a REST API that meets the needs of a variety of
> backend implementations is *hard work*, yes, but it's what we need to do if
> we are to have APIs that are viewed in the industry as stable,
> discoverable, and reliably useful.
>

++, this is the correct way forward.

Thanks,
Kyle


>
> Best,
> -jay
>
> Best,
> -jay
>
> Hoping to get some positive feedback from API and DB lieutenants too.
>>
>>
>> On Wed, Nov 4, 2015 at 1:06 PM, Salvatore Orlando
>> > wrote:
>>
>> Arbitrary blobs are a powerful tools to circumvent limitations of an
>> API, as well as other constraints which might be imposed for
>> versioning or portability purposes.
>> The parameters that should end up in such blob are typically
>> specific for the target IPAM driver (to an extent they might even
>> identify a specific driver to use), and therefore an API consumer
>> who knows what backend is performing IPAM can surely leverage it.
>>
>> Therefore this would make a lot of sense, assuming API portability
>> and not leaking backend details are not a concern.
>> The Neutron team API & DB lieutenants will be able to provide more
>> input on this regard.
>>
>> In this case other approaches such as a vendor specific extension
>> are not a solution - assuming your granularity level is the
>> allocation pool; indeed allocation pools are not first-class neutron
>> resources, and it is not therefore possible to have APIs which
>> associate vendor specific properties to allocation pools.
>>
>> Salvatore
>>
>> On 4 November 2015 at 21:46, Shraddha Pandhe
>> >
>> wrote:
>>
>> Hi folks,
>>
>> I have a small question/suggestion about IPAM.
>>
>> With IPAM, we are allowing users to have their own IPAM drivers
>> so that they can manage IP allocation. The problem is, the new
>> ipam tables in the database have the same columns as the old
>> tables. So, as a user, if I want to have my own logic for ip
>> allocation, I can't actually get any help from the database.
>> Whereas, if we had an arbitrary json blob in the ipam tables, I
>> could put any useful information/tags there, that can help me
>> for allocation.
>>
>> Does this make sense?
>>
>> e.g. If I want to create multiple allocation pools in a subnet
>> and use them for different purposes, I would need some sort of
>> tag for each allocation pool for identification. Right now,
>> there is no scope for doing something like that.
>>
>> Any thoughts? If there are any other way to solve the problem,
>> please let me know
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> 

Re: [openstack-dev] [neutron] [networking-powervm] Please createnetworking-powervm on PyPI

[Kyle Mestery]

On Wed, Nov 4, 2015 at 6:29 AM, Andrew Thorstensen <tho...@us.ibm.com>
wrote:

> Hi Kyle,
>
> My team owns the networking-powervm project.  When we moved from the
> StackForge to OpenStack namespace we changed the name from neutron-powervm
> to networking-powervm.  There is no reason for the PyPI project to have a
> different name and we were planning to publish an update shortly with the
> networking-powervm name.
>
> We were planning to do this sometime next week.  Do we need it done sooner?
>
> That should be perfect, let me know when it's done so I can remove the WIP
on the patch below. Thanks!


>
> Thanks!
>
> Drew Thorstensen
> Power Systems / Cloud Software
>
>
>
> From:Kyle Mestery <mest...@mestery.com>
> To:"OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date:11/03/2015 10:09 PM
> Subject:[openstack-dev] [neutron] [networking-powervm] Please
> createnetworking-powervm on PyPI
> --
>
>
>
> I'm reaching out to whoever owns the networking-powervm project [1]. I
> have a review out [2] which updates the PyPI publishing jobs so we can push
> releases for networking-powervm. However, in looking at PyPI, I don't see a
> networking-powervm project, but instead a neutron-powervm project. Is there
> a reason for the PyPI project to have a different name? I believe this will
> not allow us to push releases, as the name of the projects need to match.
> Further, the project creation guide recommends naming them the same [4].
>
> Can someone from the PowerVM team look at registering networking-powervm
> on PyPI and correcting this please?
>
> Thanks!
> Kyle
>
> [1] *https://launchpad.net/neutron-powervm*
> <https://launchpad.net/neutron-powervm>
> [2] *https://review.openstack.org/#/c/233466/*
> <https://review.openstack.org/#/c/233466/>
> [3] *https://pypi.python.org/pypi/neutron-powervm/0.1.0*
> <https://pypi.python.org/pypi/neutron-powervm/0.1.0>
>
> [4] *http://docs.openstack.org/infra/manual/creators.html#pypi*
> <http://docs.openstack.org/infra/manual/creators.html#pypi>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?

[Kyle Mestery]

On Tue, Nov 3, 2015 at 10:49 AM, Ihar Hrachyshka 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> currently we have a single neutron-wide stable-maint gerrit group that
> maintains all stable branches for all stadium subprojects. I believe
> that in lots of cases it would be better to have subproject members to
> run their own stable maintenance programs, leaving
> neutron-stable-maint folks to help them in non-obvious cases, and to
> periodically validate that project wide stable policies are still honore
> d.
>
> I suggest we open gate to creating subproject stable-maint teams where
> current neutron-stable-maint members feel those subprojects are ready
> for that and can be trusted to apply stable branch policies in
> consistent way.
>
> Note that I don't suggest we grant those new permissions completely
> automatically. If neutron-stable-maint team does not feel safe to give
> out those permissions to some stable branches, their feeling should be
> respected.
>
> I believe it will be beneficial both for subprojects that would be
> able to iterate on backports in more efficient way; as well as for
> neutron-stable-maint members who are often busy with other stuff, and
> often times are not the best candidates to validate technical validity
> of backports in random stadium projects anyway. It would also be in
> line with general 'open by default' attitude we seem to embrace in
> Neutron.
>
> If we decide it's the way to go, there are alternatives on how we
> implement it. For example, we can grant those subproject teams all
> permissions to merge patches; or we can leave +W votes to
> neutron-stable-maint group.
>
> I vote for opening the gates, *and* for granting +W votes where
> projects showed reasonable quality of proposed backports before; and
> leaving +W to neutron-stable-maint in those rare cases where history
> showed backports could get more attention and safety considerations
> [with expectation that those subprojects will eventually own +W votes
> as well, once quality concerns are cleared].
>
> If we indeed decide to bootstrap subproject stable-maint teams, I
> volunteer to reach the candidate teams for them to decide on initial
> lists of stable-maint members, and walk them thru stable policies.
>
> Comments?
>
>
As someone who spends a considerable amount of time reviewing stable
backports on a regular basis across all the sub-projects, I'm in favor of
this approach. I'd like to be included when selecting teams which are
approproate to have their own stable teams as well. Please include me when
doing that.

Thanks,
Kyle


> Ihar
> -BEGIN PGP SIGNATURE-
>
> iQEcBAEBAgAGBQJWOOWkAAoJEC5aWaUY1u57sVIIALrnqvuj3t7c25DBHvywxBZV
> tCMlRY4cRCmFuVy0VXokM5DxGQ3VRwbJ4uWzuXbeaJxuVWYT2Kn8JJ+yRjdg7Kc4
> 5KXy3Xv0MdJnQgMMMgyjJxlTK4MgBKEsCzIRX/HLButxcXh3tqWAh0oc8WW3FKtm
> wWFZ/2Gmf4K9OjuGc5F3dvbhVeT23IvN+3VkobEpWxNUHHoALy31kz7ro2WMiGs7
> GHzatA2INWVbKfYo2QBnszGTp4XXaS5KFAO8+4H+HvPLxOODclevfKchOIe6jthH
> F1z4JcJNMmQrQDg1WSqAjspAlne1sqdVLX0efbvagJXb3Ju63eSLrvUjyCsZG4Q=
> =HE+y
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [networking-powervm] Please create networking-powervm on PyPI

[Kyle Mestery]

I'm reaching out to whoever owns the networking-powervm project [1]. I have
a review out [2] which updates the PyPI publishing jobs so we can push
releases for networking-powervm. However, in looking at PyPI, I don't see a
networking-powervm project, but instead a neutron-powervm project. Is there
a reason for the PyPI project to have a different name? I believe this will
not allow us to push releases, as the name of the projects need to match.
Further, the project creation guide recommends naming them the same [4].

Can someone from the PowerVM team look at registering networking-powervm on
PyPI and correcting this please?

Thanks!
Kyle

[1] https://launchpad.net/neutron-powervm
[2] https://review.openstack.org/#/c/233466/
[3] https://pypi.python.org/pypi/neutron-powervm/0.1.0
[4] http://docs.openstack.org/infra/manual/creators.html#pypi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Neutron sub-project release association with Liberty?

[Kyle Mestery]

On Fri, Oct 30, 2015 at 4:05 AM, Vadivel Poonathan <
vadivel.openst...@gmail.com> wrote:

> Hi,
>
> Once the Neutron's sub-project is released to pyPI, where does it show
> that this sub-project release is associated with Liberty release of
> Openstack?.. I tried to see it in the Liberty Release notes, but it doesn't
> have any info about the supported/released vendor plug-ins/drivers.
>
>
The sub-projects are not associated with Liberty, as they are all contain
the "release:independent" tag in the governance repository. For example,
the networking-ale-omniswitch driver has that and you can see it here [1].

[1] http://governance.openstack.org/reference/projects/neutron.html


> I see the plug-in is listed here in the official sub-project list, but
> again it is not specific to a particular release.
> http://docs.openstack.org/developer/neutron/devref/sub_projects.html
> 
>
>
Right, because these are "release:independent." See my comment above.


>
> In the following link, i see but only some vendor plug-ins, not all is
> listed here!... why only some of vendor drivers are shipped with Openstack
> and not all?..
> https://www.openstack.org/marketplace/drivers/
> 
>
>
I believe you want to add your driver to the driver-log project here [2].

[2] https://github.com/openstack/driverlog/blob/master/etc/default_data.json


> So what is the criteria to get a vendor plug-in listed on this page? or
> where can i see the supported vendor plugins/drivers for a given Openstack
> release (specfically Liberty) ??
>
> Any info/link on this would be much helpful and appreciated?...
>
> Thanks,
> Vad
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Kyle Mestery]

On Wed, Oct 21, 2015 at 11:37 AM, Armando M.  wrote:

>
>
> On 21 October 2015 at 04:12, Gal Sagie  wrote:
>
>> Do we also want to consider Project Kuryr part of this?
>>
>
> No, why would we?
>
>
The reason to consider it is because Kuryr is a sub-project of Neutron, and
they are doing their spec submissions following the Neutron guidelines.
Adding the kuryr-core gerrit group to be on part with the *aas repos makes
sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
reviews in the neutron-specs repository, then adding them makes sense too.


> We already started sending Kuryr spec to the Neutron repository and I
>> think it would make sense to manage it
>> as part of Neutron spec process.
>>
>
> No, unless what you are asking are changes to the core. Do you have a
> reference for me to look at?
>
>
See above, perhaps I answered this for you.


>
>> Any opinions on that?
>>
>> Gal.
>>
>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>>
>>> Hi folks,
>>>
>>> During revision of the Neutron teams [1], we made clear that the
>>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>>> (core + *-aas).
>>>
>>> For this reason I made sure that the neutron-specs-core team +2 right
>>> was extended to all the core teams.
>>>
>>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>>> project, you should exercise that vote only for specs that pertain the
>>> project you're core of.
>>>
>>> If I could use this email as a reminder also of the core hierarchy and
>>> lieutenant system we switched to in Liberty ([3]): if you have been made
>>> core by a lieutenant of a sub-system, please use your +2/+A only within
>>> your area of comfort and reach out for help if in doubt.
>>>
>>> Reviews are always welcome though!
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/237180/
>>> [2] https://review.openstack.org/#/admin/groups/314,members
>>> [3]
>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Kyle Mestery]

On Wed, Oct 21, 2015 at 12:34 PM, Armando M. <arma...@gmail.com> wrote:

>
>
> On 21 October 2015 at 10:29, Kyle Mestery <mest...@mestery.com> wrote:
>
>> On Wed, Oct 21, 2015 at 12:08 PM, Armando M. <arma...@gmail.com> wrote:
>>
>>>
>>>
>>> On 21 October 2015 at 09:53, Kyle Mestery <mest...@mestery.com> wrote:
>>>
>>>> On Wed, Oct 21, 2015 at 11:37 AM, Armando M. <arma...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 21 October 2015 at 04:12, Gal Sagie <gal.sa...@gmail.com> wrote:
>>>>>
>>>>>> Do we also want to consider Project Kuryr part of this?
>>>>>>
>>>>>
>>>>> No, why would we?
>>>>>
>>>>>
>>>> The reason to consider it is because Kuryr is a sub-project of Neutron,
>>>> and they are doing their spec submissions following the Neutron guidelines.
>>>> Adding the kuryr-core gerrit group to be on part with the *aas repos makes
>>>> sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
>>>> reviews in the neutron-specs repository, then adding them makes sense too.
>>>>
>>>
>>> I don't believe this is the road we set ourselves on when we started the
>>> decomp/stadium. We wanted a clear separation of concerns and I don't see
>>> how going down this path is going to help us achieve that.
>>>
>>> I don't see the grounds to have such an abrupt change in direction right
>>> now, especially for the level of work that that would imply and the
>>> pressure that would put on the drivers team. Anyone is free to review and
>>> contribute where it matters for them, and location should not prevent them
>>> from doing so.
>>>
>>>
>> I was merely implying that since these projects are part of neutron, and
>> they have specs, keeping them in one place makes sense. And by doing that,
>> we'd need to give them +2 powers for their core reviewers. But, I'm fine
>> with leaving things the way they are and having them put their specs in
>> their devref. But we should update the devref in Neutron to reflect this,
>> e.g. that we don't expect specs in neutron-specs for things outside
>> [neutron, neutron-fwaas, neutron-lbaas, neutron-vpnaas].
>>
>>
>
> IMO, it's pretty clear from here [1], which I revised in the context of
> [2]. Not sure if there's anything else that's left to misunderstanding.
>
>
I think this [1] helps to make it 100% clearer, at least to me.

[1] https://review.openstack.org/238190


> [1]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team
> [2] https://review.openstack.org/#/c/237180/
>
>
>
>>
>>>>
>>>>> We already started sending Kuryr spec to the Neutron repository and I
>>>>>> think it would make sense to manage it
>>>>>> as part of Neutron spec process.
>>>>>>
>>>>>
>>>>> No, unless what you are asking are changes to the core. Do you have a
>>>>> reference for me to look at?
>>>>>
>>>>>
>>>> See above, perhaps I answered this for you.
>>>>
>>>
>>>>
>>>>>
>>>>>> Any opinions on that?
>>>>>>
>>>>>> Gal.
>>>>>>
>>>>>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M. <arma...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> During revision of the Neutron teams [1], we made clear that the
>>>>>>> neutron-specs repo is to be targeted by specs for all the Neutron 
>>>>>>> projects
>>>>>>> (core + *-aas).
>>>>>>>
>>>>>>> For this reason I made sure that the neutron-specs-core team +2
>>>>>>> right was extended to all the core teams.
>>>>>>>
>>>>>>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>>>>>>> project, you should exercise that vote only for specs that pertain the
>>>>>>> project you're core of.
>>>>>>>
>>>>>>> If I could use this email as a reminder also of the core hierarchy
>>>>>>> and lieutenant system we switched to in Liberty ([3]): if you ha

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Kyle Mestery]

On Wed, Oct 21, 2015 at 12:08 PM, Armando M. <arma...@gmail.com> wrote:

>
>
> On 21 October 2015 at 09:53, Kyle Mestery <mest...@mestery.com> wrote:
>
>> On Wed, Oct 21, 2015 at 11:37 AM, Armando M. <arma...@gmail.com> wrote:
>>
>>>
>>>
>>> On 21 October 2015 at 04:12, Gal Sagie <gal.sa...@gmail.com> wrote:
>>>
>>>> Do we also want to consider Project Kuryr part of this?
>>>>
>>>
>>> No, why would we?
>>>
>>>
>> The reason to consider it is because Kuryr is a sub-project of Neutron,
>> and they are doing their spec submissions following the Neutron guidelines.
>> Adding the kuryr-core gerrit group to be on part with the *aas repos makes
>> sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
>> reviews in the neutron-specs repository, then adding them makes sense too.
>>
>
> I don't believe this is the road we set ourselves on when we started the
> decomp/stadium. We wanted a clear separation of concerns and I don't see
> how going down this path is going to help us achieve that.
>
> I don't see the grounds to have such an abrupt change in direction right
> now, especially for the level of work that that would imply and the
> pressure that would put on the drivers team. Anyone is free to review and
> contribute where it matters for them, and location should not prevent them
> from doing so.
>
>
I was merely implying that since these projects are part of neutron, and
they have specs, keeping them in one place makes sense. And by doing that,
we'd need to give them +2 powers for their core reviewers. But, I'm fine
with leaving things the way they are and having them put their specs in
their devref. But we should update the devref in Neutron to reflect this,
e.g. that we don't expect specs in neutron-specs for things outside
[neutron, neutron-fwaas, neutron-lbaas, neutron-vpnaas].


>
>>
>>> We already started sending Kuryr spec to the Neutron repository and I
>>>> think it would make sense to manage it
>>>> as part of Neutron spec process.
>>>>
>>>
>>> No, unless what you are asking are changes to the core. Do you have a
>>> reference for me to look at?
>>>
>>>
>> See above, perhaps I answered this for you.
>>
>
>>
>>>
>>>> Any opinions on that?
>>>>
>>>> Gal.
>>>>
>>>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M. <arma...@gmail.com> wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> During revision of the Neutron teams [1], we made clear that the
>>>>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>>>>> (core + *-aas).
>>>>>
>>>>> For this reason I made sure that the neutron-specs-core team +2 right
>>>>> was extended to all the core teams.
>>>>>
>>>>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>>>>> project, you should exercise that vote only for specs that pertain the
>>>>> project you're core of.
>>>>>
>>>>> If I could use this email as a reminder also of the core hierarchy and
>>>>> lieutenant system we switched to in Liberty ([3]): if you have been made
>>>>> core by a lieutenant of a sub-system, please use your +2/+A only within
>>>>> your area of comfort and reach out for help if in doubt.
>>>>>
>>>>> Reviews are always welcome though!
>>>>>
>>>>> Cheers,
>>>>> Armando
>>>>>
>>>>> [1] https://review.openstack.org/#/c/237180/
>>>>> [2] https://review.openstack.org/#/admin/groups/314,members
>>>>> [3]
>>>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards ,
>>>>
>>>> The G.
>>>>
>>>>
>>>> __

Re: [openstack-dev] [Neutron] HenryG addition to the Neutron Drivers team

[Kyle Mestery]

On Wed, Oct 21, 2015 at 4:01 AM, Ihar Hrachyshka 
wrote:

>
> > On 21 Oct 2015, at 05:14, Armando M.  wrote:
> >
> > Hi folks,
> >
> > Henry has been instrumental in many areas of the projects and his crazy
> working hours makes even Kevin and I bow in awe.
> >
> > Jokes aside, I would like to announce HenryG as a new member of the
> Neutron Drivers team.
> >
> > Having a propension to attendance, and desire to review of RFEs puts you
> on the right foot to join the group, whose members are rotated regularly so
> that everyone is given the opportunity to grow, and no-one burns out.
> >
> > The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
> attend.
> >
> > Please, join me in welcome Henry to the team.
>
> Nice addition. :)
>
> Do we have criteria for neutron-drivers team members documented? Or is it
> a mere ‘regularly attending the meetings, be mindful and apply common
> sense’?
>
> Like everything in Neutron, we do in fact have documentation on this. You
can find it here [1]. I imagine it could be expanded a bit to include some
more information, but it's a good start nonetheless.

Thanks,
Kyle

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

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

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Kyle Mestery]

On Wed, Oct 21, 2015 at 6:12 AM, Gal Sagie  wrote:

> Do we also want to consider Project Kuryr part of this?
> We already started sending Kuryr spec to the Neutron repository and I
> think it would make sense to manage it
> as part of Neutron spec process.
>
> Any opinions on that?
>
> I think this makes sense, and I'd be in favor of this.


> Gal.
>
> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>
>> Hi folks,
>>
>> During revision of the Neutron teams [1], we made clear that the
>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>> (core + *-aas).
>>
>> For this reason I made sure that the neutron-specs-core team +2 right was
>> extended to all the core teams.
>>
>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>> project, you should exercise that vote only for specs that pertain the
>> project you're core of.
>>
>> If I could use this email as a reminder also of the core hierarchy and
>> lieutenant system we switched to in Liberty ([3]): if you have been made
>> core by a lieutenant of a sub-system, please use your +2/+A only within
>> your area of comfort and reach out for help if in doubt.
>>
>> Reviews are always welcome though!
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/237180/
>> [2] https://review.openstack.org/#/admin/groups/314,members
>> [3]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Kyle Mestery]

On Sun, Oct 18, 2015 at 1:54 PM, Murali R  wrote:

> Will there be an irc opened for these sessions to join remotely?
>
> We will have people in the room who will be on IRC, yes, just use
#openstack-neutron. Even better, you can comment on the etherpad live while
the session is going on, which is a good way to attend remotely as well.


>
>
> On Sun, Oct 18, 2015 at 9:19 AM, Armando M.  wrote:
>
>> Perhaps adding a section for 'collecting ideas' right at the bottom of
>> the etherpad will help directing input.
>>
>> We should strive for keeping the session focussed, sessions are only 40
>> mins, and realistically we'll only have 30 mins to talk about the meaty
>> stuff. If we want to go through bullet by bullet, we'll need an entire
>> summit :)
>>
>> Cheers,
>> Armando
>>
>>
>> On 18 October 2015 at 09:14, Armando M.  wrote:
>>
>>> Gal,
>>>
>>> [2] is not meant to be edited by anyone just yet. This will lead to
>>> chaos and an unproductive session. Once the link is out is obvious that
>>> anyone can edit, but welcoming input is a recipe for disaster!
>>>
>>> I appreciate the initiative, but please consider running thoughts by me
>>> for advice.
>>>
>>> Cheers,
>>> Armando
>>>
>>> On 18 October 2015 at 04:09, Gal Sagie  wrote:
>>>
 Hello All,

 In OpenStack Tokyo summit we will have a design summit session for
 containers networking
 and containers orchestration engines integration with Neutron [1].

 Please feel free to edit the session etherpad [2] with relevant topics,
 if you are working
 and have any gaps or needs from Neutron in that area, please share.

 Even if we cant resolve everything in one session, i think it would be
 great to at least understand
 the problems and document them so we can address the needs and
 priorities during the upcoming cycle.

 Thanks
 Gal.

 [1]
 http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
 [2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration


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


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

Re: [openstack-dev] [neutron][stable] proactive backporting

[Kyle Mestery]

On Fri, Oct 16, 2015 at 7:33 AM, Ihar Hrachyshka 
wrote:

> Hi all,
>
> I’d like to introduce a new initiative around stable branches for neutron
> official projects (neutron, neutron-*aas, python-neutronclient) that is
> intended to straighten our backporting process and make us more proactive
> in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a
> known bug hits a user that consumes stable branches, but backport fixes in
> advance quickly after they hit master.
>
> The idea is simple: every Fri I walk thru the new commits merged into
> master since last check; produce lists of bugs that are mentioned in
> Related-Bug/Closes-Bug; paste them into:
>
> https://etherpad.openstack.org/p/stable-bug-candidates-from-master
>
> Then I click thru the bug report links to determine whether it’s worth a
> backport and briefly classify them. If I have cycles, I also request
> backports where it’s easy (== a mere 'Cherry-Pick to' button click).
>
> After that, those interested in maintaining neutron stable branches can
> take those bugs one by one and handle them, which means: checking where it
> really applies for backport; creating backport reviews (solving conflicts,
> making tests pass). After it’s up for review for all branches affected and
> applicable, the bug is removed from the list.
>
> I started on that path two weeks ago, doing initial swipe thru all commits
> starting from stable/liberty spin off. If enough participants join the
> process, we may think of going back into git history to backport
> interesting fixes from stable/liberty into stable/kilo.
>
> Don’t hesitate to ask about details of the process, and happy backporting,
>
> Wow, this is a great idea Ihar! Thanks for taking this on! Count me in on
helping with this effort as well.

Thanks,
Kyle


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

Re: [openstack-dev] [neutron] pypi packages for networking sub-projects

[Kyle Mestery]

On Thu, Oct 15, 2015 at 7:03 AM, Neil Jerram 
wrote:

> On 02/10/15 12:33, Neil Jerram wrote:
> > On 02/10/15 11:42, Neil Jerram wrote:
> >> Thanks Kyle! I'm looking at this now for networking-calico.
> > Done, please see https://pypi.python.org/pypi/networking-calico.
> >
> > When you release, how will the version number be decided?  [...]
>
> Excitingly, I believe networking-calico is ready now for its first
> release.  Kyle - would you mind doing the honours?
>
>
Cool! Yes, I can help you. Can you follow the instructions here [1]?

Thanks!
Kyle

[1]
http://docs.openstack.org/developer/neutron/policies/bugs.html#plugin-and-driver-repositories

> (I'm assuming you're still the right person to ask - please do correct
> me if not!)
>
> Thanks,
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] From where will start particiption in Neutron Component?

[Kyle Mestery]

On Tue, Oct 13, 2015 at 1:41 AM, Neil Jerram 
wrote:

> On 13/10/15 08:45, chandraprakash mishra wrote:
> > Hi Folks,
> >
> > I have just started looking OpenStack ,As of now i would like to start
> > participation for neutron component . So where can i start participate
> > for neutron component .Is there any documentation for this components
> > so that I can start work on from bug-fix .Please any one help me(or
> > share any document)
>
> Yes, please take a look at
> http://docs.openstack.org/developer/neutron/devref/.  There is lots of
> information there about Neutron components.
>
>
And once you've done that, you can look at some low-hanging-fruit bugs [1]
as a good starting point for bugs to get you started with the codebase.

[1] https://bugs.launchpad.net/neutron/+bugs?field.tag=low-hanging-fruit

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

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

[Kyle Mestery]

On Fri, Oct 9, 2015 at 8:52 AM, Russell Bryant  wrote:

> On 10/09/2015 05:42 AM, Thierry Carrez wrote:
> > Hello everyone,
> >
> > OpenStack has become quite big, and it's easier than ever to feel lost,
> > to feel like nothing is really happening. It's more difficult than ever
> > to feel part of a single community, and to celebrate little successes
> > and progress.
> >
> > In a (small) effort to help with that, I suggested making it easier to
> > record little moments of joy and small success bits. Those are usually
> > not worth the effort of a blog post or a new mailing-list thread, but
> > they show that our community makes progress *every day*.
> >
> > So whenever you feel like you made progress, or had a little success in
> > your OpenStack adventures, or have some joyful moment to share, just
> > throw the following message on your local IRC channel:
> >
> > #success [Your message here]
> >
> > The openstackstatus bot will take that and record it on this wiki page:
> >
> > https://wiki.openstack.org/wiki/Successes
> >
> > We'll add a few of those every week to the weekly newsletter (as part of
> > the developer digest that we reecently added there).
> >
> > Caveats: Obviously that only works on channels where openstackstatus is
> > present (the official OpenStack IRC channels), and we may remove entries
> > that are off-topic or spam.
> >
> > So... please use #success liberally and record lttle everyday OpenStack
> > successes. Share the joy and make the OpenStack community a happy place.
> >
>
> This is *really* cool.  I'm excited to use this and see all the things
> others record.  Thanks!!
>
>
Indeed, sometimes it's easy to get lost in the bike shedding, this is a
good way for everyone to remember the little successes that people are
having. After all, this project is composed of actual people, it's good to
highlight the little things we each consider a success. Well done!

Thanks,
Kyle


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

Re: [openstack-dev] [Neutron] L2 gateway project

[Kyle Mestery]

On Fri, Oct 9, 2015 at 10:13 AM, Gary Kotton  wrote:

> Hi,
> Who will be creating the stable/liberty branch?
> Thanks
> Gary
>
>
I'll be doing this once someone from the L2GW team lets me know a commit
SHA to create it from.

Thanks,
Kyle


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

Re: [openstack-dev] [neutron] pypi packages for networking sub-projects

[Kyle Mestery]

On Fri, Oct 2, 2015 at 6:33 AM, Neil Jerram 
wrote:

> On 02/10/15 11:42, Neil Jerram wrote:
> > Thanks Kyle! I'm looking at this now for networking-calico.
>
> Done, please see https://pypi.python.org/pypi/networking-calico.
>
> When you release, how will the version number be decided?  And should I
> make a change to put that version into the source somewhere, or will you
> do that?  Currently it appears that there's no explicit version in the
> source, but that the build process somehow infers '0.0.1.dev8'.
>
> For the PyPI registration I put 0.1.0, but that doesn't mean that I
> expect that to be the version number when networking-calico is actually
> released.  I guessed that PyPI might impose an increasing version number
> requirement, and that the real release number might be 1.0.something,
> and so chose something logically less than that.
>
> Hope that all makes sense!
>
>
I was going to go with post versioning here. That means I'll tag a 1.0.0
version when you're ready to release, and we don't need a version in the
setup.cfg file. If you want a different version, just let me know when you
request the release.

Thanks!
Kyle

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

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

[Kyle Mestery]

On Thu, Oct 1, 2015 at 9:57 AM, Sean M. Collins  wrote:

> On Thu, Oct 01, 2015 at 10:02:24AM EDT, Ihar Hrachyshka wrote:
> > - more changes with less infra tinkering! neutron devs should not need
> to go to infra projects so often to make an impact;
> > -- make our little neat devstack plugin used for qos and sr-iov only a
> huge pile of bash code that is currently stored in devstack and is proudly
> called neutron-legacy now; and make the latter obsolete and eventually
> removed from devstack;
>
> We may need to discuss this. I am currently doing a refactor of the
> Neutron DevStack integration in
>
> https://review.openstack.org/168438
>
> If I understand your message correctly, I disagree that we should be
> moving all the DevStack support for Neutron out of DevStack and making
> it a plugin. All that does is move the mess from one corner of the room,
> to another corner.
>
> I would actually be in favor of cleaning up the mess AND moving it into
neutron. If it's in Neutron, we control our own destiny with regards to
landing patches which affect devstack and ultimately our gate jobs. To me,
that's a huge win-win. Thus, cleanup first, then move to Neutron.


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

Re: [openstack-dev] [Neutron] Release of a neutron sub-project

[Kyle Mestery]

On Tue, Sep 29, 2015 at 8:04 PM, Kyle Mestery <mest...@mestery.com> wrote:

> On Tue, Sep 29, 2015 at 2:36 PM, Vadivel Poonathan <
> vadivel.openst...@gmail.com> wrote:
>
>> Hi,
>>
>> As per the Sub-Project Release process - i would like to tag and release
>> the following sub-project as part of upcoming Liberty release.
>> The process says talk to one of the member of 'neutron-release' group. I
>> couldn’t find a group mail-id for this group. Hence I am sending this email
>> to the dev list.
>>
>> I just have removed the version from setup.cfg and got the patch merged,
>> as specified in the release process. Can someone from the neutron-release
>> group makes this sub-project release.
>>
>>
>
> Vlad, I'll do this tomorrow. Find me on IRC (mestery) and ping me there so
> I can get your IRC NIC in case I have questions.
>
>
It turns out that the networking-ale-omniswitch pypi setup isn't correct,
see [1] for more info and how to correct. This turned out to be ok, because
it's forced me to re-examine the other networking sub-projects and their
pypi setup to ensure consistency, which the thread found here [1] will
resolve.

Once you resolve this ping me on IRC and I'll release this for you.

Thanks!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/075880.html


> Thanks!
> Kyle
>
>
>>
>> ALE Omniswitch
>> Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
>> Launchpad: https://launchpad.net/networking-ale-omniswitch
>> Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch
>>
>> Thanks,
>> Vad
>> --
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] pypi packages for networking sub-projects

[Kyle Mestery]

Folks:

In trying to release some networking sub-projects recently, I ran into an
issue [1] where I couldn't release some projects due to them not being
registered on pypi. I have a patch out [2] which adds pypi publishing jobs,
but before that can merge, we need to make sure all projects have pypi
registrations in place. The following networking sub-projects do NOT have
pypi registrations in place and need them created following the guidelines
here [3]:

networking-calico
networking-infoblox
networking-powervm

The following pypi registrations did not follow directions to enable
openstackci has "Owner" permissions, which allow for the publishing of
packages to pypi:

networking-ale-omniswitch
networking-arista
networking-l2gw
networking-vsphere

Once these are corrected, we can merge [2] which will then allow the
neutron-release team the ability to release pypi packages for those
packages.

Thanks!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html
[2] https://review.openstack.org/#/c/229564/1
[3]
http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] pypi packages for networking sub-projects

[Kyle Mestery]

Sukhdev, you're right, for some reason that one didn't show up in a pypi
search on pypi itself, but does in google. And it is correctly owned [1].

[1] https://pypi.python.org/pypi/networking_arista

On Wed, Sep 30, 2015 at 2:21 PM, Sukhdev Kapur <sukhdevka...@gmail.com>
wrote:

> Hey Kyle,
>
> I am bit confused by this. I just checked networking-arista and see that
> the co-owner of the project is openstackci
> I also checked the [1] and [2] and the settings for networking-arista are
> correct as well.
>
> What else is missing which make you put networking-arista in the second
> category?
> Please advise.
>
> Thanks
> -Sukhdev
>
>
> [1] - jenkins/jobs/projects.yaml
> <https://review.openstack.org/#/c/229564/1/jenkins/jobs/projects.yaml>
> [2] - zuul/layout.yaml
> <https://review.openstack.org/#/c/229564/1/zuul/layout.yaml>
>
> On Wed, Sep 30, 2015 at 11:55 AM, Kyle Mestery <mest...@mestery.com>
> wrote:
>
>> Folks:
>>
>> In trying to release some networking sub-projects recently, I ran into an
>> issue [1] where I couldn't release some projects due to them not being
>> registered on pypi. I have a patch out [2] which adds pypi publishing jobs,
>> but before that can merge, we need to make sure all projects have pypi
>> registrations in place. The following networking sub-projects do NOT have
>> pypi registrations in place and need them created following the guidelines
>> here [3]:
>>
>> networking-calico
>> networking-infoblox
>> networking-powervm
>>
>> The following pypi registrations did not follow directions to enable
>> openstackci has "Owner" permissions, which allow for the publishing of
>> packages to pypi:
>>
>> networking-ale-omniswitch
>> networking-arista
>> networking-l2gw
>> networking-vsphere
>>
>> Once these are corrected, we can merge [2] which will then allow the
>> neutron-release team the ability to release pypi packages for those
>> packages.
>>
>> Thanks!
>> Kyle
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html
>> [2] https://review.openstack.org/#/c/229564/1
>> [3]
>> http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] pypi packages for networking sub-projects

[Kyle Mestery]

On Wed, Sep 30, 2015 at 8:26 PM, Armando M. <arma...@gmail.com> wrote:

>
>
> On 30 September 2015 at 16:02, Cathy Zhang <cathy.h.zh...@huawei.com>
> wrote:
>
>> Hi Kyle,
>>
>>
>>
>> Is this only about the sub-projects that are ready for release? I do not
>> see networking-sfc sub-project in the list. Does this mean we have done the
>> pypi registrations for the networking-sfc project correctly or it is not
>> checked because it is not ready for release yet?
>>
>
> Can't speak for Kyle, but with these many meaty patches in flight [1], I
> think it's fair to assume that although the mechanisms are in place, Kyle
> is not going to release the project at this time; networking-sfc release is
> independent, we can publish the project when the time is ripe.
>
>
Armando is exactly spot on. The release of networking-sfc would appear to
be pretty early at this point. Once the patches land and the team has some
confidence in the API and it's testing status, we'll look at releasing it.

Thanks!
Kyle


> Cheers,
> Armando
>
> [1]
> https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc,n,z
>
>
>>
>>
>> Thanks,
>>
>> Cathy
>>
>>
>>
>> *From:* Kyle Mestery [mailto:mest...@mestery.com]
>> *Sent:* Wednesday, September 30, 2015 11:55 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [neutron] pypi packages for networking
>> sub-projects
>>
>>
>>
>> Folks:
>>
>> In trying to release some networking sub-projects recently, I ran into an
>> issue [1] where I couldn't release some projects due to them not being
>> registered on pypi. I have a patch out [2] which adds pypi publishing jobs,
>> but before that can merge, we need to make sure all projects have pypi
>> registrations in place. The following networking sub-projects do NOT have
>> pypi registrations in place and need them created following the guidelines
>> here [3]:
>>
>> networking-calico
>>
>> networking-infoblox
>>
>> networking-powervm
>>
>>
>>
>> The following pypi registrations did not follow directions to enable
>> openstackci has "Owner" permissions, which allow for the publishing of
>> packages to pypi:
>>
>> networking-ale-omniswitch
>>
>> networking-arista
>>
>> networking-l2gw
>>
>> networking-vsphere
>>
>>
>> Once these are corrected, we can merge [2] which will then allow the
>> neutron-release team the ability to release pypi packages for those
>> packages.
>>
>> Thanks!
>>
>> Kyle
>>
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html
>> [2] https://review.openstack.org/#/c/229564/1
>> [3]
>> http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [election] [TC] TC Candidacy

[Kyle Mestery]

I'd like to announce my candidacy for the TC election.

A bit about me and my involvement with OpenStack: I've been
involved with OpenStack for a long time now in various capacities.
Most recently, I was the PTL for Neutron for the Juno, Kilo and
Liberty cycles. I've been a core reviewer on Neutron since July of
2013. I helped to write the Project Team Guide [1] by participating
in the sprint during it's creation. I founded and continue to lead
the Minnesota OpenStack Meetup [2]. I've spoken at many OpenStack
conferences and other Open Source conferences.

Given the "Big Tent" governance model we now find ourselves under,
my experience in leading Neutron as it adopted the "Neutron Stadium"
is very relevant to the current state of OpenStack. While leading
Neutron, the "Neutron Stadium" allowed many new project teams to
develop and grow. I hope to be able to work with new OpenStack
projects and guide them as they grow into OpenStack projects. I'd
also like to ensure the uniqueness which each projects brings to the
table isn't lost when it becomes an OpenStack project. While I
firmly believe each project must adopt the Four Opens [3] in order
to become an OpenStack project, it's important to not lose the
original spark which was lit to start these projects as they move
into the Big Tent.

If I'm elected, I will continue to dedicate time to work upstream
and help new and old projects. I'll work hard to assist anyone who
requests my help. And I'll continue to strive to do what I can
to ensure OpenStack's future success.

OpenStack has been an amazing community to be involved in. I am
fortunate to have been a part of this community for a long time now,
and should I be elected, I look forward to the chance to help guide
it while serving on the TC for the next two cycles!

Thank you!

--
Kyle Mestery
IRC: mestery

[1] http://docs.openstack.org/project-team-guide/
[2] http://www.meetup.com/Minnesota-OpenStack-Meetup/
[3]
http://docs.openstack.org/project-team-guide/introduction.html#the-four-opens
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Release of a neutron sub-project

[Kyle Mestery]

On Tue, Sep 29, 2015 at 2:36 PM, Vadivel Poonathan <
vadivel.openst...@gmail.com> wrote:

> Hi,
>
> As per the Sub-Project Release process - i would like to tag and release
> the following sub-project as part of upcoming Liberty release.
> The process says talk to one of the member of 'neutron-release' group. I
> couldn’t find a group mail-id for this group. Hence I am sending this email
> to the dev list.
>
> I just have removed the version from setup.cfg and got the patch merged,
> as specified in the release process. Can someone from the neutron-release
> group makes this sub-project release.
>
>

Vlad, I'll do this tomorrow. Find me on IRC (mestery) and ping me there so
I can get your IRC NIC in case I have questions.

Thanks!
Kyle


>
> ALE Omniswitch
> Git: https://git.openstack.org/cgit/openstack/networking-ale-omniswitch
> Launchpad: https://launchpad.net/networking-ale-omniswitch
> Pypi: https://pypi.python.org/pypi/networking-ale-omniswitch
>
> Thanks,
> Vad
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

[Kyle Mestery]

On Mon, Sep 28, 2015 at 4:00 PM, Assaf Muller  wrote:

>
>
> On Mon, Sep 28, 2015 at 12:40 PM, Zane Bitter  wrote:
>
>> On 28/09/15 05:47, Gorka Eguileor wrote:
>>
>>> On 26/09, Morgan Fainberg wrote:
>>>
 As a core (and former PTL) I just ignored commit message -1s unless
 there is something majorly wrong (no bug id where one is needed, etc).

 I appreciate well formatted commits, but can we let this one go? This
 discussion is so far into the meta-bike-shedding (bike shedding about bike
 shedding commit messages) ... If a commit message is *that* bad a -1 (or
 just fixing it?) Might be worth it. However, if a commit isn't missing key
 info (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence
 moving from topic to topic, there isn't a good reason to block the review.

>>>
>> +1
>>
>> It is not worth having a bot -1 bad commits or even having gerrit muck
 with them. Let's do the job of the reviewer and actually review code
 instead of going crazy with commit messages.

>>>
>> +1
>>
>> Sent via mobile


>>> I have to disagree, as reviewers we have to make sure that guidelines
>>> are followed, if we have an explicit guideline that states that
>>> the limit length is 72 chars, I will -1 any patch that doesn't follow
>>> the guideline, just as I would do with i18n guideline violations.
>>>
>>
>> Apparently you're unaware of the definition of the word 'guideline'. It's
>> a guide. If it were a hard-and-fast rule then we would have a bot enforcing
>> it already.
>>
>> Is there anything quite so frightening as a large group of people blindly
>> enforcing rules with total indifference to any sense of overarching purpose?
>>
>> A reminder that the reason for this guideline is to ensure that none of
>> the broad variety of tools that are available in the Git ecosystem
>> effectively become unusable with the OpenStack repos due to wildly
>> inconsistent formatting. And of course, even that goal has to be balanced
>> against our other goals, such as building a healthy community and
>> occasionally shipping some software.
>>
>> There are plenty of ways to achieve that goal other than blanket drive-by
>> -1's for trivial inconsistencies in the formatting of individual commit
>> messages.
>
>
> The actual issue is that we as a community (Speaking of the Neutron
> community at least) are stat-crazed. We have a fair number of contributors
> that -1 for trivial issues to retain their precious stats with alarming
> zeal. That is the real issue. All of these commit message issues,
> translation mishaps,
> comment typos etc are excuses for people to boost their stats without
> contributing their time or energy in to the project. I am beyond bitter
> about this
> issue at this point.
>
>
I should note that as the previous PTL, for the most part I viewed stats as
garbage. Keep in mind I nominated two new core reviewers whose stats were
lowe but who are incredibly important members of our community [1]. I did
this because they are the type of people to be core reviewers, and we had a
long conversation on this. So, I agree with you, this stats thing is awful.
And Stackalytics hasn't helped it, but made it much worse.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-August/071869.html


> I'll say what I've always said about this issue: The review process is
> about collaboration. I imagine that the author is sitting next to me, and
> we're going
> through the patch together for the purpose of improving it. Review
> comments should be motivated by a thirst to improve the proposed code in a
> real way,
> not by your want or need to improve your stats on stackalytics. The latter
> is an enormous waste of your time.
>
>
>> A polite comment and a link to the guidelines is a great way to educate
>> new contributors. For core reviewers especially, a comment like that and a
>> +1 review will *almost always* get you the change you want in double-quick
>> time. (Any contributor who knows they are 30s work away from a +2 is going
>> to be highly motivated.)
>>
>> Typos are a completely different matter and they should not be grouped
>>> together with guideline infringements.
>>>
>>
>> "Violations"? "Infringements"? It's line wrapping, not a felony case.
>>
>> I agree that it is a waste of time and resources when you have to -1 a
>>> patch for this, but there multiple solutions, you can make sure your
>>> editor does auto wrapping at the right length (I have mine configured
>>> this way), or create a git-enforce policy with a client-side hook, or do
>>> like Ihar is trying to do and push for a guideline change.
>>>
>>> I don't mind changing the guideline to any other length, but as long as
>>> it is 72 chars I will keep enforcing it, as it is not the place of
>>> reviewers to decide which guidelines are worthy of being enforced and
>>> which ones are not.
>>>
>>
>> Of course it is.
>>
>> If we're not here to use our 

Re: [openstack-dev] [cinder][neutron][all] New third-party-ci testing requirements for OpenStack Compatible mark

[Kyle Mestery]

The Neutron team also discussed this in Vancouver, you can see the etherpad
here [1]. We talked about the idea of creating a validation suite, and it
sounds like that's something we should again discuss in Tokyo for the
Mitaka cycle. I think a validation suite would be a great step forward for
Neutron third-party CI systems to use to validate they work with a release.

[1] https://etherpad.openstack.org/p/YVR-neutron-third-party-ci-liberty

On Sun, Sep 27, 2015 at 11:39 AM, Armando M.  wrote:

>
>
> On 25 September 2015 at 15:40, Chris Hoge  wrote:
>
>> In November, the OpenStack Foundation will start requiring vendors
>> requesting
>> new "OpenStack Compatible" storage driver licenses to start passing the
>> Cinder
>> third-party integration tests.
>
> The new program was approved by the Board at
>> the July meeting in Austin and follows the improvement of the testing
>> standards
>> and technical requirements for the "OpenStack Powered" program. This is
>> all
>> part of the effort of the Foundation to use the OpenStack brand to
>> guarantee a
>> base-level of interoperability and consistency for OpenStack users and to
>> protect the work of our community of developers by applying a trademark
>> backed
>> by their technical efforts.
>>
>> The Cinder driver testing is the first step of a larger effort to apply
>> community determined standards to the Foundation marketing programs. We're
>> starting with Cinder because it has a successful testing program in
>> place, and
>> we have plans to extend the program to network drivers and OpenStack
>> applications. We're going require CI testing for new "OpenStack
>> Compatible"
>> storage licenses starting on November 1, and plan to roll out network and
>> application testing in 2016.
>>
>> One of our goals is to work with project leaders and developers to help us
>> define and implement these test programs. The standards for third-party
>> drivers and applications should be determined by the developers and users
>> in our community, who are experts in how to maintain the quality of the
>> ecosystem.
>>
>> We welcome and feedback on this program, and are also happy to answer any
>> questions you might have.
>>
>
> Thanks for spearheading this effort.
>
> Do you have more information/pointers about the program, and how Cinder in
> particular is
> paving the way for other projects to follow?
>
> Thanks,
> Armando
>
>
>> Thanks!
>>
>> Chris Hoge
>> Interop Engineer
>> OpenStack Foundation
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Kyle Mestery]

On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor  wrote:

> On 09/17/2015 04:50 PM, Anita Kuno wrote:
>
>> On 09/17/2015 08:22 AM, Matt Riedemann wrote:
>>
>>>
>>>
>>> On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
>>>
 PTL Nomination is now over. The official candidate list is available on
 the wiki[0].

 There are 5 projects without candidates, so according to this
 resolution[1], the TC we'll have to appoint a new PTL for Barbican,
 MagnetoDB, Magnum, Murano and Security

>>>
>>> This is devil's advocate, but why does a project technically need a PTL?
>>>   Just so that there can be a contact point for cross-project things,
>>> i.e. a lightning rod?  There are projects that do a lot of group
>>> leadership/delegation/etc, so it doesn't seem that a PTL is technically
>>> required in all cases.
>>>
>>
>> I think that is a great question for the TC to consider when they
>> evaluate options for action with these projects.
>>
>> The election officials are fulfilling their obligation according to the
>> resolution:
>>
>> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst
>>
>> If you read the verb there the verb is "can" not "must", I choose the
>> verb "can" on purpose for the resolution when I wrote it. The TC has the
>> option to select an appointee. The TC can do other things as well,
>> should the TC choose.
>>
>
> I agree- and this is a great example of places where human judgement is
> better than rules.
>
> For instance - one of the projects had a nominee but it missed the
> deadline, so that's probably an easy on.
>
> For one of the projects it had been looking dead for a while, so this is
> the final nail in the coffin from my POV
>
> For the other three - I know they're still active projects with people
> interested in them, so sorting them out will be fun!
>
>
This is the right approach. Human judgement #ftw! :)


>
>
>>
>>>
 There are 7 projects that will have an election: Cinder, Glance, Ironic,
 Keystone, Mistral, Neutron and Oslo. The details for those will be
 posted tomorrow after Tony and I setup the CIVS system.

 Thank you,
 Tristan


 [0]:

 https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates

 [1]:

 http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html






 __

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


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

Re: [openstack-dev] [Neutron] Effective Neutron

[Kyle Mestery]

On Thu, Sep 17, 2015 at 10:20 AM, Armando M.  wrote:

> Hi fellow developers and reviewers,
>
> Some of you may have noticed that I put together patch [1] up for review.
>
> The intention of this initiative is to capture/share 'pills of wisdom'
> when it comes to Neutron development and reviewing. In fact, there are a
> number of common patterns (or anti-patterns) that we keep stumbling on, and
> I came to the realization that if we all stopped for a second and captured
> those in writing for any newcomer (or veteran) to see, we would all benefit
> during code reviews and development, because we'd all know what to watch
> out for. The wishful thinking is that once this document reaches critical
> mass, we will all have learned how to avoid common mistakes and get our
> patches merged swiftly.
>
> It is particularly aimed at the Neutron contributor and it is not meant to
> replace the wealth of information that is available on doc.openstack.org,
> the wiki or the Internet. This is also not meant to be a cross-project
> effort, because let's face it...every project is different, and pills of
> wisdom in Neutron may as well be everyone's knowledge in Heat, etc.
>
> I aim to add more material over the next couple of days, also with the
> help of some of you, so bear with me while the patch is in WIP.
>
> Feedback welcome.
>
>
Thanks for sending this out and working on this patch Armando. This is
going to greatly assist everyone working on Neutron. Nice job!

Kyle


> Many thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/224419/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Kyle Mestery]

On Thu, Sep 17, 2015 at 3:19 PM, Anne Gentle 
wrote:

>
>
> On Thu, Sep 17, 2015 at 3:15 PM, John Griffith 
> wrote:
>
>>
>>
>> On Thu, Sep 17, 2015 at 2:00 PM, Doug Hellmann 
>> wrote:
>>
>>> Excerpts from Morgan Fainberg's message of 2015-09-17 12:51:33 -0700:
>>>
>>> > I think this is all superfluous however and we should simply encourage
>>> > people to not wait until the last minute. Waiting to see who is
>>> > running/what the field looks like isn't as important as standing up and
>>> > saying you're interested in running.
>>>
>>> +1
>>>
>>> Doug
>>>
>>>
>>> __
>>> 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
>>>
>>
>> ​My dog ate my homework...
>> My car wouldn't start...
>> I couldn't figure out what UTC time was...
>>
>> The guidelines seemed pretty clear:
>> Any member of an election electorate can propose their candidacy for the
>> same election until September 17, 05:59 UTC​
>>
>> That being said, a big analysis on date/time selection etc doesn't really
>> seem warranted here or harping on the fact that something 'went wrong'.  I
>> as a TC member have no problem saying "things happen" and those that have
>> submitted candidacy albeit late and are unopposed are in.. no muss no
>> fuss.  I *think* we're all reasonable adults and don't know that anybody
>> had in mind that the TC would arbitrarily assign somebody that wasn't even
>> listed as a PTL for one of the mentioned projects.
>>
>>
> It's not so simple for Magnum, with 2 late candidacies. We'll figure it
> out but yes, we have work to do.
>
>
It could be simple: Let magnum have an election with both candidates. As
Monty said:

"... this is a great example of places where human judgement is better than
rules."

Thanks,
Kyle


> Anne
>
>
> Moving on,
>> John
>>
>>
>>
>> __
>> 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
>>
>
>
>
>
> --
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [relmgt] PTL non-candidacy

[Kyle Mestery]

On Wed, Sep 16, 2015 at 4:33 AM, Thierry Carrez 
wrote:

> Hi everyone,
>
> I have been handling release management for OpenStack since the
> beginning of this story, well before Release Management was a program or
> a project team needing a proper elected PTL. Until recently it was
> largely a one-man job. But starting with this cycle, to accommodate the
> Big Tent changes, we grew the team significantly, to the point where I
> think it is healthy to set up a PTL rotation in the team.
>
> I generally think it's a good thing to change the PTL for a team from
> time to time. That allows different perspectives, skills and focus to be
> brought to a project team. That lets you take a step back. That allows
> to recognize the efforts and leadership of other members, which is
> difficult if you hold on the throne. So I decided to put my foot where
> my mouth is and apply those principles to my own team.
>
> That doesn't mean I won't be handling release management for Mitaka, or
> that I won't ever be Release Management PTL again -- it's just that
> someone else will take the PTL hat for the next cycle, drive the effort
> and be the most visible ambassador of the team.
>
> Cheers,
>
>
You've done an amazing job as release management PTL. The project has been
incredibly lucky to have you handling this, and it's great to see you
rotating the position to grow more leadership in the team. Thanks for all
you've done over the years!

Kyle


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

Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team

[Kyle Mestery]

+1

On Wed, Sep 16, 2015 at 5:33 PM, Doug Wiegley 
wrote:

> Hi all,
>
> As the Lieutenant of the advanced services, I nominate Michael Johnson to
> be a member of the neutron-lbaas core reviewer team.
>
> Review stats are in line with other cores[2], and Michael has been
> instrumental in both neutron-lbaas and octavia.
>
> Existing cores, please vote +1/-1 for his addition to the team (that’s
> Brandon, Phil, Al, and Kyle.)
>
> Thanks,
> doug
>
> 1.
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
> 2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Kyle Mestery]

That's exactly right, and we need to get this merged early in Mitaka. We'll
discuss this in a design summit session in Tokyo in fact to ensure it's
resourced correctly and continues to address the evolving needs in this
space.

On Tue, Sep 15, 2015 at 10:47 AM, Doug Wiegley  wrote:

> Hi all,
>
> One solution to this was a neutron spec that was added for a “get me a
> network” api, championed by Jay Pipes, which would auto-assign a public
> network on vm boot. It looks like it was resource starved in Liberty,
> though:
>
> https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
>
> Thanks,
> doug
>
>
> On Sep 15, 2015, at 9:27 AM, Mike Spreitzer  wrote:
>
> Monty Taylor  wrote on 09/15/2015 11:04:07 AM:
>
> > a) an update to python-novaclient to allow a named network to be passed
> > to satisfy the "you have more than one network" - the nics argument is
> > still useful for more complex things
>
> I am not using the latest, but rather Juno.  I find that in many places
> the Neutron CLI insists on a UUID when a name could be used.  Three cheers
> for any campaign to fix that.
>
> And, yeah, creating VMs on a shared public network is good too.
>
> Thanks,
> mike
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL Non-Candidacy

[Kyle Mestery]

On Sat, Sep 12, 2015 at 12:32 PM, Ben Pfaff <b...@nicira.com> wrote:

> Are you planning to remain involved with OpenStack?
>
>
Yes, that's the plan!


> On Fri, Sep 11, 2015 at 2:12 PM, Kyle Mestery <mest...@mestery.com> wrote:
> > I'm writing to let everyone know that I do not plan to run for Neutron
> PTL
> > for a fourth cycle. Being a PTL is a rewarding but difficult job, as
> Morgan
> > recently put it in his non-candidacy email [1]. But it goes further than
> > that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> > full time job. In the case of Neutron, it's more than a full time job,
> it's
> > literally an always on job.
> >
> > I've tried really hard over my three cycles as PTL to build a stronger
> web
> > of trust so the project can grow, and I feel that's been accomplished. We
> > have a strong bench of future PTLs and leaders ready to go, I'm excited
> to
> > watch them lead and help them in anyway I can.
> >
> > As was said by Zane in a recent email [3], while Heat may have pioneered
> the
> > concept of rotating PTL duties with each cycle, I'd like to highly
> encourage
> > Neutron and other projects to do the same. Having a deep bench of leaders
> > supporting each other is important for the future of all projects.
> >
> > See you all in Tokyo!
> > Kyle
> >
> > [1]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> > [1]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> > [2]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
> >
> >
> __
> > 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
> >
>
>
>
> --
> "I don't normally do acked-by's.  I think it's my way of avoiding
> getting blamed when it all blows up."   Andrew Morton
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Allow for per-subnet dhcp options

[Kyle Mestery]

On Fri, Sep 11, 2015 at 2:04 PM, Jonathan Proulx  wrote:

> I'm hurt that this blue print has seen no love in 18 months:
> https://blueprints.launchpad.net/neutron/+spec/dhcp-options-per-subnet
>
>
This BP has no RFE bug or spec filed for it, so it's hard to be on anyone's
radar when it's not following the submission guidelines Neutron has for new
work [1]. I'm sorry this has flown under the radar so far, hopefully it can
rise up with an RFE bug.

[1] http://docs.openstack.org/developer/neutron/policies/blueprints.html


> I need different MTUs and different domians on different subnets.  It
> appears there is still no way to do this other than running a network
> node (or two if I want HA) for each subnet.
>
> Please someone tell me I'm a fool and there's an easy way to do this
> that I failed to find (again)...
>
> -Jon
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] PTL Non-Candidacy

[Kyle Mestery]

I'm writing to let everyone know that I do not plan to run for Neutron PTL
for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
recently put it in his non-candidacy email [1]. But it goes further than
that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
full time job. In the case of Neutron, it's more than a full time job, it's
literally an always on job.

I've tried really hard over my three cycles as PTL to build a stronger web
of trust so the project can grow, and I feel that's been accomplished. We
have a strong bench of future PTLs and leaders ready to go, I'm excited to
watch them lead and help them in anyway I can.

As was said by Zane in a recent email [3], while Heat may have pioneered
the concept of rotating PTL duties with each cycle, I'd like to highly
encourage Neutron and other projects to do the same. Having a deep bench of
leaders supporting each other is important for the future of all projects.

See you all in Tokyo!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Something about being a PTL

[Kyle Mestery]

Flavio, thanks for sending this out. I agree with everything you've written
below. Having served as PTL for 3 cycles now, I can say it's very
rewarding, but it's also very exhausting and takes an incredibly thick skin.

Before jumping in and throwing your hat into the ring (especially for a
large OpenStack project), please read Flavio's post carefully below. You
owe it to the project you're running for, the broader OpenStack ecosystem,
and yourself.

Thanks,
Kyle

On Wed, Sep 9, 2015 at 10:10 AM, Flavio Percoco  wrote:

> Greetings,
>
> Next week many folks will be running for PTL positions and I thought
> about taking the time to dump[0] some thoughts about what being a PTL
> means - at least for me - and what one should consider before running.
>
> Since the audience I want to reach is mostly in this mailing list, I
> thought about sending it here as well.
>
> [0] http://blog.flaper87.com/post/something-about-being-a-ptl/
> Flavio
>
>
> It's that time of the cycle, in OpenStack, when projects need to elect
> who's going to be the PTL for the next 6 months. People look at the,
> hopefully many, candidacies and vote based on the proposals that are
> more sound to them. I believe, for the PTL elections, the voting
> process has worked decently, which is why this post is not meant for
> voters but for the, hopefully many, PTL candidates.
>
> First and foremost, thank you. Thanks for raising your hand and
> willing to take on this role. It's an honor to have you in the
> community and I wish you the best of lucks in this round. Below are a
> few things that I hope will help you in the preparation of your
> candidacy and that I also hope will help making you a better PTL and
> community member.
>
>
> Why do you want to be a PTL?
> 
>
> Before even start writing your candidacy, please, ask yourself why you
> want to be a PTL. What is it that you want to bring to the project
> that is good for both, the project and the community. You don't really
> need to get stuck on this question forever, you don't really need to
> bring something new to the project.
>
> In my opinion, a very good answer for the above could be: "I believe
> I'll provide the right guidance to the community and the project."
>
> Seriously, one mistake that new PTLs often do is to believe they are
> on their own. Turns out that PTLs arent. The whole point about being a
> PTL is to help the community and to improve it. You're not going to do
> that if you think you're the one pulling the community. PTLs ought to
> work *with* the community not *for* the community.
>
> This leads me to my next point
>
> Be part of the community
> 
>
> Being a PTL is more than just going through launchpad and keeping an
> eye on the milestones. That's a lot of work, true. But here's a
> secret, it takes more time to be involved with the community of the
> project you're serving than going through launchpad.
>
> As a PTL, you have to be around. You have to keep an eye on the
> mailing list in a daily basis. You have to talk to the members of the
> community you're serving because you have to be up-to-date about the
> things that are happening in the project and the community. There may
> be conflicts in reviews, bugs and you have to be there to help solving
> those.
>
> Among all the things you'll have to do, the community should be in the
> top 2 of your priorities. I'm not talking just about the community of
> the project you're working on. I'm talking about OpenStack. Does your
> project have an impact on other projects? Is your project part of
> DefCore? Is your project widely deployed? What are the deprecation
> guarantees provided? Does your project consume common libraries? What
> can your project contribute back to the rest of the community?
>
> There are *many* things related to the project's community and its
> interaction with the rest of the OpenStack community that are
> important and that should be taken care of. However, you're not alone,
> you have a community. Remember, you'll be serving the community, it's
> not the other way around. Working with the community is the best thing
> you can do.
>
> As you can imagine, the above is exhausting and it takes time. It
> takes a lot of time, which leads me to my next point.
>
> Make sure you'll have time
> ==
>
> There are a few things impossible in this world, predicting time
> availability is one of them. Nonetheless, we can get really close
> estimates and you should strive, *before* sending your candidacy, to
> get the closest estimate of your upstream availability for the next 6
> months.
>
> Being a PTL is an upstream job, it's nothing - at the very least it
> shouldn't have - to do with your actual employer. Being a PTL is an
> *upstream* job and you have to be *upstream* to do it correctly.
> If you think you won't have time in a couple of months then, please,
> don't run for PTL. If you think your 

[openstack-dev] [neutron] Mitaka Design Summit ideas

[Kyle Mestery]

Folks:

It's that time of the cycle again! Lets start collecting ideas for our
design summit in Tokyo at the etherpad located here [1]. We'll discuss
these a bit in some upcoming meetings and ensure we have a solid schedule
to fill our 12 fishbowl slots in Tokyo.

Thanks!
Kyle

[1] https://etherpad.openstack.org/p/neutron-mitaka-designsummit
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] pushing changes through the gate

[Kyle Mestery]

I would like to second everything Armando has said below. Please, Neutron
core reviewers, follow the advice below for the rest of the Liberty cycle
as we work to merge patches targeted at Liberty.

I'd also like to thank Armando for jumping in and running things the past
week while I was on a (planned last spring) vacation with my family. He's
done a fabulous job, and his tireless effort this week shouldn't go
unnoticed.

Thanks for all your hard work Armando!

Kyle

On Thu, Sep 3, 2015 at 5:00 PM, Armando M.  wrote:

>
>
> On 2 September 2015 at 09:40, Armando M.  wrote:
>
>> Hi,
>>
>> By now you may have seen that I have taken out your change from the gate
>> and given it a -2: don't despair! I am only doing it to give priority to
>> the stuff that needs to merge in order to get [1] into a much better shape.
>>
>> If you have an important fix, please target it for RC1 or talk to me or
>> Doug (or Kyle when he's back from his time off), before putting it in the
>> gate queue. If everyone is not conscious of the other, we'll only end up
>> stepping on each other, and nothing moves forward.
>>
>> Let's give priority to gate stabilization fixes, and targeted stuff.
>>
>> Happy merging...not!
>>
>> Many thanks,
>> Armando
>>
>> [1] https://launchpad.net/neutron/+milestone/liberty-3
>> [2] https://launchpad.net/neutron/+milestone/liberty-rc1
>>
>
> Download files for the milestone are available in [1]. We still have a lot
> to do as there are outstanding bugs and blueprints that will have to be
> merged in the RC time windows.
>
> Please be conscious of what you approve. Give priority to:
>
> - Targeted bugs and blueprints in [2];
> - Gate stability fixes or patches that aim at helping troubleshooting;
>
> In these busy times, please refrain from proposing/merging:
>
> - Silly rebase generators (e.g. spelling mistakes);
> - Cosmetic changes (e.g. minor doc strings/comment improvements);
> - Refactoring required while dealing with the above;
> - A dozen of patches stacked on top of each other;
>
> Every rule has its own exception, so don't take this literally.
>
> If you are unsure, please reach out to me, Kyle or your Lieutenant and
> we'll target stuff that is worth targeting.
>
> As for the rest, I am gonna be merciless and -2 anything than I can find,
> in order to keep our gate lean and sane :)
>
> Thanks and happy hacking.
>
> A.
>
> [1] https://launchpad.net/neutron/+milestone/liberty-3
> [2] https://launchpad.net/neutron/+milestone/liberty-rc1
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] FFE process for Liberty

[Kyle Mestery]

Folks, Armando did a great job targeting things which missed Liberty-3
towards Liberty-RC1 here [1]. For the most part, I hope most of those will
land in the coming week or so, so lets work as a team to land those.

For things which are not already targeted there (or were targeted by
someone else, like [2]), the process to get these in as an FFE is to send
an email to the openstack-dev list and request this. We'll review these in
the team meeting next Tuesday morning and see what we can add. At this
point, things are mostly full, given we already have 15 BPs targeted. But
if something is small enough or only needs one more patch to land, we'll
concentrate on helping to move it along.

Thanks!
Kyle

[1] https://launchpad.net/neutron/+milestone/liberty-rc1
[2] https://blueprints.launchpad.net/neutron/+spec/ovs-tunnel-csum-option
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Kyle Mestery]

On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

  On 28 Aug 2015, at 14:08, Paul Carver pcar...@paulcarver.us wrote:
 
  Has anyone written anything up about expectations for how Big Tent or
 Neutron Stadium projects are expected to be
 installed/distributed/packaged?
 

 Seems like your questions below are more about extendability than e.g.
 packaging.


I agree, though I will say that your project is listed as
release:independent [1]. This means that networking-sfc will NOT release
when neutron and neutron-[fwaas, lbaas, vpnaas] release Liberty, but can
release whenever it desires. This would be when the code is complete and
the team has decided a release should be made. The process for handling
this release is documented here [2] (though wait for that to refresh based
on the review which merged here [3]).

[1] http://governance.openstack.org/reference/projects/neutron.html
[2]
http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html#releases
[3] https://review.openstack.org/#/c/217723/


  In particular, I'm wondering how we're supposed to handle changes to
 Neutron components. For the networking-sfc project we need to make
 additions to the API and corresponding additions to neutronclient as well
 as modifying the OvS agent to configure new flow table entries in OvS.
 
  The code is in a separate Git repo as is expected of a Stadium project
 but it doesn't make sense that we would package altered copies of files
 that are deployed by the regular Neutron packages.
 

 Of course you should not ship you custom version of neutron with your
 sub-project. Instead, you should work with neutron team to make sure you
 have all needed to extend it without duplicating efforts in your project.

  Should we be creating 99%+ of the functionality in filenames that don't
 conflict and then making changes to files in the Neutron and neutronclient
 repos to stitch together the 1% that adds our new functionality to the
 existing components? Or do we stage the code in the Stadium project's repo
 then subsequently request to merge it into the neutron/neutronclient repo?
 Or is there some other preferred way to integrate the added features?
 

 I presume that all sub-projects should use their own python namespace and
 not pollute neutron.* namespace. If that’s not the case for your
 sub-project, you should migrate to a new namespace asap.

 If there is anything missing in neutron or neutronclient for you to
 integrate with it, then you should work in those repositories to get the
 extension hooks or features you miss, and after it’s in neutron, you will
 merely utilise them from your sub-project. Of course it means some kind of
 dependency on the progress in neutron repository to be able to estimate
 feature plans in your sub-project.

 I'll second Ihar here. If you have dependencies in other projects, those
need to be worked in so they can be consumed by networking-sfc.


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

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

[openstack-dev] [neutron] Core Reviewer participation in the weekly meeting

[Kyle Mestery]

I'm sending out this email to encourage Neutron core reviewers to attend
and participate in the weekly Neutron team meeting [1]. Attendance from
core reviewers has been very low for a while now, and this is the one time
each week (or bi-weekly if you attend only one of the rotating meeting) I
have to share information which is important to the entire team. Especially
as the core reviewer team has grown, I feel this is very important for
everyone to join to keep apprised of not only things in Neutron but also of
things cross-project. I highly encourage everyone to make an effort to
attend one of the meetings (we rotate to accommodate timezones).

I should also note that as part of our devref for what it means to be a
core reviewer, we call out atttendance at this weekly meeting [2]. I
encourage everyone to review this if you have further concerns about what
being a Neutron core reviewer means.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Network/Meetings
[2]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewer-membership-expectations
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Pecan and Liberty-3

[Kyle Mestery]

Folks:

Kevin wants to merge the pecan stuff, and I agree with him. I'm on vacation
next week during Liberty-3, so Armando, Carl and Doug are running the show
while I'm out. I would guess that if Kevin thinks it's ok to merge it in
before Liberty-3, I'd go with his opinion and let it happen. If not, it can
get an FFE and we can do it post Liberty-3.

I'm sending this to the broader openstack-dev list so that everyone can be
aware of this plan, and so that Ihar can help collapse things back next
week with Doug on this.

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

Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

[Kyle Mestery]

On Mon, Aug 24, 2015 at 2:43 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/24/2015 05:25 PM, Doug Wiegley wrote:
  I took advantage of it to prototype a feature her
 
  That right there is the crux of the objections so far. Don’t get me
  wrong, I’d love this, and would abuse it within an inch of its life
  regularly.
 
  The alternative is sometimes even worse than a vendor extension or
  plugin.  Take for example, wanting to add a new load balancing
  algorithm, like LEAST_MURDERED_KITTENS. The current list is
  hard-coded all over the dang place, so you end up shipping neutron
  patches or monkey patches. Opaque pass-through to the driver is evil
  from an interoperability standpoint, but in terms of extending code
  at the operators choosing, there are MUCH worse sins that are
  actively being committed.

 I don't think even worse code makes this what's proposed here seem any
 better.  I'm not really sure what you're saying.

  Flavors covers this use case, but in a way that’s up to the operators
  to setup, and not as easy for devs to deal with.
 
  Whether the above sounds like it’s a bonus or a massive reason not to
  do this will entirely lie in the eye of the beholder, but the vendor
  extension use case WILL BE USED, no matter what we say.

 Interop really is a key part of this.  If we look at this particular
 case, yes, I get that there are lots of LB algorithms out there and that
 it makes sense to expose that choice to users.  However, I do think
 what's best for users is to define and document each of them very
 explicitly.  The end user should know that if they choose algorithm
 BEST_LB_EVER, that it means the same thing on cloud A vs cloud B.  The
 way to do that is to have it defined explicitly by Neutron and not punt.

 Maybe in practice the Neutron defined set is a subset of what's
 available overall, and the custom (vendor) ones can be clearly marked as
 such.  In any case, I'm just trying to express what goal I think we
 should be striving for.

 In general, the fight in Neutron *has* to be about common definitions of
 networking primitives that can be potentially implemented by multiple
 backends whenever possible.  That's the entire point of Neutron.  I get
 that it's hard, but that's the value Neutron brings to the table.


I couldn't have summed it up better than your last paragraph Russell. :)


 --
 Russell Bryant

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

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

Re: [openstack-dev] [neutron] RFE for DHCP agent changes for networking-calico

[Kyle Mestery]

Thanks Neil, we'll review this during the drivers meeting this week. It's
getting late in the Liberty cycle, but if you can get Brian, Cedric and
Carl to review this and ensure they are onboard, this is the best way to
move forward. Ensuring the L3 team is ok with the direction would make me
comfortable here.

Thanks!
Kyle

On Wed, Aug 19, 2015 at 9:42 AM, Neil Jerram neil.jer...@metaswitch.com
wrote:

 FYI, I've raised the new RFE bug that I suggested below:
 https://bugs.launchpad.net/neutron/+bug/1486649

 Neil


 On 18/08/15 23:22, Neil Jerram wrote:
  Although the DHCP-related patches below are I think very close to
 mergeable, Brian Haley on IRC queried what, process-wise, motivates merging
 them now (for Liberty).
 
  I think he's right that something is missing, so I'd like to discuss
 filling that hole here. What has happened so far is this:
 
  - https://review.openstack.org/#/c/198439/ described 'routed
 networking', which is the ultimate motivation for these patches.
 
  - I realised/was told that there should be an RFE bug, per current
 process, so raised https://bugs.launchpad.net/neutron/+bug/1472704
 
  - Those contributed to the beginning of discussions about supporting
 'routed' or 'L3' networks in Neutron - which are ongoing and will take
 Mitaka at least to refine.
 
  - Nevertheless, the DHCP-related patches are still valuable now (as
 explained below) and feasible within the Liberty timescale, so I've
 continued refining those.
 
  - Discussions, which I believe supported this in principle, took place
 in neutron-drivers [1][2] and main Neutron [3] IRC meetings.
 
  [1]
 http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-14-15.04.log.html
 ‎
 
  [2]
 
 http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-21-15.00.log.html
 
  [3] discussion between 14:49:44 and 14:56:49 at
 http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-28-14.01.log.html
 
  The specific process issue now is that the patches that (IMO) make sense
 for Liberty reference a bug (1472704) that has a much wider scope and so is
 quite correctly not approved for Liberty.
 
  So, what to do? My guess is to raise a new RFE bug that just motivates
 the DHCP agent support that I'd like to achieve - by way of the existing
 patches - in the Liberty timescale, ask neutron-drivers to approve that,
 and update the patches to reference that bug instead.
 
  Does that sound right?
 
  Regards,
Neil
 
 
  ‎
Original Message
  From: Neil Jerram
  Sent: Monday, 17 August 2015 18:47
  To: OpenStack Development Mailing List (not for usage questions)
  Reply To: OpenStack Development Mailing List (not for usage questions)
  Subject: [openstack-dev] [neutron] New networking-calico project
 
  I'd like to announce networking-calico, a new project within the Neutron
  stadium to provide OpenStack integration pieces for Project Calico
  [1][2]. In a sentence, Calico is a backend that uses routing and
  iptables to provide IP-level connectivity between VMs, instead of - as
  most Neutron backends do - using bridging to provide an effective L2
  broadcast domain. You can read about why that might be interesting at
  [1][2], or in more OpenStack-centric terms at [3].
 
  Calico's semantics are not fully describable by the current Neutron API,
  and I plan to contribute to API and data model work to address this.
  Discussion about that has already begun at [3] and in the email thread
  about 'routed, segmented networks' [4], and I hope it will continue
  through the end of this cycle, in Tokyo, and during Mitaka.
 
  For a practical deployment, though, and with some semantic caveats [5],
  Calico-style connectivity can be used already in an OpenStack cluster -
  and we have several operator partners interested in and trialling that.
  My team has been developing and refining this since Icehouse, using
  Calico-specific patches to Nova and Neutron, but we are now within
  touching distance, we think, of working with vanilla OpenStack when
  Liberty is released. We released our v1.0 milestone of the core Calico
  code last week [14], our Nova patches were merged in July, and we have
  the following core Neutron patches currently in review.
 
  [6] https://review.openstack.org/#/c/205181/
  [7] https://review.openstack.org/#/c/206078/
  [8] https://review.openstack.org/#/c/206077/
  [9] https://review.openstack.org/#/c/206079/
 
  These patches have been through many cycles of review - thanks in
  particular to Cedric and Oleg - and are now, I believe, fully tested and
  polished. They make small generalizations to the DHCP agent code so
  that a networking-calico-provided interface driver will be able to use
  it, instead of having to provide a parallel DHCP agent implementation.
  I would particularly appreciate if Neutron core reviewers would consider
  reviewing and approving [6] and [7] now, as they are the changes that
  would be 

Re: [openstack-dev] [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Kyle Mestery]

It's been over a week, so I'd like to welcome Brandon and Russell to the
API/DB/RPC team in Neutron!

Kyle

On Wed, Aug 12, 2015 at 6:45 AM, Kyle Mestery mest...@mestery.com wrote:

 It gives me great pleasure to propose Russell Bryant and Brandon Logan as
 core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have
 both been incredible contributors to Neutron for a while now. Their
 expertise has been particularly helpful in the area they are being proposed
 in. Their review stats [1] place them both comfortably in the range of
 existing Neutron core reviewers. I expect them to continue working with all
 community members to drive Neutron forward for the rest of Liberty and into
 Mitaka.

 Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
 please vote +1/-1 for the addition of Russell and Brandon.

 Thanks!
 Kyle

 [1] http://stackalytics.com/report/contribution/neutron-group/90

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

Re: [openstack-dev] [nova] [libvirt-vif] Extend vhost-user interface to support Cisco Nexus 1000v.

[Kyle Mestery]

On Tue, Aug 18, 2015 at 11:48 AM, Kiran Chunduri kiran.askl...@gmail.com
wrote:

 Hello All,
 We would like to extend the nova 'vhost-user' plug API to attach the port
 to Cisco Nexus 1000v, which supports vhost-user interface. Currently the
 plug-API supports attaching to OVS. The code I'm referring to is
 'plug_vhostuser()' API in 'nova/virt/libvirt/vif.py'.

 I would like to submit changes for this. But One of my colleague mentioned
 there is a proposal to make the NOVA VIF driver more generic. Can some one
 please elaborate on this (or) point to blue-print? I would like to look and
 discuss on the proposal.


This was discussed at the nova mid-cycle, and the plan of record is for Jay
Pipes to push his os_vif repo [1] out for review once he addresses some
feedback he's received already. This will make it easier to do what you're
looking to do Kiran.

Thanks,
Kyle

[1] https://github.com/jaypipes/os_vif


 thanks in advance,
 Kiran

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


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

Re: [openstack-dev] [Neutron] revert default review branch to master

[Kyle Mestery]

On Mon, Aug 17, 2015 at 5:58 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-08-17 22:39:56 + (+), Mooney, Sean K wrote:
 [...]
  Assuming this was not intentional I have opened a bug and
  submitted a patch to revert this change.
 [...]

 Fix https://review.openstack.org/213843 is already winding its way
 through the sausage factory.


Yes, this was missed during the merge back of feature/qos, of which I
approved the merge commit. Thanks to Doug for jumping on this with 213843
here, which is almost finished having it's casing added.

--
 Jeremy Stanley

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

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

Re: [openstack-dev] [neutron][vmware][stable] vmware-nsx has no releases

[Kyle Mestery]

On Mon, Aug 17, 2015 at 7:42 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-08-17 14:05:38 +0200 (+0200), Ihar Hrachyshka wrote:
 [...]
  I tried to follow the dumb way of generating a tarball from github,
  but pbr complains about lack of sdist or git when I call to 'setup.py
  build'. Putting egg-info directory inside the tarball does not help.

 In a clean checkout of the branch, run:

 tox -e venv python setup.py sdist

 Then you should have a tarball in the dist subdirectory.

  I think it would be better for everyone if tags and tarballs came from
  upstream.
 [...]

 I completely agree.


I agree as well.


 --
 Jeremy Stanley

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

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

Re: [openstack-dev] [neutron][qos] request to merge feature/qos back into master

[Kyle Mestery]

I've pushed the patch into the merge queue now. Any nits people find at
this point we'll address post merge.

Awesome work QoS team!

On Mon, Aug 17, 2015 at 9:56 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 So the patch in question sit there for some time, and honestly, I
 haven't seen much interest from reviewers to take a look at it, apart
 from Assaf who played with the code and reported a bunch of minor issues
 .

 I think Kyle's plan was to wait until Fri and then merge.

 We had a git conflict on Fri though, so today I respin the patch
 again, hoping that it will either get more reviews or it's merged
 before we hit another conflict that can be inflicted by any new db
 migration.

 Ihar

 On 08/12/2015 09:55 PM, Ihar Hrachyshka wrote:
  Hi all,
 
  with great pleasure, I want to request a coordinated review for
  merging feature/qos branch back to master:
 
  https://review.openstack.org/#/c/212170/
 
  Since it's a merge patch, gerrit fails to show the whole diff that
  it introduces into master. To get over it, fetch the patch:
 
  $ git review -d 212170
 
  and then check the difference:
 
  $ git fetch origin  git diff origin/master...
 
  I think we should stick to review process originally suggested at
  [1]. Specifically, since it's not reasonable to expect the whole
  feature branch to be reviewed by a single person, I hope multiple
  people will assign themselves to the job and split the pieces to
  review based on devref document that describes the feature [2]
  (Note that a new RPC push/pull mechanism is described in a separate
  devref section [3]).
 
  Note that we don't expect to tackle all review comments, however
  tiny, in feature/qos. We are happy to handle major flaws there, but
  for minor stuff, it's good to proceed in master. Nevertheless we
  are happy to get minors too and collect them for post-merge.
 
  Things we have in the tree:
 
  - server: QoS API extension; QoS core resource extension; QoS ML2
  extension driver; QoS versioned objects + base for new objects;
  QoS supported rule types mechanism for ML2; QoS notification
  drivers mechanism to update SDN controllers;
 
  - RPC: new push/pull mechanisms for versioned objects to propagate
  QoS objects into the agents;
 
  - agent side: new L2 agent extensions mechanism, integrated into
  OVS and SR-IOV agents; QoS l2 agent extension; OVS and SR-IOV QoS
  drivers; ovs_lib and pci_lib changes.
 
  I suggest to split review into following logical pieces:
 
  - API controller + service plugin + API tests; - Versioned objects:
  neutron.objects.* - ML2: supported_qos_rule_types mechanism,
  extension driver, update for get_device_details payload; - RPC
  mechanism (push/pull), resource manager, registries + notification
  drivers integration; - l2 extensions (manager, base interface) +
  qos extension; - OVS integration with extension manager + OVS QoS
  driver + ovs_lib changes; - SR-IOV agent integration with extension
  manager + SR-IOV QoS driver + pci_lib changes; - functional tests.
 
  We will also need to update the spec:
  https://review.openstack.org/#/c/199112/
 
  Included test coverage:
 
  - unit tests; - API tests; - functional tests (more scenarios to
  come in master); - fullstack tests [4] (not in the tree since we
  need to merge client and base fullstack patches first).
 
  We have client patches up for review [5][6] and expect them to go
  in after merge of server component.
 
  We hope that we'll make fullstack in before closing the blueprint
  in this cycle.
 
  [1]:
  http://lists.openstack.org/pipermail/openstack-dev/2015-July/069188.ht
 ml
 
 
 [2]:
  http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/devref
 /q
 
 
 uality_of_service.rst?h=feature/qos
  [3]:
  http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/devref
 /r
 
 
 pc_callbacks.rst?h=feature/qos
  [4]: https://review.openstack.org/202492 [5]:
  https://review.openstack.org/189655 [6]:
  https://review.openstack.org/198277 [7]:
  https://review.openstack.org/202061
 
  __
 
 
 
 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
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJV0fYnAAoJEC5aWaUY1u57rtsH/iaQ5HCRuFDbhFsFAkGeW/hB
 gn/pR9lmx/hXUIkEWfGPIsgtEnuA8nIQ3knwLfvkrPxR60YHkCK5YeRDaTVd0IQb
 oV5njw3eMJablTtquPybSzUljfx+oCQ2pxwhXgWAcj5KucksXLcvC+lkfk5uQ1OT
 iFum1jCmZ+7Te8uPdjkgGxxxpLjnJJs0Na6i+GhRppRc/HK77jM31MggfA3dJw9y
 cdB0JN3w2tT4wbjtmtCsVgKVWeDuuKXlnZjmI0Do1Qm1YDC0NNPLNGcBTV70vyPB
 B8lGyk9kvtbzSQ701T3LEp8hRIL6Oto8cHRrt3jkfygrlXPQL8x1pwtjSD59bXU=
 =s4FB
 -END PGP SIGNATURE-

 __
 OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [neutron][vmware][stable] vmware-nsx has no releases

[Kyle Mestery]

On Mon, Aug 17, 2015 at 7:05 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi VmWare folks,

 I wonder whether we can get some actual release tags for stable/kilo
 branch of the repo. Lack of any consumable tarballs does not help
 packagers that want to just get the tarball from pypi and use it as a
 base.

 I tried to follow the dumb way of generating a tarball from github,
 but pbr complains about lack of sdist or git when I call to 'setup.py
 build'. Putting egg-info directory inside the tarball does not help.

 I think it would be better for everyone if tags and tarballs came from
 upstream.

 I suspect other spinned-out neutron drivers could have the same
 problem. Can we somehow make sure they are releasing deliverables and
 not just git repo?


We will talk about this at the meeting today but yes, the plan is to get
releases for these. So far we've only discussed stable releases, but I
think the plan to release master snapshots would be good. It would give the
packagers a chance to package these.

Ihar, lets work to make this happen tomorrow or Wednesday.

Thanks,
Kyle



 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJV0c4PAAoJEC5aWaUY1u57M2cIALuH2MByojn7N1byCV4ctTal
 NPsUTgFyzDEXSU1QSgobR6x1uP8hYBW2RSUqnh4tR+SoYz/vmF1IvwXl53tb3Jnq
 4MTwXbom3xPgjUYsUep5TAhPglMXf4LwnTYejhqc78IOlNg7tAC0U/yA2ZitFhm2
 5zWsec1zggsku4aIMCz06bFwgQHwYl57uHBB/iqO+fbRIGZLkcGrbjiucKIlQqsF
 uv9GoymuwOEVjmTtooQBoVQ0J2f/yZYswcRBExbJU78eIP89+A2kDL9nA4fFFhCl
 b5Yus6oJDn/XMaU8PWZ8TptWEOY3Z80wbCRZk27FNObSb6yLs+2ZS7Rge+ZCz5s=
 =VP83
 -END PGP SIGNATURE-

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

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

Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]

[Kyle Mestery]

On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Thanks a lot for the reply! I think it raises some good points here
 that I would like to clarify with other team members. I don't think
 those should interface with the current nomination run, so I spin it
 into a separate thread.


Absolutely! I think it's super healthy to have these discussions, it's what
healthy open source communities do. I'll answer your specific concerns
below.


 Some comments inline.

 On 08/12/2015 07:16 PM, Kyle Mestery wrote:
  [1] http://stackalytics.com/report/contribution/neutron-group/90
 
 
  Shouldn't we use the link that shows neutron core repo
  contributions only? I think this is the right one:
 
  http://stackalytics.com/report/contribution/neutron/90
 
 
  Sure, if you want to look at only the neutron repo. I tend to
  look at people across all of our repos, which you may or may not
  agree with. I

 Neutron-core gerrit group indeed always had a vague definition. It
 worked fine before when we had just neutron and python-neutronclient
 repositories [even though client expertise stands out somewhat of
 usual server oriented development we do in neutron repo].


Agreed. And on that note, I think it may make sense to separate out client
merge responsibilities from server ones, as there are typically hardly any
core reviewers for neutron who pay attention to the client at this point.


 Now, with successful tree split into neutron, neutron-*aas,
 networking-*, + having a separate repo for specs; now that neutron is
 really a meta-project (a big tent they say),


Nope, it's the Neutron Stadium, the Big Tent moniker was already taken,
so we came up with our own. ;)


 it feels to me that leaving neutron-core group as a meta-group that
 includes everyone who makes significant positive impact in any of
 those repos is not optimal.


This is where I'd disagree. I think in general teams pay too much attention
to stats, which are incredibly easy to game. Case in point, with the
current objections people have over Brandon and Russell being nominated, I
could have waited 4-6 weeks and let them amass a plethora of review stats,
but what would the point of that have been? I trust both of them to merge
code, they have both proven it in other Neutron projects (Brandon) and
other OpenStack project (Russell). A month of collecting meaningless stats
doesn't help anyone. Further, if either of them takes advantage of their
merge responsibilities in anyway, we'll remove them. We're a community that
is self governed and built on trust and integrity, breaching that will lead
to extreme measures.


 Having core team members that are judged solely on how they impact the
 core repo seems to me a better approach. Fostering more focused teams
 was one of the goals of tree splits, so I think we should take that
 gerrit advantage of having multiple repos more seriously.


I'm not disagreeing with you here, but to your point below about areas of
focus, it's harder than it looks. We're working within the confines of the
tools we have. I'm not saying you're incorrect in your assumption here at
all. Going back to Russell and Brandon, if they don't start reviewing at a
decent pace, we should remove their merge capabilities, as we should any
core who doesn't review.


  also think that it's worth looking at the statement of what core
  reviewers do found here [1]. Particularly what common ideals all
  core reviewers across Neutron share. I'll copy them here:
 
  1. They share responsibility in the project’s success. 2. They
  have made a long-term, recurring time investment to improve the
  project. 3. They spend their time doing what needs to be done to
  ensure the projects success, not necessarily what is the most
  interesting or fun.
 

 The list is indeed a great one, and a lot of us, including - if not
 especially! - me, sometimes lag on some of those points.


:)


 But doesn't the section talk about the big neutron tent, while voting
 permissions are still per-repo?


Yes, it does.

 Also, keep in mind how we nominate core reviewers now that we
  have a Lieutenant system [2].

 That raises another interesting point that bothers me for some time.
 The section refers multiple times to 'Neutron core reviewers from the
 Lieutenant’s area of focus', but it does not say anything about
 reviewers [that I call 'obsolete'] who got into the core team before
 we had subteams and Lieutenants. Should they even have a say in
 subteam nominations? Everytime a nomination is proposed, I don't know
 whether I am in the position to put +1/-1.

 So the wording could be clarified here once we understand what the
 intended rules should be here.


In general, I want less rules. If I could do things over I'd wipe away many
of these rules and go with a system built solely on trust and integrity,
which is pretty much where we've landed. Have you noticed that no one has
gone and verified new

Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]

[Kyle Mestery]

On Fri, Aug 14, 2015 at 10:00 AM, Flavio Percoco fla...@redhat.com wrote:

 On 14/08/15 10:42 -0400, Assaf Muller wrote:

 First I'd like to say that I recognize that this discussion is incredibly
 personal. Brandon and Russell, please do not be offended, but I know that
 I
 probably would be if this very public thread involved myself. That being
 said,
 please know that from my perspective this is *not* personal, rather I see
 this
 as a general discussion about the precedent that we are creating here.

 Responses in-line.

 On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery mest...@mestery.com
 wrote:

On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:
  it feels to me that leaving neutron-core group as a meta-group
 that
includes everyone who makes significant positive impact in any of
those repos is not optimal.

  This is where I'd disagree. I think in general teams pay too much
 attention
to stats, which are incredibly easy to game. Case in point, with the
current objections people have over Brandon and Russell being
 nominated, I
could have waited 4-6 weeks and let them amass a plethora of review
 stats,
but what would the point of that have been?


 None what so ever. I think the point here is that if someone is focusing
 on
 another project then it's debatable if they should become a core in the
 Neutron
 project itself. Very simply put, if someone is a core in a subproject and
 is
 doing a fantastic job, but that person is not truly involved in the
 Neutron
 project itself, then that person becoming core in Neutron to me is
 dangerous.
 Before someone becomes core, I would like to be familiar with their
 expertise
 in Neutron so that I know if to trust their +2 or not on a given area in
 Neutron. If that person didn't really focus on Neutron then I have no way
 of
 being familiar with their expertise, thus no ability to trust them even
 if I'm
 generally a trusting person.


 I'm not really familiar with Neutron's workflow but as an outsider and
 also based on my experience from other projects, the separation of
 concerns from a review perspective is very useful. Teams that govern
 several projects are be better off giving reviewing rights to folks
 in a per-project basis rather than doing it cross-team.

 I'd go as far as saying that folks with review rights in the server
 don't necessarily need to have review rights in smaller projects. The
 reason I'm saying this is because I believe that reviewer rights is
 not a prize but a volunteer job. The moment I'm asked whether I want
 to join a reviewers team in a project, I gotta be honest with what my
 available time will allow me to do.


What you just said is what I've been trying to emphasize my entire time as
PTL: Reviewing is a duty, not a prize. The thing we're discussing here is
the issue of when to give someone +2 rights. I'm arguing in favor of a web
of trust system, which is what we have with Lieutenants. I'm also saying
that I'm a proponent of elevating folks who want to take on the duty and
letting them do that before they spend a month building up stats. This is
not an opinion shared by everyone I realize, but it's my opinion.

Like I've said in this thread, the entire system is built on trust. We as a
community need to trust more and rely on that trust. I feel as if I've
spent my PTL time trying to build that up and instill this value into the
Neutron community. The results speak for themselves at this point, but I'm
proud of what *we* as a community have built here.

Kyle


 To what I just said, I'd also add the familiarity with the code-base,
 etc.

 Just my $0.02,
 Flavio



 --
 @flaper87
 Flavio Percoco

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


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

Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]

[Kyle Mestery]

On Fri, Aug 14, 2015 at 9:42 AM, Assaf Muller amul...@redhat.com wrote:

 First I'd like to say that I recognize that this discussion is incredibly
 personal. Brandon and Russell, please do not be offended, but I know that I
 probably would be if this very public thread involved myself. That being
 said, please know that from my perspective this is *not* personal, rather I
 see this as a general discussion about the precedent that we are creating
 here.

 Responses in-line.

 On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery mest...@mestery.com wrote:

 On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka ihrac...@redhat.com
 wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Thanks a lot for the reply! I think it raises some good points here
 that I would like to clarify with other team members. I don't think
 those should interface with the current nomination run, so I spin it
 into a separate thread.


 Absolutely! I think it's super healthy to have these discussions, it's
 what healthy open source communities do. I'll answer your specific concerns
 below.


 Some comments inline.

 On 08/12/2015 07:16 PM, Kyle Mestery wrote:
  [1] http://stackalytics.com/report/contribution/neutron-group/90
 
 
  Shouldn't we use the link that shows neutron core repo
  contributions only? I think this is the right one:
 
  http://stackalytics.com/report/contribution/neutron/90
 
 
  Sure, if you want to look at only the neutron repo. I tend to
  look at people across all of our repos, which you may or may not
  agree with. I

 Neutron-core gerrit group indeed always had a vague definition. It
 worked fine before when we had just neutron and python-neutronclient
 repositories [even though client expertise stands out somewhat of
 usual server oriented development we do in neutron repo].


 Agreed. And on that note, I think it may make sense to separate out
 client merge responsibilities from server ones, as there are typically
 hardly any core reviewers for neutron who pay attention to the client at
 this point.


 Now, with successful tree split into neutron, neutron-*aas,
 networking-*, + having a separate repo for specs; now that neutron is
 really a meta-project (a big tent they say),


 Nope, it's the Neutron Stadium, the Big Tent moniker was already
 taken, so we came up with our own. ;)


 it feels to me that leaving neutron-core group as a meta-group that
 includes everyone who makes significant positive impact in any of
 those repos is not optimal.


 This is where I'd disagree. I think in general teams pay too much
 attention to stats, which are incredibly easy to game. Case in point, with
 the current objections people have over Brandon and Russell being
 nominated, I could have waited 4-6 weeks and let them amass a plethora of
 review stats, but what would the point of that have been?


 None what so ever. I think the point here is that if someone is focusing
 on another project then it's debatable if they should become a core in the
 Neutron project itself. Very simply put, if someone is a core in a
 subproject and is doing a fantastic job, but that person is not truly
 involved in the Neutron project itself, then that person becoming core in
 Neutron to me is dangerous. Before someone becomes core, I would like to be
 familiar with their expertise in Neutron so that I know if to trust their
 +2 or not on a given area in Neutron. If that person didn't really focus on
 Neutron then I have no way of being familiar with their expertise, thus no
 ability to trust them even if I'm generally a trusting person.



I'd argue the system is built on a web of trust. If you trust me, and I
trust Russell and Brandon, then you should likely trust Russell and Brandon
as well. This is EXACTLY what the Lieutenant system was meant to convey,
though I now feel like perhaps people missed this key ingredient of the new
world we find ourselves in.


 I trust both of them to merge code, they have both proven it in other
 Neutron projects (Brandon) and other OpenStack project (Russell). A month
 of collecting meaningless stats doesn't help anyone. Further, if either of
 them takes advantage of their merge responsibilities in anyway, we'll
 remove them. We're a community that is self governed and built on trust and
 integrity, breaching that will lead to extreme measures.


 Having core team members that are judged solely on how they impact the
 core repo seems to me a better approach. Fostering more focused teams
 was one of the goals of tree splits, so I think we should take that
 gerrit advantage of having multiple repos more seriously.


 I'm not disagreeing with you here, but to your point below about areas
 of focus, it's harder than it looks. We're working within the confines of
 the tools we have. I'm not saying you're incorrect in your assumption here
 at all. Going back to Russell and Brandon, if they don't start reviewing at
 a decent pace, we should remove their merge capabilities, as we should any
 core who doesn't

Re: [openstack-dev] [neutron][kuryr][magnum] Design Specification for Kuryr

[Kyle Mestery]

On Thu, Aug 13, 2015 at 1:56 PM, Adrian Otto adrian.o...@rackspace.com
wrote:

 Kyle,

 Can we please arrange for an official design specification for Kuyyr so
 members of the Magnum team can relay input to be sure that our mutual
 interests in this work are addressed?


I agree 100%. See Gals email here [1] for a status update. At this point
the team is collecting ideas in an etherpad. Gal, can I request that you
formulate those into a spec of some sort, it makes sense to file that in
the Neutron spec repo at this point. We can all then review it there.

Thanks!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-August/071940.html


 Thanks,

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

Re: [openstack-dev] [neutron] Liberty-3 BPs and gerrit topics

[Kyle Mestery]

On Wed, Aug 12, 2015 at 7:05 AM, Daniel Comnea comnea.d...@gmail.com
wrote:

 Kyle,

 Is the dashboard available to a limited set of users? curious by nature
 tried to access it and it said Session expired, please login again
 however i thought i don't have to login to Gerrit, am i missing something?


You will be required to login to gerrit to  view it, the dashboard makes
use of your login ID, for example to not show you patches which you have
proposed. :)


 Cheers,
 Dani

 On Tue, Aug 11, 2015 at 2:44 PM, Kyle Mestery mest...@mestery.com wrote:

 Folks:

 To make reviewing all approved work for Liberty-3 in Neutron easier, I've
 created a handy dandy gerrit dashboard [1]. What will make this even more
 useful is if everyone makes sure to set their topics to something uniform
 from their approved LP BP found here [2]. The gerrit dashboard includes all
 Essential, High, and Medium priority BPs from that link. If everyone who
 has patches could make sure their gerrit topics for the patches are synced
 to what is in the LP BP, that will help as people use the dashboard to
 review in the final weeks before FF.

 Thanks!
 Kyle

 [1] https://goo.gl/x9bO7i
 [2] https://launchpad.net/neutron/+milestone/liberty-3

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



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


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

Re: [openstack-dev] [neutron] Liberty-3 BPs and gerrit topics

[Kyle Mestery]

On Tue, Aug 11, 2015 at 8:44 AM, Kyle Mestery mest...@mestery.com wrote:

 Folks:

 To make reviewing all approved work for Liberty-3 in Neutron easier, I've
 created a handy dandy gerrit dashboard [1]. What will make this even more
 useful is if everyone makes sure to set their topics to something uniform
 from their approved LP BP found here [2]. The gerrit dashboard includes all
 Essential, High, and Medium priority BPs from that link. If everyone who
 has patches could make sure their gerrit topics for the patches are synced
 to what is in the LP BP, that will help as people use the dashboard to
 review in the final weeks before FF.


I should note that I've posted a review for how this dashboard was
generated here [1]. I've marked it WIP. I've done this in case people want
to see what topics I used to generate the dashboard to align their patches.

Thanks!
Kyle

[1] https://review.openstack.org/#/c/211666/


 Thanks!
 Kyle

 [1] https://goo.gl/x9bO7i
 [2] https://launchpad.net/neutron/+milestone/liberty-3

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

[openstack-dev] [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Kyle Mestery]

It gives me great pleasure to propose Russell Bryant and Brandon Logan as
core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have
both been incredible contributors to Neutron for a while now. Their
expertise has been particularly helpful in the area they are being proposed
in. Their review stats [1] place them both comfortably in the range of
existing Neutron core reviewers. I expect them to continue working with all
community members to drive Neutron forward for the rest of Liberty and into
Mitaka.

Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
please vote +1/-1 for the addition of Russell and Brandon.

Thanks!
Kyle

[1] http://stackalytics.com/report/contribution/neutron-group/90
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Kyle Mestery]

On Wed, Aug 12, 2015 at 10:54 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 08/12/2015 03:45 PM, Kyle Mestery wrote:
  It gives me great pleasure to propose Russell Bryant and Brandon
  Logan as core reviewers in the API/DB/RPC area of Neutron. Russell
  and Brandon have both been incredible contributors to Neutron for a
  while now. Their expertise has been particularly helpful in the
  area they are being proposed in. Their review stats [1] place them
  both comfortably in the range of existing Neutron core reviewers. I
  expect them to continue working with all community members to drive
  Neutron forward for the rest of Liberty and into Mitaka.
 
  Existing DB/API/RPC core reviewers (and other Neutron core
  reviewers), please vote +1/-1 for the addition of Russell and
  Brandon.
 
  Thanks! Kyle
 
  [1] http://stackalytics.com/report/contribution/neutron-group/90
 

 Shouldn't we use the link that shows neutron core repo contributions
 only? I think this is the right one:

 http://stackalytics.com/report/contribution/neutron/90


Sure, if you want to look at only the neutron repo. I tend to look at
people across all of our repos, which you may or may not agree with. I also
think that it's worth looking at the statement of what core reviewers do
found here [1]. Particularly what common ideals all core reviewers across
Neutron share. I'll copy them here:

1. They share responsibility in the project’s success.
2. They have made a long-term, recurring time investment to improve the
project.
3. They spend their time doing what needs to be done to ensure the projects
success, not necessarily what is the most interesting or fun.

Also, keep in mind how we nominate core reviewers now that we have a
Lieutenant system [2].

Finally, it's worth all core reviewers having a look at what's expected of
core reviewers here. [3] I should point out that the team is severely
lacking in weekly meeting attendance at this point, but it's not a good
thread to do that. Instead, I'll just point out what we as a team have
codified as expectations for core reviewers.

Thanks!
Kyle

[1]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewers
[2]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
[3]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewer-membership-expectations

Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVy2wjAAoJEC5aWaUY1u57LUQIAIwHlnhzzucTJss5dE3dUeiP
 WQ7h7Oax45BWhaXD1a9/ux4HYeUX0haVPLO7KqgiLaMxu5H8r98QZpsK5NnxMsE/
 XuQHM5/i8diHuZnfmP8W+kzjfuS7xxiBxqnmg3AF9PrcHOu10YCnSQaRAzbsSwcc
 R7ifeLexF8kpE9PI0/eAMBtoVmidjnxuEfU+hK0zto3MCQ86SFxeYut+efhiaphz
 CiN/H440gllw3TdZsNCMAP8ie4+cjbR9W6vkMieq3Z2esNfAZQaTaJ8NPeLzGpHj
 4+NjFTuTTQmtYmqMiVlqDeg3y0LaE21qdI649XdRub8Xp//Ht7xnnQcOrW2lSPM=
 =khEG
 -END PGP SIGNATURE-

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

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