Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[Oleg Bondarev]

+1!

On Fri, Dec 16, 2016 at 11:05 AM, Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:

> +1
> --
> -
> Andreas
> IRC: andreas_s
>
>
>
> On Fr, 2016-12-16 at 00:14 +0100, Armando M. wrote:
> > Hi neutrinos,
> >
> >
> > Miguel Lavalle has been driving the project forward consistently and
> > reliably. I would like to propose him to be entrusted with +2/+A
> > rights in the areas he's been most prolific, which are L3 and DHCP.
> >
> >
> > At the same time, I'd like to propose Brian Haley as our next Chief L3
> > Officer. Both of them have worked with Carl Baldwin extensively and
> > that can only be a guarantee of quality.
> >
> >
> > Cheers,
> > Armando
> >
> >
> > [1] https://review.openstack.org/#/c/411531/
> > 
> __
> > OpenStack Development Mailing 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] proposing Ryan Tidwell and Nate Johnston as service LTs

[Oleg Bondarev]

+1

On Fri, Dec 16, 2016 at 10:04 AM, reedip banerjee 
wrote:

> +1 for both Ryan and Nate :)
>
> On Fri, Dec 16, 2016 at 10:03 AM, Vikram Choudhary 
> wrote:
>
>> +1 for Ryan!
>>
>> On Dec 16, 2016 7:23 AM, "Sridar Kandaswamy (skandasw)" <
>> skand...@cisco.com> wrote:
>>
>>> +1. From the neutron-fwaas perspective, Nate has been instrumental in
>>> driving our integration with neutron on the agent extension framework,
>>> neutron-lib as well as on CI.
>>>
>>> Thanks
>>>
>>> Sridar
>>>
>>> From: Kevin Benton 
>>> Reply-To: OpenStack List 
>>> Date: Thursday, December 15, 2016 at 5:00 PM
>>> To: OpenStack List 
>>> Subject: Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate
>>> Johnston as service LTs
>>>
>>> +1
>>>
>>> On Dec 15, 2016 19:03, "Armando M."  wrote:
>>>
 Hi neutrinos,

 I would like to propose Ryan and Nate as the go-to fellows for
 service-related patches.

 Both are core in their repos of focus, namely neutron-dynamic-routing
 and neutron-fwaas, and have a good understanding of the service framework,
 the agent framework and other bits and pieces. At this point, entrusting
 them with the responsibility is almost a formality.

 Cheers,
 Armando

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

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.op
 enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __
> OpenStack Development Mailing 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] Proposing Abhishek Raut as neutronclient core

[Oleg Bondarev]

+1

On Wed, Dec 14, 2016 at 8:48 AM, Brandon Logan 
wrote:

> +1
>
> On Wed, 2016-12-14 at 02:22 +0100, Armando M. wrote:
>
> Hi folks,
>
> Abhishek Raut's recent involvement in OSC and python-neutronclient has
> helped moving a few efforts along in the right direction. I would like to
> suggest we double down on core firepower for the neutronclient repo
> alongside Akihiro [1].
>
> This not only will help speed up our transition to OSC CLI, but also
> improve the number of folks who can effectively liasion with the OSC team,
> and look after the needs of neutron's client repo.
>
> Many thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/410485/
>
> __
> 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

Re: [openstack-dev] [neutron] Ocata End user and operator feedback recap

[Oleg Bondarev]

On Tue, Nov 8, 2016 at 12:22 AM, Carl Baldwin  wrote:

> Ocata End user and operator feedback recap
> 
>
> The purpose of this session was to gather feedback from end users and
> operators to help direct the efforts of developers during (at least) the
> Ocata cycle. Feedback was captured on the etherpad [1]. There was a related
> session in the operators' track [2] which may also be of interest.
>
> We began with a short discussion about client compatibility which was
> deferred to the following session specifically about the client [3].
>
> There was a discussion about if Neutron will implement cells like Nova
> has. There is currently no plan. I have heard this come up for the past
> couple of summits but there is little concrete evidence of the scale issues
> being encountered by operators. If you are running Neutron at scale, we
> could use more of your input.
>
> There was some discussion about an issue around moving a floating ip from
> one instance to another when keepalive is in use. We needed more
> information to debug this. It should be sending a gratuitous arp. Another
> keepalive issue was discussed. Too many SIGHUPs within a period of time can
> cause failover resulting in disruption. I do not know if a bug was filed
> for this to follow up. If this was you, please follow up with a link to the
> bug report.
>

https://bugs.launchpad.net/neutron/+bug/1639315 looks related


>
> There was a short discussion about Horizon support for security groups on
> a port. A bug was filed for this.
>
> Finally, there was some discussion about enabling end users to create
> Neutron L3 routers which are backed by hardware resources. There is no such
> thing yet but Neutron does have a new concept in development called "L3
> flavors". This would enable a driver (to be written) which would allow this
> sort of thing.
>
> Carl Baldwin
>
> [1] https://etherpad.openstack.org/p/ocata-neutron-
> end-user-operator-feedback
> [2] https://etherpad.openstack.org/p/newton-neutron-pain-points
> [3] https://etherpad.openstack.org/p/ocata-neutron-client
>
> __
> OpenStack Development Mailing 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] Neutron team social event in Barcelona

[Oleg Bondarev]

+1

On Mon, Oct 17, 2016 at 10:23 AM, Jakub Libosvar 
wrote:

> +1
>
>
> On 14/10/2016 20:30, Miguel Lavalle wrote:
>
>> Dear Neutrinos,
>>
>> I am organizing a social event for the team on Thursday 27th at 19:30.
>> After doing some Google research, I am proposing Raco de la Vila, which
>> is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
>> menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>>
>> It is easy to get there by subway from the Summit venue:
>> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
>> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
>> we can get a final count.
>>
>> Here's some reviews:
>> https://www.tripadvisor.com/Restaurant_Review-g187497-d16820
>> 57-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>>
>> Cheers
>>
>> Miguel
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] Proposing Jakub Libosvar for testing core

[Oleg Bondarev]

+1

On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley 
wrote:

> +1
>
> On Jul 21, 2016, at 5:13 PM, Kevin Benton  wrote:
>
> +1
>
> On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin  wrote:
>
>> +1 from me
>>
>> On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller  wrote:
>>
>>> As Neutron's so called testing lieutenant I would like to propose
>>> Jakub Libosvar to be a core in the testing area.
>>>
>>> Jakub has demonstrated his inherent interest in the testing area over
>>> the last few years, his reviews are consistently insightful and his
>>> numbers [1] are in line with others and I know will improve if given
>>> the responsibilities of a core reviewer. Jakub is deeply involved with
>>> the project's testing infrastructures and CI systems.
>>>
>>> As a reminder the expectation from cores is found here [2], and
>>> specifically for cores interesting in helping out shaping Neutron's
>>> testing story:
>>>
>>> * Guide community members to craft a testing strategy for features [3]
>>> * Ensure Neutron's testing infrastructures are sufficiently
>>> sophisticated to achieve the above.
>>> * Provide leadership when determining testing Do's & Don'ts [4]. What
>>> makes for an effective test?
>>> * Ensure the gate stays consistently green
>>>
>>> And more tactically we're looking at finishing the Tempest/Neutron
>>> tests dedup [5] and to provide visual graphing for historical control
>>> and data plane performance results similar to [6].
>>>
>>> [1] http://stackalytics.com/report/contribution/neutron/90
>>> [2]
>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
>>> [3]
>>> http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
>>> [4] https://assafmuller.com/2015/05/17/testing-lightning-talk/
>>> [5] https://etherpad.openstack.org/p/neutron-tempest-defork
>>> [6]
>>> https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Oleg Bondarev]

Hi,

[1] is a doc comparing OVN and ODL for Neutron. I wrote it in March so some
info might be stale.
Hope this can be useful, comments are welcome!

[1]
https://docs.google.com/document/d/13K4Xpdu1IbRJDj5JTepDI4nwUkCDCu7IOnYwHkZtcMA/edit?usp=sharing

Thanks,
Oleg

On Fri, Jun 10, 2016 at 12:28 AM, Kyle Mestery  wrote:

> On Thu, Jun 9, 2016 at 4:19 PM, Assaf Muller  wrote:
> > On Thu, Jun 9, 2016 at 5:06 PM, Kyle Mestery 
> wrote:
> >> On Thu, Jun 9, 2016 at 2:11 PM, Assaf Muller  wrote:
> >>> On Thu, Jun 9, 2016 at 1:48 PM, Ben Pfaff  wrote:
>  On Thu, Jun 09, 2016 at 10:28:31AM -0700, rezroo wrote:
> > I'm trying to reconcile differences and similarities between OVN and
> > OpenDayLight in my head. Can someone help me compare these two
> technologies
> > and explain if they solve the same problem, or if there are
> fundamental
> > differences between them?
> 
>  OVN implements network virtualization for clouds of VMs or containers
> or
>  a mix.  Open Daylight is a platform for managing networks that can do
>  anything you want.
> >>>
> >>> That is true, but when considering a Neutron backend for OpenStack
> >>> deployments, people choose a subset of OpenDaylight projects and the
> >>> end result is a solution that is comparable in scope and feature set.
> >>> There are objective differences in where the projects are in their
> >>> lifetime, the HA architecture, the project's consistency model between
> >>> the neutron-server process and the backend, the development velocity,
> >>> the community size and the release model.
> >>>
> >> Fundamentally, the main difference is that OVN does one thing: It does
> >> network virtualization. OpenDaylight _MAY_ do network virtualization,
> >> among other things, and it likely does network virtualization in many
> >> different ways. Like Ben said:
> >>
> >> "Open Daylight is a platform for managing networks that can do
> >> anything you want."
> >
> > I agree, but I don't think that was what was asked or makes for an
> > interesting discussion. I think the obvious comparison is OVN to
> > ML2/ODL using the ovsdb ODL project.
> >
> OK, I'll bite. :)
>
> Fundamentally, a project's focus is absolutely important, especially
> when a comparison is asked. When you ask the question: "How can OVN or
> ODL solve being a backend layer for Neutron?", for example, the answer
> with OVN is simple: You do it this way, and it works. For ODL, the
> question is much more nuanced, as it depends on *what* components in
> ODL you are using.
>
> Also, yes, the comparison between "ML2+python agents" vs. "ML2+OVN" is
> much more relevant IMHO.
>
> Thanks!
> Kyle
>
> >>
> >> Thanks,
> >> Kyle
> >>
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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

[Oleg Bondarev]

On Mon, Jun 6, 2016 at 7:18 PM, Ihar Hrachyshka  wrote:

>
> > On 06 Jun 2016, at 16:44, Sean M. Collins  wrote:
> >
> > I agree, it would be convenient to have something similar to what Nova
> > has:
> >
> >
> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/versions.py#L59-L60
> >
> > We should put some resources behind implementing micro versioning and we
> > could end up with something similar.
> >
> > It would also be nice to have the agents report their version, so it
> > bubbles up into the agent-list REST API calls.
>
> Agents already report a list of object versions known to them:
>
>
> https://github.com/openstack/neutron/blob/master/neutron/db/agents_db.py#L258
>
> In theory, we can deduce the version from there. The versions are reported
> through state reports. Not sure if it’s exposed in API.
>

In my case I mostly need to know the version of neutron server, in
particular if it's still Mitaka or Newton already. This is what Dan's
concern is about in https://review.openstack.org/#/c/246910/: if we're
upgrading cluster from Mitaka to Newton and at some point have nova
upgraded but neutron still of Mitaka version, than live migration will be
broken (nova will wait for event which neutron does not send). But if we
can know neutron version we can solve the issue.


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

[Oleg Bondarev]

On Mon, Jun 6, 2016 at 2:03 PM, Armando M. <arma...@gmail.com> wrote:

>
>
> On 6 June 2016 at 10:06, Oleg Bondarev <obonda...@mirantis.com> 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.
>

Agree, that's why we have extensions-list in the API, right?


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

I'd not call it a feature, but a tiny behavior change for the neutron
reference implementation: if patch https://review.openstack.org/#/c/246898/
merges in Newton then we can be sure that neutron (newton or higher) with
ml2+ovs should send a particular event to nova during live migration (if it
doesn't than it a bug, but it's another topic) and nova can be sure it
should wait for this event.


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

[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

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

[Oleg Bondarev]

Count me in!

On Mon, Apr 25, 2016 at 10:01 AM, Ihar Hrachyshka 
wrote:

> WAT???
>
> It was never supposed to be core only. Everyone is welcome!
>

++


> Sent from my iPhone
>
> > On 25 Apr 2016, at 11:56, Edgar Magana  wrote:
> >
> > Would you extend it to ex-cores?
> >
> > Edgar
> >
> >
> >
> >
> >> On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
> >>
> >> Ihar, Henry and I were talking and we thought Thursday night makes
> sense for a Neutron social in Austin. If others agree, reply on this thread
> and we'll find a place.
> >>
> >> Thanks!
> >> Kyle
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Oleg Bondarev]

+1, thanks Hirofumi!

On Fri, Apr 8, 2016 at 7:34 AM, Akihiro Motoki  wrote:

> Hi Neutrinos,
>
> As the API Lieutenant of Neutron team,
> I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
> Neutron core reviewer team mainly focuing on the API/DB area.
>
> Hirofumi has been contributing neutron actively in the recent two
> releases constantly.
> He was involved in key features in API/DB areas in Mitaka such as
> tagging support and network availability zones.
> I believe his knowledge and involvement will be great addition to our team.
> He have been reviewing constantly [1] and I expect he continue to work
> for Newton or later.
>
> Existing API/DB core reviews (and other Neutron core reviewers),
> please vote +1/-1 for the addition of Hirofumi to the team.
>
> Thanks!
> Akihiro
>
>
> [1] http://stackalytics.com/report/contribution/neutron/90
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] Live Migration Issues with L3/L2

[Oleg Bondarev]

I think it might be a bit early to start a cross-project discussion on
this.
I'd suggest to first figure out what questions do we have, what would we
like to get from nova.
So I think it'd be more constructive if we first think on it within neutron
team.
I left some questions on the bug [1], please see comment #8

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

Thanks,
Oleg

On Fri, Dec 18, 2015 at 12:14 AM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Sean M. Collins,
> Thanks for the information.
> It would be great if we can bring in the right people from both sides to
> discuss and solve this problem
> Please let me know if you can pull in the right people from the nova side
> and I can get the people from the neutron side.
>
> Thanks
> Swami
>
> -Original Message-
> From: Sean M. Collins [mailto:s...@coreitpro.com]
> Sent: Thursday, December 17, 2015 1:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova][Neutron] Live Migration Issues with
> L3/L2
>
> On Thu, Dec 17, 2015 at 02:08:42PM EST, Vasudevan, Swaminathan (PNB
> Roseville) wrote:
> > Hi Folks,
> > I would like organize a meeting between the Nova and Neutron team to
> work refining the Nova/Neutron notificiations for the Live Migration.
> >
> > Today we only have Notification from Neutron to Nova on any port status
> update.
> >
> > But we don't have any similar notification from Nova on any Migration
> state change.
> > Neutron L3 will be interested in knowing the state change for vm
> migration and can take necessary action pro-actively to create the
> necessary L3 related plumbing that is required.
> >
> > Here are some of the bugs that are currently filed with respect to nova
> live migration and neutron.
> > https://bugs.launchpad.net/neutron/+bug/1456073
> > https://bugs.launchpad.net/neutron/+bug/1414559
> >
> > Please let me know who will be interested in participating in the
> discussion.
> > It would be great if we get some cores attention from "Nova and Neutron".
> >
> > Thanks.
> > Swaminathan Vasudevan
> > Systems Software Engineer (TC)
>
>
> Cool. Brent and I are inter-project liaisons between Neutron and Nova, so
> let us know what we can do to help raise awareness on both sides.
>
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons
>
> --
> 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
>
__
OpenStack Development Mailing 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][DVR]

[Oleg Bondarev]

On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Carl,
> Sounds reasonable suggestion.
> Thanks
> Swami
>
> -Original Message-
> From: Carl Baldwin [mailto:c...@ecbaldwin.net]
> Sent: Thursday, December 03, 2015 10:47 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Neutron][DVR]
>
> I was going to bring this up in the meeting this morning but IRC troubles
> prevented it.
>
> After chatting with Armando, I'd like to suggest a few enhancements to how
> we're tackling DVR during this cycle.  I'm hoping that these changes help
> us to get things done faster and more efficiently.  Let me know if you
> think otherwise.
>
> First, I'd like to suggest adding DvrImpact to the comment of any patches
> that are meant to improve DVR in some way.  People have asked me about
> reviewing DVR changes.  I can show them the DVR backlog [1] in launchpad
> but it would be nice to have a DVR specific dashboard.
> With DvrImpact in the subject, we can make it even more convenient to find
> reviews.
>

+1


>
> The other change I'd like to propose is to categorize our DVR backlog in
> to three categories:  broken, scale (loadimpact), and new features.
> I'd propose that we prioritize in that order.  Anyone have any suggestions
> for how to tag or otherwise categorize and tackle these?
>

This might be useful but honestly I don't feel a strong need for
categorizing dvr bugs at the moment because of the amount of bugs
(currently I see 31 when filtering by l3-dvr-backlog tag).
l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-backlog +
loadimpact for 'scale', l3-dvr-backlog + Wishlist for new (small)
enhancements.
I might be missing something though.


> I know there is a loadimpact (or similar) tag those.  Should we come up
> with a couple more tags to divide the rest?
>
> Thoughts?
>
> Carl
>
> [1] https://goo.gl/M5SwfS
>
> __
> OpenStack Development Mailing 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] Weekly DVR Meeting starting next week

[Oleg Bondarev]

Just realized that tomorrow is a non-working day in Russia due to Unity
Day.
Still will try to attend the first meeting.

Thanks,
Oleg

On Mon, Nov 2, 2015 at 9:47 PM, Ryan Moats  wrote:

> Ditto Ryan (regXboi) Moats
>
> Carl Baldwin  wrote on 11/02/2015 11:47:27 AM:
>
> > From: Carl Baldwin 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: 11/02/2015 11:48 AM
> > Subject: Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next
> week
>
> >
> > Thanks, Brian.  I'm planning to be there.
> >
> > Carl
> >
> > On Thu, Oct 29, 2015 at 10:17 PM, Brian Haley 
> wrote:
> > > A few of us had a discussion this week at Summit and decided to
> re-start the
> > > weekly Neutron Distributed Virtual Router (DVR) meeting.  The goal is
> to
> > > help:
> > >
> > > - Stabilize DVR - fix the bugs
> > > - Address performance/scalability issues
> > > - Get the DVR jobs voting again
> > >
> > > Meetings will be on Wednesdays starting next week at 15:00 UTC.  I'm
> in the
> > > process of updating
> > >
> http://eavesdrop.openstack.org/#Neutron_Distributed_Virtual_Router_Meeting
> > > with a link to the meeting page and agenda, which is currently at
> > > https://wiki.openstack.org/wiki/Meetings/Neutron-DVR
> > >
> > > -Brian
> > >
> > >
> __
> > > OpenStack Development Mailing 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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Oleg Bondarev]

+1

On Wed, Aug 12, 2015 at 4:55 PM, Henry Gessau ges...@cisco.com wrote:

 +1 to both!

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



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

__
OpenStack Development Mailing 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][dvr] Removing fip namespace when restarting L3 agent.

[Oleg Bondarev]

On Fri, Aug 7, 2015 at 10:24 AM, Korzeniewski, Artur 
artur.korzeniew...@intel.com wrote:

 Bug submitted:

 https://bugs.launchpad.net/neutron/+bug/1482521


Ok, here is the fix: https://review.openstack.org/210539
Thanks!

Oleg




 Thanks,

 Artur



 *From:* Oleg Bondarev [mailto:obonda...@mirantis.com]
 *Sent:* Thursday, August 6, 2015 5:18 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [neutron][dvr] Removing fip namespace when
 restarting L3 agent.







 On Thu, Aug 6, 2015 at 5:23 PM, Korzeniewski, Artur 
 artur.korzeniew...@intel.com wrote:

 Thanks Kevin for that hint.

 But it does not resolve the connectivity problem, it is just not removing
 the namespace when it is asked to.

 The real question is, why do we invoke the 
 /neutron/neutron/agent/l3/dvr_fip_ns.py
 FipNamespace.delete() method in the first place?



 I’ve captured the traceback for this situation:

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to
 access
 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file
 /opt/openstack/neutron/neutron/agent/linux/utils.py:222

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to
 access
 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file
 /opt/openstack/neutron/neutron/agent/linux/utils.py:222

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.external_process [-] No
 process started for 8223e12e-837b-49d4-9793-63603fccbc9f from (pid=70216)
 disable /opt/openstack/neutron/neutron/agent/linux/external_process.py:113

 Traceback (most recent call last):

  File /usr/local/lib/python2.7/dist-packages/eventlet/queue.py, line
 117, in switch

 self.greenlet.switch(value)

   File /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py,
 line 214, in main

 result = function(*args, **kwargs)

   File /usr/local/lib/python2.7/dist-packages/oslo_service/service.py,
 line 612, in run_service

 service.start()

   File /opt/openstack/neutron/neutron/service.py, line 233, in start

 self.manager.after_start()

   File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 641, in
 after_start

 self.periodic_sync_routers_task(self.context)

   File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 519, in
 periodic_sync_routers_task

 self.fetch_and_sync_all_routers(context, ns_manager)

   File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py,
 line 91, in __exit__

 self._cleanup(_ns_prefix, ns_id)

   File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py,
 line 140, in _cleanup

 ns.delete()

   File /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py, line 147,
 in delete

 raise TypeError(ss)

 TypeError: ss



 It seems that the fip namespace is not processed at startup of L3 agent,
 and the cleanup is removing the namespace…

 It is also removing the interface to local dvr router connection so… VM
 has no internet access with floating IP:

 Command: ['ip', 'netns', 'exec',
 'fip-8223e12e-837b-49d4-9793-63603fccbc9f', 'ip', 'link', 'del',
 u'fpr-fe517b4b-d']



 If the interface inside the fip namespace is not deleted, the VM has full
 internet access without any downtime.



 Ca we consider it a bug? I guess it is something in startup/full-sync
 logic since the log is saying:


 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid



 I think yes, we can consider it a bug. Can you please file one? I can take
 and probably fix it.





 And after finishing the sync loop, the fip namespace is deleted…



 Regards,

 Artur



 *From:* Kevin Benton [mailto:blak...@gmail.com]
 *Sent:* Thursday, August 6, 2015 7:40 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [neutron][dvr] Removing fip namespace when
 restarting L3 agent.



 Can you try setting the following to False:


 https://github.com/openstack/neutron/blob/dc0944f2d4e347922054bba679ba7f5d1ae6ffe2/etc/l3_agent.ini#L97



 On Wed, Aug 5, 2015 at 3:36 PM, Korzeniewski, Artur 
 artur.korzeniew...@intel.com wrote:

 Hi all,

 During testing of Neutron upgrades, I have found that restarting the L3
 agent in DVR mode is causing the VM network downtime for configured
 floating IP.

 The lockdown is visible when pinging the VM from external network, 2-3
 pings are lost.

 The responsible place in code is:

 DVR: destroy fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from
 (pid=156888) delete
 /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164



 Can someone explain why the fip namespace is deleted? Can we workout the
 situation, when there is no downtime of VM access?



 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

[Oleg Bondarev]

On Thu, Aug 6, 2015 at 5:23 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.com wrote:

 Thanks Kevin for that hint.

 But it does not resolve the connectivity problem, it is just not removing
 the namespace when it is asked to.

 The real question is, why do we invoke the 
 /neutron/neutron/agent/l3/dvr_fip_ns.py
 FipNamespace.delete() method in the first place?



 I’ve captured the traceback for this situation:

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to
 access
 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file
 /opt/openstack/neutron/neutron/agent/linux/utils.py:222

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to
 access
 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file
 /opt/openstack/neutron/neutron/agent/linux/utils.py:222

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.external_process [-] No
 process started for 8223e12e-837b-49d4-9793-63603fccbc9f from (pid=70216)
 disable /opt/openstack/neutron/neutron/agent/linux/external_process.py:113

 Traceback (most recent call last):

  File /usr/local/lib/python2.7/dist-packages/eventlet/queue.py, line
 117, in switch

 self.greenlet.switch(value)

   File /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py,
 line 214, in main

 result = function(*args, **kwargs)

   File /usr/local/lib/python2.7/dist-packages/oslo_service/service.py,
 line 612, in run_service

 service.start()

   File /opt/openstack/neutron/neutron/service.py, line 233, in start

 self.manager.after_start()

   File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 641, in
 after_start

 self.periodic_sync_routers_task(self.context)

   File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 519, in
 periodic_sync_routers_task

 self.fetch_and_sync_all_routers(context, ns_manager)

   File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py,
 line 91, in __exit__

 self._cleanup(_ns_prefix, ns_id)

   File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py,
 line 140, in _cleanup

 ns.delete()

   File /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py, line 147,
 in delete

 raise TypeError(ss)

 TypeError: ss



 It seems that the fip namespace is not processed at startup of L3 agent,
 and the cleanup is removing the namespace…

 It is also removing the interface to local dvr router connection so… VM
 has no internet access with floating IP:

 Command: ['ip', 'netns', 'exec',
 'fip-8223e12e-837b-49d4-9793-63603fccbc9f', 'ip', 'link', 'del',
 u'fpr-fe517b4b-d']



 If the interface inside the fip namespace is not deleted, the VM has full
 internet access without any downtime.



 Ca we consider it a bug? I guess it is something in startup/full-sync
 logic since the log is saying:


 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid


I think yes, we can consider it a bug. Can you please file one? I can take
and probably fix it.




 And after finishing the sync loop, the fip namespace is deleted…



 Regards,

 Artur



 *From:* Kevin Benton [mailto:blak...@gmail.com]
 *Sent:* Thursday, August 6, 2015 7:40 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [neutron][dvr] Removing fip namespace when
 restarting L3 agent.



 Can you try setting the following to False:


 https://github.com/openstack/neutron/blob/dc0944f2d4e347922054bba679ba7f5d1ae6ffe2/etc/l3_agent.ini#L97



 On Wed, Aug 5, 2015 at 3:36 PM, Korzeniewski, Artur 
 artur.korzeniew...@intel.com wrote:

 Hi all,

 During testing of Neutron upgrades, I have found that restarting the L3
 agent in DVR mode is causing the VM network downtime for configured
 floating IP.

 The lockdown is visible when pinging the VM from external network, 2-3
 pings are lost.

 The responsible place in code is:

 DVR: destroy fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from
 (pid=156888) delete
 /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164



 Can someone explain why the fip namespace is deleted? Can we workout the
 situation, when there is no downtime of VM access?



 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk




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





 --

 Kevin Benton

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

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

[Oleg Bondarev]

+1

On Thu, Jul 16, 2015 at 2:04 AM, Brian Haley brian.ha...@hp.com wrote:

 +1


 On 07/15/2015 02:47 PM, Carl Baldwin wrote:

 As the Neutron L3 Lieutenant along with Kevin Benton for control
 plane, and Assaf Muller for testing, I would like to propose Cedric
 Brandily as a member of the Neutron core reviewer team under these
 areas of focus.

 Cedric has been a long time contributor to Neutron showing expertise
 particularly in these areas.  His knowledge and involvement will be
 very important to the project.  He is a trusted member of our
 community.  He has been reviewing consistently [1][2] and community
 feedback that I've received indicates that he is a solid reviewer.

 Existing Neutron core reviewers from these areas of focus, please vote
 +1/-1 for the addition of Cedric to the team.

 Thanks!
 Carl Baldwin

 [1] https://review.openstack.org/#/q/reviewer:zzelle%2540gmail.com,n,z
 [2] http://stackalytics.com/report/contribution/neutron-group/90

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



 __
 OpenStack Development Mailing 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]Subnet's dns nameserver doesn't order by input

[Oleg Bondarev]

Hi,

Currently there is no dns servers prioritization for subnets in Neutron.
There is an opened bug for this:
https://bugs.launchpad.net/neutron/+bug/1218629

Thanks,
Oleg

On Mon, Jul 6, 2015 at 11:21 AM, Zhi Chang chang...@unitedstack.com wrote:

 Hi, all
 Subnet's nameserver is out of order. That is to say, cmd neutron
 subnet-update [subnet-id] dns_nameservers list=true 1.2.3.4 5.6.7.8
 and neutron subnet-update [subnet-id] dns_nameservers list=true
 5.6.7.8 1.2.3.4 is same. I think that we often have two or more dns
 nameservers, one is a main nameserver, another is a backup. Therefore, I
 think we should make difference of the above command.
 Does anyone have ideas?

 Thx
 Zhi Chang


 __
 OpenStack Development Mailing 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] - Proposing Miguel Angel Ajo for the Control Plane core team

[Oleg Bondarev]

Big +1

On Mon, Jul 6, 2015 at 3:43 PM, Assaf Muller amul...@redhat.com wrote:

 +1!

 - Original Message -
  A huge +1
 
  From: Kevin Benton  blak...@gmail.com 
  Reply-To: OpenStack List  openstack-dev@lists.openstack.org 
  Date: Monday, July 6, 2015 at 1:02 PM
  To: OpenStack List  openstack-dev@lists.openstack.org 
  Subject: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the
  Control Plane core team
 
 
 
  Hello!
 
  As the Lieutenant of the built-in control plane[1], I am proposing to add
  Miguel Angel Ajo to the control plane core reviewer team.
 
  His review stats are inline with the other core reviewers[2], and his
 work on
  improving the stability/performance of the agents over the last year has
  been important in making the reference implementation reliable.
 
  Existing cores, please vote +1/-1 for his addition to the team.
 
  Cheers!
 
  1.
 http://docs.openstack.org/developer/neutron/policies/core-reviewers.html
  2. http://stackalytics.com/report/contribution/neutron/30
  http://stackalytics.com/report/contribution/neutron/60
  http://stackalytics.com/report/contribution/neutron/90
 
  --
  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

__
OpenStack Development Mailing 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] Proposing YAMAMOTO Takashi for the Control Plane core team

[Oleg Bondarev]

+1

On Mon, Jun 15, 2015 at 12:16 PM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Not on the list either, but I want to +1 what Henry said. Yamamoto's
 reviews expand to the whole code base and are pretty always *very* usefu
 l.

 On 06/12/2015 11:39 PM, Henry Gessau wrote:
  Although I am not on your list I would like to add my +1! Yamamoto
  shows great attention to detail in code reviews and frequently
  finds real issues that were not spotted by others.
 
  On Thu, Jun 11, 2015, Kevin Benton blak...@gmail.com wrote:
  Hello all!
 
  As the Lieutenant of the built-in control plane[1], I would like
  YAMAMOTO Takashi to be a member of the control plane core
  reviewer team.
 
  He has been extensively reviewing the entire codebase[2] and his
  feedback on patches related to the reference implementation has
  been very useful. This includes everything ranging from the AMPQ
  API to OVS flows.
 
  Existing cores that have spent time working on the reference
  implementation (agents and AMQP code), please vote +1/-1 for his
  addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando,
  Carl and Oleg; you have all been reviewing things in these areas
  recently so I would like to hear from you specifically.
 
  1.
  http://docs.openstack.org/developer/neutron/policies/core-reviewers.h
 tml#core-review-hierarchy
 
 
 2. http://stackalytics.com/report/contribution/neutron-group/90
 
 
  Cheers -- 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
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVfpgHAAoJEC5aWaUY1u57z40IAL8HpGOEQY7aW1aa39C9ig3Y
 bNLEabeQ0K5a4+5ynVLIm1sEl4s3GF2r0gCXak9FrkqjHx2r8VeyOx8TqrCj8gX3
 +4aHI7n6rJoJtINuTd+bN7T65uaZE86erOcZN+yma5V69ObfIZhIfQKr3BMaBeZT
 ah5hkUKl88ckLL5zqc0HnT4wcFH/3Ved2fuhP7hw/IEGMFsqTDS8QUTdXg7/OF5t
 fLt0NluKoOuNMOk8dTqpqtQtiyS/E5TH+miVOzyrUeUmZOEayOO3O2b/9QRkX/hL
 ijv1j+clT69fhoVAWSaeR7IsXSfqMuKK/hrVtjnyDpBH4KuZnl3QbRpKJ6Yi3bw=
 =qnTt
 -END PGP SIGNATURE-

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

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

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

[Oleg Bondarev]

+1

On Mon, Jun 15, 2015 at 12:14 PM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 No doubt +1.

 On 06/12/2015 09:44 PM, Kevin Benton wrote:
  Hello!
 
  As the Lieutenant of the built-in control plane[1], I would like
  Rossella Sblendido to be a member of the control plane core
  reviewer team.
 
  Her review stats are in line with other cores[2] and her feedback
  on patches related to the agents has been great. Additionally, she
  has been working quite a bit on the blueprint to restructure the L2
  agent code so she is very familiar with the agent code and the APIs
  it leverages.
 
  Existing cores that have spent time working on the reference
  implementation (agents and AMQP code), please vote +1/-1 for her
  addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl
  and Oleg; you have all been reviewing things in these areas
  recently so I would like to hear from you specifically.
 
  1.
  http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht
 ml#core-review-hierarchy
 
 
 2. http://stackalytics.com/report/contribution/neutron-group/30
 
  Cheers -- 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
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVfpdmAAoJEC5aWaUY1u574skIAOm15mNKujH3X3XSpwtmy+V4
 cWNvjYZy0lCG2lbyAwGwgQD0Ybs88/RKOZPPpu9gugAuWcFQRHMSMcsahaTLcH5B
 6imK0tEUUn2HdCd9522kEWtf7Hkpux6p5TLQQo2tucvIBQohJuU42EidfKs9Peat
 ed/2kiXm+TGRSnZHAYwzJIrttux3ntTLQeTvElo+4vUQEQJNwm8eguXiAPENEjr9
 7Ou3TgnYeLXsfVopHXNV+jtkHDr92giB4joODqwc8RNDKE2+dhaqDxCrXq6ksYq7
 RFiyVy1qve394ebP0Ta0dq6LKmAYZCnRC9i928GSK5RvQBvcnJRiyFGIgtn4Qu0=
 =59av
 -END PGP SIGNATURE-

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

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

Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team

[Oleg Bondarev]

+1

On Thu, May 28, 2015 at 5:01 PM, Henry Gessau ges...@cisco.com wrote:

 +1

 On Thu, May 28, 2015, Kyle Mestery mest...@mestery.com wrote:
  Folks, I'd like to propose Assaf Muller to be a member of the Neutron
 core
  reviewer team. Assaf has been a long time contributor in Neutron, and
 he's
  also recently become my testing Lieutenant. His influence and knowledge
 in
  testing will be critical to the team in Liberty and beyond. In addition
 to
  that, he's done some fabulous work for Neutron around L3 HA and DVR.
 Assaf has
  become a trusted member of our community. His review stats place him in
 the
  pack with the rest of the Neutron core reviewers.
 
  I'd also like to take this time to remind everyone that reviewing code
 is a
  responsibility, in Neutron the same as other projects. And core
 reviewers are
  especially beholden to this responsibility. I'd also like to point out
 that
  +1/-1 reviews are very useful, and I encourage everyone to continue
 reviewing
  code even if you are not a core reviewer.
 
  Existing Neutron cores, please vote +1/-1 for the addition of Assaf to
 the
  core reviewer team.
 
  Thanks!
  Kyle
 
  [1] http://stackalytics.com/report/contribution/neutron-group/180


 __
 OpenStack Development Mailing 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] DVR and l2 population

[Oleg Bondarev]

Hi,

with https://review.openstack.org/166707/ l2_population is only checked
when tunneling is enabled.

Thanks,
Oleg

On Tue, Apr 21, 2015 at 5:18 PM, Itzik Brown itz...@redhat.com wrote:

 Hi,

 As I understand it l2 population is not a requirement but it's strongly
 recommended.
 https://review.openstack.org/#/c/165311/ validates  that OVS agent is
 configured with l2_population enabled when DVR is enabled.
 Now that DVR supports VLAN do we want to take back this validation ?

 Itzik


 __
 OpenStack Development Mailing 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] Better-quotas blueprint

[Oleg Bondarev]

On Thu, Mar 5, 2015 at 6:03 PM, Kyle Mestery mest...@mestery.com wrote:

 On Thu, Mar 5, 2015 at 3:29 AM, Salvatore Orlando sorla...@nicira.com
 wrote:

 I was hoping to push code today for [1], but unfortunately I got caught
 by something else during this week and I'll miss the code proposal deadline.

 I would like to apply for a FFE; however, since I've experienced FFEs in
 previous release cycles, please treat this request as best-effort if there
 ore other work items with higher priority applying for a FFE.

 Thanks for the note Salvatore. I'm fine with granting this an FFE given
 it's a good community feature and it's High priority. Do you think you'll
 have code pushed out by early next week? Also, lets try to find two core
 reviewers who can iterate with you quickly once you do push it so we can
 land it fairly fast.


I can be one of those.

Thanks,
Oleg



 Thanks,
 Kyle


 Salvatore

 [1] https://blueprints.launchpad.net/neutron/+spec/better-quotas



 __
 OpenStack Development Mailing 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] security group fails to attach to an instance if port-id is specified during boot.

[Oleg Bondarev]

On Tue, Feb 10, 2015 at 5:26 PM, Feodor Tersin fter...@cloudscaling.com
wrote:

 I definitely don't expect any change of the existing port in the case with
 two nics. However in the case of single nic a question like 'what is impact
 of security-groups parameter' arises.
 Also a similar question arises out of '--nic port-id=xxx,v4-fixed-ip=yyy'
 combination.
 Moreover, if we assume that, for example, security-groups parameter
 affects the specified port, the next question is 'what is the result group
 set'. Does it replace groups of the port, or just update them?

 Thus i agree with you, that this part of nova API is not clear now. But
 the case with two nics make sense, works now, and can be used by someone.
 Do you really want to break it?


I don't want to break anything :)
I guess the only option then is to just log a warning that security groups
are ignored in case port_id is provided on boot -
but this still leaves a chance of broken user expectations.




 On Tue, Feb 10, 2015 at 10:29 AM, Oleg Bondarev obonda...@mirantis.com
 wrote:



 On Mon, Feb 9, 2015 at 8:50 PM, Feodor Tersin fter...@cloudscaling.com
 wrote:

 nova boot ... --nic port-id=xxx --nic net-id=yyy
 this case is valid, right?
 I.e. i want to boot instance with two ports. The first port is
 specified, but the second one is created at network mapping stage.
 If i specify a security group as well, it will be used for the second
 port (if not - default group will):
 nova boot ... --nic port-id=xxx --nic net-id=yyy --security-groups sg-1
 Thus a port and a security group can be specified together.


 The question here is what do you expect for the existing port - it's
 security groups updated or not?
 Will it be ok to silently (or with warning in logs) ignore security
 groups for it?
 If it's ok then is it ok to do the same for:
 nova boot ... --nic port-id=xxx --security-groups sg-1
 where the intention is clear enough?



 On Mon, Feb 9, 2015 at 7:14 PM, Matt Riedemann 
 mrie...@linux.vnet.ibm.com wrote:



 On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

 On Fri, 26 Sep 2014 11:25:49 +0400
 Oleg Bondarev obonda...@mirantis.com wrote:

  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:

I think the expectation is that if a user is already interaction
 with Neutron to create ports then they should do the security group
 assignment in Neutron as well.


 Agree. However what do you think a user expects when he/she boots a
 vm (no matter providing port_id or just net_id)
 and specifies security_groups? I think the expectation should be that
 instance will become a member of the specified groups.
 Ignoring security_groups parameter in case port is provided (as it is
 now) seems completely unfair to me.


 One option would be to return a 400 if both port id and security_groups
 is supplied.

 Chris

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


 Coming back to this, we now have a change from Oleg [1] after an
 initial attempt that was reverted because it would break server creates if
 you specified a port (because the original change would blow up when the
 compute API added the 'default' security group to the request').

 The new change doesn't add the 'default' security group to the request
 so if you specify a security group and port on the request, you'll now get
 a 400 error response.

 Does this break API compatibility?  It seems this falls under the first
 bullet here [2], A change such that a request which was successful before
 now results in an error response (unless the success reported previously
 was hiding an existing error condition).  Does that caveat in parenthesis
 make this OK?

 It seems like we've had a lot of talk about warts in the compute v2 API
 for cases where an operation is successful but didn't yield the expected
 result, but we can't change them because of API backwards compatibility
 concerns so I'm hesitant on this.

 We also definitely need a Tempest test here, which I'm looking into.  I
 think I can work this into the test_network_basic_ops scenario test.

 [1] https://review.openstack.org/#/c/154068/
 [2] https://wiki.openstack.org/wiki/APIChangeGuidelines#
 Generally_Not_Acceptable

 --

 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] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

[Oleg Bondarev]

On Mon, Feb 9, 2015 at 8:50 PM, Feodor Tersin fter...@cloudscaling.com
wrote:

 nova boot ... --nic port-id=xxx --nic net-id=yyy
 this case is valid, right?
 I.e. i want to boot instance with two ports. The first port is specified,
 but the second one is created at network mapping stage.
 If i specify a security group as well, it will be used for the second port
 (if not - default group will):
 nova boot ... --nic port-id=xxx --nic net-id=yyy --security-groups sg-1
 Thus a port and a security group can be specified together.


The question here is what do you expect for the existing port - it's
security groups updated or not?
Will it be ok to silently (or with warning in logs) ignore security groups
for it?
If it's ok then is it ok to do the same for:
nova boot ... --nic port-id=xxx --security-groups sg-1
where the intention is clear enough?



 On Mon, Feb 9, 2015 at 7:14 PM, Matt Riedemann mrie...@linux.vnet.ibm.com
  wrote:



 On 9/26/2014 3:19 AM, Christopher Yeoh wrote:

 On Fri, 26 Sep 2014 11:25:49 +0400
 Oleg Bondarev obonda...@mirantis.com wrote:

  On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:

I think the expectation is that if a user is already interaction
 with Neutron to create ports then they should do the security group
 assignment in Neutron as well.


 Agree. However what do you think a user expects when he/she boots a
 vm (no matter providing port_id or just net_id)
 and specifies security_groups? I think the expectation should be that
 instance will become a member of the specified groups.
 Ignoring security_groups parameter in case port is provided (as it is
 now) seems completely unfair to me.


 One option would be to return a 400 if both port id and security_groups
 is supplied.

 Chris

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


 Coming back to this, we now have a change from Oleg [1] after an initial
 attempt that was reverted because it would break server creates if you
 specified a port (because the original change would blow up when the
 compute API added the 'default' security group to the request').

 The new change doesn't add the 'default' security group to the request so
 if you specify a security group and port on the request, you'll now get a
 400 error response.

 Does this break API compatibility?  It seems this falls under the first
 bullet here [2], A change such that a request which was successful before
 now results in an error response (unless the success reported previously
 was hiding an existing error condition).  Does that caveat in parenthesis
 make this OK?

 It seems like we've had a lot of talk about warts in the compute v2 API
 for cases where an operation is successful but didn't yield the expected
 result, but we can't change them because of API backwards compatibility
 concerns so I'm hesitant on this.

 We also definitely need a Tempest test here, which I'm looking into.  I
 think I can work this into the test_network_basic_ops scenario test.

 [1] https://review.openstack.org/#/c/154068/
 [2] https://wiki.openstack.org/wiki/APIChangeGuidelines#
 Generally_Not_Acceptable

 --

 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

Re: [openstack-dev] [neutron] Changes to the core team

[Oleg Bondarev]

+1 for Doug, he does a great job!

Thanks,
Oleg

On Fri, Jan 16, 2015 at 9:59 AM, Salvatore Orlando sorla...@nicira.com
wrote:

 I agree with the proposed changes.

 I would also like to take a chance to thank Sumit for the effort he has
 put in this project over several years - he has been in the core team since
 the project's inception and has been a witness of all its developments -
 both the good and the bad ones!

 Salvatore

 On 16 January 2015 at 04:38, Henry Gessau ges...@cisco.com wrote:

 On Thu, Jan 15, 2015, Kyle Mestery mest...@mestery.com wrote:
  As part of the change, I'd like to propose Doug Wiegley as a new
 Neutron core
  reviewer. Doug has been actively reviewing code across not only all the
  Neutron projects, but also other projects such as infra. His help and
 work in
  the services split in December were the reason we were so successful in
 making
  that happen. Doug has also been instrumental in the Neutron LBaaS V2
 rollout,
  as well as helping to merge code in the other neutron service
 repositories.

 +1 for Doug.


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



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


__
OpenStack Development Mailing 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] [Openstack-operators] The state of nova-network to neutron migration

[Oleg Bondarev]

On Tue, Dec 30, 2014 at 12:56 AM, Anita Kuno ante...@anteaya.info wrote:

 On 12/24/2014 04:07 AM, Oleg Bondarev wrote:
  On Mon, Dec 22, 2014 at 10:08 PM, Anita Kuno ante...@anteaya.info
 wrote:
 
  On 12/22/2014 01:32 PM, Joe Gordon wrote:
  On Fri, Dec 19, 2014 at 9:28 AM, Kyle Mestery mest...@mestery.com
  wrote:
 
  On Fri, Dec 19, 2014 at 10:59 AM, Anita Kuno ante...@anteaya.info
  wrote:
 
  Rather than waste your time making excuses let me state where we are
  and
  where I would like to get to, also sharing my thoughts about how you
  can
  get involved if you want to see this happen as badly as I have been
  told
  you do.
 
  Where we are:
  * a great deal of foundation work has been accomplished to
 achieve
  parity with nova-network and neutron to the extent that those
 involved
  are ready for migration plans to be formulated and be put in place
  * a summit session happened with notes and intentions[0]
  * people took responsibility and promptly got swamped with other
  responsibilities
  * spec deadlines arose and in neutron's case have passed
  * currently a neutron spec [1] is a work in progress (and it
 needs
  significant work still) and a nova spec is required and doesn't have
 a
  first draft or a champion
 
  Where I would like to get to:
  * I need people in addition to Oleg Bondarev to be available to
  help
  come up with ideas and words to describe them to create the specs in
 a
  very short amount of time (Oleg is doing great work and is a fabulous
  person, yay Oleg, he just can't do this alone)
  * specifically I need a contact on the nova side of this complex
  problem, similar to Oleg on the neutron side
  * we need to have a way for people involved with this effort to
  find
  each other, talk to each other and track progress
  * we need to have representation at both nova and neutron weekly
  meetings to communicate status and needs
 
  We are at K-2 and our current status is insufficient to expect this
  work
  will be accomplished by the end of K-3. I will be championing this
  work,
  in whatever state, so at least it doesn't fall off the map. If you
  would
  like to help this effort please get in contact. I will be thinking of
  ways to further this work and will be communicating to those who
  identify as affected by these decisions in the most effective methods
  of
  which I am capable.
 
  Thank you to all who have gotten us as far as well have gotten in
 this
  effort, it has been a long haul and you have all done great work.
 Let's
  keep going and finish this.
 
  Thank you,
  Anita.
 
  Thank you for volunteering to drive this effort Anita, I am very
 happy
  about this. I support you 100%.
 
  I'd like to point out that we really need a point of contact on the
 nova
  side, similar to Oleg on the Neutron side. IMHO, this is step 1 here
 to
  continue moving this forward.
 
 
  At the summit the nova team marked the nova-network to neutron
 migration
  as
  a priority [0], so we are collectively interested in seeing this happen
  and
  want to help in any way possible.   With regard to a nova point of
  contact,
  anyone in nova-specs-core should work, that way we can cover more time
  zones.
 
  From what I can gather the first step is to finish fleshing out the
 first
  spec [1], and it sounds like it would be good to get a few nova-cores
  reviewing it as well.
 
 
 
 
  [0]
 
 
 http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html
  [1] https://review.openstack.org/#/c/142456/
 
 
  Wonderful, thank you for the support Joe.
 
  It appears that we need to have a regular weekly meeting to track
  progress in an archived manner.
 
  I know there was one meeting November but I don't know what it was
  called so so far I can't find the logs for that.
 
 
  It wasn't official, we just gathered together on #novamigration.
 Attaching
  the log here.
 
 Ah, that would explain why I couldn't find the log. Thanks for the
 attachment.
 
  So if those affected by this issue can identify what time (UTC please,
  don't tell me what time zone you are in it is too hard to guess what UTC
  time you are available) and day of the week you are available for a
  meeting I'll create one and we can start talking to each other.
 
  I need to avoid Monday 1500 and 2100 UTC, Tuesday 0800 UTC, 1400 UTC and
  1900 - 2200 UTC, Wednesdays 1500 - 1700 UTC, Thursdays 1400 and 2100
 UTC.
 
 
  I'm available each weekday 0700-1600 UTC, 1700-1800 UTC is also
 acceptable.
 
  Thanks,
  Oleg
 Wonderful, thank you Oleg. We will aim for a meeting time in this range.
 I also understand holidays in Russia start on January 1 and go until the
 11th or the 12th, I'm guessing this includes you.


Correct. However I'll be available since January 5. Thanks Anita.

Thanks,
Oleg


 Thanks,
 Anita.
 
 
 
  Thanks,
  Anita.
 
 
  Thanks,
  Kyle
 
 
  [0]
 https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron
  [1] https

Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

[Oleg Bondarev]

On Mon, Dec 22, 2014 at 10:08 PM, Anita Kuno ante...@anteaya.info wrote:

 On 12/22/2014 01:32 PM, Joe Gordon wrote:
  On Fri, Dec 19, 2014 at 9:28 AM, Kyle Mestery mest...@mestery.com
 wrote:
 
  On Fri, Dec 19, 2014 at 10:59 AM, Anita Kuno ante...@anteaya.info
 wrote:
 
  Rather than waste your time making excuses let me state where we are
 and
  where I would like to get to, also sharing my thoughts about how you
 can
  get involved if you want to see this happen as badly as I have been
 told
  you do.
 
  Where we are:
  * a great deal of foundation work has been accomplished to achieve
  parity with nova-network and neutron to the extent that those involved
  are ready for migration plans to be formulated and be put in place
  * a summit session happened with notes and intentions[0]
  * people took responsibility and promptly got swamped with other
  responsibilities
  * spec deadlines arose and in neutron's case have passed
  * currently a neutron spec [1] is a work in progress (and it needs
  significant work still) and a nova spec is required and doesn't have a
  first draft or a champion
 
  Where I would like to get to:
  * I need people in addition to Oleg Bondarev to be available to
 help
  come up with ideas and words to describe them to create the specs in a
  very short amount of time (Oleg is doing great work and is a fabulous
  person, yay Oleg, he just can't do this alone)
  * specifically I need a contact on the nova side of this complex
  problem, similar to Oleg on the neutron side
  * we need to have a way for people involved with this effort to
 find
  each other, talk to each other and track progress
  * we need to have representation at both nova and neutron weekly
  meetings to communicate status and needs
 
  We are at K-2 and our current status is insufficient to expect this
 work
  will be accomplished by the end of K-3. I will be championing this
 work,
  in whatever state, so at least it doesn't fall off the map. If you
 would
  like to help this effort please get in contact. I will be thinking of
  ways to further this work and will be communicating to those who
  identify as affected by these decisions in the most effective methods
 of
  which I am capable.
 
  Thank you to all who have gotten us as far as well have gotten in this
  effort, it has been a long haul and you have all done great work. Let's
  keep going and finish this.
 
  Thank you,
  Anita.
 
  Thank you for volunteering to drive this effort Anita, I am very happy
  about this. I support you 100%.
 
  I'd like to point out that we really need a point of contact on the nova
  side, similar to Oleg on the Neutron side. IMHO, this is step 1 here to
  continue moving this forward.
 
 
  At the summit the nova team marked the nova-network to neutron migration
 as
  a priority [0], so we are collectively interested in seeing this happen
 and
  want to help in any way possible.   With regard to a nova point of
 contact,
  anyone in nova-specs-core should work, that way we can cover more time
  zones.
 
  From what I can gather the first step is to finish fleshing out the first
  spec [1], and it sounds like it would be good to get a few nova-cores
  reviewing it as well.
 
 
 
 
  [0]
 
 http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html
  [1] https://review.openstack.org/#/c/142456/
 
 
 Wonderful, thank you for the support Joe.

 It appears that we need to have a regular weekly meeting to track
 progress in an archived manner.

 I know there was one meeting November but I don't know what it was
 called so so far I can't find the logs for that.


It wasn't official, we just gathered together on #novamigration. Attaching
the log here.


 So if those affected by this issue can identify what time (UTC please,
 don't tell me what time zone you are in it is too hard to guess what UTC
 time you are available) and day of the week you are available for a
 meeting I'll create one and we can start talking to each other.

 I need to avoid Monday 1500 and 2100 UTC, Tuesday 0800 UTC, 1400 UTC and
 1900 - 2200 UTC, Wednesdays 1500 - 1700 UTC, Thursdays 1400 and 2100 UTC.


I'm available each weekday 0700-1600 UTC, 1700-1800 UTC is also acceptable.

Thanks,
Oleg



 Thanks,
 Anita.

 
  Thanks,
  Kyle
 
 
  [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron
  [1] https://review.openstack.org/#/c/142456/
 
  ___
  OpenStack-operators mailing list
  openstack-operat...@lists.openstack.org
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 


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

Re: [openstack-dev] Topic: Reschedule Router to a different agent with multiple external networks.

[Oleg Bondarev]

Hi Swaminathan Vasudevan,

please check the following docstring
of L3_NAT_dbonly_mixin._check_router_needs_rescheduling:


*def _check_router_needs_rescheduling(self, context, router_id,
gw_info):*
*Checks whether router's l3 agent can handle the given network*

*When external_network_bridge is set, each L3 agent can be
associated*
*with at most one external network. If router's new external
gateway*
*is on other network then the router needs to be rescheduled to the*
*proper l3 agent.*
*If external_network_bridge is not set then the agent*
*can support multiple external networks and rescheduling is not
needed*

So there can still be agents which can handle only one ext net - for such
agents resheduling is needed.

Thanks,
Oleg

On Wed, Dec 17, 2014 at 8:56 PM, Vasudevan, Swaminathan (PNB Roseville) 
swaminathan.vasude...@hp.com wrote:

  Hi Folks,



 *Reschedule router if new external gateway is on other network*

 An L3 agent may be associated with just one external network.

 If router's new external gateway is on other network then the router

 needs to be rescheduled to the proper l3 agent



 This patch was introduced when there was no support for L3-agent to handle
 multiple external networks.



 Do we think we should still retain this original behavior even if we have
 support for multiple external networks by single L3-agent.



 Can anyone comment on this.



 Thanks



 Swaminathan Vasudevan

 Systems Software Engineer (TC)





 HP Networking

 Hewlett-Packard

 8000 Foothills Blvd

 M/S 5541

 Roseville, CA - 95747

 tel: 916.785.0937

 fax: 916.785.1815

 email: swaminathan.vasude...@hp.com





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


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

Re: [openstack-dev] [nova][neutron] Migration from Nova-net to Neutron

[Oleg Bondarev]

Hi,

please see answers inline.

On Thu, Nov 13, 2014 at 2:59 PM, Hassaan Pasha pasha.hass...@gmail.com
wrote:

 Dear all,

 I have some questions related to the migration of instances from nova-net
 to neutron.

 Assuming we have deployed Openstack with neutron disabled and we are
 running some instances on it.

 Now suppose we want to migrate the instances to neutron, what mechanism
 would we require considering we don't have neutron running.


 Is there a way to have nova-net and neutron running simultaneously?
 Can we enable neutron services during run time?


AFAIK nothing prevents neutron from running along with nova-net. It only
matters how nova is configured (whether it uses neutron or nova-net as
primary network API)


 How are we handling the migration process. If we need to deploy a separate
 stack with neutron enabled, I don't understand how nova would manage to
 migrate the instances.


With the current plan (see
https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron) you
will not have to have a separate stack.



 I would really appreciate your help to better understand how the migration
 process would be managed.


Neutron migration is under design now, you'll be able to find more details
regarding the process once the specification is published.


 Regards
 Hassaan Pasha

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


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

Re: [openstack-dev] [neutron] social event

[Oleg Bondarev]

Please count me in.

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

[openstack-dev] [Nova] Launching multiple VMs in Nova

[Oleg Bondarev]

Hi,

It turns out that there is a 1:1 relationship between rpc_thread_pool_size
messaging config [1] and the number of instances that can be spawned
simultaneously.
Please see bug [2] for more details.
I think this should be at least documented. Thoughts?

Thanks,
Oleg

[1]
https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/_executors/impl_eventlet.py
[2] https://bugs.launchpad.net/neutron/+bug/1372049
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

[Oleg Bondarev]

On Fri, Sep 26, 2014 at 3:30 AM, Day, Phil philip@hp.com wrote:

  I think the expectation is that if a user is already interaction with
 Neutron to create ports then they should do the security group assignment
 in Neutron as well.


Agree. However what do you think a user expects when he/she boots a vm (no
matter providing port_id or just net_id)
and specifies security_groups? I think the expectation should be that
instance will become a member of the specified groups.
Ignoring security_groups parameter in case port is provided (as it is now)
seems completely unfair to me.



 The trouble I see with supporting this way of assigning security groups is
 what should the correct behavior be if the user passes more than one port
 into the Nova boot command ?   In the case where Nova is creating the ports
 it kind of feels (just)  Ok to assign the security groups to all the
 ports.  In the case where the ports have already been created then it
 doesn’t feel right to me that Nova modifies them.


An option may be to append existing ports' security groups with ones that a
user specifies during instance boot.
This way we will preserve both user expectations - first when the port is
created and second when the instance is spawned.
Thoughts?













 *From:* Oleg Bondarev [mailto:obonda...@mirantis.com]
 *Sent:* 25 September 2014 08:19
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [NOVA] security group fails to attach to
 an instance if port-id is specified during boot.



 Hi Parikshit,



 Looks like a bug. Currently if port is specified its security groups are
 not updated, it shpould be fixed.

 I've reported https://bugs.launchpad.net/nova/+bug/1373774 to track this.

 Thanks for reporting!



 Thanks,

 Oleg



 On Thu, Sep 25, 2014 at 10:15 AM, Parikshit Manur 
 parikshit.ma...@citrix.com wrote:

  Hi All,

 Creation of server with command  ‘nova boot  --image
 image --flavor m1.medium --nic port-id=port-id --security-groups
  sec_grp name’ fails to attach the security group to the
 port/instance. The response payload has the security group added but only
 default security group is attached to the instance.  Separate action has to
 be performed on the instance to add sec_grp, and it is successful.
 Supplying the same with ‘--nic net-id=net-id’ works as expected.



 Is this the expected behaviour / are there any other options which needs
 to be specified to add the security group when port-id needs to be attached
 during boot.



 Thanks,

 Parikshit Manur


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



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


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

Re: [openstack-dev] [NOVA] security group fails to attach to an instance if port-id is specified during boot.

[Oleg Bondarev]

Hi Parikshit,

Looks like a bug. Currently if port is specified its security groups are
not updated, it shpould be fixed.
I've reported https://bugs.launchpad.net/nova/+bug/1373774 to track this.
Thanks for reporting!

Thanks,
Oleg

On Thu, Sep 25, 2014 at 10:15 AM, Parikshit Manur 
parikshit.ma...@citrix.com wrote:

  Hi All,

 Creation of server with command  ‘nova boot  --image
 image --flavor m1.medium --nic port-id=port-id --security-groups
  sec_grp name’ fails to attach the security group to the
 port/instance. The response payload has the security group added but only
 default security group is attached to the instance.  Separate action has to
 be performed on the instance to add sec_grp, and it is successful.
 Supplying the same with ‘--nic net-id=net-id’ works as expected.



 Is this the expected behaviour / are there any other options which needs
 to be specified to add the security group when port-id needs to be attached
 during boot.



 Thanks,

 Parikshit Manur

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


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

Re: [openstack-dev] [neutron] Juno-3 BP meeting

[Oleg Bondarev]

Works for me.


On Wed, Aug 27, 2014 at 10:54 AM, Assaf Muller amul...@redhat.com wrote:

 Good for me.

 - Original Message -
  Works perfect for me. I will join.
 
  Sent from my Android phone using TouchDown ( www.nitrodesk.com )
 
 
  -Original Message-
  From: Carl Baldwin [c...@ecbaldwin.net]
  Received: Wednesday, 27 Aug 2014, 5:07
  To: OpenStack Development Mailing List [
 openstack-dev@lists.openstack.org]
  Subject: Re: [openstack-dev] [neutron] Juno-3 BP meeting
 
 
 
 
  Kyle,
 
  These are three good ones. I've been reviewing the HA ones and have had
 an
  eye on the other two.
 
  1300 is a bit early but I'll plan to be there.
 
  Carl
  On Aug 26, 2014 4:04 PM, Kyle Mestery  mest...@mestery.com  wrote:
 
 
  I'd like to propose a meeting at 1300UTC on Thursday in
  #openstack-meeting-3 to discuss Neutron BPs remaining for Juno at this
  point. We're taking specifically about medium and high priority ones,
  with a focus on these three:
 
  https://blueprints.launchpad.net/neutron/+spec/l3-high-availability )
  https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security )
 
 https://blueprints.launchpad.net/neutron/+spec/security-group-rules-for-devices-rpc-call-refactor
  )
 
  These three BPs will provide a final push for scalability in a few
  areas and are things we as a team need to work to merge this week. The
  meeting will allow for discussion of final issues on these patches
  with the goal of trying to merge them by Feature Freeze next week. If
  time permits, we can discuss other medium and high priority community
  BPs as well.
 
  Let me know if this works by responding on this thread and I hope to
  see people there Thursday!
 
  Thanks,
  Kyle
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

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

Re: [openstack-dev] [nova][neutron] Migration from nova-network to Neutron for large production clouds

[Oleg Bondarev]

Hi,

I'd like to encourage everybody interested to take a look and leave
comments on the Neutron migration spec here:
https://review.openstack.org/#/c/101921

The design currently includes both cold and live approaches, supports
host-by-host migration (as opposite to big bang)
and doesn't require to freeze the whole deployment during upgrade.

I've also started prototyping the above spec:
https://review.openstack.org/#/c/111755 - Neutron migration: synchronize IP
(de)allocations with Nova-net
https://review.openstack.org/#/c/115635 - Neutron migration as part of cold
migration



On Tue, Aug 26, 2014 at 1:59 PM, Tim Bell tim.b...@cern.ch wrote:


  From: Michael Still [mailto:mi...@stillhq.com]
  Sent: 25 August 2014 23:38
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [nova][neutron] Migration from nova-network
 to Neutron for large production clouds

 ...

  Mark McClain and I discussed a possible plan for nova-network to neutron
 upgrades at the Ops Meetup today, and it seemed generally acceptable. It
 defines a cold migration as
  freezing the ability to create or destroy instances during the upgrade,
 and then requiring a short network outage for each instance in the cell.
  This is why I'm trying to understand the no downtime use case better.
 Is it literally no downtime, ever? Or is it a more simple no simultaneous
 downtime for instances?
  Michael

 The simultaneous downtime across the cloud is the one we really need to
 avoid. Short network outages (depending on how you define short) can be
 handled along with blocking API operations for short periods.

 The other item was how to stage the upgrade.. with a cloud of a
 significant size and some concerns about scalability, we would like to be
 able to do the migration as a set of steps rather than a big bang. During
 the gap between the steps, we'd like to open the APIs for usage, such as
 new VMs get created on Neutron hypervisors. Would that be a possibility ?

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

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

Re: [openstack-dev] [neutron] Rotating the weekly Neutron meeting

[Oleg Bondarev]

+1, thanks!


On Wed, Aug 13, 2014 at 6:05 PM, Kyle Mestery mest...@mestery.com wrote:

 Per this week's Neutron meeting [1], it was decided that offering a
 rotating meeting slot for the weekly Neutron meeting would be a good
 thing. This will allow for a much easier time for people in
 Asia/Pacific timezones, as well as for people in Europe.

 So, I'd like to propose we rotate the weekly as follows:

 Monday 2100UTC
 Tuesday 1400UTC

 If people are ok with these time slots, I'll set this up and we'll
 likely start with this new schedule in September, after the FPF.

 Thanks!
 Kyle

 [1]
 http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-11-21.00.html

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

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

Re: [openstack-dev] [neutron] [nova] Weekly nova-network / neutron parity meeting

[Oleg Bondarev]

Thanks for setting this up Kyle, Wednesday 1500 UTC works for me.

Thanks,
Oleg


On Thu, Jul 17, 2014 at 6:35 AM, Kyle Mestery mest...@mestery.com wrote:

 On Wed, Jul 16, 2014 at 9:28 PM, Michael Still mi...@stillhq.com wrote:
  That time is around 1am for me. I'm ok with that as long as someone on
  the nova side can attend in my place.
 
  Michael
 
 Some of the neutron contributors to this effort are in Europe and
 Russia, so finding a time slot to get everyone could prove tricky.
 I'll leave this slot now and hope we can get someone else from nova to
 attend Michael. If not, we'll move this to another time.

 Thanks!
 Kyle

  On Thu, Jul 17, 2014 at 12:22 PM, Kyle Mestery mest...@mestery.com
 wrote:
  As we're getting down to the wire in Juno, I'd like to propose we have
  a weekly meeting on the nova-network and neutron parity effort. I'd
  like to start this meeting next week, and I'd like to propose
  Wednesday at 1500 UTC on #openstack-meeting-3 as the time and
  location. If this works for people, please reply on this thread, or
  suggest an alternate time. I've started a meeting page [1] to track
  agenda for the first meeting next week.
 
  Thanks!
  Kyle
 
  [1] https://wiki.openstack.org/wiki/Meetings/NeutronNovaNetworkParity
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  --
  Rackspace Australia
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [neutron] Proposed changes to core team

[Oleg Bondarev]

+1!
Congratulations Carl!

Thanks,
Oleg


On Tue, May 27, 2014 at 9:07 AM, Gary Kotton gkot...@vmware.com wrote:

 +1

 On 5/26/14 1:35 PM, Akihiro Motoki amot...@gmail.com wrote:

 +1 from me too.
 
 
 Akihiro
 
 On Thu, May 22, 2014 at 5:59 AM, Kyle Mestery mest...@noironetworks.com
 wrote:
  I would like to propose a few changes to the Neutron core team.
  Looking at how current cores are contributing, both in terms of review
  [1] as well as project participation and attendance at the summit
  sessions last week, I am proposing a few changes. As cores, I believe
  reviews are critical, but I also believe interacting with the Neutron
  and OpenStack communities in general is important.
 
  The first change I'd like to propose is removing Yong Sheng Gong from
  neutron-core. Yong has been a core for a long time. I'd like to thank
  him for all of his work on Neutron over the years. Going forward, I'd
  also to propose that if Yong's participation and review stats improve
  he could be fast-tracked back to core status. But for now, his review
  stats for the past 90 days do not line up with current cores, and his
  participation in general has dropped off. So I am proposing his
  removal from neutron-core.
 
  Since we're losing a core team member, I'd like to propose Carl
  Baldwin (carl_baldwin) for Neutron core. Carl has been a very active
  reviewer for Neutron, his stats are well in-line with other core
  reviewers. Additionally, Carl has been leading the L3 sub-team [2] for
  a while now. He's a very active member of the Neutron community, and
  he is actively leading development of some important features for the
  Juno release.
 
  Neutron cores, please vote +1/-1 for the proposed addition of Carl
  Baldwin to Neutron core.
 
  I also wanted to mention the process for adding, removing, and
  maintaining neutron-core membership is now documented on the wiki here
  [3].
 
  Thank you!
  Kyle
 
  [1]
 
 https://urldefense.proofpoint.com/v1/url?u=http://stackalytics.com/report
 /contribution/neutron/90k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8
 NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs8Jqf%2Fe8eY
 %2BtGs%2BpsxwPLmUJ14%3D%0As=c2f6363f076a61717a6d783c76fcfca4dd4ba7d33976
 a84d0968adf6f437856c
  [2]
 
 https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik
 i/Meetings/Neutron-L3-Subteamk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0px
 TUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs8Jqf%2
 Fe8eY%2BtGs%2BpsxwPLmUJ14%3D%0As=377c0039155a3e1eda83c067e72f95cc4c8c47a
 856f4a95fed8cca401553239e
  [3]
 
 https://urldefense.proofpoint.com/v1/url?u=https://wiki.openstack.org/wik
 i/NeutronCorek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQ
 u%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs8Jqf%2Fe8eY%2BtGs%2Bps
 xwPLmUJ14%3D%0As=326344d08265e042e513b43e0f1ea6060909ae94bed085f197e818e
 2d0710920
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 
 
 https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
 -bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
 =eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs
 8Jqf%2Fe8eY%2BtGs%2BpsxwPLmUJ14%3D%0As=74bf5902221c96ab023b45cdb752e444f
 1f7024b5c264a3a1c61e1e5fcf13c37
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
 https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
 bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
 H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=fp1wMkF3vAg5RlR9Vs8Jq
 f%2Fe8eY%2BtGs%2BpsxwPLmUJ14%3D%0As=74bf5902221c96ab023b45cdb752e444f1f70
 24b5c264a3a1c61e1e5fcf13c37


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

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

Re: [openstack-dev] [neutron]what's diffrent between the type 'PING' and ‘TCP’ in health_monitor

[Oleg Bondarev]

Hi,
LBaaS haproxy driver doesn't support PING health monitors and
doesn't distinguish PING and TCP.
We need to fix it to fail when applying PING health monitor to a haproxy
loadbalancer.
Thanks for reporting!

Oleg


On Tue, May 6, 2014 at 7:58 AM, shihanzhang ayshihanzh...@126.com wrote:

 Hi everyone!
 I've enabled LBaaS with haproxy, I've configured a pool with vip and
 members, the health_monitor type is 'PING', then I found the status of
 members is always 'INACTIVE', when I execute  'nc -l -p ' in member server, 
 the
 status of member become 'ACTIVE', who can help me to explain  what's
 diffrent between the type 'PING' and ‘TCP’ in health_monitor.



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


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

Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

[Oleg Bondarev]

On Wed, Apr 30, 2014 at 7:40 PM, Salvatore Orlando sorla...@nicira.comwrote:

 On 30 April 2014 17:28, Jesse Pretorius jesse.pretor...@gmail.com wrote:

 On 30 April 2014 16:30, Oleg Bondarev obonda...@mirantis.com wrote:

 I've tried updating interface while running ssh session from guest to
 host and it was dropped :(


 Please allow me to tell you I told you so! ;)


 The drop is not great, but ok if the instance is still able to be
 communicated to after the arp tables refresh and the connection is
 re-established.

 If the drop can't be avoided, there is comfort in knowing that there is
 no need for an instance reboot, suspend/resume or any manual actions.


 I agree with Jesse's point. I think it will be reasonable to say that the
 migration will trigger a connection reset for all existing TCP connections.
 However, what are exactly the changes we're making on the data plane? Are
 you testing with migrating VIF from a linux bridge instance to an Open
 vSwitch obne?


Actually I was testing VIF move from nova-net bridge br100 to neutron's
bridge (qbrXXX) (which is kind of final step in instance migration as I see
it)
Another problem that I faced is clearing network filters which nova-net
configures on the VIF, but this seems to be fixed in libvirt now:
https://www.redhat.com/archives/libvirt-users/2014-May/msg2.html

Thanks,
Oleg


 Salvatore



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



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


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

Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

[Oleg Bondarev]

So by running ping while instance interface update we can see ~10-20 sec of
connectivity downtime. Here is a tcp capture during update (pinging ext net
gateway):

*05:58:41.020791 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 10, length 64*
*05:58:41.020866 IP 172.24.4.1  10.0.0.4 http://10.0.0.4: ICMP echo
reply, id 29954, seq 10, length 64*
*05:58:41.885381 STP 802.1s, Rapid STP, CIST Flags [Learn, Forward,
Agreement]*
*05:58:42.022785 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 11, length 64*
*05:58:42.022832 IP 172.24.4.1  10.0.0.4 http://10.0.0.4: ICMP echo
reply, id 29954, seq 11, length 64*
*[vm interface updated..]*
*05:58:43.023310 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 12, length 64*
*05:58:44.024042 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 13, length 64*
*05:58:45.025760 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 14, length 64*
*05:58:46.026260 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 15, length 64*
*05:58:47.027813 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 16, length 64*
*05:58:48.028229 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 17, length 64*
*05:58:49.029881 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 18, length 64*
*05:58:50.029952 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 19, length 64*
*05:58:51.031380 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 20, length 64*
*05:58:52.032012 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 21, length 64*
*05:58:53.033456 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 22, length 64*
*05:58:54.034061 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 23, length 64*
*05:58:55.035170 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 24, length 64*
*05:58:56.035988 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 25, length 64*
*05:58:57.037285 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 26, length 64*
*05:58:57.045691 ARP, Request who-has 10.0.0.1 tell 10.0.0.4, length 28*
*05:58:58.038245 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 27, length 64*
*05:58:58.045496 ARP, Request who-has 10.0.0.1 tell 10.0.0.4, length 28*
*05:58:59.040143 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 28, length 64*
*05:58:59.045609 ARP, Request who-has 10.0.0.1 tell 10.0.0.4, length 28*
*05:59:00.040789 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 29, length 64*
*05:59:01.042333 ARP, Request who-has 10.0.0.1 tell 10.0.0.4, length 28*
*05:59:01.042618 ARP, Reply 10.0.0.1 is-at fa:16:3e:61:28:fa (oui Unknown),
length 28*
*05:59:01.043471 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 30, length 64*
*05:59:01.063176 IP 172.24.4.1  10.0.0.4 http://10.0.0.4: ICMP echo
reply, id 29954, seq 30, length 64*
*05:59:02.042699 IP 10.0.0.4  172.24.4.1 http://172.24.4.1: ICMP echo
request, id 29954, seq 31, length 64*
*05:59:02.042840 IP 172.24.4.1  10.0.0.4 http://10.0.0.4: ICMP echo
reply, id 29954, seq 31, length 64*

However this connectivity downtime can be significally reduced by restarting
network service on the instance right after interface update.


On Mon, Apr 28, 2014 at 6:29 PM, Kyle Mestery mest...@noironetworks.comwrote:

 On Mon, Apr 28, 2014 at 9:19 AM, Oleg Bondarev obonda...@mirantis.com
 wrote:
  On Mon, Apr 28, 2014 at 6:01 PM, Kyle Mestery mest...@noironetworks.com
 
  wrote:
 
  On Mon, Apr 28, 2014 at 8:54 AM, Oleg Bondarev obonda...@mirantis.com
  wrote:
   Yeah, I also saw in docs that update-device is supported since 0.8.0
   version,
   not sure why it didn't work in my setup.
   I installed latest libvirt 1.2.3 and now update-device works just fine
   and I
   am able
   to move instance tap device from one bridge to another with no
 downtime
   and
   no reboot!
   I'll try to investigate why it didn't work on 0.9.8 and which is the
   minimal
   libvirt version for this.
  
  Wow, cool! This is really good news. Thanks for driving this! By
  chance did you notice if there was a drop in connectivity at all, or
  if the guest detected the move at all?
 
 
  Didn't check it yet. What in your opinion would be the best way of
 testing
  this?
 
 The simplest way would to have a ping running when you run
 update-device and see if any packets are dropped. We can do more
 thorough testing after that, but that would give us a good
 approximation of connectivity while swapping the underlying device.

  Kyle
 
   Thanks,
   Oleg
  
  
   On Sat, Apr 26, 2014 at 5:46 AM, Kyle Mestery
   mest...@noironetworks.com
   wrote

Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

[Oleg Bondarev]

I've tried updating interface while running ssh session from guest to host
and it was dropped :(

*07:27:58.676570 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
44:88, ack 61, win 2563, options [nop,nop,TS val 4539607 ecr 24227108],
length 44*
*07:27:58.677161 IP 172.18.76.80.22  10.0.0.4.52556: Flags [P.], seq
61:121, ack 88, win 277, options [nop,nop,TS val 24227149 ecr 4539607],
length 60*
*07:27:58.677720 IP 10.0.0.4.52556  172.18.76.80.22: Flags [.], ack 121,
win 2563, options [nop,nop,TS val 4539608 ecr 24227149], length 0*
*07:27:59.087582 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
88:132, ack 121, win 2563, options [nop,nop,TS val 4539710 ecr 24227149],
length 44*
*07:27:59.088140 IP 172.18.76.80.22  10.0.0.4.52556: Flags [P.], seq
121:181, ack 132, win 277, options [nop,nop,TS val 24227251 ecr 4539710],
length 60*
*07:27:59.088487 IP 10.0.0.4.52556  172.18.76.80.22: Flags [.], ack 181,
win 2563, options [nop,nop,TS val 4539710 ecr 24227251], length 0*
*[vm interface updated..]*
*07:28:17.157594 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
132:176, ack 181, win 2563, options [nop,nop,TS val 4544228 ecr 24227251],
length 44*
*07:28:17.321060 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
176:220, ack 181, win 2563, options [nop,nop,TS val 4544268 ecr 24227251],
length 44*
*07:28:17.361835 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
132:176, ack 181, win 2563, options [nop,nop,TS val 4544279 ecr 24227251],
length 44*
*07:28:17.769935 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
132:176, ack 181, win 2563, options [nop,nop,TS val 4544381 ecr 24227251],
length 44*
*07:28:18.585887 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
132:176, ack 181, win 2563, options [nop,nop,TS val 4544585 ecr 24227251],
length 44*
*07:28:20.221797 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
132:176, ack 181, win 2563, options [nop,nop,TS val 4544994 ecr 24227251],
length 44*
*07:28:23.493540 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
132:176, ack 181, win 2563, options [nop,nop,TS val 4545812 ecr 24227251],
length 44*
*07:28:30.037927 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
132:176, ack 181, win 2563, options [nop,nop,TS val 4547448 ecr 24227251],
length 44*
*07:28:35.045733 ARP, Request who-has 10.0.0.1 tell 10.0.0.4, length 28*
*07:28:36.045388 ARP, Request who-has 10.0.0.1 tell 10.0.0.4, length 28*
*07:28:37.045900 ARP, Request who-has 10.0.0.1 tell 10.0.0.4, length 28*
*07:28:43.063118 IP 0.0.0.0.68  255.255.255.255.67: BOOTP/DHCP, Request
from fa:16:3e:ec:eb:a4, length 280*
*07:28:43.084384 IP 10.0.0.3.67  10.0.0.4.68: BOOTP/DHCP, Reply, length
323*
*07:28:43.085038 ARP, Request who-has 10.0.0.3 tell 10.0.0.4, length 28*
*07:28:43.099463 ARP, Reply 10.0.0.3 is-at fa:16:3e:79:9b:9c, length 28*
*07:28:43.099841 IP 10.0.0.4  10.0.0.3 http://10.0.0.3: ICMP 10.0.0.4
udp port 68 unreachable, length 359*
*07:28:43.125379 ARP, Request who-has 10.0.0.1 tell 10.0.0.4, length 28*
*07:28:43.125626 ARP, Reply 10.0.0.1 is-at fa:16:3e:61:28:fa, length 28*
*07:28:43.125907 IP 10.0.0.4.52556  172.18.76.80.22: Flags [P.], seq
132:176, ack 181, win 2563, options [nop,nop,TS val 4550720 ecr 24227251],
length 44*
*07:28:43.132650 IP 172.18.76.80.22  10.0.0.4.52556: Flags [R], seq
369316248, win 0, length 0*
*07:28:48.148853 ARP, Request who-has 10.0.0.4 tell 10.0.0.1, length 28*
*07:28:48.149377 ARP, Reply 10.0.0.4 is-at fa:16:3e:ec:eb:a4, length 28*


On Wed, Apr 30, 2014 at 5:50 PM, Kyle Mestery mest...@noironetworks.comwrote:

 Agreed, ping was a good first tool to verify downtime, but trying with
 something using TCP at this point would be useful as well.

 On Wed, Apr 30, 2014 at 8:39 AM, Eugene Nikanorov
 enikano...@mirantis.com wrote:
  I think it's better to test with some tcp connection (ssh session?)
 rather
  then with ping.
 
  Eugene.
 
 
  On Wed, Apr 30, 2014 at 5:28 PM, Oleg Bondarev obonda...@mirantis.com
  wrote:
 
  So by running ping while instance interface update we can see ~10-20 sec
  of
  connectivity downtime. Here is a tcp capture during update (pinging ext
  net gateway):
 
  05:58:41.020791 IP 10.0.0.4  172.24.4.1: ICMP echo request, id 29954,
 seq
  10, length 64
  05:58:41.020866 IP 172.24.4.1  10.0.0.4: ICMP echo reply, id 29954,
 seq
  10, length 64
  05:58:41.885381 STP 802.1s, Rapid STP, CIST Flags [Learn, Forward,
  Agreement]
  05:58:42.022785 IP 10.0.0.4  172.24.4.1: ICMP echo request, id 29954,
 seq
  11, length 64
  05:58:42.022832 IP 172.24.4.1  10.0.0.4: ICMP echo reply, id 29954,
 seq
  11, length 64
  [vm interface updated..]
  05:58:43.023310 IP 10.0.0.4  172.24.4.1: ICMP echo request, id 29954,
 seq
  12, length 64
  05:58:44.024042 IP 10.0.0.4  172.24.4.1: ICMP echo request, id 29954,
 seq
  13, length 64
  05:58:45.025760 IP 10.0.0.4  172.24.4.1: ICMP echo request, id 29954,
 seq
  14, length 64
  05:58:46.026260 IP 10.0.0.4  172.24.4.1: ICMP echo request, id 29954,
 seq
  15, length 64
  05:58:47.027813 IP

Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

[Oleg Bondarev]

Yeah, I also saw in docs that *update-device *is supported since 0.8.0
version,
not sure why it didn't work in my setup.
I installed latest libvirt 1.2.3 and now update-device works just fine and
I am able
to move instance tap device from one bridge to another with no downtime and
no reboot!
I'll try to investigate why it didn't work on 0.9.8 and which is the
minimal libvirt version for this.

Thanks,
Oleg


On Sat, Apr 26, 2014 at 5:46 AM, Kyle Mestery mest...@noironetworks.comwrote:

 According to this page [1], update-device is supported from libvirt
 0.8.0 onwards. So in theory, this should be working with your 0.9.8
 version you have. If you continue to hit issues here Oleg, I'd suggest
 sending an email to the libvirt mailing list with the specifics of the
 problem. I've found in the past there are lots of very helpful on that
 mailing list.

 Thanks,
 Kyle

 [1] http://libvirt.org/sources/virshcmdref/html-single/#sect-update-device

 On Thu, Apr 24, 2014 at 7:42 AM, Oleg Bondarev obonda...@mirantis.com
 wrote:
  So here is the etherpad for the migration discussion:
  https://etherpad.openstack.org/p/novanet-neutron-migration
  I've also filed a design session on this:
  http://summit.openstack.org/cfp/details/374
 
  Currently I'm still struggling with instance vNic update, trying to move
 it
  from one bridge to another.
  Tried the following on ubuntu 12.04 with libvirt 0.9.8:
 
 https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-dynamic-vNIC.html
  virsh update-device shows success but nothing actually changes in the
  instance interface config.
  Going to try this with later libvirt version.
 
  Thanks,
  Oleg
 
 
 
  On Wed, Apr 23, 2014 at 3:24 PM, Rossella Sblendido rsblend...@suse.com
 
  wrote:
 
 
  Very interesting topic!
  +1 Salvatore
 
  It would be nice to have an etherpad to share the information and
 organize
  a plan. This way it would be easier for interested people  to join.
 
  Rossella
 
 
  On 04/23/2014 12:57 AM, Salvatore Orlando wrote:
 
  It's great to see that there is activity on the launchpad blueprint as
  well.
  From what I heard Oleg should have already translated the various
  discussion into a list of functional requirements (or something like
 that).
 
  If that is correct, it might be a good idea to share them with relevant
  stakeholders (operators and developers), define an actionable plan for
 Juno,
  and then distribute tasks.
  It would be a shame if it turns out several contributors are working on
  this topic independently.
 
  Salvatore
 
 
  On 22 April 2014 16:27, Jesse Pretorius jesse.pretor...@gmail.com
 wrote:
 
  On 22 April 2014 14:58, Salvatore Orlando sorla...@nicira.com wrote:
 
  From previous requirements discussions,
 
 
  There's a track record of discussions on the whiteboard here:
  https://blueprints.launchpad.net/neutron/+spec/nova-to-quantum-upgrade
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

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

Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

[Oleg Bondarev]

On Mon, Apr 28, 2014 at 6:01 PM, Kyle Mestery mest...@noironetworks.comwrote:

 On Mon, Apr 28, 2014 at 8:54 AM, Oleg Bondarev obonda...@mirantis.com
 wrote:
  Yeah, I also saw in docs that update-device is supported since 0.8.0
  version,
  not sure why it didn't work in my setup.
  I installed latest libvirt 1.2.3 and now update-device works just fine
 and I
  am able
  to move instance tap device from one bridge to another with no downtime
 and
  no reboot!
  I'll try to investigate why it didn't work on 0.9.8 and which is the
 minimal
  libvirt version for this.
 
 Wow, cool! This is really good news. Thanks for driving this! By
 chance did you notice if there was a drop in connectivity at all, or
 if the guest detected the move at all?


Didn't check it yet. What in your opinion would be the best way of testing
this?

Kyle

  Thanks,
  Oleg
 
 
  On Sat, Apr 26, 2014 at 5:46 AM, Kyle Mestery mest...@noironetworks.com
 
  wrote:
 
  According to this page [1], update-device is supported from libvirt
  0.8.0 onwards. So in theory, this should be working with your 0.9.8
  version you have. If you continue to hit issues here Oleg, I'd suggest
  sending an email to the libvirt mailing list with the specifics of the
  problem. I've found in the past there are lots of very helpful on that
  mailing list.
 
  Thanks,
  Kyle
 
  [1]
 http://libvirt.org/sources/virshcmdref/html-single/#sect-update-device
 
  On Thu, Apr 24, 2014 at 7:42 AM, Oleg Bondarev obonda...@mirantis.com
  wrote:
   So here is the etherpad for the migration discussion:
   https://etherpad.openstack.org/p/novanet-neutron-migration
   I've also filed a design session on this:
   http://summit.openstack.org/cfp/details/374
  
   Currently I'm still struggling with instance vNic update, trying to
 move
   it
   from one bridge to another.
   Tried the following on ubuntu 12.04 with libvirt 0.9.8:
  
  
 https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-dynamic-vNIC.html
   virsh update-device shows success but nothing actually changes in the
   instance interface config.
   Going to try this with later libvirt version.
  
   Thanks,
   Oleg
  
  
  
   On Wed, Apr 23, 2014 at 3:24 PM, Rossella Sblendido
   rsblend...@suse.com
   wrote:
  
  
   Very interesting topic!
   +1 Salvatore
  
   It would be nice to have an etherpad to share the information and
   organize
   a plan. This way it would be easier for interested people  to join.
  
   Rossella
  
  
   On 04/23/2014 12:57 AM, Salvatore Orlando wrote:
  
   It's great to see that there is activity on the launchpad blueprint
 as
   well.
   From what I heard Oleg should have already translated the various
   discussion into a list of functional requirements (or something like
   that).
  
   If that is correct, it might be a good idea to share them with
 relevant
   stakeholders (operators and developers), define an actionable plan
 for
   Juno,
   and then distribute tasks.
   It would be a shame if it turns out several contributors are working
 on
   this topic independently.
  
   Salvatore
  
  
   On 22 April 2014 16:27, Jesse Pretorius jesse.pretor...@gmail.com
   wrote:
  
   On 22 April 2014 14:58, Salvatore Orlando sorla...@nicira.com
 wrote:
  
   From previous requirements discussions,
  
  
   There's a track record of discussions on the whiteboard here:
  
 https://blueprints.launchpad.net/neutron/+spec/nova-to-quantum-upgrade
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

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

Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

[Oleg Bondarev]

So here is the etherpad for the migration discussion:
https://etherpad.openstack.org/p/novanet-neutron-migration
I've also filed a design session on this:
http://summit.openstack.org/cfp/details/374

Currently I'm still struggling with instance vNic update, trying to move it
from one bridge to another.
Tried the following on ubuntu 12.04 with libvirt 0.9.8:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-dynamic-vNIC.html
virsh update-device shows success but nothing actually changes in the
instance interface config.
Going to try this with later libvirt version.

Thanks,
Oleg



On Wed, Apr 23, 2014 at 3:24 PM, Rossella Sblendido rsblend...@suse.comwrote:


 Very interesting topic!
 +1 Salvatore

 It would be nice to have an etherpad to share the information and organize
 a plan. This way it would be easier for interested people  to join.

 Rossella


 On 04/23/2014 12:57 AM, Salvatore Orlando wrote:

 It's great to see that there is activity on the launchpad blueprint as
 well.
 From what I heard Oleg should have already translated the various
 discussion into a list of functional requirements (or something like that).

  If that is correct, it might be a good idea to share them with relevant
 stakeholders (operators and developers), define an actionable plan for
 Juno, and then distribute tasks.
 It would be a shame if it turns out several contributors are working on
 this topic independently.

  Salvatore


 On 22 April 2014 16:27, Jesse Pretorius jesse.pretor...@gmail.com wrote:

  On 22 April 2014 14:58, Salvatore Orlando sorla...@nicira.com wrote:

 From previous requirements discussions,


  There's a track record of discussions on the whiteboard here:
 https://blueprints.launchpad.net/neutron/+spec/nova-to-quantum-upgrade

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




 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


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

Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

[Oleg Bondarev]

On Fri, Apr 18, 2014 at 9:10 PM, Kyle Mestery mest...@noironetworks.comwrote:

 On Fri, Apr 18, 2014 at 8:52 AM, Oleg Bondarev obonda...@mirantis.com
 wrote:
  Hi all,
 
  While investigating possible options for Nova-network to Neutron
 migration
  I faced a couple of issues with libvirt.
  One of the key requirements for the migration is that instances should
 stay
  running and don't need restarting. In order to meet this requirement we
 need
  to either attach new nic to the instance or update existing one to plug
 it
  to the Neutron network.
 
 Thanks for looking into this Oleg! I just wanted to mention that if
 we're trying to plug a new NIC into the VM, this will likely require
 modifications in the guest. The new NIC will likely have a new PCI ID,
 MAC, etc., and thus the guest would have to switch to this. Therefor,
 I think it may be better to try and move the existing NIC from a nova
 network onto a neutron network.


Yeah, I agree that modifying the existing NIC is the preferred way.


  So what I've discovered is that attaching a new network device is only
  applied
  on the instance after reboot although VIR_DOMAIN_AFFECT_LIVE flag is
 passed
  to
  the libvirt call attachDeviceFlags():
 
 https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1412
  Is that expected? Are there any other options to apply new nic without
  reboot?
 
  I also tried to update existing nic of an instance by using libvirt
  updateDeviceFlags() call,
  but it fails with the following:
  'this function is not supported by the connection driver: cannot modify
  network device configuration'
  libvirt API spec (http://libvirt.org/hvsupport.html) shows that 0.8.0 as
  minimal
  qemu version for the virDomainUpdateDeviceFlags call, kvm --version on my
  setup shows
  'QEMU emulator version 1.0 (qemu-kvm-1.0)'
  Could someone please point what am I missing here?
 
 What does libvirtd -V show for the libvirt version? On my Fedora 20
 setup, I see the following:

 [kmestery@fedora-mac neutron]$ libvirtd -V
 libvirtd (libvirt) 1.1.3.4
 [kmestery@fedora-mac neutron]$


On my Ubuntu 12.04 it shows:
 $ libvirtd --version
 libvirtd (libvirt) 0.9.8


 Thanks,
 Kyle

  Any help on the above is much appreciated!
 
  Thanks,
  Oleg
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

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

[openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt

[Oleg Bondarev]

Hi all,

While investigating possible options for Nova-network to Neutron migration
I faced a couple of issues with libvirt.
One of the key requirements for the migration is that instances should stay
running and don't need restarting. In order to meet this requirement we
need
to either attach new nic to the instance or update existing one to plug it
to the Neutron network.

So what I've discovered is that attaching a new network device is only
applied
on the instance after reboot although *VIR_DOMAIN_AFFECT_LIVE* flag is
passed to
the libvirt call *attachDeviceFlags()*:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1412
Is that expected? Are there any other options to apply new nic without
reboot?

I also tried to update existing nic of an instance by using libvirt
*updateDeviceFlags()* call,
but it fails with the following:
*'this function is not supported by the connection driver: cannot modify
network device configuration'*
libvirt API spec (http://libvirt.org/hvsupport.html) shows that 0.8.0 as
minimal
qemu version for the virDomainUpdateDeviceFlags call, kvm --version on my
setup shows
'*QEMU emulator version 1.0 (qemu-kvm-1.0)*'
Could someone please point what am I missing here?

Any help on the above is much appreciated!

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

Re: [openstack-dev] [Neutron LBaaS] Need help with LBaaS drivers

[Oleg Bondarev]

Hi Vijay,

Currently you may follow two ways in writing an LBaaS driver:
1) write it from scratch (like Radware, Netscaler, Embrane drivers) -
in this case your driver should inherit
abstract_driver.LoadBalancerAbstractDriver
and
will be running on Neutron service process, LBaaS agent won't be used.
So you should restart not q-lbaas but q-svc process in order for new
driver to be used and it should work with the steps you've described.

2) leverage
neutron/services/loadbalancer/drivers/common/agent_drive_base.py framework
and in fact write only device driver which inheritits

neutron.services.loadbalancer.agent.agent_device_driver.AgentDeviceDriver.
This is how HAProxy driver is implemented, please see
neutron/services/loadbalancer/drivers/haproxy/plugin_driver.py
and namespace_driver.py (this is device driver).
Along with updating service_provider in neutron.conf you should also
add your device driver to lbaas_agent.ini file (again please check how it
is done for haproxy)
In this case your driver will be running on LBaaS agent and you should
restart both q-svc and q-lbaas.

Generally, the second approach is preferable as it's better scalable and
provides you a built-in async mechanism.

Thanks,
Oleg


On Wed, Apr 2, 2014 at 5:44 AM, Vijay B os.v...@gmail.com wrote:

 Hi,


 I'm trying to understand how LBaaS drivers work and so am attempting to
 write a dummy driver that does nothing for now, but instead of loading my
 dummy driver, neutron always loads the HAProxy namespace driver. These are
 the steps I followed:


 1) I created a new directory neutron/services/loadbalancer/drivers/dummy/,
 and in that directory I put in a new file dummy_driver.py, which
 basically has a class class
 DummyPluginDriver(abstract_driver.LoadBalancerAbstractDriver):

 and has empty __init__(), create_vip(), delete_vip() etc functions.


 2) I'm testing using a devstack setup, so I also edited the
 /etc/neutron/neutron.conf file, commenting out the default loadbalancer
 driver entry for HAProxy, and added a line for my dummy driver as follows:



 service_provider=LOADBALANCER:Dummy:neutron.services.loadbalancer.drivers.dummy.dummy_driver.DummyPluginDriver:default



 3) I created a /etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini
 directory/file

 I simply copied over the haproxy's lbaas_agent.ini file and changed
 [haproxy] to [dummy]

 and then I restarted the q-lbaas service using cd /opt/stack/neutron 
 python /usr/local/bin/neutron-lbaas-agent --config-file
 /etc/neutron/neutron.conf
 --config-file=/etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini



 However, I see that the default HAProxyNS driver is still being loaded

 When I put a breakpoint in loadbalancer/agent/agent_manager.py:86, I see
 this (relevant text marked in red):



 2014-03-31 13:47:16.998 DEBUG neutron.common.utils [-] Reloading cached
 file /etc/neutron/policy.json from (pid=28405) read_cached_file
 /opt/stack/neutron/neutron/common/utils.py:53

 2014-03-31 13:47:16.998 DEBUG neutron.policy [-] Loading policies from
 file: /etc/neutron/policy.json from (pid=28405) _set_rules
 /opt/stack/neutron/neutron/policy.py:89

 
 /opt/stack/neutron/neutron/services/loadbalancer/agent/agent_manager.py(86)_load_drivers()

 - self.device_drivers = {}

 (Pdb) l

  81 # pool_id-device_driver_name mapping used to store known
 instances

  82 self.instance_mapping = {}

  83

  84 def _load_drivers(self):

  85 import pdb; pdb.set_trace()

  86  - self.device_drivers = {}

  87 for driver in self.conf.device_driver:

  88 try:

  89 driver_inst = importutils.import_object(

  90 driver,

  91 self.conf,

 (Pdb) self.conf.device_driver


 ['neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver']

 (Pdb)


 I'm not sure what I'm doing wrong - am I missing something that needs to
 be done within the dummy driver itself? (in dummy_driver.py?). Should I
 register some opts or similar?


 Any help would be much appreciated!



 Thanks,

 Regards,

 Vijay

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


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

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

[Oleg Bondarev]

Hi Vijay,
Currently Neutron LBaaS supports only namespace based implementation for
HAProxy.
You can however run LBaaS agent on the host other than network controller
node - in that
case HAProxy processes will be running on that host but still in namespaces.

Also there is an effort in Neutron regarding adding support of advanced
services in VMs [1].
After it is completed I hope it will be possible to adopt it in LBaaS and
run HAProxy in such a service VM.

[1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

Thanks,
Oleg


On Tue, Mar 25, 2014 at 1:39 AM, Vijay B os.v...@gmail.com wrote:

 Hi Eugene,

 Thanks for the reply! How/where is the agent configuration done for
 HAProxy? If I don't want to go with a network namespace based HAProxy
 process, but want to deploy my own HAProxy instance on a host outside of
 the network controller node, and make neutron deploy pools/VIPs on that
 HAProxy instance, does neutron currently support this scenario? If so, what
 are the configuration steps I will need to carry out to deploy HAProxy on a
 separate host (for example, where do I specify the ip address of the
 haproxy host, etc)?

 Regards,
 Vijay


 On Mon, Mar 24, 2014 at 2:04 PM, Eugene Nikanorov enikano...@mirantis.com
  wrote:

 Hi,

 HAProxy driver has not removed from the trunk, instead it became a base
 for agent-based driver, so the only haproxy-specific thing in the plugin
 driver is device driver name. Namespace driver is a device driver on the
 agent side and it was there from the beginning.
 The reason for the change is mere refactoring: it seems that solutions
 that employ agents could share the same code with only device driver being
 specific.

 So, everything is in place, HAProxy continues to be the default
 implementation of Neutron LBaaS service. It supports spawning haproxy
 processes on any host that runs lbaas agent.

 Thanks,
 Eugene.



 On Tue, Mar 25, 2014 at 12:33 AM, Vijay B os.v...@gmail.com wrote:

 Hi,

 I'm looking at HAProxy support in Neutron, and I observe that the
 drivers/haproxy/plugin_driver.py file in the stable/havana release has been
 effectively removed from trunk (master), in that the plugin driver in the
 master simply points to the namespace driver. What was the reason to do
 this? Was the plugin driver in havana tested and documented? I can't seem
 to get hold of any relevant documentation that describes how to configure
 HAProxy LBs installed on separate boxes (and not brought up in network
 namespaces) - can anyone please point me to the same?

 Also, are there any plans to bring back the HAProxy plugin driver to
 talk to remote HAProxy instances?

 Thanks,
 Regards,
 Vijay

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



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



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


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

Re: [openstack-dev] [Neutron][LBaaS] Requirements Wiki

[Oleg Bondarev]

Hi Jorge,

Thanks for taking care of this and bringing it all together! This will be
really useful for LBaaS discussions.
I updated the wiki to include L7 rules support and also marking already
implemented requirements.

Thanks,
Oleg


On Wed, Mar 19, 2014 at 2:57 AM, Jorge Miramontes 
jorge.miramon...@rackspace.com wrote:

 Hey Neutron LBaaS folks,

 Per last week's IRC meeting I have created a preliminary requirements 
 use case wiki page. I requested adding such a page since there appears to
 be a lot of new interest in load balancing and feel that we need a
 structured way to align everyone's interest in the project. Furthermore,
 it appears that understanding everyone's requirements and use cases will
 aid in the current object model discussion we all have been having. That
 being said, this wiki is malleable and open to discussion. I have added
 some preliminary requirements from my team's perspective in order to start
 the discussion. My vision is that people add requirements and use cases to
 the wiki for what they envision Neutron LBaaS becoming. That way, we can
 all discuss as a group, figure out what should and shouldn't be a
 requirement and prioritize the rest in an effort to focus development
 efforts. ReadyŠsetŠgo!

 Here is the link to the wiki ==
 https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements

 Cheers,
 --Jorge


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

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

Re: [openstack-dev] [Neutron] DOWN and INACTIVE status in FWaaS and LBaaS

[Oleg Bondarev]

Hi,

For LBaaS the background is simple: it uses statuses from
neutron/plugins/common/constants.py and INACTIVE was there initially while
DOWN
appeared later (with VPNaaS first commit). So LBaaS doesn't use DOWN at all.
As for INACTIVE, it is currently used only for members that stop responding
to health checks.
Also there is a patch on review (https://review.openstack.org/#/c/55032)
which sets INACTIVE
status for resources with admin state down.

My personal opinion is that we can easily fix that for LBaaS and replace
INACTIVE with DOWN
to be consistent with other network resources.

Thanks,
Oleg


On Wed, Feb 26, 2014 at 1:50 PM, Xuhan Peng pengxu...@gmail.com wrote:

 Hello,

 This email is triggered by the comments I received in my patch [1] when
 trying to fix bug [2].

 The problem I was trying to fix is that current firewall remains in status
 ACTIVE after admin state is changed to DOWN. My plan is to change the
 status of firewall from ACTIVE to DOWN when admin state is down, as other
 network resource is doing currently.

 But I noticed besides DOWN state, INACTIVE state is also used in FWaaS
 and LBaaS. So I hope someone can help me understand any background of this.
 If this is not particularly by design and inconsistent with other network
 resource, I can open a bug to fix this in FWaaS and LBaaS.

 Thanks,
 Xu Han

 [1]: https://review.openstack.org/#/c/73944/
 [2]: https://launchpad.net/bugs/1279213



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


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

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

[Oleg Bondarev]

Thanks Mark,

thanks everyone for voiting! I'm so happy to become a member of this really
great team!

Oleg


On Thu, Feb 20, 2014 at 6:29 PM, Mark McClain mmccl...@yahoo-inc.comwrote:

  I'd like to welcome Oleg as member of the core Neutron team as he has
 received more than enough +1s and no negative votes from the other cores.

 mark

 On Feb 10, 2014, at 6:28 PM, Mark McClain mmccl...@yahoo-inc.com wrote:

  All-
 
  I'd like to nominate Oleg Bondarev to become a Neutron core reviewer.
  Oleg has been valuable contributor to Neutron by actively reviewing,
 working on bugs, and contributing code.
 
  Neutron cores please reply back with +1/0/-1 votes.
 
  mark
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

Re: [openstack-dev] [Neutron][LBaaS] L7 data types

[Oleg Bondarev]

Hi folks,
please see a few comments inline.

On Wed, Feb 19, 2014 at 12:51 AM, Stephen Balukoff sbaluk...@bluebox.netwrote:

 A couple quick suggestions (additions):

  Entity: L7Rule

 o   Attribute: type

 §  Possible values:


- HTTP_METHOD

 o   Attribute: compare_type

 §  Possible values:


- GT (greater than)
- LT (less than)
- GE (greater than or equal to)
- LE (less than or equal to)

 Will we be doing syntax checking based on the L7Rule type being presented?
  (eg. if w'ere going to check that HEADER X has a value that is greater
 than Y, are we going to make sure that Y is an integer? Or if we're going
 to check that the PATH STARTS_WITH Z, are we going to make sure that Z is a
 non-zero-length string? )

I think we should do these checks on the plugin level (API level doesn't
support such checks at the moment).



Thanks,
 Stephen

 On Tue, Feb 18, 2014 at 3:58 AM, Avishay Balderman 
 avish...@radware.comwrote:

  Here are the suggested values for the attributes below:

 · Entity: L7Rule

 o   Attribute: type

 §  Possible values:

 · HOST_NAME

 · PATH

 · FILE_NAME

 · FILE_TYPE

 Can somebody please clarify what FILE_NAME and FILE_TYPE mean? Just can't
find corresponding matching criterias in haproxy.

  · HEADER

 · COOKIE

 o   Attribute: compare_type

 §  Possible values:

 · EQUAL

 · CONTAINS

 · REGEX

 · STARTS_WITH

 · ENDS_WITH

 · Entity:L7VipPolicyAssociation

 o   Attribute:action

 §  Possible values:

 · POOL (must have pool id)

 · REDIRECT(must have a url to be used as redirect destination)

 · REJECT





 *From:* Oleg Bondarev [mailto:obonda...@mirantis.com]
 *Sent:* Monday, February 17, 2014 9:17 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][LBaaS] L7 data types



 Hi,



 I would add another candidate for being a closed set:
 L7VipPolicyAssociation.action (use_backend, block, etc.)



 Thanks,

 Oleg



 On Sun, Feb 16, 2014 at 3:53 PM, Avishay Balderman avish...@radware.com
 wrote:

 (removing extra space from the subject - let email clients apply their
 filters)



 *From:* Avishay Balderman
 *Sent:* Sunday, February 16, 2014 9:56 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* [openstack-dev] [Neutron][LBaaS] L7 data types



 Hi

 There are 2 fields in the L7 model that are candidates for being a closed
 set (Enum).

 I would like to hear your opinion.



 Entity:  L7Rule

 Field : type

 Description:  this field holds the part of the request where we should
 look for a value

 Possible values: URL,HEADER,BODY,(?)



 Entity:  L7Rule

 Field : compare_type

 Description: The way we compare the value against a given value

 Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)

 *Note*: With REG_EXP we can cover the rest of the values.



 In general In the L7rule one can express the following (Example):

 check if in the value of header named 'Jack'  starts with X - if this
 is true - this rule returns true





 Thanks



 Avishay


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



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




 --
 Stephen Balukoff
 Blue Box Group, LLC
 (800)613-4305 x807

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


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

Re: [openstack-dev] [Neutron][LBaaS] L7Policy deletion

[Oleg Bondarev]

Hi Avishay,

I agree that we can do that as you proposed. However I'd like to remind
that for health monitors we decided to prohibit deletion if there are any
associations (https://bugs.launchpad.net/neutron/+bug/1243129).
So I'd like l7 policy deletion to be consistent with health monitor
deletion unless there are any points aginst it.

Thanks,
Oleg



On Mon, Feb 17, 2014 at 1:04 PM, Avishay Balderman avish...@radware.comwrote:

   Hi

 Question:

 Do we want to block the deletion of L7Policy if it is associated with a
 Vip already?

 In my eyes we can do that, it will drop the L7PolicyVip assoc from DB. All
 we have to do is invoke the driver and let him know that a L7Policy was
 removed.

 At the end of the day  it will be the driver that will do the real
 deletion from DB. The plugin will mark the record as PENDEING_DELETE



 Avishay



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


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

Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy

[Oleg Bondarev]

Hi,


On Mon, Feb 17, 2014 at 1:23 PM, Eugene Nikanorov
enikano...@mirantis.comwrote:

 Hi Avishay,

 1) I think name might be useful. Consider user forms a list of rules which
 route requests to a pool with static images or static pages, it may make
 sense to give those policy a name 'static-iamges', 'static-pages', rather
 then operate on ids.

+1




 2) I think updating the name is useful as well, but just on DB level, so
 there is no point in calling the driver and communicating with the backend.

+1


 Thanks,
 Eugene.


 On Mon, Feb 17, 2014 at 12:58 PM, Avishay Balderman 
 avish...@radware.comwrote:

   Hi

 L7Policy  holds a list of L7rules plus 1 attribute: name .

 Questions:

 1)  Do we need to have this name attribute?

 2)  Do we want to allow update operation of the name attribute? Do
 we need to invoke the driver when such update occurred?



 Thanks



 Avishay

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



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


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

Re: [openstack-dev] [Neutron][LBaaS] L7 data types

[Oleg Bondarev]

Hi,

I would add another candidate for being a closed set:
L7VipPolicyAssociation.action (use_backend, block, etc.)

Thanks,
Oleg


On Sun, Feb 16, 2014 at 3:53 PM, Avishay Balderman avish...@radware.comwrote:

  (removing extra space from the subject - let email clients apply their
 filters)



 *From:* Avishay Balderman
 *Sent:* Sunday, February 16, 2014 9:56 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* [openstack-dev] [Neutron][LBaaS] L7 data types



 Hi

 There are 2 fields in the L7 model that are candidates for being a closed
 set (Enum).

 I would like to hear your opinion.



 Entity:  L7Rule

 Field : type

 Description:  this field holds the part of the request where we should
 look for a value

 Possible values: URL,HEADER,BODY,(?)



 Entity:  L7Rule

 Field : compare_type

 Description: The way we compare the value against a given value

 Possible values: REG_EXP, EQ, GT, LT,EQ_IGNORE_CASE,(?)

 *Note*: With REG_EXP we can cover the rest of the values.



 In general In the L7rule one can express the following (Example):

 check if in the value of header named 'Jack'  starts with X - if this is
 true - this rule returns true





 Thanks



 Avishay

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


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

Re: [openstack-dev] [Neutron] Neutron py27 test 'FAIL: process-returncode'

[Oleg Bondarev]

Hi Gary,

please see my comments on the review.

Thanks,
Oleg


On Wed, Feb 12, 2014 at 5:52 AM, Gary Duan garyd...@gmail.com wrote:

 Hi,

 The patch I submitted for L3 service framework integration fails on
 jenkins test, py26 and py27. The console only gives following error message,

 2014-02-12 00:45:01.710 | FAIL: process-returncode
 2014-02-12 00:45:01.711 | tags: worker-1

 and at the end,

 2014-02-12 00:45:01.916 | ERROR: InvocationError: 
 '/home/jenkins/workspace/gate-neutron-python27/.tox/py27/bin/python -m 
 neutron.openstack.common.lockutils python setup.py testr --slowest 
 --testr-args='
 2014-02-12 00:45:01.917 | ___ summary 
 
 2014-02-12 00:45:01.918 | ERROR:   py27: commands failed

 I wonder what might be the reason for the failure and how to debug this 
 problem?

 The patch is at, https://review.openstack.org/#/c/59242/

 The console output is, 
 http://logs.openstack.org/42/59242/7/check/gate-neutron-python27/e395b06/console.html

 Thanks,

 Gary


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


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

[openstack-dev] LBaaS: should we check for associations when deleting health monitor?

[Oleg Bondarev]

Hi,
Currently in LBaaS when health monitor object is deleted all associations
with pools are deleted automatically. A bug was reported recently in
Neutron where the reporter considers this behavior as wrong:
https://bugs.launchpad.net/neutron/+bug/1243129
I have no strong opinion so I'd like to hear others thoughts on this (devs
and vendors).

One option may be to add kind of 'force_delete' parameter to the delete
operation but that would require changes in api/docs/neutronclient/horizon
what is probably an overkill.

Please add your comments on bug in launchpad.

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

Re: [openstack-dev] [Neutron] Tenant's info from plugin/services

[Oleg Bondarev]

Hi Ivar,

Please take a look at this review: https://review.openstack.org/#/c/52128/
Here Akihiro adds tenant and user names to the Neutron context.

Thanks,
Oleg


On Thu, Oct 17, 2013 at 2:55 AM, Ivar Lazzaro i...@embrane.com wrote:

  Hello Everyone,

 ** **

 I was wondering if there’s a “standard” way within Neutron to retrieve
 tenants’ specific information (e.g. “name”) from a plugin/service.

 The call “context” already provides the tenant’s UUID, but that may be
 useful to have some extra info in certain cases.

 ** **

 Thanks,

 Ivar.

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


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

Re: [openstack-dev] [Quantum][LBaaS] Feedback needed: Healthmonitor workflow.

[Oleg Bondarev]

Hi,
First want to mention that currently health monitor is not a pure DB
object: upon creation the request is also send to device/driver.
Another thing is that there is no delete_health_monitor in driver API
(delete_pool_health_monitor only deletes the association) which is weird
because potentially health monitors will remain on device forever.

From what I saw from the thread referenced by Salvatore the main argument
against health monitor templates approach was:
*In NetScaler, F5 and similar products, health monitors are created*
*beforehand just like in the API, and then they are “bound” to pools (our*
*association API), so the mapping will be more natural*

IMO this is a strong argument until we start to maintain several
devices/drivers/service_providers per LB service.
With several drivers we'll need to send create/update/delete_health_monitor
requests to each driver and it's a big overhead. Same for pool monitor
assiciations as described in Eugene's initial mail.
I think it's not a big deal for drivers such as F5 to create/delete monitor
object upon creating/deleting 'private' health monitor.
So I vote for monitor templates and 1:1 mapping of 'private' health
monitors to pools until it's not too late and I'm ready to implement this
in havana.
Thoughts?

Thanks,
Oleg


On Thu, Jun 20, 2013 at 6:53 PM, Salvatore Orlando sorla...@nicira.comwrote:

 The idea of health-monitor templates was first discussed here:
 http://lists.openstack.org/pipermail/openstack-dev/2012-November/003233.html
 See follow-up on that mailing list thread to understand pro and cons of
 the idea.

 I will avoid moaning about backward compatibility at the moment, but that
 something else we need to discuss at some point if go ahead with changes in
 the API.

 Salvatore


 On 20 June 2013 14:54, Samuel Bercovici samu...@radware.com wrote:

  Hi,

 ** **

 I agree with this.

 We are facing challenges when the global health pool is changed to
 atomically modify all the groups that are linked to this health check as
 the groups might be configured in different devices.

 So if one of the group modification fails it is very difficult to revert
 the change back.

 ** **

 -Sam.

 ** **

 ** **

 *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com]
 *Sent:* Thursday, June 20, 2013 3:10 PM
 *To:* OpenStack Development Mailing List
 *Cc:* Avishay Balderman; Samuel Bercovici
 *Subject:* [Quantum][LBaaS] Feedback needed: Healthmonitor workflow.

 ** **

 Hi community,

 ** **

 Here's a question.

 Currently Health monitors in Loadbalancer service are made in such way
 that health monitor itself is a global shared database object. 

 If user wants to add health monitor to a pool, it adds association
 between pool and health monitor.

 In order to update existing health monitor (change url, for example)
 service will need to go over existing pool-health monitor associations
 notifying devices of this change.

 ** **

 I think it could be changed to the following workflow:

 Instead of adding pool-healthmonitor association, use health monitor
 object as a template (probably renaming is needed) and add 'private' health
 monitor to the pool. 

 So all further operations would result in changing health monitor on one
 device only.

 ** **

 What do you think?

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



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


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

Re: [openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS

[Oleg Bondarev]

Ok, here is the wiki page describing lbaas common agent:
https://wiki.openstack.org/wiki/Neutron/LBaaS/CommonAgentDriver

Thanks,
Oleg


On Thu, Jul 4, 2013 at 9:50 PM, Eugene Nikanorov enikano...@mirantis.comwrote:

 No, I meant server side, e.g. plugins or plugin drivers.
 RPC api should be designed in such way that allows sending messages to
 proper device driver.

 Thanks,
 Eugene.


 On Thu, Jul 4, 2013 at 12:51 PM, Oleg Bondarev obonda...@mirantis.comwrote:

 Hi Eugene,

 ...RPC API which then is shared between services.
 Did you mean device drivers rather than services?

 Thanks,
 Oleg


 On Thu, Jul 4, 2013 at 12:42 PM, Eugene Nikanorov 
 enikano...@mirantis.com wrote:

 I think the design should be documented on the wiki.
 Major part of such agent should be corresponding RPC API which then is
 shared between services.
 That needs to be thought out and discussed.

 Thanks,
 Eugene.


 On Thu, Jul 4, 2013 at 12:27 PM, Oleg Bondarev 
 obonda...@mirantis.comwrote:

 Hi folks,

 While working on agent scheduling for LBaaS reference implementation (
 https://review.openstack.org/#/c/32137/) I thought that it would be
 useful to unify existing agent to make it suite any vendor who wants to use
 async mechanism and agent scheduling.
 I filed a blueprint on this -
 https://blueprints.launchpad.net/neutron/+spec/lbaas-common-agent-driver
 So what do you guys think? Wishes/suggestions are welcome.

 Thanks,
 Oleg


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



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



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



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


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

[openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS

[Oleg Bondarev]

Hi folks,

While working on agent scheduling for LBaaS reference implementation (
https://review.openstack.org/#/c/32137/) I thought that it would be useful
to unify existing agent to make it suite any vendor who wants to use async
mechanism and agent scheduling.
I filed a blueprint on this -
https://blueprints.launchpad.net/neutron/+spec/lbaas-common-agent-driver
So what do you guys think? Wishes/suggestions are welcome.

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

Re: [openstack-dev] [Neutron][LBaaS] Common agent based driver for LBaaS

[Oleg Bondarev]

Hi Eugene,

...RPC API which then is shared between services.
Did you mean device drivers rather than services?

Thanks,
Oleg


On Thu, Jul 4, 2013 at 12:42 PM, Eugene Nikanorov
enikano...@mirantis.comwrote:

 I think the design should be documented on the wiki.
 Major part of such agent should be corresponding RPC API which then is
 shared between services.
 That needs to be thought out and discussed.

 Thanks,
 Eugene.


 On Thu, Jul 4, 2013 at 12:27 PM, Oleg Bondarev obonda...@mirantis.comwrote:

 Hi folks,

 While working on agent scheduling for LBaaS reference implementation (
 https://review.openstack.org/#/c/32137/) I thought that it would be
 useful to unify existing agent to make it suite any vendor who wants to use
 async mechanism and agent scheduling.
 I filed a blueprint on this -
 https://blueprints.launchpad.net/neutron/+spec/lbaas-common-agent-driver
 So what do you guys think? Wishes/suggestions are welcome.

 Thanks,
 Oleg


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



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


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