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

[Armando M.]

On 11 January 2016 at 12:04, Carl Baldwin <c...@ecbaldwin.net> wrote:

> What do we do?  My calendar was set up with the sane bi-weekly thing
> and it shows the meeting for tomorrow.  The last word from our
> fearless leader is that we'll have it today.  So, I'll be there today
> unless instructed otherwise.
>
> The ics file now seems to reset the cadence beginning today at 2100
> and next Tuesday, the 19th, at 1400.  I guess we should either hold
> the meeting today and reset the cadence or fix the ics file.
>
>
This is what I would like to do now:

https://review.openstack.org/#/c/266019

I personally haven't seen that much of an attendance difference anyway, and
at this point, it'll simplify our lives and avoid grief going forward.

Carl
>
> On Mon, Jan 11, 2016 at 12:09 PM, Kevin Benton <blak...@gmail.com> wrote:
> > The issue is simply that you have a sane bi-weekly thing setup in your
> > calendar. What we have for Neutron is apparently defined as “odd and even
> > weeks when weeks are represented as an short integer counting from the
> first
> > of the year”, a.k.a. “bi-weekly” as a robot might define it. :)
> >
> >
> > On Jan 11, 2016, at 11:00 AM, Kyle Mestery <mest...@mestery.com> wrote:
> >
> > 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.openstac

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

[Armando M.]

On 3 June 2016 at 13:31, Carl Baldwin  wrote:

> On Fri, Jun 3, 2016 at 2:26 PM, Henry Gessau  wrote:
> > Darek Smigiel  wrote:
> >> strange, that owner is not able to just get rid of *his* network and
> subnets.
> >
> > But not all the subnets are his, and consequently the network is
> partially not
> > his.
>
> To me, this is a nonsensical outcome and tells me that subnets
> probably shouldn't really have owners distinct from the network's.
>

This might turn out to be a PEBCAK, as an admin can create a subnet on
behalf of a tenant by specifying his/her tenant id on the request, and that
might as well be the reason why this was never tackled before and we have a
latent loop in the code.

Having said that I think I lean on avoiding the ransomware situation where
a tenant cannot delete his/her own resources, unless the other tenant frees
up the resource explicitly, but only for situations where the resource is
indeed idle. I would be extra cautious of elevating the context
indiscriminately though.


>
> Carl
>
> __
> 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] Getting project version from API

[Armando M.]

On 6 June 2016 at 10:06, Oleg Bondarev  wrote:

> Hi,
>
> There are cases where it would be useful to know the version of Neutron
> (or any other project) from API, like during upgrades or in cross-project
> communication cases.
> For example in https://review.openstack.org/#/c/246910/ Nova needs to
> know if Neutron sends vif-plugged event during live migration. To ensure
> this it should be enough to know Neutron is "Newton" or higher.
>
> Not sure why it wasn't done before (or was it and I'm just blind?) so the
> question to the community is what are possible issues/downsides of exposing
> code version through the API?
>

If you are not talking about features exposed through the API (for which
they'd have a new extension being advertised), knowing that you're running
a specific version of the code might not guarantee that a particular
feature is available, especially in the case where the capability is an
implementation detail that is config tunable (evil, evil). This may also
lead to needless coupling between the two projects, as you'd still want to
code defensively and assume the specific behavior may or may not be there.

I suspect that your case is slightly different in that the lack of a
received event may be due to an error rather than a missing capability and
you would not be able to distinguish the difference if not optimistically
assume lack of capability. Then you need to make a "mental" note and come
back to the code to assume a failure two cycles down the road from when
your code merges. Definitely not a pretty workflow without advertising the
new feature explicitly via the API.


>
> Thanks,
> Oleg
>
> __
> 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] Does the openvswitch-agent need to be run along side the neutron-l3-agent?

[Armando M.]

On 6 June 2016 at 19:59, Sean M. Collins  wrote:

> While reviewing https://review.openstack.org/#/c/292778/5 I think I
> might have found a bit of coupling between the neutron l2 agent and the
> l3 agent when it comes to DevStack.
>
> In the DevStack neutron guide - the "control node" currently
> does double duty as both an API server and also as a compute host.
>
>
> https://github.com/openstack-dev/devstack/blob/master/doc/source/guides/neutron.rst#devstack-configuration
>
> Extra compute nodes have a pretty short configuration
>
>
> https://github.com/openstack-dev/devstack/blob/master/doc/source/guides/neutron.rst#devstack-compute-configuration
>
> So, recently I poked at having a pure control node on the "devstack-1"
> host, by removing the q-agt and n-cpu entries from ENABLED_SERVICES,
> while leaving q-l3.
>
> It appears that the code in DevStack, relies on the presence of q-agt in
> order to create the integration bridge (br-int), so when the L3 agent
> comes up it complains because br-int hasn't been created.
>
>
> https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/ovs_base#L20
>
> Anyway, here's the fix.
>
> https://review.openstack.org/#/c/326063/


The short answer to your question in the question is yes. For OVS, wherever
you run network services (l3 or dhcp), you need an l2 agent that in charge
of port wiring.


>
> --
> 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] Getting project version from API

[Armando M.]

On 6 June 2016 at 17:05, Andreas Scheuring 
wrote:

> Is there a chance to get rid of this vif-plugged event at all? E.g. by
> transitioning it to an ReST API interface? As far as I know this is the
> only RPC interface between neutron and nova.
>

This handshake between Neutron and Nova does not happen over RPC


>
>
> --
> -
> Andreas
> IRC: andreas_s (formerly scheuran)
>
>
>
> On Mo, 2016-06-06 at 20:25 +0900, Akihiro Motoki wrote:
> > Hi,
> >
> > If I understand correctly, what you need is to expose the neutron
> > behavior through API or something. In this particular case, neutron
> > need to send a vif-plugged event when neutron detects some event in
> > the data plane (VIF plugging in OVS or some virtual switch). Thus I
> > think the question can be generalized to whether we expose a
> > capability (such that neutron server behaves in XXX way) through API
> > (API version? extension?). For example, do we have an extension to
> > expose that neutron supports the event callback mechanism?
> >
> > I also think the important point is that it is a topic of
> > deployment.Operators are responsible of deploying correct combination
> > of nova and neutron.
> >
> > Honestly I am not sure we need to expose this kind of things through
> > API. Regarding the current event callback mechanism, we assume that
> > operators deploy the expected combination of releases of nova and
> > neutron. Can't we assume that operators deploy Newton nova and neutron
> > when they want to use live-migration vif-plugging support?
> >
> > Akihiro
> >
> > 2016-06-06 17:06 GMT+09:00 Oleg Bondarev :
> > > Hi,
> > >
> > > There are cases where it would be useful to know the version of
> Neutron (or
> > > any other project) from API, like during upgrades or in cross-project
> > > communication cases.
> > > For example in https://review.openstack.org/#/c/246910/ Nova needs to
> know
> > > if Neutron sends vif-plugged event during live migration. To ensure
> this it
> > > should be enough to know Neutron is "Newton" or higher.
> > >
> > > Not sure why it wasn't done before (or was it and I'm just blind?) so
> the
> > > question to the community is what are possible issues/downsides of
> exposing
> > > code version through the API?
> > >
> > > Thanks,
> > > Oleg
> > >
> > >
> __
> > > 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] support of NSH in networking-SFC

[Armando M.]

On 24 May 2016 at 22:07, Elzur, Uri <uri.el...@intel.com> wrote:

> Hi Armando
>
>
>
> Pls see below [UE]
>
>
>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> *From:* Armando M. [mailto:arma...@gmail.com]
> *Sent:* Friday, May 20, 2016 9:08 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 20 May 2016 at 17:37, Elzur, Uri <uri.el...@intel.com> wrote:
>
> Hi Armando, Cathy, All
>
>
>
> First I apologize for the delay, returning from a week long international
> trip. (yes, I know,  a lousy excuse on many accounts…)
>
>
>
> If I’m attempting to summarize all the responses, it seems like
>
> · A given abstraction in Neutron is allowed (e.g. in support of
> SFC), preferably not specific to a given technology e.g. NSH for SFC
>
> · A stadium project is not held to the same tests (but we do not
> have a “formal” model here, today) and therefore can support even a
> specific technology e.g. NSH (definitely better with abstractions to meet
> Neutron standards for future integration)
>
>
>
> A given abstraction is allowed so long as there is enough agreement that
> it is indeed technology agnostic. If the abstraction maps neatly to a given
> technology, the implementation may exist within the context of Neutron or
> elsewhere.
>
> [UE] I think we have agreement SFC is a needed abstraction
>
>
>
> Having said that I'd like to clarify a point: you seem to refer to the
> stadium as a golden standard. The stadium is nothing else but a list of
> software repositories that the Neutron team develops and maintain. Given
> the maturity of a specific repo, it may or may not implement an abstraction
> with integration code to non open technologies. This is left at discretion
> of the group of folks who are directly in control of the specific repo,
> though it has been the general direction to strongly encourage and promote
> openness throughout the entire stack that falls under the responsibility of
> the Neutron team and thus the stadium.
>
>
>
> [UE] carefully read (
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and hope I understand Stadium. All NSH patches that we’d like to support
> are OPEN. I’m still looking for the place where a restriction prevents
> networking-SFC form moving forward on NSH before all other external
> projects to OpenStack has completed their work. Pls see also reply to Tim
> Rozet
>
>
>
> However,
>
> · There still is a chicken and egg phenomenon… how can a
> technology become main stream with OPEN SOURCE support  if we can’t get an
> OpenStack to support the required abstractions *before* the technology
> was adopted elsewhere??
>
> o   Especially as Stadium, can we let Neutron to lead the industry, given
> broad enough community interest?
>
> · BTW,  in this particular case, there originally has been a
> *direct* ODL access as a NSH solution (i.e. NO OpenStack option), then we
> got Tacker (now an Neutron Stadium project, if I get it right) to support
> SFC and NSH, but we are still told that networking-sfc (another Neutron
> Stadium project ) can’t do the same….
>
> I cannot comment for the experience and the conversations you've had so
> far as I have no context. All I know is that if you want to experiment with
> OpenDaylight and its NSH provider and want to use that as a Neutron backend
> you can. However, if that requires new abstractions, these new abstractions
> must be agreed by all interested parties, be technology agnostic, and allow
> for multiple implementation, an open one included. That's the nature of
> OpenStack.
>
> [UE] thanks for this clarification! I think it means that now that we all
> agree SFC abstraction is needed and that NSH is an emerging standard and
> networking-sfc team agrees to support NSH – there should be no reason to
> wait. As Tim Rozet mentioned an ODL driver with explicit SFC support is
> WIP, so sounds like NSH  support in it should be a go!
>

So long the required support is not specific to NSH and the API is not
polluted by implementation details specific to NSH.

> · Also regarding the  following comment made on another message
> in this thread, “As to OvS features, I guess the OvS ml is a better place,
> but wonder if the Neutron community wants to hold itself hostage to the
> pace of other projects who are reluctant to adopt a feature”, what I mean
> is again, that chicken and egg situation as above. Personally, I think
> OpenStack N

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

[Armando M.]

On 25 May 2016 at 10:24, Tim Rozet <tro...@redhat.com> wrote:

> In my opinion, it is a better approach to break this down into plugin vs
> driver support.  There should be no problem adding support into
> networking-sfc plugin for NSH today.  The OVS driver however, depends on
> OVS as the dataplane - which I can see a solid argument for only supporting
> an official version with a non-NSH solution.  The plugin side should have
> no dependency on OVS.  Therefore if we add NSH SFC support to an ODL driver
> in networking-odl, and use that as our networking-sfc driver, the argument
> about OVS goes away (since neutron/networking-sfc is totally unaware of the
> dataplane at this point).


I am afraid the argument does not go away is the crux of the matter is
exposing implementation aspects over the SFC API where such aspects  can
only be realized/understood by a single plugin.


> We would just need to ensure that API calls to networking-sfc specifying
> NSH port pairs returned error if the enabled driver was OVS (until official
> OVS with NSH support is released).
>
>
I am not 100% sure what you mean by specifying NSH port pairs over the API
but this to me seems to be in violation of the above mentioned abstraction
principle we're trying to abide. To date a plugin is allowed to bring its
own extensions, however that doesn't mean that those extensions can be
universally implemented and as such must be considered plugin specific.

Thoughts?


> Tim Rozet
> Red Hat SDN Team
>
> - Original Message -
> From: "Armando M." <arma...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Cc: "Tim Rozet" <tro...@redhat.com>
> Sent: Wednesday, May 25, 2016 12:33:16 PM
> 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 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 

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

[Armando M.]

On 25 May 2016 at 12:29, 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 I said, you're free to experiment. The general directive is to allow
these experimentations to take place and use them as a feedback tool to
iterate on the abstractions. However the abstraction would only be
considered community accepted if and only if there's enough evidence that
there is established support from a broad variety of plugins (open source
and non).


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

We're mixing two things here: OVN is not experimenting with (Neutron) APIs
(as it's adopting those as is), but it's experimenting with
implementations. So I would not conflate OVN and NSH in the same
discussion. I simply brought it up as another example (alongside DPDK) of
how innovation can be fostered in open source communities.


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

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

[Armando M.]

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.


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

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

[Armando M.]

On 13 June 2016 at 22:22, Terry Wilson  wrote:

> > So basically, as long as we try to plug ports with different MTUs into
> the same bridge, we are utilizing a bug in Open vSwitch, that may break us
> any time.
> >
> > I guess our alternatives are:
> > - either redesign bridge setup for openvswitch to e.g. maintain a bridge
> per network;
> > - or talk to ovs folks on whether they may support that for us.
> >
> > I understand the former option is too scary. It opens lots of questions,
> including upgrade impact since it will obviously introduce a dataplane
> downtime. That would be a huge shift in paradigm, probably too huge to
> swallow. The latter option may not fly with vswitch folks. Any better ideas?
>
> I know I've heard from people who'd like to be able to support both
> DPDK and non-DPDK workloads on the same node. The current
> implementation with a single br-int (and thus datapath) makes that
> impossible to pull of with good performance. So there may be other
> reasons to consider introducing multiple isolated bridges: MTUs,
> datapath_types, etc.
>

Incidentally this is something that Nova is already capable of handling
(ie. wiring VM's in different bridges) thanks to [1], and with some minor
additions as being discussed in the context of [2] vlan-aware-vms, we can
open up the possibility to this deployment model in a not so distant future.

[1] https://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-June/097025.html


> Terry
>
> On Mon, Jun 13, 2016 at 11:49 AM, Ihar Hrachyshka 
> wrote:
> > Hi all,
> >
> > in Mitaka, we introduced a bunch of changes to the way we handle MTU in
> Neutron/Nova, making sure that the whole instance data path, starting from
> instance internal interface, thru hybrid bridge, into the br-int; as well
> as router data path (qr) have proper MTU value set on all participating
> devices. On hypervisor side, both Nova and Neutron take part in it, setting
> it with ip-link tool based on what Neutron plugin calculates for us. So far
> so good.
> >
> > Turns out that for OVS, it does not work as expected in regards to
> br-int. There was a bug reported lately:
> https://launchpad.net/bugs/1590397
> >
> > Briefly, when we try to set MTU on a device that is plugged into a
> bridge, and if the bridge already has another port with lower MTU, the
> bridge itself inherits MTU from that latter port, and Linux kernel (?) does
> not allow to set MTU on the first device at all, making ip link calls
> ineffective.
> >
> > AFAIU this behaviour is consistent with Linux bridging rules: you can’t
> have ports of different MTU plugged into the same bridge.
> >
> > Now, that’s a huge problem for Neutron, because we plug ports that
> belong to different networks (and that hence may have different MTUs) into
> the same br-int bridge.
> >
> > So I played with the code locally a bit and spotted that currently, we
> set MTU for router ports before we move their devices into router
> namespaces. And once the device is in a namespace, ip-link actually works.
> So I wrote a fix with a functional test that proves the point:
> https://review.openstack.org/#/c/327651/ The fix was validated by the
> reporter of the original bug and seems to fix the issue for him.
> >
> > It’s suspicious that it works from inside a namespace but not when the
> device is still in the root namespace. So I reached out to Jiri Benc from
> our local Open vSwitch team, and here is a quote:
> >
> > ===
> >
> > "It's a bug in ovs-vswitchd. It doesn't see the interface that's in
> > other netns and thus cannot enforce the correct MTU.
> >
> > We'll hopefully fix it and disallow incorrect MTU setting even across
> > namespaces. However, it requires significant effort and rework of ovs
> > name space handling.
> >
> > You should not depend on the current buggy behavior. Don't set MTU of
> > the internal interfaces higher than the rest of the bridge, it's not
> > supported. Hacking this around by moving the interface to a netns is
> > exploiting of a bug.
> >
> > We can certainly discuss whether this limitation could be relaxed.
> > Honestly, I don't know, it's for a discussion upstream. But as of now,
> > it's not supported and you should not do it.”
> >
> > So basically, as long as we try to plug ports with different MTUs into
> the same bridge, we are utilizing a bug in Open vSwitch, that may break us
> any time.
> >
> > I guess our alternatives are:
> > - either redesign bridge setup for openvswitch to e.g. maintain a bridge
> per network;
> > - or talk to ovs folks on whether they may support that for us.
> >
> > I understand the former option is too scary. It opens lots of questions,
> including upgrade impact since it will obviously introduce a dataplane
> downtime. That would be a huge shift in paradigm, probably too huge to
> swallow. The latter option may not fly with vswitch folks. Any better ideas?
> >
> > 

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

[Armando M.]

On 13 June 2016 at 10:35, Daniel P. Berrange  wrote:

> On Thu, Jun 09, 2016 at 05:31:13PM -0600, Carl Baldwin wrote:
> > Hi,
> >
> > You may or may not be aware of the vlan-aware-vms effort [1] in
> > Neutron.  If not, there is a spec and a fair number of patches in
> > progress for this.  Essentially, the goal is to allow a VM to connect
> > to multiple Neutron networks by tagging traffic on a single port with
> > VLAN tags.
> >
> > This effort will have some effect on vif plugging because the datapath
> > will include some changes that will effect how vif plugging is done
> > today.
> >
> > The design proposal for trunk ports with OVS adds a new bridge for
> > each trunk port.  This bridge will demux the traffic and then connect
> > to br-int with patch ports for each of the networks.  Rawlin Peters
> > has some ideas for expanding the vif capability to include this
> > wiring.
> >
> > There is also a proposal for connecting to linux bridges by using
> > kernel vlan interfaces.
> >
> > This effort is pretty important to Neutron in the Newton timeframe.  I
> > wanted to send this out to start rounding up the reviewers and other
> > participants we need to see how we can start putting together a plan
> > for nova integration of this feature (via os-vif?).
>
> I've not taken a look at the proposal, but on the timing side of things
> it is really way to late to start this email thread asking for design
> input from os-vif or nova. We're way past the spec proposal deadline
> for Nova in the Newton cycle, so nothing is going to happen until the
> Ocata cycle no matter what Neutron want  in Newton.


For sake of clarity, does this mean that the management of the os-vif
project matches exactly Nova's, e.g. same deadlines and processes apply,
even though the core team and its release model are different from Nova's?
I may have erroneously implied that it wasn't, also from past talks I had
with johnthetubaguy.

Perhaps the answer to this question is clearly stated somewhere else, but I
must have missed it. I want to make sure I ask explicitly now to avoid
future confusion.

For os-vif our
> focus right now is exclusively on getting existing functionality ported
> over, and integrated into Nova in Newton. So again we're not really looking
> to spend time on further os-vif design work right now.
>
> In the Ocata cycle we'll be looking to integrate os-vif into Neutron to
> let it directly serialize VIF objects and send them over to Nova, instead
> of using the ad-hoc port-binding dicts.  From the Nova side, we're not
> likely to want to support any new functionality that affects port-binding
> data until after Neutron is converted to os-vif. So Ocata at the earliest,
> but probably more like P, unless the Neutron conversion to os-vif gets
> completed unexpectedly quickly.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
__
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][os-vif] Expanding vif capability for wiring trunk ports

[Armando M.]

On 13 June 2016 at 14:11, Daniel P. Berrange <berra...@redhat.com> wrote:

> On Mon, Jun 13, 2016 at 02:08:30PM +0200, Armando M. wrote:
> > On 13 June 2016 at 10:35, Daniel P. Berrange <berra...@redhat.com>
> wrote:
> >
> > > On Thu, Jun 09, 2016 at 05:31:13PM -0600, Carl Baldwin wrote:
> > > > Hi,
> > > >
> > > > You may or may not be aware of the vlan-aware-vms effort [1] in
> > > > Neutron.  If not, there is a spec and a fair number of patches in
> > > > progress for this.  Essentially, the goal is to allow a VM to connect
> > > > to multiple Neutron networks by tagging traffic on a single port with
> > > > VLAN tags.
> > > >
> > > > This effort will have some effect on vif plugging because the
> datapath
> > > > will include some changes that will effect how vif plugging is done
> > > > today.
> > > >
> > > > The design proposal for trunk ports with OVS adds a new bridge for
> > > > each trunk port.  This bridge will demux the traffic and then connect
> > > > to br-int with patch ports for each of the networks.  Rawlin Peters
> > > > has some ideas for expanding the vif capability to include this
> > > > wiring.
> > > >
> > > > There is also a proposal for connecting to linux bridges by using
> > > > kernel vlan interfaces.
> > > >
> > > > This effort is pretty important to Neutron in the Newton timeframe.
> I
> > > > wanted to send this out to start rounding up the reviewers and other
> > > > participants we need to see how we can start putting together a plan
> > > > for nova integration of this feature (via os-vif?).
> > >
> > > I've not taken a look at the proposal, but on the timing side of things
> > > it is really way to late to start this email thread asking for design
> > > input from os-vif or nova. We're way past the spec proposal deadline
> > > for Nova in the Newton cycle, so nothing is going to happen until the
> > > Ocata cycle no matter what Neutron want  in Newton.
> >
> >
> > For sake of clarity, does this mean that the management of the os-vif
> > project matches exactly Nova's, e.g. same deadlines and processes apply,
> > even though the core team and its release model are different from
> Nova's?
> > I may have erroneously implied that it wasn't, also from past talks I had
> > with johnthetubaguy.
>
> No, we don't intend to force ourselves to only release at milestones
> like nova does. We'll release the os-vif library whenever there is new
> functionality in its code that we need to make available to nova/neutron.
> This could be as frequently as once every few weeks.
>

Thanks, but I could get this answer from [1]. I was asking about specs and
deadlines.

[1] https://governance.openstack.org/reference/projects/nova.html


> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
__
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

[Armando M.]

On 31 May 2016 at 11:17, Ihar Hrachyshka <ihrac...@redhat.com> wrote:

>
> > On 31 May 2016, at 20:12, Armando M. <arma...@gmail.com> 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.
>
> VPNaaS and FWaaS are the land of the dead these days. Even LBaaS is not
> that active.
>
> +1 for the change.
>

https://review.openstack.org/#/c/323522/


>
> 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][Release] Changing release model for *-aas services

[Armando M.]

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]
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-dev] [Neutron] Team meeting - cancelled

[Armando M.]

Neutrinos,

Because of holidays in US/UK, it's probably safer to cancel the meeting for
the week starting Monday 30th.

We are approaching N-1, and we'll cut the release sometime next week.
Please be aware of release deadlines [1], if you have cross-project items
you are working on.

Cheers,
Armando

[1] http://releases.openstack.org/newton/schedule.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-dev] [Neutron] Stadium Evolution - next steps

[Armando M.]

Hi Neutrinos,

I wanted to give an update on [1]. Based on the feedback received so far I
think it is time to get on the next stage of this transition and execute on
some of the things identified in the proposal, as well as provide more
detailed information to some of the folks involved in the projects affected
by this proposal.

More precisely, I will be going over [2] to revise the content and make
sure it is inline with the spec proposal. I will also start consolidating
the Neutron's API over to neutron-lib and shepard the transition.

Please do not hesitate to reach out for any question.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/312199/
[2] http://docs.openstack.org/developer/neutron/#neutron-stadium
__
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

[Armando M.]

On 1 June 2016 at 02:28, Thierry Carrez <thie...@openstack.org> wrote:

> Armando M. wrote:
>
>> 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 commented on the review, but I think it's easier to discuss this here...
>
> Beyond changing the release model, what you're proposing here is to remove
> functionality from an existing deliverable ("neutron" which was a
> combination of openstack/neutron and openstack/neutron-*aas, released
> together) and making the *aas things separate deliverables.
>

All I wanted to do is change the release model of the *-aas projects,
without side effects. I appreciate that the governance structure doesn't
seem to allow this easily, and I am looking for guidance.


>
> From a Defcore perspective, the trademark programs include the "neutron"
> deliverable. So the net effect for DefCore is that you remove functionality
> -- and removing functionality from a Defcore-used project needs extra care
> and heads-up time.
>

To the best of my knowledge none of the *-aas projects are part of defcore,
and since [1] has no presence of vpn, fw, lb, nor planned, I thought I was
on the safe side.


> It's probably fine to remove *-aas from the neutron deliverable if there
> is no Defcore capability or designated section there (current or planned).
> Otherwise we need to have a longer conversation that is likely to extend
> beyond the release model deadline tomorrow.


I could not see one in [1]

[1] https://github.com/openstack/defcore/blob/master/2016.01.json


>
> --
> 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][os-vif] Expanding vif capability for wiring trunk ports

[Armando M.]

On 16 June 2016 at 03:33, Matt Riedemann  wrote:

> On 6/13/2016 3:35 AM, Daniel P. Berrange wrote:
>
>> On Thu, Jun 09, 2016 at 05:31:13PM -0600, Carl Baldwin wrote:
>>
>>> Hi,
>>>
>>> You may or may not be aware of the vlan-aware-vms effort [1] in
>>> Neutron.  If not, there is a spec and a fair number of patches in
>>> progress for this.  Essentially, the goal is to allow a VM to connect
>>> to multiple Neutron networks by tagging traffic on a single port with
>>> VLAN tags.
>>>
>>> This effort will have some effect on vif plugging because the datapath
>>> will include some changes that will effect how vif plugging is done
>>> today.
>>>
>>> The design proposal for trunk ports with OVS adds a new bridge for
>>> each trunk port.  This bridge will demux the traffic and then connect
>>> to br-int with patch ports for each of the networks.  Rawlin Peters
>>> has some ideas for expanding the vif capability to include this
>>> wiring.
>>>
>>> There is also a proposal for connecting to linux bridges by using
>>> kernel vlan interfaces.
>>>
>>> This effort is pretty important to Neutron in the Newton timeframe.  I
>>> wanted to send this out to start rounding up the reviewers and other
>>> participants we need to see how we can start putting together a plan
>>> for nova integration of this feature (via os-vif?).
>>>
>>
>> I've not taken a look at the proposal, but on the timing side of things
>> it is really way to late to start this email thread asking for design
>> input from os-vif or nova. We're way past the spec proposal deadline
>> for Nova in the Newton cycle, so nothing is going to happen until the
>> Ocata cycle no matter what Neutron want  in Newton. For os-vif our
>> focus right now is exclusively on getting existing functionality ported
>> over, and integrated into Nova in Newton. So again we're not really
>> looking
>> to spend time on further os-vif design work right now.
>>
>> In the Ocata cycle we'll be looking to integrate os-vif into Neutron to
>> let it directly serialize VIF objects and send them over to Nova, instead
>> of using the ad-hoc port-binding dicts.  From the Nova side, we're not
>> likely to want to support any new functionality that affects port-binding
>> data until after Neutron is converted to os-vif. So Ocata at the earliest,
>> but probably more like P, unless the Neutron conversion to os-vif gets
>> completed unexpectedly quickly.
>>
>> Regards,
>> Daniel
>>
>>
> +1. Nova is past non-priority spec approval freeze for Newton. With
> respect to os-vif it's a priority to integrate that into Nova in Newton [1].
>
> We're also working on refactoring how we allocate and bind ports when
> creating a server [2]. This is a dependency for the routed networks work
> and it's also going to bump up against the changes I'm making in nova for
> get-me-a-network in Newton (which is another priority).
>
> So if vlan-aware-vms changes how nova allocates/binds ports, that's going
> to be dependent on this also, and will have to be worked into the Ocata
> release from Nova's POV.
>

If my understanding is correct, everything that was required in Nova was
done in the context of [1], which completed in Mitaka. What's left is the
os-vif part: if os-vif is not tied to the Nova release cycle or the
spec/blueprint approval and freeze process and the change in question is
trivial, then I hope we can make an effort to pull it off.

Now, if the review process unveiled loose ends and changes that are indeed
required to Nova, then I'd agree we should not change priorities.

Thanks,
Armando

[1] https://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name


>
> [1]
> https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html#os-vif-integration
> [2]
> http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/prep-for-network-aware-scheduling.html
>
> --
>
> 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

[openstack-dev] [Neutron] Intermittent failures on unit tests

[Armando M.]

Neutrinos,

There's been a number of intermittent failures induced by the DNS
integration code that popped up lately. One has been reported in [1],
another showed up in [2]. I am in the progress of digging deeper to see
what's going on, but if someone knows or working on the issue, please let
us know.

Also, please do not recheck blindly hoping the issue goes away.

Thanks,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1593647
[2] https://bugs.launchpad.net/neutron/+bug/1594796
__
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] Deprecation and release notes

[Armando M.]

Hi Neutrinos,

I would like to remind you to be extra careful when handling the
deprecation of config options.

Do not forget to associate release notes when appropriate, or even bug
reports tagged with 'deprecation' to track the deprecation cycle. Alerting
operators/deployers/packagers of impeding changes to their configuration
files makes us more friendly to our users.

I have seen instances of neglects [1,2] on this front.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/330273/
[2] https://review.openstack.org/#/c/332018/
__
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] Intermittent failures on unit tests

[Armando M.]

On 21 June 2016 at 08:41, Armando M. <arma...@gmail.com> wrote:

> Neutrinos,
>
> There's been a number of intermittent failures induced by the DNS
> integration code that popped up lately. One has been reported in [1],
> another showed up in [2]. I am in the progress of digging deeper to see
> what's going on, but if someone knows or working on the issue, please let
> us know.
>
> Also, please do not recheck blindly hoping the issue goes away.
>

I spoke with Ihar on IRC and it turns out it may (or may not be) that the
issue related to [2] is induced by change [3] or even [4], see [5] for more
details.

Cheers,
Armando


> Thanks,
> Armando
>
> [1] https://bugs.launchpad.net/neutron/+bug/1593647
> [2] https://bugs.launchpad.net/neutron/+bug/1594796
>

[3] https://review.openstack.org/#/c/327413/
[4] https://review.openstack.org/#/c/330273/
[5] http://paste.openstack.org/show/520931/
__
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] Elevating context to remove subnets created by admin

[Armando M.]

On 20 June 2016 at 18:41, Carl Baldwin  wrote:

> Somehow, this thread hid from me for a couple of weeks.  I just
> reviewed something relevant to this here [1].  It proposes adding
> tenant id to segment.  But, it also enforces that tenant id is the
> same as that of the network owning the segment.  So, I say why store
> it at all?
>
> I would argue that subnet should also not have a tenant_id and should
> just inherit it from the network.
>

It seems it may potentially limit the ability to describe ownership.
Virtually all Neutron models have it. Not sure I see the value in its
absence.


>
> Carl
>
> [1] https://review.openstack.org/#/c/331497/2/neutron/db/segments_db.py
>
> On Fri, Jun 3, 2016 at 3:05 PM, Henry Gessau  wrote:
> > Carl Baldwin  wrote:
> >> On Fri, Jun 3, 2016 at 2:26 PM, Henry Gessau  wrote:
> >>> Darek Smigiel  wrote:
>  strange, that owner is not able to just get rid of *his* network and
> subnets.
> >>>
> >>> But not all the subnets are his, and consequently the network is
> partially not
> >>> his.
> >>
> >> To me, this is a nonsensical outcome and tells me that subnets
> >> probably shouldn't really have owners distinct from the network's.
> >
> > Right. So are you saying we should prevent that?
> >
> >
> >
> >
> __
> > 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][os-vif] Expanding vif capability for wiring trunk ports

[Armando M.]

On 16 June 2016 at 00:31, Carl Baldwin  wrote:

> I know I've been pretty quiet since I started this thread.  Y'all have
> been doing so well, I've just been reading the thread every day and
> enjoying it.  I thought I'd top post here to kind of summarize.
>
> I see wisdom in the strategy suggested by Sean Mooney to make a very
> minimal change to os-vif to merely create a bridge if it doesn't exist
> already and otherwise plug as normal.  I agree that this is the
> strategy that we should take and I think there is a lot of support for
> it in this thread.  I'm assuming at this point that this is the way
> we're going to move forward unless we hear something soon.
>

+1


>
> There were a few side conversations about deprecating veth, linux
> bridge topics, and possibly something else.  I think those are their
> own topics and we don't necessarily need to wrap anything up on those
> at the moment.
>
> Thank you for all of your thoughts.
>
> Carl
>
> __
> 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][os-vif] Expanding vif capability for wiring trunk ports

[Armando M.]

On 16 June 2016 at 03:33, Matt Riedemann  wrote:

> On 6/13/2016 3:35 AM, Daniel P. Berrange wrote:
>
>> On Thu, Jun 09, 2016 at 05:31:13PM -0600, Carl Baldwin wrote:
>>
>>> Hi,
>>>
>>> You may or may not be aware of the vlan-aware-vms effort [1] in
>>> Neutron.  If not, there is a spec and a fair number of patches in
>>> progress for this.  Essentially, the goal is to allow a VM to connect
>>> to multiple Neutron networks by tagging traffic on a single port with
>>> VLAN tags.
>>>
>>> This effort will have some effect on vif plugging because the datapath
>>> will include some changes that will effect how vif plugging is done
>>> today.
>>>
>>> The design proposal for trunk ports with OVS adds a new bridge for
>>> each trunk port.  This bridge will demux the traffic and then connect
>>> to br-int with patch ports for each of the networks.  Rawlin Peters
>>> has some ideas for expanding the vif capability to include this
>>> wiring.
>>>
>>> There is also a proposal for connecting to linux bridges by using
>>> kernel vlan interfaces.
>>>
>>> This effort is pretty important to Neutron in the Newton timeframe.  I
>>> wanted to send this out to start rounding up the reviewers and other
>>> participants we need to see how we can start putting together a plan
>>> for nova integration of this feature (via os-vif?).
>>>
>>
>> I've not taken a look at the proposal, but on the timing side of things
>> it is really way to late to start this email thread asking for design
>> input from os-vif or nova. We're way past the spec proposal deadline
>> for Nova in the Newton cycle, so nothing is going to happen until the
>> Ocata cycle no matter what Neutron want  in Newton. For os-vif our
>> focus right now is exclusively on getting existing functionality ported
>> over, and integrated into Nova in Newton. So again we're not really
>> looking
>> to spend time on further os-vif design work right now.
>>
>> In the Ocata cycle we'll be looking to integrate os-vif into Neutron to
>> let it directly serialize VIF objects and send them over to Nova, instead
>> of using the ad-hoc port-binding dicts.  From the Nova side, we're not
>> likely to want to support any new functionality that affects port-binding
>> data until after Neutron is converted to os-vif. So Ocata at the earliest,
>> but probably more like P, unless the Neutron conversion to os-vif gets
>> completed unexpectedly quickly.
>>
>> Regards,
>> Daniel
>>
>>
> +1. Nova is past non-priority spec approval freeze for Newton. With
> respect to os-vif it's a priority to integrate that into Nova in Newton [1].
>
> We're also working on refactoring how we allocate and bind ports when
> creating a server [2]. This is a dependency for the routed networks work
> and it's also going to bump up against the changes I'm making in nova for
> get-me-a-network in Newton (which is another priority).
>
> So if vlan-aware-vms changes how nova allocates/binds ports, that's going
> to be dependent on this also, and will have to be worked into the Ocata
> release from Nova's POV.
>

If my understanding is correct, everything that was required in Nova was
done in the context of [1], which completed in Mitaka. What's left is the
os-vif part: if os-vif is not tied to the Nova release cycle or the
spec/blueprint approval and freeze process and the change in question is
trivial, then I hope we can make an effort to pull it off. After all, the
review effort required would be roughly the same to the one involved to pay
participate to this thread.

Now, if the review process unveiled loose ends and changes that are indeed
required to Nova, then I'd agree we should not change priorities.

Thanks,
Armando

[1] https://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name


>
> [1]
> https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html#os-vif-integration
> [2]
> http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/prep-for-network-aware-scheduling.html
>
> --
>
> 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

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

[Armando M.]

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

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

[Armando M.]

Disregard the email subject.

I stand corrected. Let's meet today.

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

Re: [openstack-dev] Further closing the holes that let gate breakage happen

[Armando M.]

On 13 January 2016 at 11:24, Carl Baldwin  wrote:

> Hi,
>
> I was looking at the most recent gate breakage in Neutron [1], fixed
> by [2].  This gate breakage was held off for some time by the
> upper-constraints.txt file.   This is great progress and I applaud it.
> I'll continue to cheer on this effort.
>
> Now to the next problem.   If my assessment of this gate failure is
> correct, the update to the upper-constraints file [3] was merged
> without running all of the tests across all of the projects that would
> be broken by bringing in this new constraint.  So, we still get
> breakage and it is still (IMO) too often.
>
>
This is my understanding too, but I let the infra and requirements gurus
confirm.


> As I see it, there are a couple of options.
>
> 1) We run all tests under the upper-constraints control on all updates
> to the upper constraints file like [2].  This would probably mean each
> update has a very long list of tests and we would require that they
> all be fixed before the upper constraint update can be merged.  This
> seems like a difficult thing to coordinate all at once.
> 2) We handle upper-constraints much like we do the global requirements
> updates.  We have the master and a bot that proposes updates to it out
> to the individual projects.  This would create a situation where
> projects are out of sync with the master but I think if we froze the
> master early enough, we could have time to reconcile before release.
> 3) We continue to allow changes in the upper constraints to break
> individual projects.
>

> Are there options that I missed?  What is your opinion?  In my
> opinion, gate breakage happens a bit too often and the effect on the
> community is widespread.  I'd like to contain it even a little bit
> more.
>

I suppose another (not ideal) solution might be to use Depends-on
cautiously. We could have filed a sentinel patch against the neutron repo
in conjunction with the upper-constraints change.

That said, I'd love to be a little more bullet proof.


>
> Carl
>
> [1] https://bugs.launchpad.net/neutron/+bug/1533638
> [2] https://review.openstack.org/#/c/266885/
> [3] https://review.openstack.org/#/c/266042/
>
> __
> 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] Team meeting on Monday at 2100UTC

[Armando M.]

Hi folks,

A reminder of next week meeting. Let's see if we manage to have the first
one of the year!

Word of notice: Monday is a public holiday for US.

Cheers,
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-dev] [Neutron] Gate failure

[Armando M.]

It's the usual time of the week where I submit the dreaded email

Please do not push anything in the queue until change [1] merges.

Cheers,
Armando

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

[Armando M.]

On 12 January 2016 at 20:07, Kyle Mestery  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 :)

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.

Cheers,
Armando


>
> 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
>
>
__
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] [QA][Neutron] IPv6 related intermittent test failures

[Armando M.]

On 3 February 2016 at 18:49, Armando M. <arma...@gmail.com> wrote:

>
>
> On 3 February 2016 at 04:28, Sean Dague <s...@dague.net> wrote:
>
>> On 02/02/2016 10:03 PM, Matthew Treinish wrote:
>> > On Tue, Feb 02, 2016 at 05:09:47PM -0800, Armando M. wrote:
>> >> Folks,
>> >>
>> >> We have some IPv6 related bugs [1,2,3] that have been lingering for
>> some
>> >> time now. They have been hurting the gate (e.g. [4] the most recent
>> >> offending failure) and since it looks like they have been without
>> owners
>> >> nor a plan of action for some time, I made the hard decision of
>> skipping
>> >> them [5] ahead of the busy times ahead.
>> >
>> > So TBH I don't think the failure rate for these tests are really at a
>> point
>> > necessitating a skip:
>> >
>> >
>> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac
>> >
>> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os
>> >
>> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os
>> >
>> > (also just a cool side-note, you can see the very obvious performance
>> regression
>> > caused by the keystonemiddleware release and when we excluded that
>> version in
>> > requirements)
>> >
>> > Well, test_dualnet_dhcp6_stateless_from_os is kinda there with a ~10%
>> failure
>> > rate, but the other 2 really aren't. I normally would be -1 on the skip
>> patch
>> > because of that. We try to save the skips for cases where the bugs are
>> really
>> > severe and preventing productivity at a large scale.
>> >
>> > But, in this case these ipv6 tests are kinda of out of place in
>> tempest. Having
>> > all the permutations of possible ip allocation configurations always
>> seemed a
>> > bit too heavy handed. These tests are also consistently in the top 10
>> slowest
>> > for a run. We really should have trimmed down this set a while ago so
>> we're only
>> > have a single case in tempest. Neutron should own the other possible
>> > configurations as an in-tree test.
>> >
>> > Brian Haley has a patch up from Dec. that was trying to clean it up:
>> >
>> > https://review.openstack.org/#/c/239868/
>> >
>> > We probably should revisit that soon, since quite clearly no one is
>> looking at
>> > these right now.
>>
>> We definitely shouldn't be running all the IPv6 tests.
>>
>> But I also think the assumption that the failure rate is low is not a
>> valid reason to keep a test. Unreliable tests that don't have anyone
>> looking into them should be deleted. They are providing negative value.
>> Because people just recheck past them even if their code made the race
>> worse. So any legitimate issues they are exposing are being ignored.
>>
>> If the neutron PTL wants tests pulled, we should just do it.
>>
>>
> Thanks for the support! Having said, I think it's important to make a
> judgement call on a case by case basis, because removing tests blindly
> might as well backfire.
>
> In this specific instance and all things considered, merging [2] (or even
> better [1]) feel like a net gain.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/239868/
> [2] https://review.openstack.org/#/c/275457/
>
>

Btw I did respin [1], because I am still seeing intermittent failures.

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

-Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> __
>> 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] Migration to pluggable IPAM

[Armando M.]

On 4 February 2016 at 08:22, John Belamaric  wrote:

>
> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin  wrote:
> >
> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar 
> wrote:
> >> I am trying to bring more attention to [1] to make final decision on
> >> approach to use.
> >> There are a few point that are not 100% clear for me at this point.
> >>
> >> 1) Do we plan to switch all current clouds to pluggable ipam
> >> implementation in Mitaka?
> >
> > I think our plan originally was only to deprecate the non-pluggable
> > implementation in Mitaka and remove it in Newton.  However, this is
> > worth some more consideration.  The pluggable version of the reference
> > implementation should, in theory, be at parity with the current
> > non-pluggable implementation.  We've tested it before and shown
> > parity.  What we're missing is regular testing in the gate to ensure
> > it continues this way.
> >
>
> Yes, it certainly should be at parity, and gate testing to ensure it would
> be best.
>
> >> yes -->
> >> Then data migration can be done as alembic_migration and it is what
> >> currently implemented in [2] PS54.
> >> In this case during upgrade from Liberty to Mitaka all users are
> >> unconditionally switched to reference ipam driver
> >> from built-in ipam implementation.
> >> If operator wants to continue using build-in ipam implementation it can
> >> manually turn off ipam_driver in neutron.conf
> >> immediately after upgrade (data is not deleted from old tables).
> >
> > This has a certain appeal to it.  I think the migration will be
> > straight-forward since the table structure doesn't really change much.
> > Doing this as an alembic migration would be the easiest from an
> > upgrade point of view because it fits seamlessly in to our current
> > upgrade strategy.
> >
> > If we go this way, we should get this in soon so that we can get the
> > gate and others running with this code for the remainder of the cycle.
> >
>
> If we do this, and the operator reverts back to the non-pluggable version,
> then we will leave stale records in the new IPAM tables. At the very least,
> we would need a way to clean those up and to migrate at a later time.
>
> >> no -->
> >> Operator is free to choose whether it will switch to pluggable ipam
> >> implementation
> >> and when. And it leads to no automatic data migration.
> >> In this case operator is supplied with script for migration to pluggable
> >> ipam (and probably from pluggable ipam),
> >> which can be executed by operator during upgrade or at any point after
> >> upgrade is done.
> >> I was testing this approach in [2] PS53 (have unresolved issues in it
> >> for now).
> >
> > If there is some risk in changing over then this should still be
> > considered.  But, the more I think about it, the more I think that we
> > should just make the switch seamlessly for the operator and be done
> > with it.  This approach puts a certain burden on the operator to
> > choose when to do the migration and go through the steps manually to
> > do it.  And, since our intention is to deprecate and remove the
> > non-pluggable implementation, it is inevitable that they will have to
> > eventually switch anyway.
> >
> > This also makes testing much more difficult.  If we go this route, we
> > really should be testing both equally.  Does this mean that we need to
> > set up a whole new job to run the pluggable implementation along side
> > the old implementation?  This kind of feels like a nightmare to me.
> > What do you think?
> >
>
> Originally (as I mentioned in the meeting), I was thinking that we should
> not automatically migrate. However, I see the appeal of your arguments.
> Seamless is best, of course. But if we offer going back to non-pluggable,
> (which I think we need to at this point in the Mitaka cycle), we probably
> need to provide a script as mentioned above. Seems feasible, though.
>
>
>
>
We're tackling more than one issue in this thread and I am having a hard
time wrapping my head around it. Let me try to sum it all up.

a) switching from non-pluggable to pluggable it's a matter of running a
data migration + a config change
b) We can either switch automatically on restart (option b1) or manually on
operator command (b2)
c) Do we make pluggable ipam default and when
d) Testing the migration
e) Deprecating the non-pluggable one.

I hope we are all in agreement on bullet point a), because knowing the
complexity of your problem is halfway to our solution.

as for b) I think that manual migration is best for two reasons: 1) In HA
scenarios, seamless upgrade (ie. on server restart) can be a challenge; 2)
the operator must 'manually' change the driver, so he/she is very conscious
of what he/she is doing and can take enough precautions should something go
astray. Technically we can make this as sophisticated and seamless as we
want, but this is a one-off, once it's done the pain goes away, and we
won't be 

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

[Armando M.]

On 5 February 2016 at 05:41, Gal Sagie <gal.sa...@gmail.com> wrote:

> Armando,
>
> I think that contributing and innovating in Dragonflow to implement
> Neutron in an open way and serve as an  alternative and as an example
> for distributed networking patterns IS driving Neutron forward, i am very
> sad that you fail to see this and try to pick to
> my review/patches count.
>

> Beside the big over head i devote to Dragonflow, due to the fact that it
> really runs as an open source project, i also help and contribute
> as much as i can to OVN and of course my efforts in Kuryr, which to me
> solves a critical and important thing for Neutron and for OpenStack
> in mixed containers environments.
> (And the rest of the time that i try to devote to Neutron and other
> sub-projects, currently still under Neutron big-stadium)
>
> Of course that all of this in addition to my efforts and success to
> convince and assist in bringing more people
> and more companies to contribute in an open way with the community in many
> areas in Neutron (some you are familiar with like the border gateway and
> l2gateway others that you are not..),
> both internally and externally, writing blogs/arranging meetups to promote
> and extend some
> of the above projects visibility and Neutron as such.
>
> Believe me that i truly am passionate about Neutron, OpenStack and open
> source and try my best to help and
> contribute when ever i can and many times not due to my "Job requirement",
> i apologise that this is
> not enough for you, there is only a limited amount of hours in a day :)
>
> However, i truly believe that Dragonflow, and ANY other true open source
> implementation of Neutron helps move
> Neutron forward and i hope to continue do so either as Neutron
> big-stadium, as a big-tent project or as something else.
>

I don't recall pointing at any stats. I appreciate your sales pitch, but
that doesn't change the fact that when looking at features like port
forwarding and tags (stuff that you indeed proposed and that can be
beneficial for the project as a whole), you didn't seem to give them enough
priority, meaning that Neutron core is not a priority for you...but don't
get me wrong...everyone has his/her own priorities.

My point being contributing to Dragonflow/OVN/etc alone is great because it
drives adoption and provide choice, but it is not enough to provide benefit
and value to the rest of projects and initiatives that exist within the
Neutron ecosystem, and use Neutron as a backbone to deliver network
services.

There's a wealth of more or less glamorous activities that the core team is
responsible for and are the true blood of this project. If the heart
doesn't pump out this blood to the limbs, the limbs might as well die.


>
> As i have talked with Russell and explained, to me the Big Stadium was/is
> a way to keep Networking related projects "near"
> the group of people that has the best context to review / help and
> comment, its obviously not working and thats fine, lets
> try something different...
>
>
> On Thu, Feb 4, 2016 at 8:18 PM, Armando M. <arma...@gmail.com> wrote:
>
>>
>>
>> On 4 February 2016 at 04:05, Gal Sagie <gal.sa...@gmail.com> wrote:
>>
>>> Hi Assaf,
>>>
>>> I think that if we define a certain criteria we need to make sure that
>>> it applies to everyone equally.
>>> and it is well understood.
>>>
>>
>> I must admit I am still waking up and going through the entire logs etc.
>> However I cannot help but point out that one criteria that Russell and
>> other TC people are behind (me included) is the significant 'team overlap'
>> (and I would add it to be for a prolonged amount of time). This doesn't
>> mean just drop the accidental bug fix or enhancement to enable the
>> subproject to work with Neutron or address the odd regression that sneaks
>> in from time to time, but it means driving Neutron forward so that it is
>> beneficial for the project as a whole.
>>
>> If you look at yourself, can you candidly say that you are making an
>> impact to the core of Neutron? You seem you have dropped off the radar in
>> the Mitaka timeframe, and haven't made a lasting impact in the Liberty
>> timeframe. I applaud your Kuryr initiative and your specs proposals, but
>> both are not enough to warrant Dragonflow for inclusion.
>>
>> If the team overlap changes, then great, we'll reassess.
>>
>> That said, I'll continue my discussion on the patch...
>>
>>
>>> I have contributed and still am to both OVN and Dragonflow and hope to
>>> continue do so in the future,
>>> i want to see both of these solutions beco

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

[Armando M.]

On 12 February 2016 at 09:15, Matt Riedemann 
wrote:

> Forgive me for thinking out loud, but I'm trying to sort out how nova
> would use a microversion in the nova API for the get-me-a-network feature
> recently added to neutron [1] and planned to be leveraged in nova (there
> isn't a spec yet for nova, I'm trying to sort this out for a draft).
>
> Originally I was thinking that a network is required for nova boot, so
> we'd simply check for a microversion and allow not specifying a network,
> easy peasy.
>
> Turns out you can boot an instance in nova (with neutron as the network
> backend) without a network. All you get is a measly debug log message in
> the compute logs [2]. That's kind of useless though and seems silly.
>

Incidentally, I was checking this out with Horizon, and the dashboard
instance boot workflow doesn't let you proceed without specifying a network
(irrespective of the network backend). So if the user has no networks,
he/she is stuck and has to flip to the CLI. Nice, uh?


>
> I haven't tested this out yet to confirm, but I suspect that if you create
> a nova instance w/o a network, you can latter try to attach a network using
> the os-attach-interfaces API as long as you either provide a network ID
> *or* there is a public shared network or the tenant has a network at that
> point (nova looks those up if a specific network ID isn't provided).
>

Just to make sure we're on the same page: if you're referring to 'public
shared network' as the devstack's provisioned network called 'public',
that's technically not shared and it represent your floating IP pool. A
user can explicitly boot VM's on it, but that's not to be confused with a
'shared' provider network.

That said, I tried the workflow of booting a vm without networks and trying
to attach an interface without specifying anything and I got a 500 [1].
Error aside, I think it's it would be erroneous to expect the attach
command to accept no networks (and still pick one), when the boot command
doesn't.

[1] http://paste.openstack.org/show/486856/


> The high-level plan for get-me-a-network in nova was simply going to be if
> the user tries to boot an instance and doesn't provide a network, and there
> isn't a tenant network or public shared network

to default to, then nova would call neutron's new auto-allocated-topology
> API to get a network. This, however, is a behavior change.
>

I assume that for you 'public shared network' it's not the public network
as available in DevStack because, because I don't believe that user can
boot VM's on that network automatically.


> So I guess the question now is how do we handle that behavior change in
> the nova API?
>
> We could add an auto-create-net boolean to the boot server request which
> would only be available in a microversion, then we could check that boolean
> in the compute API when we're doing network validation.
>
> Today if you don't specify a network and don't have a network available,
> then the validation in the API is basically just quota checking that you
> can get at least one port in your tenant [3]. With a flag on a
> microversion, we could also validate some other things about auto-creating
> a network (if we know that's going to be the case once we hit the compute).
>
> Anyway, this is mostly me getting thoughts out of my head before the
> weekend so I don't forget it and am looking for other ideas here or things
> I might be missing.
>

John and I just finished talking about this a bit more and I think the the
thought process led us to this conclusion:

>From Horizon, we could provide a 'get-me-a-network' button on the Networks
wizard for the boot workflow. If the user doesn't see any Networks
available he/she can hit the button, see the network being pre-populated
and choose to proceed, instead of going back to the Network panel and do
the entire workflow.

As for Nova, we could introduce a new micro-version that changes the
behavior of nova boot without networks. In this case, if the tenant has
access to no networks, one will be created for him/her and the VM will boot
off of it.

On the other end, if the user does want a VM without nics, he/she should be
explicit about this and specify 'no-nic' boolean, e.g.

  nova boot  --flavor  --image 
--no-nics

John and I think this would be preferable because the output of the command
becomes more predictable: the user doesn't end up having VM's connected to
NICs accidentally if some net-create sneaks underneath.

Anyhow, food for thought.

Thanks for starting this thread.

Cheers,
Armando


> [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
> [2]
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
> [3]
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> 

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

[Armando M.]

On 12 February 2016 at 11:08, Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:

>
>
> On 2/12/2016 12:44 PM, Armando M. wrote:
>
>>
>>
>> On 12 February 2016 at 09:15, Matt Riedemann <mrie...@linux.vnet.ibm.com
>> <mailto:mrie...@linux.vnet.ibm.com>> wrote:
>>
>> Forgive me for thinking out loud, but I'm trying to sort out how
>> nova would use a microversion in the nova API for the
>> get-me-a-network feature recently added to neutron [1] and planned
>> to be leveraged in nova (there isn't a spec yet for nova, I'm trying
>> to sort this out for a draft).
>>
>> Originally I was thinking that a network is required for nova boot,
>> so we'd simply check for a microversion and allow not specifying a
>> network, easy peasy.
>>
>> Turns out you can boot an instance in nova (with neutron as the
>> network backend) without a network. All you get is a measly debug
>> log message in the compute logs [2]. That's kind of useless though
>> and seems silly.
>>
>>
>> Incidentally, I was checking this out with Horizon, and the dashboard
>> instance boot workflow doesn't let you proceed without specifying a
>> network (irrespective of the network backend). So if the user has no
>> networks, he/she is stuck and has to flip to the CLI. Nice,
>> uh?
>>
>>
>> I haven't tested this out yet to confirm, but I suspect that if you
>> create a nova instance w/o a network, you can latter try to attach a
>> network using the os-attach-interfaces API as long as you either
>> provide a network ID *or* there is a public shared network or the
>> tenant has a network at that point (nova looks those up if a
>> specific network ID isn't provided).
>>
>>
>> Just to make sure we're on the same page: if you're referring to 'public
>> shared network' as the devstack's provisioned network called 'public',
>> that's technically not shared and it represent your floating IP pool. A
>> user can explicitly boot VM's on it, but that's not to be confused with
>> a 'shared' provider network.
>>
>
> I was referring to this code:
>
>
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L217-L223
>
>
Ok I am with you: the public in the comment is somewhat misleading because
there's nothing 'public' about a shared network and as a matter of fact
RBAC [1] allows for networks to be shared only to a subset of tenants.

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html


>
>> That said, I tried the workflow of booting a vm without networks and
>> trying to attach an interface without specifying anything and I got a
>> 500 [1]. Error aside, I think it's it would be erroneous to expect the
>> attach command to accept no networks (and still pick one), when the boot
>> command doesn't.
>>
>> [1] http://paste.openstack.org/show/486856/
>>
>
> Cool, yeah, I was totally expecting an IndexError because of the code here:
>
>
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L610
>
>
>
>>
>> The high-level plan for get-me-a-network in nova was simply going to
>> be if the user tries to boot an instance and doesn't provide a
>> network, and there isn't a tenant network or public shared network
>>
>> to default to, then nova would call neutron's new
>> auto-allocated-topology API to get a network. This, however, is a
>> behavior change.
>>
>>
>> I assume that for you 'public shared network' it's not the public
>> network as available in DevStack because, because I don't believe that
>> user can boot VM's on that network automatically.
>>
>>
>> So I guess the question now is how do we handle that behavior change
>> in the nova API?
>>
>> We could add an auto-create-net boolean to the boot server request
>> which would only be available in a microversion, then we could check
>> that boolean in the compute API when we're doing network validation.
>>
>> Today if you don't specify a network and don't have a network
>> available, then the validation in the API is basically just quota
>> checking that you can get at least one port in your tenant [3]. With
>> a flag on a microversion, we could also validate some other things
>> about auto-creating a network (if we know that's going to be the
>> case once we hit the compute).
>>
>

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

[Armando M.]

w removing from Neutron big
>> >> stadium and letting them comment.
>> >>
>> >> Gal.
>> >
>> > I understand you see 'Dragonflow being part of the Neutron stadium'
>> > and 'Dragonflow having high visibility' as tied together. I'm curious,
>> > from a practical perspective, how does being a part of the stadium
>> > give Dragonflow visibility? If it were not a part of the stadium and
>> > you had your own PTL etc, what specifically would change so that
>> > Dragonflow would be less visible. Currently I don't understand why
>> > being a part of the stadium is good or bad for a networking project,
>> > or why does it matter. Looking at Russell's patch, it's concerned with
>> > placing projects (e.g. ODL, OVN, Dragonflow) either in or out of the
>> > stadium and the criteria for doing so, I'm just asking how do you
>> > (Gal) perceive the practical effect of that decision.
>>
>> Allow me to expand:
>> It seems to me like there is no significance to who is 'in or out'.
>> However, people, including potential customers, look at the list of
>> the Neutron stadium and deduce that project X is better than Y because
>> X is in but Y is out, and *that* in itself is the value of being in or
>> out, even though it has no meaning. Maybe we should explain what
>> exactly does it mean being in or out. It's just a governance decision,
>> it doesn't reflect in any way of the quality or appeal of a project
>> (For example some of the open source Neutron drivers out of the
>> stadium are much more mature, stable and feature full than other
>> drivers in the stadium).
>>
>> >
>> >>
>> >>
>> >> On Wed, Feb 3, 2016 at 11:48 PM, Russell Bryant <rbry...@redhat.com>
>> 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
>>
>
>
>
> --
> 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-dev] [Neutron] Team meeting this Monday at 2100 UTC

[Armando M.]

Hi neutrinos,

A kind reminder for next week's meeting. More on the agenda [1].

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

Re: [openstack-dev] [Nova][Neutron] Scheduling with routed networks

[Armando M.]

On 29 January 2016 at 12:16, Jay Pipes  wrote:

> On 01/28/2016 09:15 PM, Carl Baldwin wrote:
>
>> Hi Nova and Neutron,
>>
>> It was a pleasure to attend the Nova mid-cycle in Bristol this week.
>>
>
> Indeed, I thought the mid-cycle was super-productive.


Yup, I always thought that Nova folks had tails, horns and pitchforks...it
turns out I was wrong!


>
>
> I think we made a lot of progress.  I spent a little time capturing
>> the highlights of what we discussed about scheduling and routed
>> networks in a new revision to the backlog spec [1] that I created a
>> couple of weeks ago.
>>
>> I also captured my understanding of the discussion we had this
>> afternoon as things were winding down.  I remember Jay Pipes, Andrew
>> Laskey, Dan Smith, John Garbutt, and Armando Migliaccio actively
>> participating in that discussion with me.  I would appreciate it if
>> you could visit this spec and record any thoughts or conclusions that
>> I might have missed or mis-understood.
>>
>
> Will do for sure. I'll also keep you updated on the progress of the
> generic-resource-pools work which intersects with the routed networks
> features.
>

It's my intention of going over the spec whilst my memory is fresh...I need
some _light reading_ for my journey back anyway :)

Cheers,
Armando


>
> Best,
> -jay
>
>
> Thanks,
>> Carl Baldwin
>>
>> [1] https://review.openstack.org/#/c/263898/
>>
>> __
>> 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] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

[Armando M.]

I'll kill it, as this should be superseded by the in-tree devref version.

Thanks for pointing my attention to it.

On 27 January 2016 at 23:40, Neil Jerram  wrote:

> Is there any part of the cited wiki page that is still relevant?I've just
> been asked whether networking-calico (a backend project that I work on)
> should be listed there, and I think the answer is no because that page is
> out of date now.
>
> If that's right, could/should it be deleted?
>
> 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

[openstack-dev] [QA][Neutron] IPv6 related intermittent test failures

[Armando M.]

Folks,

We have some IPv6 related bugs [1,2,3] that have been lingering for some
time now. They have been hurting the gate (e.g. [4] the most recent
offending failure) and since it looks like they have been without owners
nor a plan of action for some time, I made the hard decision of skipping
them [5] ahead of the busy times ahead.

Now one might argue that skipping them is counterproductive because it may
allow other regressions to sneak in, but I am hoping that this
controversial action will indeed smoke out the right folks.

Comments welcome.

Regards,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1477192
[2] https://bugs.launchpad.net/neutron/+bug/1509004
[3] https://bugs.launchpad.net/openstack-gate/+bug/1540983
[4]
http://logs.openstack.org/37/264937/5/gate/gate-tempest-dsvm-neutron-full/afeaabd//logs/testr_results.html.gz
[5] https://review.openstack.org/#/c/275457/
__
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] [QA][Neutron] IPv6 related intermittent test failures

[Armando M.]

On 3 February 2016 at 04:28, Sean Dague <s...@dague.net> wrote:

> On 02/02/2016 10:03 PM, Matthew Treinish wrote:
> > On Tue, Feb 02, 2016 at 05:09:47PM -0800, Armando M. wrote:
> >> Folks,
> >>
> >> We have some IPv6 related bugs [1,2,3] that have been lingering for some
> >> time now. They have been hurting the gate (e.g. [4] the most recent
> >> offending failure) and since it looks like they have been without owners
> >> nor a plan of action for some time, I made the hard decision of skipping
> >> them [5] ahead of the busy times ahead.
> >
> > So TBH I don't think the failure rate for these tests are really at a
> point
> > necessitating a skip:
> >
> >
> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac
> >
> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os
> >
> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os
> >
> > (also just a cool side-note, you can see the very obvious performance
> regression
> > caused by the keystonemiddleware release and when we excluded that
> version in
> > requirements)
> >
> > Well, test_dualnet_dhcp6_stateless_from_os is kinda there with a ~10%
> failure
> > rate, but the other 2 really aren't. I normally would be -1 on the skip
> patch
> > because of that. We try to save the skips for cases where the bugs are
> really
> > severe and preventing productivity at a large scale.
> >
> > But, in this case these ipv6 tests are kinda of out of place in tempest.
> Having
> > all the permutations of possible ip allocation configurations always
> seemed a
> > bit too heavy handed. These tests are also consistently in the top 10
> slowest
> > for a run. We really should have trimmed down this set a while ago so
> we're only
> > have a single case in tempest. Neutron should own the other possible
> > configurations as an in-tree test.
> >
> > Brian Haley has a patch up from Dec. that was trying to clean it up:
> >
> > https://review.openstack.org/#/c/239868/
> >
> > We probably should revisit that soon, since quite clearly no one is
> looking at
> > these right now.
>
> We definitely shouldn't be running all the IPv6 tests.
>
> But I also think the assumption that the failure rate is low is not a
> valid reason to keep a test. Unreliable tests that don't have anyone
> looking into them should be deleted. They are providing negative value.
> Because people just recheck past them even if their code made the race
> worse. So any legitimate issues they are exposing are being ignored.
>
> If the neutron PTL wants tests pulled, we should just do it.
>
>
Thanks for the support! Having said, I think it's important to make a
judgement call on a case by case basis, because removing tests blindly
might as well backfire.

In this specific instance and all things considered, merging [2] (or even
better [1]) feel like a net gain.

Cheers,
Armando

[1] https://review.openstack.org/#/c/239868/
[2] https://review.openstack.org/#/c/275457/


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] Team meeting this Tuesday at 1400 UTC

[Armando M.]

Hi neutrinos,

According to [1], this is a kind reminder for next week's meeting: please
do not get caught by the confusion.

The Tuesday meetings will be hosted by Ihar, and I will be working with him
to discuss these meeting agendas [2] ahead of time. For this reason, stay
tuned for reminder updates coming from him too.

I do not plan on attending, but I may occasionally join the irc meetings
when I travel to more friendly time zones. If you have something to discuss
with me (whilst I am in the PTL capacity), please do not rely on the
Tuesday meetings to reach out.

In the meantime, let's thank Ihar for volunteering!

Cheers,
Armando

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

Re: [openstack-dev] [QA][Neutron] IPv6 related intermittent test failures

[Armando M.]

On 2 February 2016 at 19:03, Matthew Treinish <mtrein...@kortar.org> wrote:

> On Tue, Feb 02, 2016 at 05:09:47PM -0800, Armando M. wrote:
> > Folks,
> >
> > We have some IPv6 related bugs [1,2,3] that have been lingering for some
> > time now. They have been hurting the gate (e.g. [4] the most recent
> > offending failure) and since it looks like they have been without owners
> > nor a plan of action for some time, I made the hard decision of skipping
> > them [5] ahead of the busy times ahead.
>
> So TBH I don't think the failure rate for these tests are really at a point
> necessitating a skip:
>
>
> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac
>
> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os
>
> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os
>
> (also just a cool side-note, you can see the very obvious performance
> regression
> caused by the keystonemiddleware release and when we excluded that version
> in
> requirements)
>
> Well, test_dualnet_dhcp6_stateless_from_os is kinda there with a ~10%
> failure
> rate, but the other 2 really aren't. I normally would be -1 on the skip
> patch
> because of that. We try to save the skips for cases where the bugs are
> really
> severe and preventing productivity at a large scale.
>

I am being overly aggressive here, just because I am conscious of the time
of the year :)


>
> But, in this case these ipv6 tests are kinda of out of place in tempest.
> Having
> all the permutations of possible ip allocation configurations always
> seemed a
> bit too heavy handed. These tests are also consistently in the top 10
> slowest
> for a run. We really should have trimmed down this set a while ago so
> we're only
> have a single case in tempest. Neutron should own the other possible
> configurations as an in-tree test.
>

+1


>
> Brian Haley has a patch up from Dec. that was trying to clean it up:
>
> https://review.openstack.org/#/c/239868/
>
> We probably should revisit that soon, since quite clearly no one is
> looking at
> these right now.
>
>
I thought that had merged already...my memory doesn't serve me as it used
to anymore :(


>
> -Matt Treinish
>
>
> >
> > Now one might argue that skipping them is counterproductive because it
> may
> > allow other regressions to sneak in, but I am hoping that this
> > controversial action will indeed smoke out the right folks.
> >
> > Comments welcome.
> >
> > Regards,
> > Armando
> >
> > [1] https://bugs.launchpad.net/neutron/+bug/1477192
> > [2] https://bugs.launchpad.net/neutron/+bug/1509004
> > [3] https://bugs.launchpad.net/openstack-gate/+bug/1540983
> > [4]
> >
> http://logs.openstack.org/37/264937/5/gate/gate-tempest-dsvm-neutron-full/afeaabd//logs/testr_results.html.gz
> > [5] https://review.openstack.org/#/c/275457/
>
>
> __
> 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] Drivers meeting cancelled Feb 25

[Armando M.]

Folks,

Just a reminder that due to the ongoing Neutron mid-cycle, the drivers team
is cancelled for this week.

We'll be sending out a report at the end of the week/early next week to
keep you abreast of the progress made.

Cheers,
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-dev] [Neutron] Gate failure

[Armando M.]

Folks,

The API job recent breakage prevents us from merging code. Please refrain
from pushing patches to the merge queue until [1] completes going through
the pipeline.

A.

[1] https://review.openstack.org/#/c/284911/
__
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] DocImpact flag: a kind reminder

[Armando M.]

Hi Neutrinos,

Please remember that what you decorate a commit message with DocImpact,
this must be followed by a brief description of the documentation impact
[1]. Also, please be aware that currently, as soon as the patch merges, a
bug report is filed against the Launchpad project of the targeted repo.
This is tagged with 'doc' and '' [2].

So, if you have a train of patches affecting the same feature (client side,
server side, *-aas projects etc), be mindful to where you put the tag and
avoid adding DocImpact to more than one commit message, unless the
documentation target is indeed meant to be separate.

Cheers,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080294.html
[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
__
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] DocImpact flag: a kind reminder

[Armando M.]

On 29 February 2016 at 15:34, Hirofumi Ichihara <
ichihara.hirof...@lab.ntt.co.jp> wrote:

> Hi Armando,
>
> I didn't know and I have such patch now.
> Thank you for your message.
>
> I have seen that neutron spec has the flag in the Commit Message.
> In such case, we don't need to add the flag into the implementation patch,
> do we?
>

I would not personally add a DocImpact on a spec patch.


>
> Thanks,
> Hirofumi
>
>
> On 2016/03/01 7:18, Armando M. wrote:
>
> Hi Neutrinos,
>
> Please remember that what you decorate a commit message with DocImpact,
> this must be followed by a brief description of the documentation impact
> [1]. Also, please be aware that currently, as soon as the patch merges, a
> bug report is filed against the Launchpad project of the targeted repo.
> This is tagged with 'doc' and '' [2].
>
> So, if you have a train of patches affecting the same feature (client
> side, server side, *-aas projects etc), be mindful to where you put the tag
> and avoid adding DocImpact to more than one commit message, unless the
> documentation target is indeed meant to be separate.
>
> Cheers,
> Armando
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080294.html
> [2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Mid-cycle report

[Armando M.]

Hi Neutrinos,

For those of you who couldn't join in person, please find a few notes below
to capture some of the highlights of the event.

I would like to thank everyone one who helped me put this report together,
and everyone who helped make this mid-cycle a fruitful one.

I would also like to thank IBM, and the individual organizers who made
everything go smoothly.

Feel free to reach out if something is unclear, incorrect or incomplete.

Cheers,
Armando

~~~

We touched on these topics (as initially proposed on
https://etherpad.openstack.org/p/neutron-mitaka-midcycle)

   - Neutron-lib: discussed strategy for taking base DB model and context
   code into neutron-lib and getting rid of common-db-mixin. More to
   follow/baking in
   - Routed-networks
  - Develpment started as per specification
  https://review.openstack.org/#/c/225384/. In particular:
  - Client patches
 - Segment extension
 - segments / host mapping
 - Troubleshooting
  - A number of proposals have been made over time, armax intends to
  push back on them all and invite the team to pause and think
about this as
  two separate problems, which are at two different level of
  abstractions/complexity. Neutron, like an automobile, needs a dashboard
  whose warning lights provide feedback to the operator; only once this is
  available, well understood and well documented, remedy actions and
  effective tools in the toolbox can be implemented/used when digging under
  the bonnet. We clearly have an inexistent or an inadequate dashboard so
  far; figuring out what this dashboard looks like should be the first step
  to improve operability of Neuton deployments. More to follow on
pending RFE
  bug.
 - https://bugs.launchpad.net/neutron/+bug/1507499
 - Some preliminary notes available at:
 https://etherpad.openstack.org/p/neutron-troubleshooting
 - Usability and stability fixes:
  - MTU cleanups: Implemented all MTU changes in Nova and Neutron
  required to fix the interface MTU setting mismatches identified
by Matt and
  Sean. Deprecated the old network device mtu option in Nova and Neutron.
  Started working on a patch to address an issue when tunnels are used over
  IPv6 endpoints since the additional 20 byte overhead is not accounted for.
 - https://bugs.launchpad.net/neutron/+bug/1542108
 - https://bugs.launchpad.net/neutron/+bug/1542475
 - https://review.openstack.org/#/c/283798/
 - https://review.openstack.org/#/c/285532/
 - https://review.openstack.org/#/c/284818/
 - https://review.openstack.org/#/c/283790/
 - https://review.openstack.org/#/c/284814/
  - L3 HA: Worked out some race conditions in L3 HA when the server is
  receiving lots of router creates/deletes for the same tenant and
pushed two
  patches to fix them.
 - https://review.openstack.org/#/c/282876/14
 - Reduce IP consumptions for router gateway ports (both DVR and
  non). carl_baldwin to put up model proposal, haleyb to follow up
with code.
   - CI jobs cleanup
  - Assaf and armax had a chat about the -plus job and the current
  marching order is:
  - keep the API job as is; in the medium term they would like to adopt
 the same approach taken by the functional job to streamline
the setup (e.g.
 setting up Keystone and Neutron only); this way they can cut
back on the
 time to feedback as far as API tests go.
 - continue to use the -plus job to run scenario tests, that
 requires the setup of an end-to-end cloud (Nova, Glance,
Keystone, Neutron,
 et al).
 - Keeping the two jobs separate should help better tolerate,
 identify and isolate potential intermittent failures induced
by scenario
 tests, by keeping the api job stable and on both check and gate queues.
 - Continue the de-fork effort
- https://review.openstack.org/#/c/280427/
- https://review.openstack.org/#/c/285116/
 - Nova integration aspects
  - Continued the conversation on get-me-a-network, thanks to Matt
  Riedemann for kickstarting the nova side of the effort
 - Nova spec: https://review.openstack.org/#/c/283206/
 - Neutron blueprint dashboard:
 https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
 - Documentation: https://review.openstack.org/#/c/283133/
 - Provide validation api to reduce amount of api calls to make
 between nova/neutron:
- https://review.openstack.org/#/c/283849/
- https://review.openstack.org/#/c/284307/
-  Made progress on Nova live migration with DVR patches,
 including removing a flaky tempest test from the gate when neutron is
 enabled.
 - Talked about cells v2 and what Neutron can do, if at all, to
 adopt the 

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

[Armando M.]

On 22 February 2016 at 04:56, Ihar Hrachyshka <ihrac...@redhat.com> wrote:

> Sean M. Collins <s...@coreitpro.com> wrote:
>
> Armando M. wrote:
>>
>>> Now that the blocking issue has been identified, I filed project-config
>>> change [1] to enable us to test the Neutron Grenade multinode more
>>> thoroughly.
>>>
>>> [1] https://review.openstack.org/#/c/282428/
>>>
>>
>>
>> Indeed - I want to profusely thank everyone that I reached out to during
>> these past months when I got stuck on this. Ihar, Matt K, Kevin B,
>> Armando - this is a huge win.
>>
>> --
>> Sean M. Collins
>>
>
> Thanks everyone to make that latest push. We are almost there!..
>
> I guess the next steps are:
> - monitoring the job for a week, making sure it’s stable enough (comparing
> failure rate to non-partial grenade job?);


Btw, the job trend is here:

http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=6

I'd prefer to wait a little longer. Depending on how things go we may want
to make it not until N opens up.


> - if everything goes fine, propose project-config change to make it voting;
> - propose governance patch to enable rolling-upgrade tag for neutron repo
> (I believe not for *aas repos though?).
>
> I guess with that we would be able to claim victory for the basic 'server
> vs. agent’ part of rolling scenario. Right?
>
> Follow up steps would probably be:
> - look at enabling partial job for DVR flavour;
>

That should be only instrumental to see how sane DVR during upgrades is,
and proceed in tweaking the existing grenade-multi job in the check queue
to be dvr-aware. In other words: I personally wouldn't want to see two
grenade jobs in the gate.


> - proceed on objectification of neutron db layer to open doors for later
> mixed server versions in the same cluster.
>
> Anything I missed?
>
> Also, what do we do with non-partial flavour of the job? Is it staying?


What job are you talking about exactly?


>
>
> 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] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

[Armando M.]

On 22 February 2016 at 08:52, Ihar Hrachyshka <ihrac...@redhat.com> wrote:

> Armando M. <arma...@gmail.com> wrote:
>
>
>>
>> On 22 February 2016 at 04:56, Ihar Hrachyshka <ihrac...@redhat.com>
>> wrote:
>> Sean M. Collins <s...@coreitpro.com> wrote:
>>
>> Armando M. wrote:
>> Now that the blocking issue has been identified, I filed project-config
>> change [1] to enable us to test the Neutron Grenade multinode more
>> thoroughly.
>>
>> [1] https://review.openstack.org/#/c/282428/
>>
>>
>> Indeed - I want to profusely thank everyone that I reached out to during
>> these past months when I got stuck on this. Ihar, Matt K, Kevin B,
>> Armando - this is a huge win.
>>
>> --
>> Sean M. Collins
>>
>> Thanks everyone to make that latest push. We are almost there!..
>>
>> I guess the next steps are:
>> - monitoring the job for a week, making sure it’s stable enough
>> (comparing failure rate to non-partial grenade job?);
>>
>> Btw, the job trend is here:
>>
>>
>> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=6
>>
>> I'd prefer to wait a little longer. Depending on how things go we may
>> want to make it not until N opens up.
>>
>
> Agreed.
>
>
>> - if everything goes fine, propose project-config change to make it
>> voting;
>> - propose governance patch to enable rolling-upgrade tag for neutron repo
>> (I believe not for *aas repos though?).
>>
>> I guess with that we would be able to claim victory for the basic 'server
>> vs. agent’ part of rolling scenario. Right?
>>
>> Follow up steps would probably be:
>> - look at enabling partial job for DVR flavour;
>>
>> That should be only instrumental to see how sane DVR during upgrades is,
>> and proceed in tweaking the existing grenade-multi job in the check queue
>> to be dvr-aware. In other words: I personally wouldn't want to see two
>> grenade jobs in the gate.
>>
>
> Ack, that would be the end goal. There still may be some short time when
> both are in gate.
>
>
>> - proceed on objectification of neutron db layer to open doors for later
>> mixed server versions in the same cluster.
>>
>> Anything I missed?
>>
>> Also, what do we do with non-partial flavour of the job? Is it staying?
>>
>> What job are you talking about exactly?
>>
>
> gate-grenade-dsvm-neutron
>
> It’s not ‘partial’ in that we don’t run mixed versions of components
> during tempest run. It only covers that new code can run using old
> configuration files, and that alembic migrations apply correctly for some
> limited number of so called ‘long standing’ resources like instances
> created on the ‘old’ side of grenade.


Yes, that is staying. Especially considering that's part of the integrate
gate on a bunch of other projects. We'll reconsider what to do, once we
strengthen our rolling upgrade story.


>
>
> 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] Gate failure

[Armando M.]

On 26 February 2016 at 11:43, Doug Wiegley <doug...@parksidesoftware.com>
wrote:

> This has merged, so you can resume your previously scheduled
> mad-merge-for-Mitaka and break it all again.
>

Assume this is the default behavior unless told otherwise. So, yes go nuts!

Cheers,
Armando


>
> Thanks,
> doug
>
> On Feb 25, 2016, at 2:46 PM, Armando M. <arma...@gmail.com> wrote:
>
> Folks,
>
> The API job recent breakage prevents us from merging code. Please refrain
> from pushing patches to the merge queue until [1] completes going through
> the pipeline.
>
> A.
>
> [1] https://review.openstack.org/#/c/284911/
> __
> 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] BGP Dynamic Routing Development Going Forward

[Armando M.]

On 22 January 2016 at 08:57, Tidwell, Ryan  wrote:

> I wanted to raise the question of whether to develop BGP dynamic routing
> in the Neutron repo or spin it out to as a stadium project.  This question
> has been raised recently on reviews and in offline discussions.  For those
> unfamiliar with this work, BGP efforts in Neutron entail admin-only API’s
> for configuring and propagating BGP announcements of next-hops for floating
> IP’s, tenant networks, and host routes for each compute port when using
> DVR.  As we are getting late in the Mitaka cycle, I would like to be sure
> there is consensus on the approach for Mitaka.  As I see it, we have 3
> courses of action:
>
> 1. Continue with development in the main repo without any intention of
> spinning out to a stadium project
>
> 2. Continue on the current development course for Mitaka while targeting a
> spin-out to a stadium project during the N cycle
>
> 3. Spin out to a stadium project immediately
>
>
>
> Each has pros and cons.  This question seems to have arisen while looking
> at the sheer amount code being proposed, its place in the Neutron model,
> and questioning whether we really want to bring that code into Neutron.  As
> such, continuing with option 1 definitely requires us to come to some
> consensus.  Let me be clear that I’m not opposed to any of these options,
> I’m simply looking for some guidance.  With that said, if the end game is a
> stadium project I do question whether #2 makes sense.
>

Not sure if you followed the latest discussion on [1,2] ([1] capturing the
latest events). Delivering something production worthy goes a lot more
beyond simply posting code upstream. We, as a community, have promised to
deliver BGP capabilities for many cycles, and failed so far. Choosing 3 is
clearly going to defer this to N or even O because of the amount of effort
required to set it all up (release, docs, testing, etc). Option 2, as
painful as it may sound, gives us the ability to get immediate access to
all that's required to deliver something to users so that they can play
with it at the end of Mitaka if they choose to. In the meantime that will
give us some breathing room to get ready as soon as N opens up.

I am operating under the assumption that what you guys have been working on
is close to being functionally complete. If we don't even have that, then
we're in trouble no matter which option we choose and we can defer this yet
again :/

Having said that, we can all agree that option #1 is not what we all want.
Just to be clear, I am in favor of #2.

Cheers,
Armando

[1] https://review.openstack.org/#/c/268727/
[2] https://review.openstack.org/#/c/268726/


>
>
> -Ryan
>
>
>
> https://review.openstack.org/#/c/201621/
>
> https://review.openstack.org/#/q/topic:bp/bgp-dynamic-routing
>
>
>
> __
> 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] BGP Dynamic Routing Development Going Forward

[Armando M.]

On 25 January 2016 at 08:23, Tidwell, Ryan <ryan.tidw...@hpe.com> wrote:

> Responses inline
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Friday, January 22, 2016 9:49 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron] BGP Dynamic Routing Development
> Going Forward
>
>
>
> The real question that needs to be asked (at least for me) is how this
> feature can work with other plugins/ML2 drivers
>
> that are not the reference implementation.
>
>
>
> -  Regardless of the ML2 drivers you use, ML2 is
> supported with the reference implementation.  The code we have only works
> with ML2 though, which is a concern for putting this in the main repo.
>
>
>
> How hard (possible) it is to take the API part (or maybe even the agent)
> and use that in another Neutron implementation.
>
> Then focus on which ever option that works best to achieve this.
>
>
>
> -  The agent is actually very portable in my opinion.  The
> server-side code is not so portable, as mentioned above only ML2 is
> supported.  Identifying next-hops is done by querying the DB, it’s hard to
> make that portable between plugins.
>
>
>
> I personally think that if the long term goal is to have this in a
> separate repo then this should happen right now.
>
> "We will do this later" just won't work, it will be harder and it will
> just not happen (or it will cause a lot of pain to people
>
> that started deploying this)
>
> At least thats my opinion, of course it depends a lot on the people who
> actually work on this...
>
>
>
> -  I completely agree which is why I’m not too
> excited about deferring a split.  It doesn’t really set us back in our
> development efforts to move out to a separate repo.  We’re quickly closing
> in on being functionally complete and this code peels out of the main repo
> rather cleanly, so I feel we really lose nothing by just moving to out of
> the main repo immediately if that’s the direction we go for the long haul.
> As you point out it saves users some pain in during a future upgrade.
>

In my humble opinion, you should get yourselves be guided by the ones who
have the most hands-on experience with the Neutron codebase. By all means,
we do make mistakes, but we're the ones who have been dealing with the
hurdles caused by those mistakes. If we advised you for a strategy, then
this strategy is most likely the direct consequence of a past/ongoing
experience; if you continue ignoring this simple fact in your judgement,
then this discussion is pointless.

>
>
> Gal.
>
>
>
> On Sat, Jan 23, 2016 at 2:15 AM, Vikram Choudhary <viks...@gmail.com>
> wrote:
>
> I agree with Armando and feel option 2 would be viable if we really want
> to deliver this feature in Mitaka time frame. Adding a new stadium project
> invites more work and can be done in N release.
>
> Thanks
> Vikram
>
> On Jan 22, 2016 11:47 PM, "Armando M." <arma...@gmail.com> wrote:
>
>
>
>
>
> On 22 January 2016 at 08:57, Tidwell, Ryan <ryan.tidw...@hpe.com> wrote:
>
> I wanted to raise the question of whether to develop BGP dynamic routing
> in the Neutron repo or spin it out to as a stadium project.  This question
> has been raised recently on reviews and in offline discussions.  For those
> unfamiliar with this work, BGP efforts in Neutron entail admin-only API’s
> for configuring and propagating BGP announcements of next-hops for floating
> IP’s, tenant networks, and host routes for each compute port when using
> DVR.  As we are getting late in the Mitaka cycle, I would like to be sure
> there is consensus on the approach for Mitaka.  As I see it, we have 3
> courses of action:
>
> 1. Continue with development in the main repo without any intention of
> spinning out to a stadium project
>
> 2. Continue on the current development course for Mitaka while targeting a
> spin-out to a stadium project during the N cycle
>
> 3. Spin out to a stadium project immediately
>
>
>
> Each has pros and cons.  This question seems to have arisen while looking
> at the sheer amount code being proposed, its place in the Neutron model,
> and questioning whether we really want to bring that code into Neutron.  As
> such, continuing with option 1 definitely requires us to come to some
> consensus.  Let me be clear that I’m not opposed to any of these options,
> I’m simply looking for some guidance.  With that said, if the end game is a
> stadium project I do question whether #2 makes sense.
>
>
>
> Not sure if you followed the latest discussion on [1,2] ([1] capturing

Re: [openstack-dev] [Neutron][[Infra] Gate failure

[Armando M.]

On 19 January 2016 at 17:53, Robert Collins <robe...@robertcollins.net>
wrote:

> I suspect we'll see fallout in unit tests too, once new images are built.
>

Thanks for the quick feedback. I knew people were already on top of it!

Cheers,
Armando


>
> On 20 January 2016 at 14:47, Davanum Srinivas <dava...@gmail.com> wrote:
> > https://review.openstack.org/#/c/269954/ is the plan of action.
> > @mtreinish is driving it. Plan is to request infra to promote it once
> > it passes check. This is not a neutron only break. it breaks all dsvm
> > jobs.
> >
> > -- Dims
> >
> > On Tue, Jan 19, 2016 at 8:28 PM, Armando M. <arma...@gmail.com> wrote:
> >> Hi neutrinos,
> >>
> >> New week, new gate failure. This time this might be infra related [1].
> This
> >> one fails with [2]. If you know what's going on, spread the word!
> >>
> >> Cheers,
> >> Armando
> >>
> >> [1] https://review.openstack.org/#/c/269937/
> >> [2]
> >>
> http://logs.openstack.org/37/269937/1/check/gate-tempest-dsvm-neutron-full/a91b641/logs/devstacklog.txt.gz#_2016-01-20_01_12_41_571
> >>
> >>
> __
> >> 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
> >>
> >
> >
> >
> > --
> > Davanum Srinivas :: https://twitter.com/dims
> >
> >
> __
> > 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
>
>
>
> --
> Robert Collins <rbtcoll...@hpe.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __
> 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

[Armando M.]

On 20 January 2016 at 08:20, Edgar Magana  wrote:

> Just providing support for Kyle’s proposal!
> It is working very well for other teams such as nova, docs between others.
>

At risk of stating the obvious, not every project is equal, and as I
mentioned in an earlier response, I have always been skeptical of the
double schedule because a) numbers haven't proven the overwhelming
attendance and b) the agenda is set on a weekly basis and certain topics
are only discussed during one of the meetings.

That said, I welcome anyone willing to step up and co-chair the Tuesday
meetings. Feel free to post a patch on irc-meetings and I'd be happy to
bless it.

Cheers,
Armando


> Edgar
>
>
>
>
> On 1/20/16, 3:55 AM, "Rossella Sblendido"  wrote:
>
> >
> >
> >On 01/19/2016 05:14 PM, 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.
> >
> >You are right Ihar, I misread. I like Kyle's proposal better too.
> >
> >Rossella
> >
> >>
> >> 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.
> >>
> >> 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
>
__
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] Drivers meeting calendar update

[Armando M.]

Hi folks,

At request of a team member, we've been looking into other time slots [1]

I am afraid, there is no way we can please everyone, and we may want to
revise the slot in function of the location of the team members in the
future.

Let me remind that we look at team membership [2] regularly to make sure we
have enough commitment from all parties involved, and when people from
different timezone get involved, we'll have to inevitably revise the slot
again.

Cheers,
Armando

[1] https://review.openstack.org/#/c/269780/
[2] https://review.openstack.org/#/admin/groups/464,members
__
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] [keystone][neutron][requirements] - keystonemiddleware-4.1.0 performance regression

[Armando M.]

On 19 January 2016 at 22:46, Kevin Benton  wrote:

> Hi all,
>
> We noticed a major jump in the neutron tempest and API test run times
> recently in Neutron. After digging through logstash I found out that it
> first occurred on the requirements bump here:
> https://review.openstack.org/#/c/265697/
>
> After locally testing each requirements change individually, I found that
> the keystonemiddleware change seems to be the culprit. It almost doubles
> the time it takes to fulfill simple port-list requests in Neutron.
>
> Armando pushed up a patch here to confirm:
> https://review.openstack.org/#/c/270024/
> Once that's verified, we should probably put a cap on the middleware
> because it's causing the tests to run up close to their time limits.
>

Kevin,

As usual your analytical skills are to be praised.

I wonder if anyone else is aware of the issue/s, because during the usual
hunting I could see other projects being affected and showing abnormally
high run times of the dsvm jobs.

I am not sure that [1] is the right approach, but it should give us some
data points if executed successfully.

Cheers,
Armando

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


> --
> Kevin Benton
>
> __
> 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] [keystone][neutron][requirements] - keystonemiddleware-4.1.0 performance regression

[Armando M.]

On 19 January 2016 at 23:11, Steve Martinelli <steve...@ca.ibm.com> wrote:

> Hmm, looking at:
> https://github.com/openstack/keystonemiddleware/compare/4.0.0...4.1.0 the
> only change that I can think of that might be the culprit is:
> https://github.com/openstack/keystonemiddleware/commit/f27d7f776e8556d976f75d07c99373455106de52
>
> I'll dig into this some more soon, but it might be worth trying things out
> with that commit reverted.
>

Unfortunately patch [1] didn't have any effect. So I am trying with [2].

[1] https://review.openstack.org/#/c/270024/
[2] https://review.openstack.org/#/c/270417/

>
>
> stevemar
>
> [image: Inactive hide details for "Armando M." ---2016/01/20 01:59:44
> AM---On 19 January 2016 at 22:46, Kevin Benton <blak...@gmail.com]"Armando
> M." ---2016/01/20 01:59:44 AM---On 19 January 2016 at 22:46, Kevin Benton <
> blak...@gmail.com> wrote: > Hi all,
>
> From: "Armando M." <arma...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 2016/01/20 01:59 AM
> Subject: Re: [openstack-dev] [keystone][neutron][requirements] -
> keystonemiddleware-4.1.0 performance regression
> --
>
>
>
>
>
> On 19 January 2016 at 22:46, Kevin Benton <*blak...@gmail.com*
> <blak...@gmail.com>> wrote:
>
>Hi all,
>
>We noticed a major jump in the neutron tempest and API test run times
>recently in Neutron. After digging through logstash I found out that it
>first occurred on the requirements bump here:
>*https://review.openstack.org/#/c/265697/*
><https://review.openstack.org/#/c/265697/>
>
>After locally testing each requirements change individually, I found
>that the keystonemiddleware change seems to be the culprit. It almost
>doubles the time it takes to fulfill simple port-list requests in Neutron.
>
>Armando pushed up a patch here to confirm:
>*https://review.openstack.org/#/c/270024/*
><https://review.openstack.org/#/c/270024/>
>Once that's verified, we should probably put a cap on the middleware
>because it's causing the tests to run up close to their time limits.
>
>
> Kevin,
>
> As usual your analytical skills are to be praised.
>
> I wonder if anyone else is aware of the issue/s, because during the usual
> hunting I could see other projects being affected and showing abnormally
> high run times of the dsvm jobs.
>
> I am not sure that [1] is the right approach, but it should give us some
> data points if executed successfully.
>
> Cheers,
> Armando
>
> [1]  *https://review.openstack.org/#/c/270024/*
> <https://review.openstack.org/#/c/270024/>
>
>
>--
>Kevin Benton
>
>
>__
>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*
><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] Mitaka-2

[Armando M.]

Hi neutrinos,

The release patch [1] has landed.

The existing workload for the remainder of the cycle is tracked in [2]. If
you have something shown on this dashboard (or if you don't, but you want
to), please reach out either via ML (on this thread) or on
#openstack-neutron.

Cheers,
Armando

[1] https://review.openstack.org/#/c/269265/
[2] https://launchpad.net/neutron/+milestone/mitaka-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

Re: [openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

[Armando M.]

On 22 January 2016 at 10:35, Neil Jerram  wrote:

> networking-calico [1] is currently implemented as an ML2 mechanism
> driver, but
> I'm wondering if it might be better as its own core plugin, and I'm
> looking for
> input about the implications of that, or for experience with that kind of
> change; and also for experience and understanding of hybrid ML2
> networking.
>
> Here the considerations that I'm aware of:
>
> * Why change from ML2 to core plugin?
>
> - It could be seen as resolving a conceptual mismatch.
> networking-calico uses
>   IP routing to provide L3 connectivity between VMs, whereas ML2 is
> ostensibly
>   all about layer 2 mechanisms.  Arguably it's the Wrong Thing for a
> L3-based
>   network to be implemented as an ML2 driver, and changing to a core plugin
>   would fix that.
>
>   On the other hand, the current ML2 implementation seems to work fine,
> and I
>   think that the L2 focus of ML2 may be seen as traditional assumption just
>   like the previously assumed L2 semantics of neutron Networks; and it
> may be
>   that the scope of 'ML2' could and should be expanded to both L2- and
> L3-based
>   implementations, just as [2] is proposing to expand the scope of the
> neutron
>   Network object to encompass L3-only behaviour as well as L2/L3.
>
> - Some simplification of the required config.  A single 'core_plugin =
> calico'
>   setting could replace 'core_plugin = ml2' plus a handful of ML2 settings.
>
> - Code-wise, it's a much smaller change than you might imagine, because
> the new
>   core plugin can still derive from ML2, and so internally retain the ML2
>   coding architecture.
>
> * Why stay as an ML2 driver?
>
> - Perhaps because of ML2's support for multiple networking
> implementations in
>   the same cluster.  To the extent that it makes sense, I'd like
>   networking-calico networks to coexist with other networking
> implementations
>   in the same data center.
>
>   But I'm not sure to what extent such hybrid networking is a real
> thing, and
>   this is the main point on which I'd appreciate input.  In principle ML2
>   supports multiple network Types and multiple network Mechanisms, but I
> wonder
>   how far that really works - or is useful - in practice.
>
>   Let's look at Types first.  ML2 supports multiple provider network types,
>   with the Type for each network being specified explicitly by the
> provider API
>   extension (provider:network_type), or else defaulting to the
>   'external_network_type' ML2 config setting.  However, would a cloud
> operator
>   ever actually use more than one provider Type?  My understanding is that
>   provider networks are designed to map closely onto the real network, and
> I
>   guess that an operator would also favour a uniform design there, hence
> just
>   using a single provider network Type.
>
>   For tenant networks ML2 allows multiple network Types to be configured
> in the
>   'tenant_network_types' setting.  However, if my reading of the code is
>   correct, only the first of these Types will ever be used for a tenant
> network
>   - unless the system runs out of the 'resources' needed for that Type, for
>   example if the first Type is 'vlan' but there are no VLAN IDs left to
> use.
>   Is that a feature that is used in practice, within a given
> deployment?  For
>   exampe, to first use VLANs for tenant networks, then switch to
> something else
>   when those run out?
>
>   ML2 also supports multiple mechanism drivers.  When a new Port is being
>   created, ML2 calls each mechanism driver to give it the chance to do
> binding
>   and connectivity setup for that Port.  In principle, if mechanism
> drivers are
>   present, I guess each one is supposed to look at some of the available
> Port
>   data - and perhaps the network Type - and thereby infer whether it
> should be
>   responsible for that Port, and so do the setup for it.  But I wonder if
>   anyone runs a cloud where that really happens?  If so, have I got it
> right?
>

Have you consider asking these questions to your 'customers'? They are the
ones you should listen to :)

Ultimately both choices are reasonably valid and both have pros and cons:
moving away from ML2 frees you up and let you be fully in control but
you'll lose access to compl(i|e)mentary L2 and L3 services. Do you need
those? That's up to you and/or your customers. There's no right nor wrong,
but knowing that calico has an already unique relationship with Neutron
(which you worked hard to nail down) and the ongoing effort [1], perhaps
it's safer to stay put for a cycle and see how that plays out.

OVN went down the same decision making process, you may want to reach out
to those folks to see what their opinion was, and reconsider the urgency of
the switch.

Should you switch, you should also take in consideration the cost of
migrating (if you have existing deployments).

Cheers,
Armando

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


>
> All in all, if hybrid 

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

[Armando M.]

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 discussion. More details on [1].

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-dev] [Neutron][[Infra] Gate failure

[Armando M.]

Hi neutrinos,

New week, new gate failure. This time this might be infra related [1]. This
one fails with [2]. If you know what's going on, spread the word!

Cheers,
Armando

[1] https://review.openstack.org/#/c/269937/
[2]
http://logs.openstack.org/37/269937/1/check/gate-tempest-dsvm-neutron-full/a91b641/logs/devstacklog.txt.gz#_2016-01-20_01_12_41_571
__
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] Check queue broken on master

[Armando M.]

Hi folks,

It looks like something slipped in and how we got persistent failures on
functional/fullstack jobs [1]. Has anyone triaged? I couldn't find anything
in [2].

The effect for this: we can't merge anything until this gets resolved. Some
might argue this is not necessarily a bad thing...

Cheers,
Armando

[1]
http://docs.openstack.org/developer/neutron/dashboards/check.dashboard.html
[2]
https://bugs.launchpad.net/neutron/+bugs?field.tag=gate-failure=-datecreated=0
__
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] Check queue broken on master

[Armando M.]

On 17 February 2016 at 11:12, Armando M. <arma...@gmail.com> wrote:

> Hi folks,
>
> It looks like something slipped in and how we got persistent failures on
> functional/fullstack jobs [1]. Has anyone triaged? I couldn't find anything
> in [2].
>

Looks like [1] fixed it. Thanks Assaf.

Be safe outta there. It's a scary world.


[1] https://bugs.launchpad.net/neutron/+bug/1546506


> The effect for this: we can't merge anything until this gets resolved.
> Some might argue this is not necessarily a bad thing...
>
> Cheers,
> Armando
>
> [1]
> http://docs.openstack.org/developer/neutron/dashboards/check.dashboard.html
> [2]
> https://bugs.launchpad.net/neutron/+bugs?field.tag=gate-failure=-datecreated=0
>
__
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] Check queue broken on master

[Armando M.]

On 17 February 2016 at 11:22, Assaf Muller <amul...@redhat.com> wrote:

> On Wed, Feb 17, 2016 at 2:16 PM, Armando M. <arma...@gmail.com> wrote:
> >
> >
> > On 17 February 2016 at 11:12, Armando M. <arma...@gmail.com> wrote:
> >>
> >> Hi folks,
> >>
> >> It looks like something slipped in and how we got persistent failures on
> >> functional/fullstack jobs [1]. Has anyone triaged? I couldn't find
> anything
> >> in [2].
> >
> >
> > Looks like [1] fixed it. Thanks Assaf.
>
> You mean thanks Jakub!
>

Indeed, sorry I am clearly still sleeping this morning.


>
> >
> > Be safe outta there. It's a scary world.
> >
> >
> > [1] https://bugs.launchpad.net/neutron/+bug/1546506
> >
> >>
> >> The effect for this: we can't merge anything until this gets resolved.
> >> Some might argue this is not necessarily a bad thing...
> >>
> >> Cheers,
> >> Armando
> >>
> >> [1]
> >>
> http://docs.openstack.org/developer/neutron/dashboards/check.dashboard.html
> >> [2]
> >>
> https://bugs.launchpad.net/neutron/+bugs?field.tag=gate-failure=-datecreated=0
> >
> >
> >
> >
> __
> > 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] [nova][neutron][upgrade] Grenade multinode partial upgrade

[Armando M.]

On 18 February 2016 at 08:41, Sean M. Collins  wrote:

> This week's update:
>
> Armando was kind enough to take a look[1], since he's got a fresh
> perspective. I think I've been suffering from Target Fixation[1]
> where I failed to notice a couple other failures in the logs.
>

It's been fun, and I am glad I was able to help. Once I validated the root
cause of the metadata failure [1], I got run [2] and a clean pass in [3] :)

There are still a few things to iron out, ie. choosing metadata over
config-drive, testing both in the gate etc. But that's for another day.

Cheers,
Armando

[1] https://bugs.launchpad.net/nova/+bug/1545101/comments/4
[2]
http://logs.openstack.org/00/281600/6/experimental/gate-grenade-dsvm-neutron-multinode/40e16c8/
[3]
http://logs.openstack.org/00/281600/6/experimental/gate-grenade-dsvm-neutron-multinode/40e16c8/logs/testr_results.html.gz



>
> For example - during the SSH test into the instances, we are able to get
> a full SSH handshake and offer up the SSH key, however authentication
> fails[3], apparently due to the fact that the instance is not successful
> in contacting the metadata service and getting the SSH public key[4].
>
> So, I think the next bit of work is to track down why the metadata
> service isn't functioning properly. We pinged Matt Riedemann about one
> error we saw over in the nova metadata service, however he had seen it
> before us and already wrote a fix[5].
>
> That's the status of where things stand. Metadata service being broken,
> and also still MTU issues lurking in the background.
>
> [1]:
> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-02-18.log.html#t2016-02-18T00:26:29
> [2]: https://en.wikipedia.org/wiki/Target_fixation
> [3]:
> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-02-18.log.html#t2016-02-18T01:18:32
> [4]:
> http://logs.openstack.org/78/279378/9/experimental/gate-grenade-dsvm-neutron-multinode/40a5659/console.html#_2016-02-17_22_37_33_277
> [5]: https://review.openstack.org/#/c/279721/
> --
> 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] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

[Armando M.]

On 19 February 2016 at 04:43, Sean Dague <s...@dague.net> wrote:

> On 02/18/2016 09:50 PM, Armando M. wrote:
> >
> >
> > On 18 February 2016 at 08:41, Sean M. Collins <s...@coreitpro.com
> > <mailto:s...@coreitpro.com>> wrote:
> >
> > This week's update:
> >
> > Armando was kind enough to take a look[1], since he's got a fresh
> > perspective. I think I've been suffering from Target Fixation[1]
> > where I failed to notice a couple other failures in the logs.
> >
> >
> > It's been fun, and I am glad I was able to help. Once I validated the
> > root cause of the metadata failure [1], I got run [2] and a clean pass
> > in [3] :)
> >
> > There are still a few things to iron out, ie. choosing metadata over
> > config-drive, testing both in the gate etc. But that's for another day.
> >
> > Cheers,
> > Armando
> >
> > [1] https://bugs.launchpad.net/nova/+bug/1545101/comments/4
> > [2]
> http://logs.openstack.org/00/281600/6/experimental/gate-grenade-dsvm-neutron-multinode/40e16c8/
> > [3]
> http://logs.openstack.org/00/281600/6/experimental/gate-grenade-dsvm-neutron-multinode/40e16c8/logs/testr_results.html.gz
>
> I want to thank everyone that's been working on this issue profusely.
> This exposed a release critical bug in Nova that we would not have
> caught otherwise. Finding that before milestone 3 is a huge win and
> gives us a lot more options in fixing it correctly.
>
> I think we've got the proper fix now -
> https://review.openstack.org/#/c/279721/ (fingers crossed). The metadata
> server is one of the least tested components we've got on the Nova side,
> so I'll be looking at ways to fix that problem and hopefully avoid
> situations like this again.
>

Now that the blocking issue has been identified, I filed project-config
change [1] to enable us to test the Neutron Grenade multinode more
thoroughly.

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


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] next Team meeting cancelled (Feb-22)

[Armando M.]

Hi Neutrinos,

This week is Mid-cycle week [1], and some of us will be potentially enroute
to the destination. For this reason, the meeting is cancelled.

If you're interested in participating remotely, please keep an eye on the
etherpad for updates.

Cheers,
Armando

[1] https://etherpad.openstack.org/p/neutron-mitaka-midcycle
__
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] How would nova microversion get-me-a-network in the API?

[Armando M.]

On 19 February 2016 at 09:49, John Garbutt  wrote:

> On 19 February 2016 at 16:28, Andrew Laski  wrote:
> > On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote:
> >> On 02/19/2016 09:30 AM, Andrew Laski wrote:
> >> >
> >> >
> >> > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote:
> >> >> On Feb 12, 2016, at 14:49, Jay Pipes  wrote:
> >> >>
> >> >>> This would be my preference as well, even though it's technically a
> backwards-incompatible API change.
> >> >>>
> >> >>> The idea behind get-me-a-network was specifically to remove the
> current required complexity of the nova boot command with regards to
> networking options and allow a return to the nova-net model where an admin
> could auto-create a bunch of unassigned networks and the first time a user
> booted an instance and did not specify any network configuration (the
> default, sane behaviour in nova-net), one of those unassigned networks
> would be grabbed for the troject, I mean prenant, sorry.
> >> >>>
> >> >>> So yeah, the "opt-in to having no networking at all with a
> --no-networking or --no-nics option" would be my preference.
> >> >>
> >> >> +1 to this, especially opting in to have no network at all. It seems
> most
> >> >> friendly to me to have the network allocation automatically happen if
> >> >> nothing special is specified.
> >> >>
> >> >> This is something where it seems like we need a "reset" to a default
> >> >> behavior that is user-friendly. And microversions is the way we have
> to
> >> >> "fix" an undesirable current default behavior.
> >> >
> >> > The question I would still like to see addressed is why do we need to
> >> > have a default behavior here? The get-me-a-network effort is motivated
> >> > by the current complexity of setting up a network for an instance
> >> > between Nova and Neutron and wants to get back to a simpler time of
> >> > being able to just boot an instance and get a network. But it still
> >> > isn't clear to me why requiring something like "--nic auto" wouldn't
> >> > work here, and eliminate the confusion of changing a default behavior.
> >>
> >> The point was the default behavior was a major concern to people. It's
> >> not like this was always the behavior. If you were (or are) on nova net,
> >> you don't need that option at all.
> >
> > Which is why I would prefer to shy away from default behaviors.
> >
> >>
> >> The major reason we implemented API microversions was so that we could
> >> make the base API experience better for people, some day. One day, we'll
> >> have an API we love, hopefully. Doing so means that we do need to make
> >> changes to defaults. Deprecate some weird and unmaintained bits.
> >>
> >> The principle of least surprise to me is that you don't need that
> >> attribute at all. Do the right thing with the least amount of work.
> >> Instead of making the majority of clients and users do extra work
> >> because once upon a time when we brought in neutron a thing happen.
> >
> > The principal of least surprise to me is that a user explicitly asks for
> > something rather than relying on a default that changes based on network
> > service and/or microversion. This is the only area in the API where
> > something did, and would, happen without explicitly being requested by a
> > user. I just don't understand why it's special compared to
> > flavor/image/volume which we require to be explicit. But I think we just
> > need to agree to disagree here.
>
> Consider a user that uses these four clouds:
> * nova-network flat DHCP
> * nova-network VLAN manager
> * neutron with a single provider network setup
> * neutron where user needs to create their own network
>
> For the first three, the user specifies no network, and they just get
> a single NIC with some semi-sensible IP address, likely with a gateway
> to the internet.
>
> For the last one, the user ends up with a network with zero NICs. If
> they then go and configure a network in neutron (and they can now use
> the new easy one shot give-me-a-network CLI), they start to get VMs
> just like they would have with nova-network VLAN manager.
>
> We all agree the status quo is broken. For me, this is a bug in the
> API where we need to fix the consistency. Because its a change in the
> behaviour, it needs to be gated by a micro version.
>
> Now, if we step back and created this again, I would agree that
> --nic=auto is a good idea, so its explicit. However, all our users are
> used to automatic being the default, all be it a very patchy default.
> So I think the best evolution here is to fix the inconsistency by
> making a VM with no network being the explicit option (--no-nic or
> something?), and failing the build if we are unable to get a nic using
> an "automatic guess" route. So now the default is more consistent, and
> those that what a VM with no NIC have a way to get their special case
> sorted.
>

As much as I can see why a '--nic auto' option makes sense to some, 

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

[Armando M.]

On 20 February 2016 at 12:58, Steven Dake (stdake)  wrote:

> Neutron, the largest project in OpenStack by active committers and
> reviewers as measured by the governance repository teamstats tool, has a
> limit of 2 core reviewers per company.  They do that for a reason.  I
> expect Kolla will grow over time (we are about 1/4 their size in terms of
> contributors and reviewers).  I believe other projects follow a similar
> pattern besides Neutron that already have good diversity (and intend to
> keep it in place).
>

Where did you find this information? I do not believe this is true. I agree
wholeheartedly with Joshua: I personally value the judgement of the people
I trust rather than looking at affiliation.


>
> Regards
> -steve
>
>
> From: Gal Sagie 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Saturday, February 20, 2016 at 10:38 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer
> limitations by company
>
> I think setting these limits is wrong, some companies have more overall
> representation then others.
> The core reviewer job should be on a personal basis and not on a company
> basis, i think the PTL of each project needs
> to make sure the diversity and the community voice is heard in each
> project and the correct path is taken even if
> many (or even if all) of the cores are from the same company.
> If you really want to set limits then i would go with something like 2
> cores from the same company cannot +2 the same patch, but
> again i am against such things personally..
>
> Disclaimer: i am not personally involved in Kolla or know how things are
> running there.
>
> On Sat, Feb 20, 2016 at 7:09 PM, Steven Dake (stdake) 
> wrote:
>
>> Hey folks,
>>
>> Mirantis has been developing a big footprint in the core review team, and
>> Red Hat already has a big footprint in the core review team.  These are all
>> good things, but I want to avoid in the future a situation in which one
>> company has a majority of core reviewers.  Since core reviewers set policy
>> for the project, the project could be harmed if one company has such a
>> majority.  This is one reason why project diversity is so important and has
>> its own special snowflake tag in the governance repository.
>>
>> I'd like your thoughts on how to best handle this situation, before I
>> trigger  a vote we can all agree on.
>>
>> I was thinking of something simple like:
>> "1 company may not have more then 33% of core reviewers.  At the
>> conclusion of PTL elections, the current cycle's 6 months of reviews
>> completed will be used as a metric to select the core reviewers from that
>> particular company if the core review team has shrunk as a result of
>> removal of core reviewers during the cycle."
>>
>> Thoughts, comments, questions, concerns, etc?
>>
>> Regards,
>> -steve
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> 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] [kolla] discussion about core reviewer limitations by company

[Armando M.]

On 20 February 2016 at 14:06, Kevin Benton  wrote:

> I don't think neutron has a limit. There are 4 from redhat and 3 from hp
> and mirantis right now.
> https://review.openstack.org/#/admin/groups/38,members
>

By the way, technically speaking some of those also only limit themselves
the right to merge to their area of expertise.


> On Feb 20, 2016 13:02, "Steven Dake (stdake)"  wrote:
>
>> Neutron, the largest project in OpenStack by active committers and
>> reviewers as measured by the governance repository teamstats tool, has a
>> limit of 2 core reviewers per company.  They do that for a reason.  I
>> expect Kolla will grow over time (we are about 1/4 their size in terms of
>> contributors and reviewers).  I believe other projects follow a similar
>> pattern besides Neutron that already have good diversity (and intend to
>> keep it in place).
>>
>> Regards
>> -steve
>>
>>
>> From: Gal Sagie 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Saturday, February 20, 2016 at 10:38 AM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer
>> limitations by company
>>
>> I think setting these limits is wrong, some companies have more overall
>> representation then others.
>> The core reviewer job should be on a personal basis and not on a company
>> basis, i think the PTL of each project needs
>> to make sure the diversity and the community voice is heard in each
>> project and the correct path is taken even if
>> many (or even if all) of the cores are from the same company.
>> If you really want to set limits then i would go with something like 2
>> cores from the same company cannot +2 the same patch, but
>> again i am against such things personally..
>>
>> Disclaimer: i am not personally involved in Kolla or know how things are
>> running there.
>>
>> On Sat, Feb 20, 2016 at 7:09 PM, Steven Dake (stdake) 
>> wrote:
>>
>>> Hey folks,
>>>
>>> Mirantis has been developing a big footprint in the core review team,
>>> and Red Hat already has a big footprint in the core review team.  These are
>>> all good things, but I want to avoid in the future a situation in which one
>>> company has a majority of core reviewers.  Since core reviewers set policy
>>> for the project, the project could be harmed if one company has such a
>>> majority.  This is one reason why project diversity is so important and has
>>> its own special snowflake tag in the governance repository.
>>>
>>> I'd like your thoughts on how to best handle this situation, before I
>>> trigger  a vote we can all agree on.
>>>
>>> I was thinking of something simple like:
>>> "1 company may not have more then 33% of core reviewers.  At the
>>> conclusion of PTL elections, the current cycle's 6 months of reviews
>>> completed will be used as a metric to select the core reviewers from that
>>> particular company if the core review team has shrunk as a result of
>>> removal of core reviewers during the cycle."
>>>
>>> Thoughts, comments, questions, concerns, etc?
>>>
>>> Regards,
>>> -steve
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> 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] [ipam] Migration to pluggable IPAM

[Armando M.]

On 10 February 2016 at 15:19, Carl Baldwin <c...@ecbaldwin.net> wrote:

> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <arma...@gmail.com> wrote:
> > Technically we can make this as sophisticated and seamless as we want,
> but
> > this is a one-off, once it's done the pain goes away, and we won't be
> doing
> > another migration like this ever again. So I wouldn't over engineer it.
>
> Frankly, I was worried that going the other way was over-engineering
> it.  It will be more difficult for us to manage this transition.
>
> I'm still struggling to see what makes this particular migration
> different than other cases where we change the database schema and the
> code a bit and we automatically migrate everyone to it as part of the
> routine migration.  What is it about this case that necessitates
> giving the operator the option?
>

I believe we have more recovery options out a potentially fatal situation.
In fact the offline script can provide a dry-run option that can just
validate that the migration will succeed before it is even actually
performed; I think that the size and the amount of tables involved in the
data migration justifies this course of action rather than the other. Think
about what Sean said, bugs are always lurking in the dark and as much as we
can strive for correctness, things might go bad. This is not a routine
migration and some operators may not be in a rush to embrace pluggable
IPAM, hence I don't think we are in the position to make the decision on
their behalf and go through the usual fast-path deprecation process.


>
> Carl
>
> __
> 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] Migration to pluggable IPAM

[Armando M.]

On 11 February 2016 at 07:01, John Belamaric <jbelama...@infoblox.com>
wrote:

>
>
> ---
> John Belamaric
> (240) 383-6963
>
> > On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka <ihrac...@redhat.com>
> wrote:
> >
> > What’s the user visible change in behaviour after the switch? If it’s
> only internal implementation change, I don’t see why we want to leave the
> choice to operators.
> >
>
> It is only internal implementation changes.
>

That's not entirely true, is it? There are config variables to change and
it opens up the possibility of a scenario that the operator may not care
about.


>
>
> >> The other aspect is the deprecation process. If you add the switch into
> the DB migration path then the whole deprecation becomes superseded as the
> old IPAM logic should be abandoned immediately after that. But perhaps the
> other way of looking at it is that we should make an exception in the
> deprecation process.
> >>
> >> Salvatore
> >>
> >> On 11 February 2016 at 00:19, Carl Baldwin <c...@ecbaldwin.net> wrote:
> >> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <arma...@gmail.com> wrote:
> >> > Technically we can make this as sophisticated and seamless as we
> want, but
> >> > this is a one-off, once it's done the pain goes away, and we won't be
> doing
> >> > another migration like this ever again. So I wouldn't over engineer
> it.
> >>
> >> Frankly, I was worried that going the other way was over-engineering
> >> it.  It will be more difficult for us to manage this transition.
> >>
> >> I'm still struggling to see what makes this particular migration
> >> different than other cases where we change the database schema and the
> >> code a bit and we automatically migrate everyone to it as part of the
> >> routine migration.  What is it about this case that necessitates
> >> giving the operator the option?
> >>
> >> Carl
> >>
> >>
> __
> >> 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] Team meeting this Tuesday at 1400 UTC

[Armando M.]

On 1 February 2016 at 16:59, Carl Baldwin <c...@ecbaldwin.net> wrote:

> I almost missed this because [Neutron] was missing from the subject.
> I'm replying now to add it in case someone else missed it.
>
>
Ah...so there are people who indeed read these emails!

Thanks for spotting this, I totally miss it, the jet lag must have caught
up with me.

Cheers,
Armando


> On Sat, Jan 30, 2016 at 2:27 PM, Armando M. <arma...@gmail.com> wrote:
> > Hi neutrinos,
> >
> > According to [1], this is a kind reminder for next week's meeting:
> please do
> > not get caught by the confusion.
> >
> > The Tuesday meetings will be hosted by Ihar, and I will be working with
> him
> > to discuss these meeting agendas [2] ahead of time. For this reason, stay
> > tuned for reminder updates coming from him too.
> >
> > I do not plan on attending, but I may occasionally join the irc meetings
> > when I travel to more friendly time zones. If you have something to
> discuss
> > with me (whilst I am in the PTL capacity), please do not rely on the
> Tuesday
> > meetings to reach out.
> >
> > In the meantime, let's thank Ihar for volunteering!
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/272494/
> > [2] 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
>
__
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] Hitting Mitaka Milestone 3 and feature freeze exception process

[Armando M.]

Hi Neutrinos,

As I am sure all of you know, this week is Milestone week [1], for this
reason, we need to cut releases for both neutron, neutron *-aas, and the
client. Patches [2, 3] are still in draft, and whilst stuff is in flight,
we'll hold on until we have reached a sensible point where it's safe to
land them with the right hashes.

That said, not everything is complete and we'll need a few feature freeze
exceptions.

This cycle I would like to experiment with a new exception process: I
proposed a change to neutron-specs [4]. I would like to invite anyone who
has been identified as feature owner [5] (or anyone who actively
participated on the development of the feature as approver or simply
interested party), to comment on the status of the feature, so that I can
assess (with your help) if the feature is complete, whether it can safely
be granted an exception (being very close to being complete) or if it needs
to be deferred altogether.

So, consider this a collective sign-off. We'll look into finalizing this
document once we have the first release candidate. Then, this document can
be used as a base for Newton planning.

For any questions/comments, please do not hesitate to ask.

Many thanks,
Armando

[1] http://releases.openstack.org/mitaka/schedule.html
[2] https://review.openstack.org/#/c/286609
[3] https://review.openstack.org/#/c/286585/
[4] https://review.openstack.org/#/c/286413/
[5]
https://review.openstack.org/#/c/286413/3/specs/mitaka/postmortem/postmortem.rst
__
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][oslo]neutron agent not receiving callback

[Armando M.]

On 9 March 2016 at 09:14, Assaf Muller  wrote:

> On Wed, Mar 9, 2016 at 9:40 AM, Ihar Hrachyshka 
> wrote:
> > Vikash Kumar  wrote:
> >
> >>
> >>
> >> On Wed, Mar 9, 2016 at 3:42 PM, Vikash Kumar
> >>  wrote:
> >> I have written a sample neutron agent which subscribe for the
> AFTER_CREATE
> >> event of router. I have defined a sample method as callback, but the
> method
> >> doesn't gets called anytime.
> >>
> >> Also, in logs:
> >>
> >> 2016-03-09 01:36:08.220 7075 DEBUG neutron.callbacks.manager [-]
> >> Subscribe:  router after_create
> >> subscribe /opt/stack/neutron/neutron/callbacks/manager.py:41
> >>
> >>
> >> which means the subscription is successful.
> >>
> >>Do I need to enable anything in config file to get that ? Or am I
> >> missing something ?
> >
> >
> > First, nothing oslo specific is discussed here, so [oslo] tag is probably
> > redundant.
> >
> > Overall, I believe you try to rely on wrong thing that won’t deliver for
> > you: callbacks are internal to neutron-server, so events triggered by
> > neutron-servers will never reach any other processes (like your agent).
>
> The same callbacks mechanism is also used in the L3 agent, but as Ihar
> said, events in one process (neutron-server) will not trigger
> callbacks in another process (l3-agent). If that's what you want,
> you'll need RPC.
>

Callbacks is a general pub/sub local communication mechanism, whether it
applies to neutron-server or an agent. Clarifying here:

https://review.openstack.org/#/c/290700/


>
> >
> > More info:
> http://docs.openstack.org/developer/neutron/devref/callbacks.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

[openstack-dev] [Neutron] stable/mitaka branch imminent for the client

[Armando M.]

Folks,

Please see [1]. I gave Doug the go-ahead.

Cheers,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088853.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-dev] [Neutron] Ihar as *-aas core reviewer

[Armando M.]

Folks,

I would like to have Ihar as core reviewer for the advanced services (or
any neutron-governance project for the time we have those projects in the
governance).

Ihar is instrumental in ensuring that gate/stable issues are dealt with
promptly and swiftly and I trust he'll be using such as as responsibility
wisely.

So if you see him in your core team, that's the reason.

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

Re: [openstack-dev] [neutron] Last chance to finish changes affecting DB schema for Mitaka

[Armando M.]

On 9 March 2016 at 07:42, Ihar Hrachyshka  wrote:

> Henry Gessau  wrote:
>
> By tomorrow we intend to tag the heads of all the neutron alembic branches
>> with the MITAKA label [1][2][3][4].
>>
>> If you have a patch that adds an alembic migration and you want to get it
>> in
>> Mitaka you must be associated with a targeted BP/RFE/bug [5] and get your
>> code
>> merged by tomorrow (Wednesday, March 9).
>>
>> Here is a list of open reviews with DB migration changes [6]. Check if
>> your
>> Mitaka-targeted patch is on the list and if so, reach out to me (HenryG)
>> or
>> our PTL (armax) on IRC and let us know of your plans.
>>
>> -- HenryG
>>
>> [1] https://review.openstack.org/288212
>> [2] https://review.openstack.org/288213
>> [3] https://review.openstack.org/288214
>> [4] https://review.openstack.org/288215
>> [5] https://launchpad.net/neutron/+milestone/mitaka-rc1
>> [6]
>>
>> https://review.openstack.org/#/q/(project:openstack/neutron+OR+project:openstack/neutron-fwaas+OR+project:openstack/neutron-lbaas+OR+project:openstack/neutron-vpnaas)+status:open+file:%22%255E.*/versions/mitaka/.*%22+-label:workflow-1
>>
>>
> Note we are still in the middle of clarifying whether we want to allow
> DSCP feature in Mitaka, that involves alembic scripts. More details on the
> discussion:
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088717.html
>
> Thanks for holding the label patches.


Alea iacta est:

https://review.openstack.org/#/q/topic:bug/1552935

Please refrain from approving any change that involve DB migrations

Thanks,
Armando


>
> 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][all][ptl] preparing to create stable/mitaka branches for libraries

[Armando M.]

Good to go with:

openstack/python-neutronclient 4.1.1

Thanks,
Armando

On 9 March 2016 at 09:26, Doug Hellmann  wrote:

> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
>
> I will process each repository as I hear from the owning team.
>
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
>
> __
> 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 release planning

[Armando M.]

On 3 March 2016 at 12:05, Armando M. <arma...@gmail.com> wrote:

> Hi Neutrinos,
>
> Mitaka-3 is out [1] and we should be focussing on rc1. This is the time
> where we switch gear:
>
>- Test M-3, find issues and target them for RC1 [2];
>- Apply/agree for FFE status for pending features on the postmortem
>[3];
>- For features that get FFE granted, I'll be moving targeting them to
>RC1. Those that get denied will be pushed back to N as soon as it opens up.
>- Be mindful of the gate. Watch its state and make sure that you
>approve/merge only changes that are targeted for RC1. Anything else should
>be pushed back, especially trivial, and cosmetic fixes.
>- RC1 is for critical and high bug fixes (release blockers or gate
>failures) and FFE changes only. Anything else should be left untargeted.
>- Remember to tie loose ends, testing and docs are paramount to allow
>our users to enjoy our new features reliably.
>
> When in doubt, reach out!
>

You have one more day to comment/provide feedback on [1], before we close
Mitaka for good. Some items still miss documentation (not even as a patch
up for review). For this reason, they will be marked incomplete for Mitaka.
An example is Flavors [2]. If I got it wrong, please let me know.

[1] https://review.openstack.org/#/c/286413/
[2] https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework


>
> Cheers,
> Armando
>
> [1] https://launchpad.net/neutron/+milestone/mitaka-3
> [2] https://launchpad.net/neutron/+milestone/mitaka-rc1
> [3] https://review.openstack.org/#/c/286413/
>
__
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] Ironing out outstanding issues in time for RC1

[Armando M.]

On 13 March 2016 at 15:14, Ihar Hrachyshka <ihrac...@redhat.com> wrote:

> Armando M. <arma...@gmail.com> wrote:
>
> Neutrinos,
>>
>> We have about ~20 outstanding bugs marked Medium/High/Critical, and we
>> have only one or two days left to have a chance to get them in the gate
>> queue [1]. Can I trouble you to go and make sure patches are up to date and
>> well reviewed?
>>
>> Many thanks,
>> Armando
>>
>> [1] https://launchpad.net/neutron/+milestone/mitaka-rc1
>>
>
> Hi Armando and all,
>
> [Full disclosure: I am really interested in getting stable/mitaka cut off
> asap due to the code sprint starting on Mon where we would like to land a
> number of N bits to master.]
>
>
Do you have a list of patches that are currently blocked by the feature
freeze? I have this:


https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:ovo+label:Code-Review%253C%253D-2

I appreciate your concern, and we should do everything we can to enable you
guys to have a productive sprint. That said, it's unfortunate that the
sprint ended up being scheduled for this week, where attention should
really be devoted to Mitaka rather than Newton...but I guess you couldn't
predict the state of the codebase too far in advance.



> Currently I see 25 unreleased bugs targeted for RC1. I believe the list is
> too broad and does not represent actual team priorities as of right now; I
> suggest we go thru the list and postpone those bugs that either won’t land
> on Mon, or aren't really critical for the release; then cut-off
> stable/mitaka to unblock master.
>

Yes it is (you should have seen the list before I already had my first pass
;)). Bear in mind that most of these bugs ended up being automatically
rolled over to RC1 being targeted for earlier milestones (some of them are
as old as Liberty).


>
> If you think the list is fine, remember that at this point we should land
> only safe fixes, or those that make release impossible [aka ‘something base
> to the cloud operation is totally broken in Mitaka comparing to Liberty’].
> If you like, you can compare Neutron with its 25 targeted bugs to other
> projects (hint: nova - 2 bugs; glance - 2 bugs; cinder - 5 bugs; horizon -
> 12 bugs).


You should not trust the Launchpad view of other projects, because,
especially if you looked at Nova, this would mean that they fixed virtually
nothing in Mitaka, which is clearly not true. In other words, some projects
moved away from tracking issues using Launchpad. So rest assured that we're
not as lousy as we look.


> If we would start landing all cool stuff that we happen to produce in the
> last week, we would be undermining freeze and release process, also raising
> chances of releasing a pile of broken code.
>

Can you start telling me something I don't know? :)


>
> With that in mind, I went through the target to see what is really
> critical for the release.
>
> ===
>

Great, let's dig in!

Bear in mind that we can really consider RC1 bugs those for which we, as a
team, can clearly identify fixes that can safely land in the next day or
so. Any other, sadly, must be dropped no matter how bad it looks, due to
the time constraint we have.


>
> We have 18 bugs that are High+. Below is each of those bugs, with [*] mark
> where I think RC target is justified at this point.
>
> https://bugs.launchpad.net/neutron/+bug/1523031: linuxbridge + l2pop +
> l3ha broken.
> ^ while it’s unfortunate, I don’t see how it stands for a release critical
> bug since it affects setup that is not really that common. Also, looking at
> the bug state, I don’t see any work started on it. I would prefer we drop
> it out of RC1 target.
>

Agreed


>
> https://bugs.launchpad.net/bugs/1551288
> ^ fullstack (non-voting) job sometimes fails for native ovsdb interface.
> No idea why it’s critical for the release. Suggesting to postpone to N.


Agreed. The only comment I have to make here is: the sooner we make
fullstack voting the better. I wish we could have made that a Mitaka
priority so that we'd have an extra tool in our stability arsenal.


>
> https://bugs.launchpad.net/bugs/1513765 [*]
> ^ conntrack calls block ovs agent; patch in review optimizes for some use
> cases, but does not tackle the general issue of the agent being blocked;
> patch opens some rolling upgrade scenario concerns too since it touches RPC
> version and method signatures; that said, we indeed want to try to tackle
> it in RC;


> https://bugs.launchpad.net/neutron/+bug/1556139 [*]
> ^ create/delete race when returning new resource body in ml2; the patch is
> up for review and ready for merge; good to go;
>
> https://bugs.launchpad.net/neutron/+bug/1453350
> ^ port ready event sent to nova before dhcp

[openstack-dev] [Neutron] RC1 candidate

[Armando M.]

Neutrinos,

I believe we reached the point [1] where RC1 can be cut [2]. If I made an
error of judgement, or any other catastrophic failure arises, please report
a bug, and tag it as mitaka-rc-potential [3]. Please, sign off on
postmortem [4], so that we can finalize the specs status for Mitaka and
open up to Newton.

Please, consider this the last warning to ensure that everything is in the
right order so that you can feel proud of what you and your teammates have
accomplished this release!

Cheers,
Armando

[1] https://launchpad.net/neutron/+milestone/mitaka-rc1
[2] https://review.openstack.org/#/c/292445/
[3] https://bugs.launchpad.net/neutron/+bugs?field.tag=mitaka-rc-potential
[4] https://review.openstack.org/#/c/286413/
[5] https://review.openstack.org/#/c/283383/
__
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] Releasing python-neutronclient 4.1.2?

[Armando M.]

On 8 March 2016 at 15:07, Doug Hellmann <d...@doughellmann.com> wrote:

> Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700:
> > Hi folks,
> >
> > There's a feature or two that are pending to be delivered in Mitaka
> [1,2],
> > and those involve changes to both the server and client sides. Ideally
> we'd
> > merge both sides in time for Mitaka RC and that implies that we would be
> > able to release a new version of the client including changes [3,4]. This
> > is especially important since a new client release would be beneficial to
> > improving test coverage as needed by [5].
> >
> > Considering what we released already, and what the tip of master is for
> the
> > client [6], I can't see any side effect that a new neutronclient release
> > may introduce.
> >
> > Having said that, I am leaning towards the all-or-none approach, but the
> > 'all' approach is predicated on the fact that we are indeed allowed to
> > release a new client and touch the global requirements.
> >
> > What's the release team's recommendation? Based on it, we may want to
> > decide to defer these to as soon as N master opens up.
>
> I'm a bit reluctant to start touching the requirements lists for
> feature work. We do have some bug fixes in the pipeline that will
> require library releases, but those are for bugs not new features.
> We also have one or two libs where feature work needed to be extended,
> but none of those have dependencies outside of the project producing
> them.
>
> The main reason to require a client release is for some *other* project
> to take advantage of the new feature work. Is that planned?
>

Thanks for the prompt reply. Neutron would be the only consumer of these
additions, and no other project has pending work to leverage these
capabilities.


>
> Doug
>
> >
> > Many thanks,
> > Armando
> >
> > [1] https://review.openstack.org/#/q/topic:bug/1468353
> > [2] https://review.openstack.org/#/q/topic:bug/1521783
> > [3] https://review.openstack.org/#/c/254280/
> > [4] https://review.openstack.org/#/c/288187/
> > [5] https://review.openstack.org/#/c/288392/
> > [6]
> >
> https://github.com/openstack/python-neutronclient/commit/8460b0dbb354a304a112be13c63cb933ebe1927a
>
> __
> 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] Linuxbridge gate failures

[Armando M.]

Neutrinos,

We had two back-to-back gate failures on [1,2] and more seem to be ramping
up. These are tracked in bug [3] (e-r query tracked in [4]). Can I trouble
some gentle soul to have a look?

Thanks,
Armando

[1] https://review.openstack.org/#/c/286818/
[2] https://review.openstack.org/#/c/285339/
[3] https://bugs.launchpad.net/neutron/+bug/1531862
[4] https://review.openstack.org/#/c/290861/
__
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] Ironing out outstanding issues in time for RC1

[Armando M.]

Neutrinos,

We have about ~20 outstanding bugs marked Medium/High/Critical, and we have
only one or two days left to have a chance to get them in the gate queue
[1]. Can I trouble you to go and make sure patches are up to date and well
reviewed?

Many thanks,
Armando

[1] https://launchpad.net/neutron/+milestone/mitaka-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

Re: [openstack-dev] [Neutron] BGP support

[Armando M.]

On 30 March 2016 at 17:07, Abhishek Raut  wrote:

> I think what Gary is talking about is BGP and the Border Gateway API
> spec[1] in L2 GW repo.
> [1] https://review.openstack.org/#/c/270786/
>

Spec [1] has nothing to do with BGP (the routing protocol) last time I
checked (note to self: I should go and have another look). We should
probably consider clarify the confusion that stems from the use of the word
'Border' in spec [1].

A.


>
>
—Abhishek Raut
>
> From: "Tidwell, Ryan" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, March 30, 2016 at 4:52 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] BGP support
>
> Gary,
>
>
>
> I’m not sure I understand the relationship you’re drawing between BGP and
> L2 GW, could you elaborate?  The BGP code that landed in Mitaka is mostly
> geared toward the use case where you want to directly route your tenant
> networks without any NAT (ie no floating IP’s, no SNAT).  Neutron peers
> with upstream routers and announces prefixes that tenants allocate
> dynamically.  We have talked about how we could build on what was merged in
> Mitaka to support L3 VPN in the future, but to my knowledge no concrete
> plan has emerged as of yet.
>
>
>
> -Ryan
>
>
>
> *From:* Gary Kotton [mailto:gkot...@vmware.com ]
> *Sent:* Sunday, March 27, 2016 11:36 PM
> *To:* OpenStack List
> *Subject:* [openstack-dev] [Neutron] BGP support
>
>
>
> Hi,
>
> In the M cycle BGP support was added in tree. I have seen specs in the L2
> GW project for this support too. Are we planning to consolidate the
> efforts? Will the BGP code be moved from the Neutron git to the L2-GW
> project? Will a new project be created?
>
> Sorry, a little in the dark here and it would be nice if someone could
> please provide some clarity here. It would be a pity that there were
> competing efforts and my take would be that the Neutron code would be the
> single source of truth (until we decide otherwise).
>
> I think that the L2-GW project would be a very good place for that service
> code to reside. It can also have MPLS etc. support. So it may be a natural
> fit.
>
> Thanks
>
> Gary
>
> __
> 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] What to do about booting into port_security_enabled=False networks?

[Armando M.]

On 30 March 2016 at 13:40, Sean Dague  wrote:

> On 03/29/2016 09:55 PM, Matt Riedemann wrote:
> 
> >
> > Yup, HenryG walked me through the cases on IRC today.
> >
> > The more I think about option (b) above, the less I like that idea given
> > how much work goes into the allocate_for_instance code in nova where
> > it's already building the list of possible networks that will be used
> > for creating/updating ports, we'd essentially have to duplicate that
> > logic in a separate method to get an idea of what security groups would
> > be applied.
> >
> > I'd prefer to be lazy and go with option (a) and just say nova doesn't
> > return security-groups in the REST API when creating a server and
> > neutron is the network API. That would require a microversion probably,
> > but it would still be easy to do. I'm not sure if that's the best user
> > experience though.
> >
>
> Is there a sane resource on the neutron side we could link to? Today
> security_groups are returned with a name from nova, which made sense
> when it was an internal structure, but makes way less sense now.
>
> "security_groups": [
>{
> "href": "",
> }
> ]
>
> Where the link is to a neutron resource (and we could do a local link
> for the few nova net folks) might be more appropriate.
>

Not that I could think of, though the extra level of indirection to solve
this issue is kind of a neat idea.


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] What to do about booting into port_security_enabled=False networks?

[Armando M.]

On 29 March 2016 at 18:55, Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:

>
>
> On 3/29/2016 4:44 PM, Armando M. wrote:
>
>>
>>
>> On 29 March 2016 at 08:08, Matt Riedemann <mrie...@linux.vnet.ibm.com
>> <mailto:mrie...@linux.vnet.ibm.com>> wrote:
>>
>> Nova has had some long-standing bugs that Sahid is trying to fix
>> here [1].
>>
>> You can create a network in neutron with
>> port_security_enabled=False. However, the bug is that since Nova
>> adds the 'default' security group to the request (if none are
>> specified) when allocating networks, neutron raises an error when
>> you try to create a port on that network with a 'default' security
>> group.
>>
>> Sahid's patch simply checks if the network that we're going to use
>> has port_security_enabled and if it does not, no security groups are
>> applied when creating the port (regardless of what's requested for
>> security groups, which in nova is always at least 'default').
>>
>> There has been a similar attempt at fixing this [2]. That change
>> simply only added the 'default' security group when allocating
>> networks with nova-network. It omitted the default security group if
>> using neutron since:
>>
>> a) If the network does not have port security enabled, we'll blow up
>> trying to add a port on it with the default security group.
>>
>> b) If the network does have port security enabled, neutron will
>> automatically apply a 'default' security group to the port, nova
>> doesn't need to specify one.
>>
>> The problem both Feodor's and Sahid's patches ran into was that the
>> nova REST API adds a 'default' security group to the server create
>> response when using neutron if specific security groups weren't on
>> the server create request [3].
>>
>> This is clearly wrong in the case of
>> network.port_security_enabled=False. When listing security groups
>> for an instance, they are correctly not listed, but the server
>> create response is still wrong.
>>
>> So the question is, how to resolve this?  A few options come to mind:
>>
>> a) Don't return any security groups in the server create response
>> when using neutron as the backend. Given by this point we've cast
>> off to the compute which actually does the work of network
>> allocation, we can't call back into the network API to see what
>> security groups are being used. Since we can't be sure, don't
>> provide what could be false info.
>>
>> b) Add a new method to the network API which takes the requested
>> networks from the server create request and returns a best guess if
>> security groups are going to be applied or not. In the case of
>> network.port_security_enabled=False, we know a security group won't
>> be applied so the method returns False. If there is
>> port_security_enabled, we return whatever security group was
>> requested (or 'default'). If there are multiple networks on the
>> request, we return the security groups that will be applied to any
>> networks that have port security enabled.
>>
>> Option (b) is obviously more intensive and requires hitting the
>> neutron API from nova API before we respond, which we'd like to
>> avoid if possible. I'm also not sure what it means for the
>> auto-allocated-topology (get-me-a-network) case. With a standard
>> devstack setup, a network created via the auto-allocated-topology
>> API has port_security_enabled=True, but I also have the 'Port
>> Security' extension enabled and the default public external network
>> has port_security_enabled=True. What if either of those are False
>> (or the port security extension is disabled)? Does the
>> auto-allocated network inherit port_security_enabled=False? We could
>> duplicate that logic in Nova, but it's more proxy work that we would
>> like to avoid.
>>
>>
>> Port security on the external network has no role in this because this
>> is not the network you'd be creating ports on. Even if it had
>> port-security=False, an auto-allocated network will still be created
>> with port security enabled (i.e. =True).
>>
>> A user can obviously change that later on.
>>
>>
>> [1] https://review.openstack.org/#/c/284095/
>> [2] https://review.openstack.org/#/c/173204/
>> [3]
>>
>> https://github.com/openstack/nov

[openstack-dev] [Neutron] Drivers team cancelled

[Armando M.]

Hi Neutrinos,

Too many firefights this week and I personally didn't have much time to
spend on reviewing RFEs etc. If you guys want to have it, please go ahead
but I won't be able to join.

Cheers,
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-dev] Drivers team cancelled

[Armando M.]

Hi Neutrinos,

Too many firefights this week and I personally didn't have much time to
spend on reviewing RFEs etc. If you guys want to have it, please go ahead
but I won't be able to join.

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

Re: [openstack-dev] [Neutron] Newton blueprints call for action

[Armando M.]

Folks, thanks to everyone who has replied to the the thread. Much
appreciated it.

I'll reach out individually to figure out next steps and come back here to
provide a status update.

Cheers,
Armando

On 6 April 2016 at 07:17, Brent Eagles <beag...@redhat.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Armando,
>
> On 05/04/16 01:13 AM, Armando M. wrote:
> > Hi Neutrinos,
> >
> > During today's team meeting [0], we went through the current
> > milestone workload [1].
> >
> > This is mostly made of Mitaka backlog items, amongst which we
> > discussed two blueprints [2, 3]. These two efforts had their spec
> > approved during the Mitaka timeframe, but code lagged behind, and
> > hence got deferred [4].
> >
> > I would like to understand if these need new owners (both assignees
> > and approvers). Code submitted [5,6] has not been touched in a
> > while, and whilst I appreciate people have been busy focussing on
> > Mitaka (myself included), the Newton master branch has been open
> > for a while.
> >
> > With this email I would like to appeal to the people in CC to
> > report back their interest in continuing working on these items in
> > their respective capacities, and/or the wider community, in case
> > new owners need to be identified.
> >
> > I look forward to hearing back, hoping we can find the right
> > resources to resume progress, and bring these important
> > requirements to completion in time for Newton.
> >
> > Many thanks, Armando
>
> As it happens, I've been tasked to work on TripleO as a general
> contributor with a networking focus. For better or worse, the database
> related work was the only thing on my early radar and I will shepherd
> that along as needed, but I won't be able to commit to the larger bits
> of the remaining work.
>
> While we could wait for summit to hand off, I think it would be better
> for someone who is looking to take over ownership of all or some of
> the pieces to sync up with Bence, myself, and Songming ASAP.
>
> Cheers,
>
> Brent
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJXBRpyAAoJEIXWptqvFlBWIHgQAL3e+HjvDXvziee1oLfkz/kT
> DIghPQoqZg+oLJYmezoa4ixzNY53pE/EtkTxCtXrmEfbvwCqNWkgNWqTKm4nGe1J
> Uv1HFpdrUtg9j7bS9bIPRKQKaWr9nkNUJZPL5fjIs467WWQP0e6YbigVgoJQRYXi
> t/o5ZKgRKp8DOW+bqjXvQvM69WXq9iyH7KmjVfbJ2o3NeoFOmPTlXtAunbp33xj4
> 6MuFH4USJZS11x0IgIiaCZHJS+RWfDdxI+4ONCqQ1lYkrLp9wl8XNznQzum60wFU
> jhjJcaRtfdbMHmRd72//QVeIlX9VA6b5q36a/adPxbKrD2XTd4pntJ86dnU0aQFJ
> sriJRk3KlD0IMDMS+rRsKz7EyJJP+9b5zlWCzX0V+1zNlcB6eiowOmo3QUQrFBQT
> O50KS9YC7ef0EMWE6kikxyK8AxZ1Hjcm3eM50mShU+eCI/JPgkHeRQX+Z16RBybj
> xhEBgRIvLS7bH8c6vqjIgmLQ1zxQ3EPR440Zpi0rw3rChP/lugYYQpcjXDfVFWED
> gwe+RQvevj4tJeVjXG662DMuzmjy/cM2nNLZm3AZsaASkR73/M+Qmy53Y22T+T2o
> VVcbOsK2+1Y8JFAVZguUib9pQ/z8DgBKs4+rfWiV4mzBAGwVIxePiNDiQ1kQU/Z0
> 3kUfgrNS0CgmE/nmg05x
> =7kzU
> -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

Re: [openstack-dev] [Neutron] Newton Design summit schedule - Draft

[Armando M.]

On 12 April 2016 at 12:16, Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:

>
>
> On 4/11/2016 11:56 PM, Armando M. wrote:
>
>> Hi folks,
>>
>> A provisional schedulefor the Neutron project is available [1]. I am
>> still working with the session chairs and going through/ironing out some
>> details as well as gathering input from [2].
>>
>> I hope I can get something more final by the end of this week. In the
>> meantime, please free to ask questions/provide comments.
>>
>> Many thanks,
>> Armando
>>
>> [1]
>>
>> https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Neutron%3A
>> [2] https://etherpad.openstack.org/p/newton-neutron-summit-ideas
>>
>
>> __
>> 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
>>
>>
> FYI, I have the nova/neutron cross-project session for Wednesday at 11am
> in the schedule:
>
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/9089


Thanks,

Surprisingly this does not show up when searching by Neutron tag, even
though I can see the sessions it's been tagged with both Nova and Neutron.
I wonder if I am doing something wrong.


>
> --
>
> 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] Newton Design summit schedule - Draft

[Armando M.]

On 12 April 2016 at 07:08, Michael Johnson <johnso...@gmail.com> wrote:

> Armando,
>
> Is there any way we can move the "Neutron: Development track: future
> of *-aas projects" session?  I overlaps with the LBaaS talk:
>
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/6893?goback=1
>
> Michael
>

Swapped with the first slot of the day. I also loaded etherpads here:

https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Neutron

Cheers,
Armando

>
>
> On Mon, Apr 11, 2016 at 9:56 PM, Armando M. <arma...@gmail.com> wrote:
> > Hi folks,
> >
> > A provisional schedule for the Neutron project is available [1]. I am
> still
> > working with the session chairs and going through/ironing out some
> details
> > as well as gathering input from [2].
> >
> > I hope I can get something more final by the end of this week. In the
> > meantime, please free to ask questions/provide comments.
> >
> > Many thanks,
> > Armando
> >
> > [1]
> >
> https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Neutron%3A
> > [2] https://etherpad.openstack.org/p/newton-neutron-summit-ideas
> >
> >
> __
> > 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] Newton Design summit schedule - Draft

[Armando M.]

On 12 April 2016 at 12:36, Anita Kuno <ante...@anteaya.info> wrote:

> On 04/12/2016 03:23 PM, Armando M. wrote:
> > On 12 April 2016 at 12:16, Matt Riedemann <mrie...@linux.vnet.ibm.com>
> > wrote:
> >
> >>
> >>
> >> On 4/11/2016 11:56 PM, Armando M. wrote:
> >>
> >>> Hi folks,
> >>>
> >>> A provisional schedulefor the Neutron project is available [1]. I am
> >>> still working with the session chairs and going through/ironing out
> some
> >>> details as well as gathering input from [2].
> >>>
> >>> I hope I can get something more final by the end of this week. In the
> >>> meantime, please free to ask questions/provide comments.
> >>>
> >>> Many thanks,
> >>> Armando
> >>>
> >>> [1]
> >>>
> >>>
> https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Neutron%3A
> >>> [2] https://etherpad.openstack.org/p/newton-neutron-summit-ideas
> >>>
> >>
> >>>
> __
> >>> 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
> >>>
> >>>
> >> FYI, I have the nova/neutron cross-project session for Wednesday at 11am
> >> in the schedule:
> >>
> >>
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/9089
> >
> >
> > Thanks,
> >
> > Surprisingly this does not show up when searching by Neutron tag, even
> > though I can see the sessions it's been tagged with both Nova and
> Neutron.
> > I wonder if I am doing something wrong.
>
> The title for that session includes "Nova: Neutron"
> So it comes up when searching for Neutron (without the colon) or Nova:
> (with the colon) but not Neutron: (with the colon).
>
> Hopefully the web folks will have this straightened out for Barcelona.
>
>
Thanks Anita!


> Thanks,
> Anita.
>
> >
> >
> >>
> >> --
> >>
> >> 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
> >
>
>
> __
> 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] Eliminating the DevStack layer

[Armando M.]

On 8 April 2016 at 11:06, Sean Dague  wrote:

> On 04/08/2016 12:05 PM, Morales, Victor wrote:
> > Agree, sometimes is hard to figure out what is the Devstack variable
> that will modify the configuration value.
> >
> > There is an effort to categorize the configuration options[1] of some of
> the projects.  I’m wondering if it could be possible to create category or
> field that specifies the Destack variable that changes this configuration
> value.
> >
> > [1]
> https://review.openstack.org/#/c/295543/8/specs/categorized-configuration-options.rst
>
> I really don't think that Devstack should leak that far back into real
> projects.
>
> Devstack variables make a ton of sense when you are communicating a
> higher level construct, and it needs to do some logic on it and possibly
> set multiple things.
>
> Devstack variables that are basically pass through for individual config
> vars aren't really a good idea. We try to -1 them all now. But a lot of
> leaked in.
>
> I think Sean Collins' plan is a good one.
>
> -Sean
>
>
The plethora of networking-specific config variables is a vestigial
presence of a time where local.conf and the plugin mechanism was not in
place in DevStack. Bear in mind that this is not a Neutron specific
problem: all projects are affected more or less equally.

I 100% agree with SeanD that the proposals of passthrough variables is to
be shot down. Those that are used to tune more than one variable at any
given time are more useful instead, as they reduce the number of moving
parts that will have to go into local.conf.

My understanding of the plan to overhaul the neutron (bloated) layer
present in DevStack being tackled in [1] has always been that this was
about trimming the layer rather than eliminating it altogether. Is this
email a reflection of a desire to change direction? If so, SeanC please
clarify because I am slightly confused.

To the very minimum we'd need to find the right blend of config variables
which (in conjunction with some other *optional* local.conf extra juice)
produce the Neutron configuration files that we have in the gate, namely
OVS, LB and OVS+DVR, with their multi-node variants, and thus allow us to
get happy pass with Grenade/Tempest (if that means skipping some tests so
be it) across all the branches we currently gate against. The rest of the
layer can be stripped to the bare bone, but without it we're basically
gonna have to deal with long local.conf files with entire chunks of agent
files etc. thus making Neutron support for repos like devstack-gate and
project-config rather more painful (I am assuming we're gonna have to use
the new layer/approach at some point?). Bear in mind that the complexity
bubble needs to move/split, it's not just gonna burst and vanish :)

On another note, we'd have to keep in mind neutron_plugins that currently
have a place in the devstack tree and/or that rely on the existing
neutron_legacy bits. What's the plan for those (e.g. networking-[ovn, odl,
...] et al)? Finally, what's the plan for switching in the gate?

Cheers,
Armando

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


> --
> Sean Dague
> http://dague.net
>
> __
> 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] Newton Design summit schedule - Draft

[Armando M.]

Hi folks,

A provisional schedule for the Neutron project is available [1]. I am still
working with the session chairs and going through/ironing out some details
as well as gathering input from [2].

I hope I can get something more final by the end of this week. In the
meantime, please free to ask questions/provide comments.

Many thanks,
Armando

[1]
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Neutron%3A
[2] https://etherpad.openstack.org/p/newton-neutron-summit-ideas
__
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

[Armando M.]

On 29 March 2016 at 20:43, Vikram Choudhary <viks...@gmail.com> wrote:

> Hi Armando,
>
> We want to add the support for a new ML2 driver. Can you please guide what
> is the step moving forward?
>
> Thanks
> Vikram
>

Vikram,

Apologies for the late reply, the Mitaka release tasks took precedence and
I did not have the time to fully resume this effort though it's my
intention to come back to it in the next few days. To start with, I resumed
[1,2] to reflect the team decision made in [3]. Now that Newton has
started, and other repos of the same nature are available in openstack.org,
it makes sense to give power back to the individual teams to be fully in
charge of release and backport duties. Some of these projects were already
released as indicated in [4], and I'll work with the openstack release team
to clarify next steps for those that have not.

Thanks,
Armando

[1] https://review.openstack.org/#/c/303026/
[2] https://review.openstack.org/#/c/303039/
[3] https://review.openstack.org/#/c/276461/
[4]
https://github.com/openstack/releases/tree/master/deliverables/_independent



>
>
> On Fri, Mar 4, 2016 at 12:39 AM, Armando M. <arma...@gmail.com> wrote:
>
>> Hi folks,
>>
>> Status update on this matter:
>>
>> Russell, Kyle and I had a number of patches out [1], to try and converge
>> on how to better organize Neutron-related efforts. As a result, a number of
>> patches merged and a number of patches are still pending. Because of Mitaka
>> feature freeze, other initiatives too priority.
>>
>> That said, some people rightly wonder what's the latest outcome of the
>> discussion. Bottom line: we are still figuring this out. For now the
>> marching order is unchanged: as far as Mitaka is concerned, things stay as
>> they were, and new submissions for inclusion are still frozen. I aim (with
>> or without the help of the new PTL) to get to a final resolution by or
>> shortly after the Mitaka release [2].
>>
>> Please be patient and stay focussed on delivering a great Mitaka
>> experience!
>>
>> Cheers,
>> Armando
>>
>> [1]
>> https://review.openstack.org/#/q/branch:master+topic:stadium-implosion
>> [2] http://releases.openstack.org/mitaka/schedule.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] [Heat][Neutron] Mitaka RC1 available

[Armando M.]

On 16 March 2016 at 22:45, Thierry Carrez  wrote:

> Hello everyone,
>
> Heat and Neutron just produced a release candidate for the end of the
> Mitaka cycle! You can find their RC1 source code tarballs at:
>
> https://tarballs.openstack.org/heat/heat-6.0.0.0rc1.tar.gz
>
> https://tarballs.openstack.org/neutron/neutron-8.0.0.0rc1.tar.gz
>
> https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-8.0.0.0rc1.tar.gz
>
> https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-8.0.0.0rc1.tar.gz
>
> https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0rc1.tar.gz
>
> Unless release-critical issues are found that warrant a release candidate
> respin, these RC1s will be formally released as the final Mitaka releases
> on April 7th. You are therefore strongly encouraged to test and validate
> these tarballs !
>
> Alternatively, you can directly test the stable/mitaka release branches at:
>
> http://git.openstack.org/cgit/openstack/heat/log/?h=stable/mitaka
>
> http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/mitaka
> http://git.openstack.org/cgit/openstack/neutron-lbaas/log/?h=stable/mitaka
> http://git.openstack.org/cgit/openstack/neutron-fwaas/log/?h=stable/mitaka
> http://git.openstack.org/cgit/openstack/neutron-vpnaas/log/?h=stable/mitaka
>
> If you find an issue that could be considered release-critical, please
> file it at:
>
> https://bugs.launchpad.net/heat/+filebug
> or
> https://bugs.launchpad.net/neutron/+filebug
>
> and tag it *mitaka-rc-potential* to bring it to the release crew's
> attention.
>
> Note that the "master" branches of Heat and Neutron are now open for
> Newton development, and feature freeze restrictions no longer apply there !


Unfortunately, Neutron is also going to need an RC2 due to upstream CI
issues triggered by infra change [1] that merged right about the same time
RC1 was being cut.

Thanks,
Armando

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


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

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

[Armando M.]

Hi neutrinos,

A kind reminder for next week's meeting. More on the agenda [1].

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