[openstack-dev] [Neutron] stepping down from core

[Rossella Sblendido]

Hi all,

I've moved to a new position recently and despite my best intentions I
was not able to devote to Neutron as much time and energy as I wanted.
It's time for me to move on and to leave room for new core reviewers.

It's been a great experience working with you all, I learned a lot both
on the technical and on the human side.
I won't disappear, you will see me around in IRC, etc, don't hesitate to
contact me if you have any question or would like my feedback on something.

ciao,

Rossella

__
OpenStack Development Mailing 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] keeping on top of neutron reviews

[Rossella Sblendido]

Hi all,

I'd like to remind that there's a dashboard that it's populated every
day showing patches that are fixes for high/critical bugs, approved
blueprints and RFE. You can find it here [1] under "Gerrit Dashboard links"

cheers,

Rossella

[1] http://status.openstack.org/reviews/

On 04/18/2017 12:45 AM, Kevin Benton wrote:
> Hello Neutron reviewers,
> 
> Please keep an eye on the review links
> in https://docs.openstack.org/developer/neutron/dashboards/index.html as
> part of your review routine.
> 
> I went through and reviewed a lot of old patches over the weekend so if
> we keep on top of that list it shouldn't get out of hand.
> 
> 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
> 

__
OpenStack Development Mailing 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] Risk prediction model for OpenStack

[Rossella Sblendido]

Hi Zoey Lin,

thanks a lot for sharing your analysis. I agree with you, diversity and
turnover of developers could be a good predictor for risk. Anyway
there's an important point that should be considered: who's reviewing
the code? A developer that has experience in a specific module might
stop contributing to it directly but might still review the code. This
helps the newcomers learning faster and reduces the risk of introducing
bugs.

cheers,

Rossella

On 04/06/2017 05:22 AM, 林泽燕 wrote:
> Hi Kevin,
> 
> I believe that the code ownership can reflect the module size in some
> way. The code ownership is small, which means a lot of commits made by a
> group of contributors, and thus the module might be quite large.
> And I think the amount of bugs might be used to identify the risky files
> for developers and managers and could act as an indicator of workload
> needed to improve the quality of the file, thus our develop team can
> estimate the workload on each file and adjust the work priority.
> I wonder if I have made it clear. Thank you for your attention.
> 
> Zoey Lin
> 
> 
> -原始邮件-
> *发件人:*"Kevin Benton" 
> *发送时间:*2017-04-05 22:17:08 (星期三)
> *收件人:* "OpenStack Development Mailing List (not for usage
> questions)" 
> *抄送:*
> *主题:* Re: [openstack-dev] [neutron] Risk prediction model for
> OpenStack
> 
> Thanks for this analysis. So one thing that jumps out at me right
> away is the correlation of this with the module size.
> ovs_neutron_agent.py is one of the biggest modules (if not the
> biggest non-test module) in Neutron, so if you don't control for
> line count in the analysis, this one would come out on top even if
> it had the same code quality (bugs per line) as other modules. How
> do you deal with module size?
> 
> Cheers,
> Kevin Benton
> 
> On Tue, Apr 4, 2017 at 11:01 PM, 林泽燕  > wrote:
> 
> Dear everyone, 
> 
> My name is Zoey Lin, majored in Computer Science, Peking
> University, China. I’m a candidate of Master Degree. Recently
> I'm making a research on OpenStack about the contribution
> composition of a code file, to predict the potential amount of
> defect that the file would have in the later development stage
> of a release.
> 
> I wonder if I could show you my study, including some metrics
> for the prediction model and a visualization tool. I would
> appreciate it if you could share your opinions or give some
> advices, which would really, really help me a lot. Thank you so
> much for your kindness. :)
> 
>  
> 
> First of all, I would give a brief introduction to my study. I
> analyzed and designed some metrics to describe the contribution
> composition of a code file, and then use these metrics to train
> a model to predict the amount of bug that a file would have as a
> risk value in the later development stage of a release, using
> the historical commit log data of the former development stage.
> The model showed a good performance. I also developed a tool to
> visualize the metrics and the potential risk value, which we
> believe could help developers and project managers being aware
> of the current situation and risk of the code file. We expect
> that project managers could estimate the workload, adjust the
> personnel assignment and locate the development problems based
> on the information of the tool and finally could reduce the risk
> and improve the quality of the project efficiently in some way.
> 
>  
> 
> Then, I would introduce two main metrics of my model.
> 
> 1. code ownership of files and developers: 
> 
> Code ownership shows the number of engineers contributing to a
> source code artifact and the relative proportion of their
> contributions. The code ownership of a file refers to the
> proportion of ownership for the contributor with the highest
> proportion of ownership, which could indicate that whether there
> is one developer who “owns” the file and has a high level of
> expertise, who can act as a single point of contact for others
> who need to use the component, need changes to it, or just have
> questions about it. Minor developer refers to developer whose
> code ownership is lower than 5%. Previous literatures have
> proven that code ownership and amount of minor developer
> strongly correlate with code defects.
> 
> 2. contribution diversity of the file:
> 
> We measured the uncertainty in a code file's contributions (or
> the diversity of sources of contributions) in a given month
> using the Teachman/Shannon entropy index, a commonly used
>

Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[Rossella Sblendido]

+1

On 12/16/2016 09:25 AM, Ihar Hrachyshka wrote:
> 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.
> 
> Great, +1.
> 
> __
> OpenStack Development Mailing List (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 Lavalle as neutron core and Brian Haley as L3 Lt

[Rossella Sblendido]

well deserved, +1!

On 12/16/2016 09:32 AM, Miguel Angel Ajo Pelayo wrote:
> +1 :)
> 
> On Fri, Dec 16, 2016 at 2:44 AM, Vasudevan, Swaminathan (PNB Roseville)
> mailto:swaminathan.vasude...@hpe.com>>
> wrote:
> 
> +1
> 
> __ __
> 
> *From:*Armando M. [mailto:arma...@gmail.com ]
> *Sent:* Thursday, December 15, 2016 3:15 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
>  >
> *Subject:* [openstack-dev] [neutron] proposing Miguel Lavalle as
> neutron core and Brian Haley as L3 Lt
> 
> __ __
> 
> 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] Neutron team social event in Barcelona

[Rossella Sblendido]

+1 Thanks Miguel!

On 10/19/2016 01:18 AM, Isaku Yamahata wrote:
> +1
> Thanks for organizing this.
> 
> On Fri, Oct 14, 2016 at 01:30:57PM -0500,
> 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-d1682057-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: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] Adding ihrachys to the neutron-drivers team

[Rossella Sblendido]

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

Rossella

On 09/20/2016 10:57 AM, Miguel Angel Ajo Pelayo wrote:

Congratulations Ihar!, well deserved through hard work! :)

On Mon, Sep 19, 2016 at 8:03 PM, Brian Haley  wrote:

Congrats Ihar!

-Brian


On 09/17/2016 12:40 PM, Armando M. wrote:


Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers
team [1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties
as
stable core, downstream package whisperer, release and oslo liaison (I am
sure I
am forgetting some other capacity he is in) is going to put him at great
comfort
in the newly appointed role, and help him grow and become wise even
further.

Even though we have not been meeting regularly lately we will resume our
Thursday meetings soon [2], and having Ihar onboard by then will be highly
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

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


[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers



__
OpenStack Development Mailing List (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 Jakub Libosvar for testing core

[Rossella Sblendido]

I find Jakub's reviews always very insightful. He contributed to several 
areas of the code base (OVSFirewallDriver, oslo versioned object and of 
course testing). Big +1 from me!


On 07/22/2016 10:12 AM, Oleg Bondarev wrote:

+1

On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley
mailto:doug...@parksidesoftware.com>> wrote:

+1


On Jul 21, 2016, at 5:13 PM, Kevin Benton mailto:ke...@benton.pub>> wrote:

+1

On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin mailto:c...@ecbaldwin.net>> wrote:

+1 from me

On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller
mailto:as...@redhat.com>> 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&feature=youtu.be&t=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



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

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

[Rossella Sblendido]

On 06/14/2016 11:43 AM, Daniel P. Berrange wrote:

Ok, so we're already passing that bridge name - all we need change is
make sure it is actuall created if it doesn't already exist ? If so
that sounds simple enough to add to os-vif - we already have exactly
the same logic for the linux_bridge plugin


That's exactly what I wanted to ask, thanks Daniel!
Note that in the devref [1] about the OVS agent implementation for trunk 
port we were already assuming strategy 2 . I am glad to see we are on 
the same page!


cheers,

Rossella

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

__
OpenStack Development Mailing 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] Mid-cycle development sprint

[Rossella Sblendido]

On 05/26/2016 10:47 PM, Henry Gessau wrote:
> I am happy to announce that the location logistics for the Neutron mid-cycle
> have been finalized. The mid-cycle will take place in Cork, Ireland on August
> 15-17. I have updated the wiki [1] where you will find a link to an etherpad
> with all the details. There you can add yourself if you plan to attend, and
> make updates to topics that you would like to work on.

Thanks for organizing this! I am happy to see a sprint in Europe :)
Unfortunately the 15th is bank holidays in some European countries and
at least in Italy most people organize their holidays around those days.
I will try to change my plans and do my best to attend.

cheers,

Rossella

> 
> 
> [1] https://wiki.openstack.org/wiki/Sprints#Newton_sprints
> 
> 
> 
> __
> OpenStack Development Mailing List (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] - Design summit session on the future of Neutron architecture

[Rossella Sblendido]

Hi all,

in Austin we had a session to discuss the future of Neutron
architecture. You can find the etherpad here [1].

The first part was about agents. In the last releases we have been
factoring common code out and allowing pluggability: in Liberty L2 agent
extensions were introduced and in Mitaka a common agent framework. We
were wondering if it could be worth considering to move to a single
agent, where l2, l3, etc. are just roles that can be loaded according to
the configuration. We didn't reach any consensus, many people expressed
doubts regarding this approach so for now nothing will change.

The second part was about upgrades and specifically about the
introduction of Oslo VersionedObject in Neutron. The upgrade subteam is
taking care of this [2]. This work still requires lots of effort but
everybody agreed that it's needed. We decided that new features need to
adopt OVO straight away. The only exception is if a feature uses a
resource that is already in the code base and has not been ported to OVO
yet. As action items we need to figure out which features are in flight
and need to adopt OVO and we need to fill any gap in the documentation.
The upgrades team should make authors of patches in flight aware of the
new requirements and should deliver foundational bits to build features
upon. Some patches may still land without objects right now and it’s
advised to reach upgrades subteam for recommendations if in doubt.

To test upgrades with two Neutron servers we might want to have a
three-node testing. Assaf suggested that we can achieve the same results
modifying the job that currently uses two nodes since we can run compute
services (l2 agent, nova-compute) on the ‘new’ node in addition to the
‘old’ services, and have a connectivity test for instances explicitly
landed on different nodes.

cheers,

Rossella and Ihar


[1]
https://etherpad.openstack.org/p/newton-neutron-future-neutron-architecture
[2] https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam

__
OpenStack Development Mailing 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] [infra][neutron][nova] publish and update Gerrit dashboard link automatically

[Rossella Sblendido]

Hi all,

in case you are wondering what's the progress of this, I am happy to say
that we finally have a link in reviewday [1] that points to the Neutron
dashboard that it's constantly updated. It took some effort to get
there, thanks to the infra team for the help and especially to AJaeger.
Now that the groundwork is done, I think this strategy can be easily
adopted by other projects.

cheers,

Rossella

[1] http://status.openstack.org//reviews/

On 03/23/2016 05:40 PM, Rossella Sblendido wrote:
> 
> 
> On 03/22/2016 02:28 PM, Markus Zoeller wrote:
>>> From: Jeremy Stanley 
>>> To: "OpenStack Development Mailing List (not for usage questions)" 
>>> 
>>> Date: 02/18/2016 02:05 AM
>>> Subject: Re: [openstack-dev] [infra][neutron] publish and update 
>>> Gerrit dashboard link automatically
>>>
>>> On 2016-02-16 14:52:04 -0700 (-0700), Carl Baldwin wrote:
>>> [...]
>>>> No matter how it is done, there is the problem of where to host such a
>>>> page which can be automatically updated daily (or more often) by this
>>>> script.
>>>>
>>>> Any thoughts from infra on this?
>>>
>>> A neat idea, and sounds like an evolution of/replacement for
>>> reviewday[1][2]. Our community already has all the tools it needs
>>> for running scripts and publishing the results in an automated
>>> fashion (based on a timer, triggered by merged commits in a Git
>>> repo, et cetera), as well as running Web servers... you could just
>>> add a vhost to the openstack_project::static class[3] and then a job
>>> in our project configuration[4] to update it.
>>>
>>> [1] http://status.openstack.org/reviews/
>>> [2] http://git.openstack.org/cgit/openstack-infra/reviewday/
>>> [3] http://git.openstack.org/cgit/openstack-infra/system-config/tree/
>>> modules/openstack_project/manifests/static.pp
>>> [4] http://git.openstack.org/cgit/openstack-infra/project-config/tree/
>>> jenkins/jobs/
>>> -- 
>>> Jeremy Stanley
>>
>> I didn't see this thread back then when it started. I think Nova would
>> benefit from that too. I didn't find a Neutron related change in [1]
>> as Jeremy suggested. I'm mainly interested in bug fix changes, ordered
>> by bug report importance.
>>
>> @Rossella: 
>> Are you still working on this or is this solved in another way?
> 
> Hi Markus,
> 
> yes I am still working on this. The idea is to use Gerrit project
> dashboard as suggested by jeblair[1]. I pushed a patch for Neutron [2],
> it's still work in progress, waiting for feedback from infra.
> 
> cheers,
> 
> Rossella
> 
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-03-11.log.html#t2016-03-11T14:47:06
> [2] https://review.openstack.org/#/c/284284/
> 
>>
>> References:
>> [1] 
>> http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/static.pp
>>
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> __
>> OpenStack Development Mailing List (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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Rossella Sblendido]

On 04/22/2016 02:42 AM, Cathy Zhang wrote:
> So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday
> and then continue the discussion at Room 400 at 3:10pm Thursday.
> 
> Since Salon C is a big room, I will put a sign “Common Flow Classifier
> and OVS Agent Extension” on the table.
> 
I am also interested in joining the conversation. Wednesday for lunch
works for me!

__
OpenStack Development Mailing 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] L3 HA testing on scale

[Rossella Sblendido]

On 04/18/2016 04:15 PM, Anna Kamyshnikova wrote:
> Hi guys!
> 
> As a developer I use Devstack or multinode OpenStack installation (4-5
> nodes) for work, but these are "abstract" environments, where you are
> not able to perform some scenarios as your machine is not powerful
> enough. But it is really important to understand the issues that real
> deployments have.
> 
> Recently I've performed testing of L3 HA on the scale environment 49
> nodes (3 controllers, 46 computes) Fuel 8.0. On this environment I ran
> shaker and rally tests and also performed some
> manual destructive scenarios. I think that this is very important to
> share these results. Ideally, I think that we should collect statistics
> for different configurations each release to compare and check it to
> make sure that we are heading the right way.  
> 
> The results of shaker and rally tests [1]. I put detailed report in
> google doc [2]. I would appreciate all comments on these results.

It's a great report, thanks for sharing that! Do you plan to run similar
scale tests on other scenarios e.g. dvr?

Rossella

> 
> [1] - http://akamyshnikova.github.io/neutron-benchmark-results/
> [2]
> - 
> https://docs.google.com/a/mirantis.com/document/d/1TFEUzRRlRIt2HpsOzFh-RqWwgTzJPBefePPA0f0x9uw/edit?usp=sharing
> 
> Regards,
> Ann Kamyshnikova
> Mirantis, Inc
> 
> 
> __
> OpenStack Development Mailing List (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] Prevent invalid live migration instead of failing and setting instance to error state after porbinding failed

[Rossella Sblendido]

On 04/12/2016 12:05 PM, Andreas Scheuring wrote:
> Hi together, 
> I wanted to start discussion about Live Migration problem that currently 
> exists in the nova neutron communication.
> 
> Basics Live Migration and Nova - Neutron communication
> --
> On a high level, Nova Live Migration happens in 3 stages. (--> is what's 
> happening from network perspective)
> #1 pre_live_migration
>--> libvirtdriver: nova plugs the interface (for ovs hybrid sets up the 
> linuxbridge + veth and connects it to br-int)
> #2 live_migration_operation
>--> instance is being migrated (using libvirt with the domain.xml that is 
> currently active on the migration source)
> #3 post_live_migration
>--> binding:host_id is being updated for the port
>--> libvirtdriver: domain.xml is being regenerated  
> More details can be found here [1]
> 
> The problem - portbinding fails
> ---
> With this flow, ML2 portbinding is triggered in post_live_migration. At this 
> point, the instance has already been migrated and is active on the migration 
> destination.
> Part of the port-binding is happening in the mechanism drivers, where the vif 
> information for the port (vif-type, vif-details,..) is being updated.
> If this portbinding fails, port will get the binding:vif_type 
> "binding_failed".
> After that the nova libvirt driver starts generating the domain xml again to 
> persist it. Part of this generation is also generating the interface 
> definition. 
> This fails as the vif_type is "binding_failed". Nova will set the instance to 
> error state. --> There is no rollback, as it's already too late!
> 
> Just a remark: There is no explicit check for the vif_type binding_failed. I 
> have the feeling that it (luckily) fails by accident when generating the xml.
> 
> --> Ideally we would trigger the portbinding before the migration started - 
> in pre_live_migration. Then, if binding fails, we could abort migration 
> before it even started. The instance would still be
> active and fully functional on the source host. I have a WIP patchset out 
> proposing this change [2]
> 
> 
> The impact
> --
> Patchset [2] propose updating the host_id already in pre_live_migration. 
> During migration, the port would already be owned by the migration target 
> (although the guest is still active on the source)
> Technically this works fine for all the reference implementations, but this 
> could be a problem for some third party mech drivers, if they shut down the 
> port on the source and activate it on the target - although instance is still 
> on the source
> 
> Any thoughts on this?

+1 on this anyway let's hear back from third party drivers maintainers.

> 
> 
> Additional use cases that would be enabled with this change
> ---
> When updating the host_id in pre_live_migration, we could modify the 
> domain.xml with the new vif information before live migration (see patch [2] 
> and nova spec [4]).
> This enables the following use cases
> 
> #1 Live Migration between nodes that run different l2 agents
>E.g. you could migrate a instance from an ovs node to an lb node and vice 
> versa. This could be used as l2 agent transition strategy!
> #2 Live Migration with macvtap agent
>It would enable the macvtap agent to live migrate instances between hosts, 
> that use a different physical_interface_mapping. See bug [3]
> 
> --> #2 is the use case that made me thinking about this whole topic
> 
> Potential other solutions
> -
> #1 Have something like simultaneous portbinding - On migration, a port is 
> bound to 2 hosts (like a dvr port can today).
> Therefore some database refactorings would be required (work has already been 
> started in the DVR context [7])
> And the Rest API would need to be changed in a way, that there's not a single 
> binding, but a list of bindings returned. Of course also create & update that 
> list.
>

I don't like this one. This would require lots of code changes and I am
not sure it would solve the problem completely. The model of having a
port bound to two hosts just because it's migrating, it's confusing.


> #2 execute portbinding without saving it to db
> we could also introduce a new api( like update port, with live migration 
> flag), that would run through the portbinding code and would return the port
> information for the target node, but would not persist this information. Son 
> on port-show you would still get the old information. Update would only 
> happen if the migration flag is not present (in post_live_migration like 
> today)
> Alternatively the generated protbidning could be stored in the port context 
> and be used on the final port_update be instead of running through all the 
> code pathes again.
> 

Another possible solution is to apply the same strategy we use for
instance creation. Nova should wait to get a

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

[Rossella Sblendido]

On 04/05/2016 05:43 AM, Armando M. wrote:
> 
> With this email I would like to appeal to the people in CC to report
> back their interest in continuing working on these items in their
> respective capacities, and/or the wider community, in case new owners
> need to be identified.
> 
> I look forward to hearing back, hoping we can find the right resources
> to resume progress, and bring these important requirements to completion
> in time for Newton.

Count me in for the vlan-aware-vms. We have now a solid design, it's
only a matter of putting it into code. I will help any way I can, I
really want to see this feature in Newton.

cheers,

Rossella

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

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

[Rossella Sblendido]

On 03/23/2016 05:52 PM, Ihar Hrachyshka wrote:
> Hey folks,
> 
> some update on proactive backporting for neutron, and a call for action
> from subteam leaders.
> 
> As you probably know, lately we started to backport a lot of bug fixes
> in latest stable branch (liberty atm) + became more systematic in
> getting High+ bug fixes into older stable branch (kilo atm).
> 
> I work on some tooling lately to get the process a bit more straight:
> 
> https://review.openstack.org/#/q/project:openstack-infra/release-tools+owner:%22Ihar+Hrachyshka+%253Cihrachys%2540redhat.com%253E%22
> 
> 
> I am at the point where I can issue a single command and get the list of
> bugs fixed in master since previous check, with Wishlist bugs filtered
> out [since those are not applicable for backporting]. The pipeline looks
> like:
> 
> ./bugs-fixed-since.py neutron  |
> ./lp-filter-bugs-by-importance.py --importance=Wishlist neutron |
> ./get-lp-links.py
> 
> For Kilo, we probably also need to add another filter for Low impact bugs:
> 
> ./lp-filter-bugs-by-importance.py --importance=Low neutron
> 
> There are more ideas on how to automate the process (specifically, kilo
> backports should probably be postponed till Liberty patches land and be
> handled in a separate workflow pipeline since old-stable criteria are
> different; also, the pipeline should fully automate ‘easy' backport
> proposals, doing cherry-pick and PS upload for the caller).

Wow, great work, thanks a lot!

> 
> However we generate the list of backport candidates, in the end the bug
> list is briefly triaged and categorized and put into the etherpad:
> 
> https://etherpad.openstack.org/p/stable-bug-candidates-from-master
> 
> I backport some fixes that are easy to cherry-pick myself. (easy == with
> a press of a button in gerrit UI)
> 
> Still, we have a lot of backport candidates that require special
> attention in the etherpad.
> 
> I ask folks that cover specific topics in our community (f.e. Assaf for
> testing; Carl and Oleg for DVR/L3; John for IPAM; etc.) to look at the
> current list, book some patches for your subteams to backport, and make
> sure the fixes land in stable.

I've gone through the L2 and ML2 section. I backported missing patches
and added comments where I think no backport is needed.

cheers,

Rossella

> 
> Note that the process generates a lot of traffic on stable branches, and
> that’s why we want more frequent releases. We can’t achieve that on kilo
> since kilo stable is still in the integrated release mode, but starting
> from Liberty we should release more often. It’s on my todo to document
> release process in neutron devref.
> 
> For your reference, it’s just a matter of calling inside
> openstack/releases repo:
> 
> ./tools/new_release.sh liberty neutron bugfix
> 
> FYI I just posted a new Liberty release patch at:
> https://review.openstack.org/296608
> 
> Thanks for attention,
> 
> Ihar Hrachyshka  wrote:
> 
>> Ihar Hrachyshka  wrote:
>>
>>> Rossella Sblendido  wrote:
>>>
>>>> Hi,
>>>>
>>>> thanks Ihar for the etherpad and for raising this point.
>>>> .
>>>>
>>>>
>>>> On 12/18/2015 06:18 PM, Ihar Hrachyshka wrote:
>>>>> Hi all,
>>>>>
>>>>> just wanted to note that the etherpad page [1] with backport
>>>>> candidates
>>>>> has a lot of work for those who have cycles for backporting relevant
>>>>> pieces to Liberty (and Kilo for High+ bugs), so please take some on
>>>>> your
>>>>> plate and propose backports, then clean up from the page. And please
>>>>> don’t hesitate to check the page for more worthy patches in the
>>>>> future.
>>>>>
>>>>> It can’t be a one man army if we want to run the initiative in long
>>>>> term.
>>>>
>>>> I completely agree, it can't be one man army.
>>>> I was thinking that maybe we can be even more proactive.
>>>> How about adding as requirement for a bug fix to be merged to have
>>>> the backport to relevant branches? I think that could help
>>>
>>> I don’t think it will work. First, not everyone should be required to
>>> care about stable branches. It’s my belief that we should avoid
>>> formal requirements that mechanically offload burden from stable team
>>> to those who can’t possible care less about master.
>>
>> Of course I meant ‘about stable branches’.
>>
>> Ihar
>>
>> _

Re: [openstack-dev] [infra][neutron][nova] publish and update Gerrit dashboard link automatically

[Rossella Sblendido]

On 03/22/2016 02:28 PM, Markus Zoeller wrote:
>> From: Jeremy Stanley 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Date: 02/18/2016 02:05 AM
>> Subject: Re: [openstack-dev] [infra][neutron] publish and update 
>> Gerrit dashboard link automatically
>>
>> On 2016-02-16 14:52:04 -0700 (-0700), Carl Baldwin wrote:
>> [...]
>>> No matter how it is done, there is the problem of where to host such a
>>> page which can be automatically updated daily (or more often) by this
>>> script.
>>>
>>> Any thoughts from infra on this?
>>
>> A neat idea, and sounds like an evolution of/replacement for
>> reviewday[1][2]. Our community already has all the tools it needs
>> for running scripts and publishing the results in an automated
>> fashion (based on a timer, triggered by merged commits in a Git
>> repo, et cetera), as well as running Web servers... you could just
>> add a vhost to the openstack_project::static class[3] and then a job
>> in our project configuration[4] to update it.
>>
>> [1] http://status.openstack.org/reviews/
>> [2] http://git.openstack.org/cgit/openstack-infra/reviewday/
>> [3] http://git.openstack.org/cgit/openstack-infra/system-config/tree/
>> modules/openstack_project/manifests/static.pp
>> [4] http://git.openstack.org/cgit/openstack-infra/project-config/tree/
>> jenkins/jobs/
>> -- 
>> Jeremy Stanley
> 
> I didn't see this thread back then when it started. I think Nova would
> benefit from that too. I didn't find a Neutron related change in [1]
> as Jeremy suggested. I'm mainly interested in bug fix changes, ordered
> by bug report importance.
> 
> @Rossella: 
> Are you still working on this or is this solved in another way?

Hi Markus,

yes I am still working on this. The idea is to use Gerrit project
dashboard as suggested by jeblair[1]. I pushed a patch for Neutron [2],
it's still work in progress, waiting for feedback from infra.

cheers,

Rossella

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-03-11.log.html#t2016-03-11T14:47:06
[2] https://review.openstack.org/#/c/284284/

> 
> References:
> [1] 
> http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/static.pp
> 
> Regards, Markus Zoeller (markus_z)
> 
> 
> __
> OpenStack Development Mailing List (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] CI jobs take pretty long, can we improve that?

[Rossella Sblendido]

Hello all,

the tests that we run on the gate for Neutron take pretty long (longer
than one hour). I think we can improve that and make better use of the
resources.
Here are some ideas that came up when Ihar and I discussed this topic
during the sprint in Brno:

1) We have few jobs that are non-voting. I think it's OK to have
non-voting jobs for a limited amount of time, while we try to make them
stable but this shouldn't be too long, otherwise we waste time running
those tests without even using the results. If a job is still not-voting
after 3 months (or 4 or 6, we can find a good time interval) the job
should be removed. My hope is that this threat will make us find some
time to actually fix the job and make it vote :)

2) multi-node jobs run for every patch set. Is that really what we want?
They take pretty long. We could move them to a periodic job. I know we
can easily forget about periodic jobs, to avoid that we could run them
in the gate queue too. If a patch can't merge because of a failure we
will fix the issue. To trigger them for a specific patch that might
affect multi-node we can run the experimental jobs.

Thoughts?

Rossella

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

Re: [openstack-dev] [all][infra][ptls] tagging reviews, making tags searchable

[Rossella Sblendido]

On 03/19/2016 05:51 PM, Jeremy Stanley wrote:
> Rossella Sblendido was working on a similar solution[1] for Neutron
> reviews, so this seems to be a popular desire across many projects.
> The rough consensus[2] in Infra was in favor of a CI job to perform
> the appropriate analysis to generate the desired dashboards and then
> push those into Gerrit so that it could host them directly rather
> than people having to maintain and update separate websites hosting
> query-based Gerrit dashboards.
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086392.html
> [2] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-03-11.log.html#t2016-03-11T14:46:05

Thanks Jeremy :)
Since this desire is shared across projects we can work together on it.
I will try to get a patch ready this week to have a CI job generate the
project dashboard for Neutron.
In Neutron we use a script to select the patches that fix critical/high
bugs and implement blueprints targeting the current milestone. The
script outputs a file that gerrit-dash-creator uses to generate a
dashboard [1]. I think this can be easily changed so that other project
can use it.

cheers,

Rossella

[1]
https://github.com/openstack/neutron/blob/master/tools/milestone-review-dash.py

__
OpenStack Development Mailing 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] report from Brno code sprint, Mar 14-16

[Rossella Sblendido]

On 03/21/2016 07:11 AM, Doug Wiegley wrote:
> 
>> On Mar 18, 2016, at 4:01 AM, Ihar Hrachyshka  wrote:
>>
>> Hi all,
>>
>> Just giving my fellows an update from the event where we gathered our 
>> upgrades subteam to plan for Newton and do some coding.
>>
>> ==
>>
>> We had folks from multiple companies participating in the event (Red Hat, 
>> SuSE, Intel, IBM). We also had some folks joining us online. Thanks everyone 
>> who gave us a hand at these days!
>>
>> For the most part, we were working on the plan to adopt versioned objects 
>> for neutron db codebase. Just in case someone is not aware about the end 
>> goal for the effort: we want to eventually get to the point where you can 
>> upgrade your neutron-server processes between major releases without 
>> shutting all of them down to run database migration scripts. [There are 
>> other applications for objects, but that’s currently out of immediate scope 
>> for the N effort.]
> 
> What is the plan for out of tree objects derived from neutron, and out of 
> tree projects that are using the current neutron objects?  Specifically, the 
> ones which *can’t* use the REST API, because they’re for something loaded 
> directly into neutron-server (core plugins, service plugins, etc). Will they 
> work?  Is our live upgrade strategy going to be labeled “reference only”?
> 

That's a good point. Ideally plugins should use objects too. Once we
have objects in the core code base it should be easy to introduce them
in the plugins. In most cases we probably won't have to change anything
in the plugins code, since objects can be accessed as dict. We have
started this effort very early in the release cycle, so my hope is that
we will have enough time to test and make required changes.

cheers,

Rossella

> doug
> 
> 
>>
>> Long story short, the current plan of the team for the near future is:
>>
>> - N: provide objects for all major neutron resources;
>> - N: get most if not all the db code in neutron repo switched to using 
>> objects;
>> - N: start using objects to handle database live data migration (aka 
>> ‘contract’ scripts);
>> - start of O: forbid contract alembic scripts;
>> - O and beyond: introduce gating for HA neutron-servers; complete objects 
>> adoption; look into utilizing objects for plugin API; API version pinning; 
>> ...
>>
>> If all goes well, this plan should allow ops to upgrade Newton 
>> neutron-server to O without API endpoint downtime.
>>
>> ==
>>
>> We also discussed current gating for upgrades. The plan for that would be 
>> getting the current l3 legacy job voting next weeks; adding dvr flavor into 
>> check queue (non-voting); get voting for the latter (probably while removing 
>> the former from check gate).
>>
>> There are still some things to improve in multinode grenade that we have.
>>
>> One thing is that we should look into running dvr tests for dvr flavour of 
>> the job. Though there are some dvr tests in tempest, they are not tagged as 
>> smoke, and hence are not executed in the job. Also, as per Assaf, those dvr 
>> tests go away from tempest middle term, leaving just tests inside neutron 
>> tree. So we should come up with some way to run dvr tests that are 
>> maintained inside neutron tree. One way is utilizing a tempest plugin (there 
>> is a patch for review for that).
>>
>> Another thing we may want to consider is moving some more services into 
>> ‘old’ node of the multinode setup. Specifically, dhcp and l3 agent (even for 
>> l3 legacy job). There are questions though whether we would then effectively 
>> hide some potential places to break (due to external-to-internal routing not 
>> leaving the node, or no tunneling needed between l3/dhcp and instances). So 
>> it may require introducing a separate ‘networking’ node in the multinode 
>> setup to host l3/dhcp agents there.
>>
>> ==
>>
>> We realize that subteam plans are not well known to other community members. 
>> We will work on raising awareness about use cases and features we target for 
>> next releases. That will include posting proper ‘ops oriented’ RFEs, working 
>> on documentation (devref as well as networking-guide), etc.
>>
>> One thing that we discussed on the event is updating networking-guide with 
>> detailed description of the upgrade process for neutron. We already have 
>> some pieces scattered there [f.e. we have some coverage for 
>> neutron-db-manage tool] but it’s nothing complete or deep enough. That’s 
>> something we will look into improving at the start of the N cycle.
>>
>> ==
>>
>> As for actual coding, we focused on objects. We track the effort using ‘ovo’ 
>> topic in gerrit:
>>
>> https://review.openstack.org/#/q/topic:ovo
>>
>> We landed some patches already, and we will land a lot more in the next 
>> months. Reviews from outside the subteam are highly appreciated. If 
>> anything, you may learn something new. :)
>>
>> ==
>>
>> It was the second time we organized a highly focused sprint for Neutron (the 
>> previous one was 

Re: [openstack-dev] [infra][neutron] publish and update Gerrit dashboard link automatically

[Rossella Sblendido]

On 02/17/2016 07:17 PM, Doug Wiegley wrote:

Results, updated hourly (bookmarkable, will redirect to gerrit):

http://104.236.79.17/
http://104.236.79.17/current
http://104.236.79.17/current-min


Nice, thanks a lot for looking into this!!

__
OpenStack Development Mailing 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] [infra][neutron] publish and update Gerrit dashboard link automatically

[Rossella Sblendido]

On 02/12/2016 12:25 PM, Rossella Sblendido wrote:

Hi all,

it's hard sometimes for reviewers to filter reviews that are high
priority. In Neutron in this mail thread [1] we had the idea to create a
script for that. The script is now available in the Neutron repository [2].
The script queries Launchpad and creates a file that can be used by
gerrit-dash-creator to display a dashboard listing patches that fix
critical/high bugs, that implement approved blueprint or feature
requests. This is how it looks like today [3].
For it to be really useful the dashboard link needs to be updated once a
day at least. Here I need your help. I'd like to publish the URL in a
public place and update it every day in an automated way. How can I do
that?

thanks,

Rossella

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079816.html

[2]
https://github.com/openstack/neutron/blob/master/tools/milestone-review-dash.py

[3] https://goo.gl/FSKTj9


This last link is wrong, this is the right one [1] sorry.

[1] https://goo.gl/Hb3vKu



__
OpenStack Development Mailing List (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] [infra][neutron] publish and update Gerrit dashboard link automatically

[Rossella Sblendido]

Hi all,

it's hard sometimes for reviewers to filter reviews that are high 
priority. In Neutron in this mail thread [1] we had the idea to create a 
script for that. The script is now available in the Neutron repository [2].
The script queries Launchpad and creates a file that can be used by 
gerrit-dash-creator to display a dashboard listing patches that fix 
critical/high bugs, that implement approved blueprint or feature 
requests. This is how it looks like today [3].
For it to be really useful the dashboard link needs to be updated once a 
day at least. Here I need your help. I'd like to publish the URL in a 
public place and update it every day in an automated way. How can I do that?


thanks,

Rossella

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079816.html
[2] 
https://github.com/openstack/neutron/blob/master/tools/milestone-review-dash.py

[3] https://goo.gl/FSKTj9

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

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

[Rossella Sblendido]

On 01/19/2016 05:14 PM, Ihar Hrachyshka wrote:

Rossella Sblendido  wrote:




On 01/19/2016 04:36 PM, Miguel Angel Ajo Pelayo wrote:

Thinking of this, I had another idea, a bit raw yet.

But how does it sound to have two meetings a week, one in a EU/ASIA
friendlier
timezone, and another for USA/AU (current one), with different chairs.

We don't impose unnatural-working hours (too early, too late for
family, etc..)
to anyone, we encourage gathering as a community (may be split by
timezones, but
it feels more human and faster than ML conversations..) and also
people able
to make to both, could serve as bridges for both meetings.


Thoughts?


I think that is what Kyle was proposing and if I am not wrong that's
what they do in nova.


My understanding is that Kyle proposed to switch back to bi-weekly
alternating meetings, and have a separate chair for each.


You are right Ihar, I misread. I like Kyle's proposal better too.

Rossella



I think Kyle’s suggestion is wiser since it won’t leave the community
split into two separate parts, and it won’t waste two hours each week
where we could make it with just one.

Ihar

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


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

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

[Rossella Sblendido]

On 01/19/2016 04:36 PM, Miguel Angel Ajo Pelayo wrote:

Thinking of this, I had another idea, a bit raw yet.

But how does it sound to have two meetings a week, one in a EU/ASIA friendlier
timezone, and another for USA/AU (current one), with different chairs.

We don't impose unnatural-working hours (too early, too late for family, etc..)
to anyone, we encourage gathering as a community (may be split by timezones, but
it feels more human and faster than ML conversations..) and also people able
to make to both, could serve as bridges for both meetings.


Thoughts?


I think that is what Kyle was proposing and if I am not wrong that's 
what they do in nova.


+1






- Original Message -

In Nova the alternate meetings were chaired by different people. I think that
was very productive and fruitful. So it is certainly something worth
considering. At the end of the day all of the meetings are logged and people
can go over the logs and address issues that can and may concern them. At
the end of the day we are a community and it would be nice to know that the
community is open to accommodating people irrespective of where and how they
live (yeah we are all envious of the IRC surfer ‘checkyouinthetubes’ who
spends her/his days surfing around the world). If we do decide to continue
with the single meeting time then we need to understand and accept that
certain people may not be able to take part. In general if there is
something really important that one wants to raise and it does not get
addressed on the mail list then they can make an effort to attend the
meeting to raise their issues/concerns/points.

Meetings aside the core team is spread pretty nicely across the globe.

A luta continua


From: " mest...@mestery.com " < mest...@mestery.com >
Reply-To: OpenStack List < openstack-dev@lists.openstack.org >
Date: Wednesday, January 13, 2016 at 6:07 AM
To: OpenStack List < openstack-dev@lists.openstack.org >
Subject: Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On Tue, Jan 12, 2016 at 5:28 PM, Doug Wiegley < doug...@parksidesoftware.com

wrote:



I don’t think it ninja merged. It had plenty of reviews, and was open during
international hours. I don’t have any issue there.

I don’t like the crazy early meeting, so I set out to prove it didn’t matter:

Average attendance before rotating: 20.7 people
Average attendance on Monday afternoons (U.S. time): 20.9
Average attendance on Tuesday morning (U.S. time): 23.7

Stupid data, that’s not what I wanted to see.

I haven’t yet correlated people to which meeting time yet, but attendance was
slightly up during the crazy early hated time, across the 1.25 years it was
running (started 9/9/14). This is just people saying something; lurkers can
just read the logs.

Data is from eavesdrop meeting logs, if anyone else wants to crunch it.

Since it's ridiculous to assume people are required to attend this meeting,
one easy solution to this would be to go back to the rotating meeting and
have a different chair for the Tuesday morning PST meeting. I think rotating
chairs for this meeting would be a good idea for a multitude of reasons
(spreads the pain, lets others have a chance at the pulpit, grooms future
meeting leaders, etc.).

Thanks,
Kyle



Thanks,
doug



On Jan 12, 2016, at 4:32 PM, Tony Breeds < t...@bakeyournoodle.com > wrote:

On Tue, Jan 12, 2016 at 01:27:30PM +0100, Ihar Hrachyshka wrote:

Agreed with Gary on behalf of my European compatriots. (Note that I
*personally* +1’d the patch because I don’t mind, doing late hours anyway;
but it’s sad it was ninja merged without giving any chance for those from
affected timezones to express their concerns).


So Ninja merged has a negative connotation that I refute.

I merged it. It was judgment error, and I apologise for that.

* I found and read through the list thread.
* Saw only +1's yours included
- known you'd be affected I used your +1 as a barometer

My mistake was not noticing your request to leave the review open for
longer.

I also noted in my review that reverting it is pretty low cost to back it
out
if needed.

I understand that the 'root cause' for this change was the yaml2ical issue
that
stemmed from having 2 odd week in a row. We've fixed that [1]. I'm also
working a a more human concept of biweekly meeting in yaml2ical.

Tony
[1] the next time it could have been a problem is 2020/2021 ;P
__
OpenStack Development Mailing List (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] changing in neutron code

[Rossella Sblendido]

Hi Atif,

you can find all the answers in the Neutron developer guide [1].

cheers,

Rossella

[1] http://docs.openstack.org/developer/neutron/devref/index.html

On 01/17/2016 08:17 PM, Atif Saeed wrote:

Hi All,

I am a newbie in an Open Stack developers community. I want to do some
modification in Devstack/kilo neutron part. Can anyone guide me how to
test the modification in the code part.

(1) Should I need to define my own module/class.
(2) Can I add some def in neutron code.

and Importantly, How to test that my code is working or not?

Suggestions are highly appreciated and welcome. Really need to get help.

A.




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



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

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

[Rossella Sblendido]

I agree too.
Neutron community is scattered all over the world, it makes sense for me 
to have two different times.
If attendance is not big enough that's something that we should try to 
address. It's a problem that we should try to fix, not a condition that 
we should accept. Moving to one time because of this gives the wrong 
message I think.


cheers,

Rossella

On 01/12/2016 01:47 PM, Miguel Angel Ajo wrote:

I agree with Gary here,

The 21:00 UTC time here is a difficult time for me, because it's
exactly the time of getting kids to sleep
at home. It's generally very unpredictable for me.

 I missed last meeting exactly because of that, laptop was ready, I
was ready, kids didn't cooperate.

 I will do my best to be there every 21:00 UTC if it's finally
changed, but, I can't guarantee.

Ihar Hrachyshka wrote:

Agreed with Gary on behalf of my European compatriots. (Note that I
*personally* +1’d the patch because I don’t mind, doing late hours
anyway; but it’s sad it was ninja merged without giving any chance for
those from affected timezones to express their concerns).

Ihar

Gary Kotton  wrote:


Hi,
I personally liked that fact that there were two times. It was
reasonable to make an effort to stay up very late to attend the one
and then have the privileged of the other being at a reasonable time.
Now it is back to the crazy hours.
Thanks
Gary

From: Hirofumi Ichihara 
Reply-To: OpenStack List 
Date: Tuesday, January 12, 2016 at 1:39 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC



On 2016/01/12 7:14, Armando M. wrote:

On 11 January 2016 at 13:54, Hirofumi Ichihara
 wrote:

On 2016/01/12 5:14, Armando M. wrote:

On 11 January 2016 at 12:04, Carl Baldwin  wrote:

What do we do?  My calendar was set up with the sane bi-weekly thing
and it shows the meeting for tomorrow.  The last word from our
fearless leader is that we'll have it today.  So, I'll be there
today
unless instructed otherwise.

The ics file now seems to reset the cadence beginning today at 2100
and next Tuesday, the 19th, at 1400.  I guess we should either hold
the meeting today and reset the cadence or fix the ics file.


This is what I would like to do now:

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

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

I like it.

However, we have gathered from all over the world because neutron
is big project. Should we have the choice so that more people get
attendance opportunity?


This time, the return to the normal schedule was a disaster, plus
every time we switch to daylight savings, or every time there's a
holiday break/summit we have twice the chances to screw up if we
keep the bi-weekly schedule.

If I go and look at the logs [1] I don't have hard evidence that the
bi-weekly schedule does indeed help the attendance of friendlier
timezones, so I wonder...what's the point?

You're right. My reply was just general opinion. I think that most
regular folks probably attend both days now. I actually do as well.

I was worried that sometimes there are developers who introduce his
bug or ask core to review although they usually don't attend.
However, we have openstack-neutron channel for it.


A.

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

Carl

On Mon, Jan 11, 2016 at 12:09 PM, Kevin Benton
 wrote:
> The issue is simply that you have a sane bi-weekly thing setup
in your
> calendar. What we have for Neutron is apparently defined as
“odd and even
> weeks when weeks are represented as an short integer counting
from the first
> of the year”, a.k.a. “bi-weekly” as a robot might define it. :)
>
>
> On Jan 11, 2016, at 11:00 AM, Kyle Mestery
 wrote:
>
> On Mon, Jan 11, 2016 at 12:57 PM, Kyle Mestery
 wrote:
>>
>> On Mon, Jan 11, 2016 at 12:45 PM, Armando M.
 wrote:
>>>
>>> Disregard the email subject.
>>>
>>> I stand corrected. Let's meet today.
>>>
>>
>> Something is wrong, I have the meeting on my google calendar,
and it shows
>> up as tomorrow for this week. I've had these setup as rotating
for a while
>> now, so something is fishy with the .ics files.
>
>
> If you look here [1], the meeting cadence was:
>
> 12-15-2015: Tuesday
> 12-21-2015: Monday
> 12-29-2015: Tuesday (skipped)
> 01-04-2016: Monday (skipped)
> 01-12-2016 Tuesday
>
> The meeting is tomorrow.
>
> [1] http://eavesdrop.openstack.org/meetings/networking/2015/
>>
>>
>>>
>>> On 11 January 2016 at 10:24, Ihar Hrachyshka
 wrote:

 Armando M.  wrote:

> Hi neutrinos,
>
> A kind reminder for tomorrow's meeting at 1400UTC.
>
> Cheers,
> Armando
>
> [1] https://wiki.openstack.org/wiki/Network/Meetings
>
>
__

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

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

[Rossella Sblendido]

Hi,

thanks Ihar for the etherpad and for raising this point.
.


On 12/18/2015 06:18 PM, Ihar Hrachyshka wrote:

Hi all,

just wanted to note that the etherpad page [1] with backport candidates
has a lot of work for those who have cycles for backporting relevant
pieces to Liberty (and Kilo for High+ bugs), so please take some on your
plate and propose backports, then clean up from the page. And please
don’t hesitate to check the page for more worthy patches in the future.

It can’t be a one man army if we want to run the initiative in long term.


I completely agree, it can't be one man army.
I was thinking that maybe we can be even more proactive.
How about adding as requirement for a bug fix to be merged to have the 
backport to relevant branches? I think that could help




[1]: https://etherpad.openstack.org/p/stable-bug-candidates-from-master

Thanks in advance,
Ihar

Miguel Angel Ajo  wrote:


I thought that may be, some of the work Ihar is proposing, could be
automated.


Yes indeed! We can do that.

cheers,

Rossella



Like, for example, checking if bug fixes are backportable as-is to the
previous stable
branches, and if they pass testing.

If that's the case, the bot could automatically automatically add the
bug to the list, or
flag it with some sort of specific flag, so, we humans could verify it
does make sense
to backport such bug, and if it actually meets the "backportable"
guidelines.



Kuvaja, Erno wrote:

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Friday, October 16, 2015 1:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][stable] proactive backporting

Hi all,

I’d like to introduce a new initiative around stable branches for
neutron
official projects (neutron, neutron-*aas, python-neutronclient) that is
intended to straighten our backporting process and make us more
proactive
in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait
until a
known bug hits a user that consumes stable branches, but backport
fixes in
advance quickly after they hit master.

The idea is simple: every Fri I walk thru the new commits merged
into master
since last check; produce lists of bugs that are mentioned in Related-
Bug/Closes-Bug; paste them into:

https://etherpad.openstack.org/p/stable-bug-candidates-from-master

Then I click thru the bug report links to determine whether it’s
worth a
backport and briefly classify them. If I have cycles, I also request
backports
where it’s easy (== a mere 'Cherry-Pick to' button click).

After that, those interested in maintaining neutron stable branches
can take
those bugs one by one and handle them, which means: checking where it
really applies for backport; creating backport reviews (solving
conflicts,
making tests pass). After it’s up for review for all branches
affected and
applicable, the bug is removed from the list.

I started on that path two weeks ago, doing initial swipe thru all
commits
starting from stable/liberty spin off. If enough participants join
the process,
we may think of going back into git history to backport interesting
fixes from
stable/liberty into stable/kilo.

Don’t hesitate to ask about details of the process, and happy
backporting,

Ihar


Hi,

This looks like neat way to do it. In Glance we're doing constantly
proactive backporting and I have been nominating bugs for series' and
approving backports for a while now. We prefer not to have user
coming to us and telling that they hit to bug in "stable" we had
known already for ages, just didn't bother to backport the fix.  It
has worked out really well and people are learning to propose these
without me needing to read every single commit message.

Good luck, has worked great for us!

- Erno
__

OpenStack Development Mailing List (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] How could an L2 agent extension access agent methods ?

[Rossella Sblendido]

On 12/17/2015 04:45 PM, Ihar Hrachyshka wrote:

Rossella Sblendido  wrote:


Hi Ihar,


wow, good job!!
Sorry for the very slow reply.
I really like your proposal...some comments inline.

On 12/03/2015 04:46 PM, Ihar Hrachyshka wrote:

Hi,

Small update on the RFE. It was approved for Mitaka, assuming we come up
with proper details upfront thru neutron-specs process.

In the meantime, we have found more use cases for flow management among
features in development: QoS DSCP, also the new OF based firewall
driver. Both authors for those new features independently realized that
agent does not currently play nice with flows set by external code due
to its graceful restart behaviour when rules with unknown cookies are
cleaned up. [The agent uses a random session uuid() to mark rules that
belong to its current run.]

Before I proceed, full disclosure: I know almost nothing about OpenFlow
capabilities, so some pieces below may make no sense. I tried to come up
with high level model first and then try to map it to available OF
features. Please don’t hesitate to comment, I like to learn new
stuff! ;)


I am not an expert either so I encourage people to chime in here.


I am thinking lately on the use cases we collected so far. One common
need for all features that were seen to be interested in proper
integration with Open vSwitch agent is to be able to manage feature
specific flows on br-int and br-tun. There are other things that
projects may need, like patch ports, though I am still struggling with
the question of whether it may be postponed or avoided for phase 1.

There are several specific operation 'kinds' that we should cover for
the RFE:
- managing flows that modify frames in-place;
- managing flows that redirect frames.

There are some things that should be considered to make features
cooperate with the agent and other extensions:
- feature flows should have proper priorities based on their ‘kind’
(f.e. in-place modification probably go before redirections);
- feature flows should survive flow reset that may be triggered by the
agent;
- feature flows should survive flow reset without data plane disruption
(=they should support graceful restart:
https://review.openstack.org/#/c/182920).

With that in mind, I see the following high level design for the flow
tables:

- table 0 serves as a dispatcher for specific features;
- each feature gets one or more tables, one per flow ‘kind’ needed;
- for each feature table, a new flow entry is added to table 0 that
would redirect to feature specific table; the rule will be triggered
only if OF metadata is not updated inside the feature table (see the
next bullet); the rule will have priority that is defined for the ‘kind’
of the operation that is implemented by the table it redirects to;
-  each feature table will have default actions that will 1) mark OF
metadata for the frame as processed by the feature; 2) redirect back to
table 0;
- all feature specific flow rules (except dispatcher rules) belong to
feature tables;

Now, the workflow for extensions that are interested in setting flows
would be:
- on initialize() call, extension defines feature tables it will need;


Do you mean this in a dynamic way or every extension will have tables
assigned, basically hard-coded? I prefer the second way so we have
more controls of the tables that are currently used.


Do you suggest creating several tables even if an extension is not
interested in all of them? As for the table name, I guess we may build
it as agent_cookie + extension name so that it’s clear which tables were
bootstrapped in current session, and which can be cleaned up after we
clear flows from previous sessions.


I like this.





it passes the name of the feature table and the ‘kind’ of the actions it
will execute; with that, the following is initialized by the agent: 1)


It would be nice to pass also a filter to match some packets. We
probably don't want to send all the packet to the feature table, the
extension can define that.



It probably stands for some optimization, though I am not sure how
serious. If we go this route, we also need to short-circuit metadata
marking on filter unmatched, or do we expect other extensions to
influence filter matching?

I am not sure how it would look like. Do we allow random matching
filters, or enforce some base types and leave more detailed filters to
extension tables?


Let's leave it for later then. You are right, that's probably an early 
optimization





table 0 dispatcher entry to redirect frames into feature table; the
entry has the priority according to the ‘kind’ of the table; 2) the


I think we need to define the priority better. According to what you
wrote we assign priority based on "in-place modification probably go
before redirections" not sure if it's enough. What happens if we have
two features that both requires in place-modifications? How do we
prioritize them? Are we going to allow 2 extension at the same

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Rossella Sblendido]

On 12/17/2015 05:07 PM, Ihar Hrachyshka wrote:

We may probably think of passing agent uuid into extensions to allow it
to be used as a cookie for their flows, and make sure extensions are
triggered before we reset obsolete flows in the agent. It may work.

I would only want to see it as a temporary solution. One thing that I
would like to tackle with the proposal is keeping our main flow tables
clean from extension specific flows, if anything, for easier debugging.


I agree with you here. Let's pass the uuid as a temporary solution. This 
will buy us some time to iterate on the extensions flow tables proposal 
and get it working. In the meanwhile the subprojects that install flows 
won't be blocked.


cheers,

Rossella

__
OpenStack Development Mailing 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] How could an L2 agent extension access agent methods ?

[Rossella Sblendido]

Hi Ihar,


wow, good job!!
Sorry for the very slow reply.
I really like your proposal...some comments inline.

On 12/03/2015 04:46 PM, Ihar Hrachyshka wrote:

Hi,

Small update on the RFE. It was approved for Mitaka, assuming we come up
with proper details upfront thru neutron-specs process.

In the meantime, we have found more use cases for flow management among
features in development: QoS DSCP, also the new OF based firewall
driver. Both authors for those new features independently realized that
agent does not currently play nice with flows set by external code due
to its graceful restart behaviour when rules with unknown cookies are
cleaned up. [The agent uses a random session uuid() to mark rules that
belong to its current run.]

Before I proceed, full disclosure: I know almost nothing about OpenFlow
capabilities, so some pieces below may make no sense. I tried to come up
with high level model first and then try to map it to available OF
features. Please don’t hesitate to comment, I like to learn new stuff! ;)


I am not an expert either so I encourage people to chime in here.



I am thinking lately on the use cases we collected so far. One common
need for all features that were seen to be interested in proper
integration with Open vSwitch agent is to be able to manage feature
specific flows on br-int and br-tun. There are other things that
projects may need, like patch ports, though I am still struggling with
the question of whether it may be postponed or avoided for phase 1.

There are several specific operation 'kinds' that we should cover for
the RFE:
- managing flows that modify frames in-place;
- managing flows that redirect frames.

There are some things that should be considered to make features
cooperate with the agent and other extensions:
- feature flows should have proper priorities based on their ‘kind’
(f.e. in-place modification probably go before redirections);
- feature flows should survive flow reset that may be triggered by the
agent;
- feature flows should survive flow reset without data plane disruption
(=they should support graceful restart:
https://review.openstack.org/#/c/182920).

With that in mind, I see the following high level design for the flow
tables:

- table 0 serves as a dispatcher for specific features;
- each feature gets one or more tables, one per flow ‘kind’ needed;
- for each feature table, a new flow entry is added to table 0 that
would redirect to feature specific table; the rule will be triggered
only if OF metadata is not updated inside the feature table (see the
next bullet); the rule will have priority that is defined for the ‘kind’
of the operation that is implemented by the table it redirects to;
-  each feature table will have default actions that will 1) mark OF
metadata for the frame as processed by the feature; 2) redirect back to
table 0;
- all feature specific flow rules (except dispatcher rules) belong to
feature tables;

Now, the workflow for extensions that are interested in setting flows
would be:
- on initialize() call, extension defines feature tables it will need;


Do you mean this in a dynamic way or every extension will have tables 
assigned, basically hard-coded? I prefer the second way so we have more 
controls of the tables that are currently used.



it passes the name of the feature table and the ‘kind’ of the actions it
will execute; with that, the following is initialized by the agent: 1)


It would be nice to pass also a filter to match some packets. We 
probably don't want to send all the packet to the feature table, the 
extension can define that.



table 0 dispatcher entry to redirect frames into feature table; the
entry has the priority according to the ‘kind’ of the table; 2) the


I think we need to define the priority better. According to what you 
wrote we assign priority based on "in-place modification probably go 
before redirections" not sure if it's enough. What happens if we have 
two features that both requires in place-modifications? How do we 
prioritize them? Are we going to allow 2 extension at the same time? Let 
me think more about this...It would be nice to have some real world 
example...



actual feature table with two default rules (update metadata and push
back to table 0);
- whenever extension needs to add a new flow rule, it passes the
following into the agent: 1) table name; 2) flow specific parameters
(actions, priority, ...)

Since the agent will manage setting flows for extensions, it will be
able to use the active agent cookie for all feature flows; next time the
agent is restarted, it should be able to respin extension flows with no
data plane disruption. [Note: we should make sure that on agent restart,
we call to extensions *before* we clean up stale flow rules.]


I like this :)


That design will hopefully allow us to abstract interaction with flows
from extensions into management code inside the agent. It should
guarantee extensions cooperate properly assuming they properly define
their pr

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

[Rossella Sblendido]

On 11/25/2015 11:05 PM, Assaf Muller wrote:

We could then consider running the script automatically on a daily
basis and publishing the
resulting URL in a nice bookmarkable place.


An update on this. The easiest bookmarkable place that I found it's my 
blog [1]. I have a script that updates the url every day, I can do that 
more often. I'd love to have the url on the wiki but I think it requires 
to create a patch every day and approve it...not nice at all. Any 
suggestion?


cheers,

Rossella

[1] http://rossella-sblendido.net/2015/12/14/gerrit-url-neutron-reviews/

__
OpenStack Development Mailing 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] Bug deputy process

[Rossella Sblendido]

Hi Armando,

On 12/02/2015 07:49 PM, Armando M. wrote:

Hi neutrinos,

It's been a couple of months that the Bug deputy process has been in
place [1,2]. Since the beginning of Mitaka we have collected the
following statistics (for neutron and neutronclient):

Total bug reports: 373

  * Fix committed: 144
  * Unassigned: 73
  o New: 17
  o Incomplete: 20
  o Confirmed: 27
  o Triaged: 6


At first, it is clear that we do not fix issues nearly as fast as they
come in, but at least we managed to keep the number of
unassigned/unvetted bugs relatively small, so kudos to you all who
participated in this experiment. I don't have data based on older
releases, so I can't see whether we've improved or worsened, and I'd
like to ask for feedback from the people who played with this first
hand, especially on the amount of time that has taken them to do deputy
duty for their assigned week.


my feedback is very positive. I think the new process is good, thanks 
for setting it up! During my week I was looking at newly filed bugs 
every day and triaged them. This took around 1 or 2 hours a day. But it 
was a quiet week...so the load was not super high.


cheers,

Rossella



  * ihrachys
  * regXboi
  * markmcclain
  * mestery
  * mangelajo
  * garyk
  * rossella_s
  * dougwig

Many thanks,
Armando

[1] https://wiki.openstack.org/wiki/Network/Meetings#Bug_deputy
[2]
http://docs.openstack.org/developer/neutron/policies/bugs.html#neutron-bug-deputy



__
OpenStack Development Mailing List (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] Encouraging first-time contributors through bug tags/reviews

[Rossella Sblendido]

On 11/26/2015 10:40 AM, Thierry Carrez wrote:

Doug Hellmann wrote:

Excerpts from Shamail's message of 2015-11-26 02:07:55 +0500:



On Nov 26, 2015, at 1:42 AM, Doug Hellmann  wrote:

OK, reserving bugs for new contributors does reduce the number of
people contending for them, but it doesn't eliminate the need to
figure out if someone else is already working on a bug before you
start. Encouraging folks to assign bugs to themselves when they start
work is probably the best way to solve that.

+1, I think most do a good job at this.

Where do you think is the appropriate place to formally ask for a new tag 
and/or reservations?


This list is a good place to ask for a tag like that. It's also a good
topic for the cross-project meetings.


Launchpad "tags" are per-project, so ideally you would find a pilot
project (or a few pilot projects) ready to play with a
"I-added-instructions-for-first-timers-to-follow" type tag. If those are
successful, we could then encourage every other project to adopt it too...



I really like this idea. I was contacted many times by people who wanted 
to start contributing and had troubles finding a bug to fix.
low-hanging-fruit are not always so easy to understand for newbies even 
if they might be straightforward for experienced people. Another issue 
is that sometimes trivial bugs are fixed by experienced people. Which is 
not optimal. Somebody spends time filing a bug, editing the description 
and tagging it low-hanging-fruit, hoping that it will be taken by a 
newbie (there's no way to reserve a bug for newbies right now). Then 
it's taken by an experience contributor, :/ the reporter could have 
fixed it easily in the first place, without spending time adding a 
detailed description to it.


I'd like to help. Neutron could be one of the pilot project. I will 
mention that in the next Neutron team meeting :)


Rossella

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

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

[Rossella Sblendido]

On 11/24/2015 06:53 PM, Armando M. wrote:



On 24 November 2015 at 04:13, Rossella Sblendido mailto:rsblend...@suse.com>> wrote:



On 11/23/2015 06:38 PM, Armando M. wrote:



On 23 November 2015 at 04:02, Rossella Sblendido
mailto:rsblend...@suse.com>
<mailto:rsblend...@suse.com <mailto:rsblend...@suse.com>>> wrote:



 On 11/20/2015 03:54 AM, Armando M. wrote:



 On 19 November 2015 at 18:26, Assaf Muller
mailto:amul...@redhat.com>
 <mailto:amul...@redhat.com <mailto:amul...@redhat.com>>
 <mailto:amul...@redhat.com <mailto:amul...@redhat.com>
<mailto:amul...@redhat.com <mailto:amul...@redhat.com>>>> wrote:

  On Wed, Nov 18, 2015 at 9:14 PM, Armando M.
 mailto:arma...@gmail.com>
<mailto:arma...@gmail.com <mailto:arma...@gmail.com>>
  <mailto:arma...@gmail.com
<mailto:arma...@gmail.com> <mailto:arma...@gmail.com
<mailto:arma...@gmail.com>>>> wrote:
  > Hi Neutrites,
  >
  > We are nearly two weeks away from the end of
Mitaka 1.
  >
  > I am writing this email to invite you to be
mindful to
 what you review,
  > especially in the next couple of weeks. Whenever
you have
 the time to review
  > code, please consider giving priority to the
following:
  >
  > Patches that target blueprints targeted for Mitaka;
  > Patches that target bugs that are either
critical or high;
  > Patches that target rfe-approved 'bugs';
  > Patches that target specs that have followed the
most
 current submission
  > process;

  Is it possible to create Gerrit dashboards for
patches that
 answer these
  criteria, and then persist the links in Neutron's
 dashboards devref
  page?
http://docs.openstack.org/developer/neutron/dashboards/index.html
  That'd be super useful.


 We should look into that, but to be perfectly honest I
am not
 sure how
 easy it would be, since we'd need to cross-reference
content
 that lives
 into gerrit as well as launchpad. Would that even be
possible?


 To cross-reference we can use the bug ID or the blueprint name.

 I created a script that queries launchpad to get:
 1) Bug number of the bugs tagged with approved-rfe
 2) Bug number of the critical/high bugs
 3) list of blueprints targeted for the current milestone
(mitaka-1)

 With this info the script builds a .dash file that can be
used by
 gerrit-dash-creator [2] to produce a dashboard url .

 The script prints also the queries that can be used in
gerrit UI
 directly, e.g.:
 Critical/High Bugs
 (topic:bug/1399249 OR topic:bug/1399280 OR topic:bug/1443421 OR
 topic:bug/1453350 OR topic:bug/1462154 OR topic:bug/1478100 OR
 topic:bug/1490051 OR topic:bug/1491131 OR topic:bug/1498790 OR
 topic:bug/1505575 OR topic:bug/1505843 OR topic:bug/1513678 OR
 topic:bug/1513765 OR topic:bug/1514810)


 This is the dashboard I get right now [3]

 I tried in many ways to get Gerrit to filter patches if the
commit
 message contains a bug ID. Something like:

 (message:"#1399249" OR message:"#1399280" OR
message:"#1443421" OR
 message:"#1453350" OR message:"#1462154" OR
message:"#1478100" OR
 message:"#1490051" OR message:"#1491131" OR
message:"#1498790" OR
 message:"#1505575" OR message:"#1505843" OR
message:"#1513678" OR
 message:"#1513765" OR message:"#1514810")

 but it doesn't work well, the result of the filter contains
patches
 that have nothing to do with the bugs queried.


Try to drop the # and quote the bug number like this:

message:"'1399280'"

Otherwise I believe gerrit looks for substring matches.


That was my first attempt, it doesn't work unfortunately.

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

[Rossella Sblendido]

On 11/23/2015 06:38 PM, Armando M. wrote:



On 23 November 2015 at 04:02, Rossella Sblendido mailto:rsblend...@suse.com>> wrote:



On 11/20/2015 03:54 AM, Armando M. wrote:



On 19 November 2015 at 18:26, Assaf Muller mailto:amul...@redhat.com>
<mailto:amul...@redhat.com <mailto:amul...@redhat.com>>> wrote:

 On Wed, Nov 18, 2015 at 9:14 PM, Armando M.
mailto:arma...@gmail.com>
 <mailto:arma...@gmail.com <mailto:arma...@gmail.com>>> wrote:
 > Hi Neutrites,
 >
 > We are nearly two weeks away from the end of Mitaka 1.
 >
 > I am writing this email to invite you to be mindful to
what you review,
 > especially in the next couple of weeks. Whenever you have
the time to review
 > code, please consider giving priority to the following:
 >
 > Patches that target blueprints targeted for Mitaka;
 > Patches that target bugs that are either critical or high;
 > Patches that target rfe-approved 'bugs';
 > Patches that target specs that have followed the most
current submission
 > process;

 Is it possible to create Gerrit dashboards for patches that
answer these
 criteria, and then persist the links in Neutron's
dashboards devref
 page?
http://docs.openstack.org/developer/neutron/dashboards/index.html
 That'd be super useful.


We should look into that, but to be perfectly honest I am not
sure how
easy it would be, since we'd need to cross-reference content
that lives
into gerrit as well as launchpad. Would that even be possible?


To cross-reference we can use the bug ID or the blueprint name.

I created a script that queries launchpad to get:
1) Bug number of the bugs tagged with approved-rfe
2) Bug number of the critical/high bugs
3) list of blueprints targeted for the current milestone (mitaka-1)

With this info the script builds a .dash file that can be used by
gerrit-dash-creator [2] to produce a dashboard url .

The script prints also the queries that can be used in gerrit UI
directly, e.g.:
Critical/High Bugs
(topic:bug/1399249 OR topic:bug/1399280 OR topic:bug/1443421 OR
topic:bug/1453350 OR topic:bug/1462154 OR topic:bug/1478100 OR
topic:bug/1490051 OR topic:bug/1491131 OR topic:bug/1498790 OR
topic:bug/1505575 OR topic:bug/1505843 OR topic:bug/1513678 OR
topic:bug/1513765 OR topic:bug/1514810)


This is the dashboard I get right now [3]

I tried in many ways to get Gerrit to filter patches if the commit
message contains a bug ID. Something like:

(message:"#1399249" OR message:"#1399280" OR message:"#1443421" OR
message:"#1453350" OR message:"#1462154" OR message:"#1478100" OR
message:"#1490051" OR message:"#1491131" OR message:"#1498790" OR
message:"#1505575" OR message:"#1505843" OR message:"#1513678" OR
message:"#1513765" OR message:"#1514810")

but it doesn't work well, the result of the filter contains patches
that have nothing to do with the bugs queried.


Try to drop the # and quote the bug number like this:

message:"'1399280'"

Otherwise I believe gerrit looks for substring matches.


That was my first attempt, it doesn't work unfortunately.

thanks,

Rossella




That's why I had to filter using the topic.

CAVEAT: To make the dashboard work, bug fixes must use the topic
"bug/ID" and patches implementing a blueprint the topic "bp/name".
If a patch is not following this convention it won't be showed in
the dashboard, since the topic is used as filter. Most of us use
this convention already anyway so I hope it's not too much of a burden.

Feedback is appreciated :)


Nice one, I'll provide feedback on [1].


[1] https://review.openstack.org/248645
[2] https://github.com/openstack/gerrit-dash-creator
[3] https://goo.gl/sglSbp


Btw, I was looking at the current blueprint assignments [1] for
Mitaka:
there are some blueprints that still need assignee, approver and
drafter; we should close the gap. If there are volunteers,
please reach
out to me.

Thanks,
Armando

[1] https://blueprints.launchpad.net/neutron/mitaka/+assignments


 >
 > Everything else should come later, no matter how easy or
interesting it is
 > to review; remember that as a community we have the
collective duty to

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

[Rossella Sblendido]

On 11/23/2015 06:42 PM, Armando M. wrote:



On 23 November 2015 at 09:22, Carl Baldwin mailto:c...@ecbaldwin.net>> wrote:

On Mon, Nov 23, 2015 at 5:02 AM, Rossella Sblendido
mailto:rsblend...@suse.com>> wrote:
> To cross-reference we can use the bug ID or the blueprint name.
>
> I created a script that queries launchpad to get:
> 1) Bug number of the bugs tagged with approved-rfe
> 2) Bug number of the critical/high bugs
> 3) list of blueprints targeted for the current milestone (mitaka-1)

Rossella, this is a great start!  In principle, I have wanted
something like this for a long time now.  The process of scraping
launchpad and gerrit manually for the most important stuff to review
is labor intensive and sometimes I just want to take a little bit of
extra time and review something.  It is very tempting to go straight
to gerrit and pick something.  I think it is very important for us to
finally crack this nut and have a dashboard which can help us easily
find the most important reviews.  I think your time on this is very
well spent and will positively affect the whole team.


Thanks a lot Carl! I really hope it will be useful :)



 > With this info the script builds a .dash file that can be used by
 > gerrit-dash-creator [2] to produce a dashboard url .
 >
 > The script prints also the queries that can be used in gerrit UI
directly,
 > e.g.:
 > Critical/High Bugs
 > (topic:bug/1399249 OR topic:bug/1399280 OR topic:bug/1443421 OR
 > topic:bug/1453350 OR topic:bug/1462154 OR topic:bug/1478100 OR
 > topic:bug/1490051 OR topic:bug/1491131 OR topic:bug/1498790 OR
 > topic:bug/1505575 OR topic:bug/1505843 OR topic:bug/1513678 OR
 > topic:bug/1513765 OR topic:bug/1514810)
 >
 > This is the dashboard I get right now [3]
 >
 > I tried in many ways to get Gerrit to filter patches if the
commit message
 > contains a bug ID. Something like:
 >
 > (message:"#1399249" OR message:"#1399280" OR message:"#1443421" OR
 > message:"#1453350" OR message:"#1462154" OR message:"#1478100" OR
 > message:"#1490051" OR message:"#1491131" OR message:"#1498790" OR
 > message:"#1505575" OR message:"#1505843" OR message:"#1513678" OR
 > message:"#1513765" OR message:"#1514810")
 >
 > but it doesn't work well, the result of the filter contains
patches that
 > have nothing to do with the bugs queried.
 > That's why I had to filter using the topic.
 >
 > CAVEAT: To make the dashboard work, bug fixes must use the topic
"bug/ID"
 > and patches implementing a blueprint the topic "bp/name". If a
patch is not
 > following this convention it won't be showed in the dashboard,
since the
 > topic is used as filter. Most of us use this convention already
anyway so I
 > hope it's not too much of a burden.
 >
 > Feedback is appreciated :)

I looked for the address scopes blueprint [1] which is targeted for
Mitaka-1 [2] and there are 6 (or 5, one is in the gate) patches on the
bp/address-scopes topic [3].  It isn't obvious to me yet why it didn't
get picked up on the dashboard.  I've only started to look in to this
and may not have much time right now.  I wondered if you could easily
tell why it didn't get picked up.


Isn't it missing bp/ ? From the URL I can only see topic:address-scope,
which isn't the right one.


Yes Armando is right. I fixed that. Another reason is that I am 
filtering out patches that are WIP or that failed Jenkins tests. This 
can be changed anyway. This is what I get now (after fixing the missing 
'bp/') [1]


cheers,

Rossella

[1] goo.gl/C7UjdD




Given that I only see one review in
the blueprints section, I suspect there are other blueprints which are
in the same situation.



[1] https://blueprints.launchpad.net/neutron/+spec/address-scopes
[2] https://launchpad.net/neutron/+milestone/mitaka-1
[3]
https://review.openstack.org/#/q/status:open+topic:bp/address-scopes,n,z

Thanks!
Carl

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




__
OpenStack Development Mailing List (n

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

[Rossella Sblendido]

On 11/20/2015 03:54 AM, Armando M. wrote:



On 19 November 2015 at 18:26, Assaf Muller mailto:amul...@redhat.com>> wrote:

On Wed, Nov 18, 2015 at 9:14 PM, Armando M. mailto:arma...@gmail.com>> wrote:
> Hi Neutrites,
>
> We are nearly two weeks away from the end of Mitaka 1.
>
> I am writing this email to invite you to be mindful to what you review,
> especially in the next couple of weeks. Whenever you have the time to 
review
> code, please consider giving priority to the following:
>
> Patches that target blueprints targeted for Mitaka;
> Patches that target bugs that are either critical or high;
> Patches that target rfe-approved 'bugs';
> Patches that target specs that have followed the most current submission
> process;

Is it possible to create Gerrit dashboards for patches that answer these
criteria, and then persist the links in Neutron's dashboards devref
page?
http://docs.openstack.org/developer/neutron/dashboards/index.html
That'd be super useful.


We should look into that, but to be perfectly honest I am not sure how
easy it would be, since we'd need to cross-reference content that lives
into gerrit as well as launchpad. Would that even be possible?


To cross-reference we can use the bug ID or the blueprint name.

I created a script that queries launchpad to get:
1) Bug number of the bugs tagged with approved-rfe
2) Bug number of the critical/high bugs
3) list of blueprints targeted for the current milestone (mitaka-1)

With this info the script builds a .dash file that can be used by 
gerrit-dash-creator [2] to produce a dashboard url .


The script prints also the queries that can be used in gerrit UI 
directly, e.g.:

Critical/High Bugs
(topic:bug/1399249 OR topic:bug/1399280 OR topic:bug/1443421 OR 
topic:bug/1453350 OR topic:bug/1462154 OR topic:bug/1478100 OR 
topic:bug/1490051 OR topic:bug/1491131 OR topic:bug/1498790 OR 
topic:bug/1505575 OR topic:bug/1505843 OR topic:bug/1513678 OR 
topic:bug/1513765 OR topic:bug/1514810)



This is the dashboard I get right now [3]

I tried in many ways to get Gerrit to filter patches if the commit 
message contains a bug ID. Something like:


(message:"#1399249" OR message:"#1399280" OR message:"#1443421" OR 
message:"#1453350" OR message:"#1462154" OR message:"#1478100" OR 
message:"#1490051" OR message:"#1491131" OR message:"#1498790" OR 
message:"#1505575" OR message:"#1505843" OR message:"#1513678" OR 
message:"#1513765" OR message:"#1514810")


but it doesn't work well, the result of the filter contains patches that 
have nothing to do with the bugs queried.

That's why I had to filter using the topic.

CAVEAT: To make the dashboard work, bug fixes must use the topic 
"bug/ID" and patches implementing a blueprint the topic "bp/name". If a 
patch is not following this convention it won't be showed in the 
dashboard, since the topic is used as filter. Most of us use this 
convention already anyway so I hope it's not too much of a burden.


Feedback is appreciated :)

[1] https://review.openstack.org/248645
[2] https://github.com/openstack/gerrit-dash-creator
[3] https://goo.gl/sglSbp



Btw, I was looking at the current blueprint assignments [1] for Mitaka:
there are some blueprints that still need assignee, approver and
drafter; we should close the gap. If there are volunteers, please reach
out to me.

Thanks,
Armando

[1] https://blueprints.launchpad.net/neutron/mitaka/+assignments


>
> Everything else should come later, no matter how easy or interesting it is
> to review; remember that as a community we have the collective duty to 
work
> towards a common (set of) target(s), as being planned in collaboration 
with
> the Neutron Drivers team and the larger core team.
>
> I would invite submitters to ensure that the Launchpad resources
> (blueprints, and bug report) capture the most updated view in terms of
> patches etc. Work with your approver to help him/her be focussed where it
> matters most.
>
> Finally, we had plenty of discussions at the design summit, and some of
> those discussions will have to be followed up with actions (aka code in
> OpenStack lingo). Even though, we no longer have deadlines for feature
> submission, I strongly advise you not to leave it last minute. We can only
> handle so much work for any given release, and past experience tells us 
that
> we can easily hit a breaking point at around the ~30 blueprint mark.
>
> Once we reached it, it's likely we'll have to start pushing back work for
> Mitaka and allow us some slack; things are fluid as we all know, and the
> random gate breakage is always lurking round the corner! :)
>
> Happy hacking,
> Armando
>
 >
__
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
openstack-

Re: [openstack-dev] [neutron][upgrade] new 'all things upgrade' subteam

[Rossella Sblendido]

Hi Ihar,

same for me, all options are ok!

cheers,

Rossella

On 11/12/2015 11:00 PM, Martin Hickey wrote:


Hi Ihar,

Any of those options would suit me, thanks.

Cheers,
Martin




From:   Ihar Hrachyshka 
To: "OpenStack Development Mailing List (not for usage questions)"
 
Date:   12/11/2015 21:39
Subject:Re: [openstack-dev] [neutron][upgrade] new 'all things
 upgrade'   subteam



Artur  wrote:


My TZ is UTC +1:00.
Do we have any favorite day? Maybe Tuesday?


I believe Tue is already too packed with irc meetings to be considered (we

have, for the least, main neutron meetings and neutron-drivers meetings
there).

We have folks in US and Central Europe and Russia and Japan… I believe the

best time would be somewhere around 13:00 to 15:00 UTC (that time would
still be ‘before midnight' for Japan; afternoon for Europe, and morning for

US East Coast).

I have checked neutron meetings at [1], and I see that we have 13:00 UTC
slots free for all days; 14:00 UTC slot available for Thu; and 15:00 UTC
slots for Mon and Fri (I don’t believe we want to have it on Fri though).
Also overall Mondays are all free.

Should I create a doodle for those options? Or are there any alternative
suggestions?

[1]:
http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/meetings

Ihar

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



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

Re: [openstack-dev] Can we get some sanity in the Neutron logs please?

[Rossella Sblendido]

Hello Matt,


On 11/10/2015 07:33 PM, Matt Riedemann wrote:

Let me qualify by saying I'm not a Neutron person.

We know that gate-tempest-dsvm-neutron-full is failing hard as of the
last 24 hours [1].

An error that's been showing up in tempest runs with neutron a lot is:

"AssertionError: 0 == 0 : No IPv4 addresses found in: []"

So checking logstash [2] it's hitting a lot. It's only recent because
that failure message is new to Tempest in the last day or so, but it has
a lot of hits, so whatever it is, it's failing a lot.

So the next step is usually digging into service logs looking for
errors. I check the q-svc logs first. Not many errors but a bazillion
warnings for things not found (networks and devices). [3]

For example:

2015-11-10 17:13:02.542 WARNING neutron.plugins.ml2.rpc
[req-15a73753-1512-4689-9404-9658a0cd0c09 None None] Device
aaa525be-14eb-44a5-beb0-ed722896be93 requested by agent
ovs-agent-devstack-trusty-rax-iad-5785199 not found in database

2015-11-10 17:14:17.754 WARNING neutron.api.rpc.handlers.dhcp_rpc
[req-3d7e9848-6151-4780-907f-43f11a2a8545 None None] Network
b07ad9b2-e63e-4459-879d-3721074704e5 could not be found, it might have
been deleted concurrently.

Are several hundred of these warnings useful to an operator trying to
debug a problem? The point of the CI gate testing is to try and simulate
a production cloud environment. When something goes wrong, you check the
logs. With the amount of warning/error level logging that is in the
neutron logs, finding a real problem is like looking for a needle in a
haystack. Since everything is async, 404s are expected when racing to
delete a resource and they should be handled gracefully.

Anyway, the server log isn't useful so I go digging in the agent logs
and stacktraces there are aplenty. [4]

Particularly this:

"Exception: Port tapcea51630-e1 is not ready, resync needed"

That's due to a new change landing in the last 24 hours [5]. But the
trace shows up over 16K times since it landed [6].

Checking the code, it's basically a loop processing events and when it
hits an event it can't handle, it punts (breaking the loop so you don't
process the other events after it - which is a bug), and the code that
eventually handles it is just catching all Exception and tracing them
out assuming they are really bad.


As you noticed in the review [1] there was a dependent patch that was 
solving this. It was a big and pretty complex change, I tried to split 
it in few patches. I should have split it in a better way.




At this point, as a non-neutron person, i.e. not well versed in the
operations of neutron or how to debug it in great detail, I assume
something is bad here but I don't really know - and the logs are so full
of noise that I can't distinguish real failures.

I don't mean to pick on this particular change, but it's a good example
of a recent thing.

I'd like to know if this is all known issue or WIP type stuff. I've
complained about excessively noisey neutron logs in channel before and
I'm usually told that they are either necessary (for whatever reason) or
that rather than complain about the verbosity, I should fix the race
that is causing it - which is not likely to happen since I don't have
the async rpc happy nature of everything in neutron in my head to debug
it (I doubt many do).


Yes in this case it's a WIP, logs were not meant to stay there, actually 
they were cleaned up by the dependent patch.





Anyway, this is a plea for sanity in the logs. There are logging
guidelines for openstack [7]. Let's please abide by them. Let's keep
operators in mind when we're looking at logs and be proactive about
making them useful (which includes more granular error handling and less
global try/except Exception: LOG.exception constructs).


We are aware of the guidelines and when reviewing code in Neutron we try 
to enforce them. We all want better logs :) so please keep giving 
feedback. Thanks for raising this point.


cheers,

Rossella




[1] http://tinyurl.com/ne3ex4v
[2]
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22AssertionError:%200%20==%200%20:%20No%20IPv4%20addresses%20found%20in:%20%5B%5D%5C%22%20AND%20tags:%5C%22console%5C%22

[3]
http://logs.openstack.org/85/239885/2/gate/gate-tempest-dsvm-neutron-full/602d864/logs/screen-q-svc.txt.gz?level=TRACE

[4]
http://logs.openstack.org/85/239885/2/gate/gate-tempest-dsvm-neutron-full/602d864/logs/screen-q-agt.txt.gz?level=TRACE

[5] https://review.openstack.org/#/c/164880/
[6]
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22Exception:%20Port%5C%22%20AND%20message:%5C%22is%20not%20ready,%20resync%20needed%5C%22%20AND%20tags:%5C%22screen-q-agt.txt%5C%22

[7]
http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html




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

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

[Rossella Sblendido]

Congratulations Henry! Well deserved!

On 10/21/2015 05:14 AM, Armando M. wrote:

Hi folks,

Henry has been instrumental in many areas of the projects and his crazy
working hours makes even Kevin and I bow in awe.

Jokes aside, I would like to announce HenryG as a new member of the
Neutron Drivers team.

Having a propension to attendance, and desire to review of RFEs puts you
on the right foot to join the group, whose members are rotated regularly
so that everyone is given the opportunity to grow, and no-one burns out.

The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
attend.

Please, join me in welcome Henry to the team.

Cheers,
Armando

[1]
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers



__
OpenStack Development Mailing List (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 rolling upgrade - are we there yet?

[Rossella Sblendido]

Hello Artur,

thanks for staring this thread. See inline please.

On 10/15/2015 05:23 PM, Ihar Hrachyshka wrote:

Hi Artur,

thanks a lot for caring about upgrades!

There are a lot of good points below. As you noted, surprisingly, we seem to 
have rolling upgrades working for RPC layer. Before we go into complicating 
database workflow by doing oslo.versionedobjects transition heavy-lifting, I 
would like us to spend cycles on making sure rolling upgrades work not just 
surprisingly, but also covered with appropriate gating (I speak grenade).


+1 agreed that the first step is to have test coverage then we can go on 
improving the process :)




I also feel that upgrades are in lots of ways not only a technical issue, but a 
cultural one too. You should have reviewers being aware of all the moving 
parts, and how a seemingly innocent change can break the flow. That’s why I 
plan to start on a devref page specifically about upgrades, where we could lay 
ground about which scenarios we should support, and those we should not (f.e. 
we have plenty of compatibility code in agents that to handle old controller 
scenario, which should not be supported); how all pieces interact and behave in 
transition, and what to look for during reviews. Hopefully, once such a page is 
up and read by folks, we will be able to have more meaningful conversation 
about our upgrade strategy.


On 14 Oct 2015, at 20:10, Korzeniewski, Artur  
wrote:

Hi all,

I would like to gather all upgrade activities in Neutron in one place, in order 
to summarizes the current status and future activities on rolling upgrades in 
Mitaka.



If you think it’s worth it, we can start up a new etherpad page to gather 
upgrade ideas and things to do.




1.  RPC versioning

a.  It is already implemented in Neutron.

b.  TODO: To have the rolling upgrade we have to implement the RPC version 
pinning in conf.

 i. I’m not a big fan 
of this solution, but we can work out better idea if needed.


As Dan pointed out, and as I think Miguel was thinking about, we can have pin 
defined by agents in the cluster. Actually, we can have per agent pin.


I am not a big fan either mostly because the pinning is a manual task. 
Anyway looking at the patch Dan linked 
https://review.openstack.org/#/c/233289/ ...if we remove the manual step 
I can become a fan of this approach :)






c.  Possible unit/functional tests to catch RPC version incompatibilities 
between RPC revisions.

d.  TODO: Multi-node Grenade job to have rolling upgrades covered in CI.


That is not for unit or functional test level.

As you mentioned, we already have grenade project that is designed to test 
upgrades. To validate RPC compatibility on rolling upgrade we would need so 
called ‘partial’ job (when different components are running with different 
versions; in case of neutron it would mean a new controller and old agents). 
The job is present in nova gate and validates RPC compatibility.

As far as I know, Russell Bryant was looking into introducing the job for 
neutron, but was blocked by ongoing grenade refactoring to support partial 
upgrades ‘the right way’ (using multinode setups). I think that we should check 
with grenade folks on that matter, I have heard start of Mitaka was ETA for 
this work to complete.



2.  Message content versioning – versioned objects

a.  TODO: implement Oslo Versionobject in Mitaka cycle. The interesting 
entities to be implemented: network, subnet, port, security groups…


Though we haven’t touched base neutron resources in Liberty, we introduced 
oslo.versionedobjects based NeutronObject class during Liberty as part of QoS 
effort. I plan to expand on that work during Mitaka.

The existing code for QoS resources can be found at:

https://github.com/openstack/neutron/tree/master/neutron/objects



b.  Will OVO have impact on vendor plugins?


It surely can have significant impact, but hopefully dict compat layer should 
make transition more smooth:

https://github.com/openstack/neutron/blob/master/neutron/objects/base.py#L50



c.  Be strict on changes in version objects in code review, any change in 
object structure should increment the minor (backward-compatible) or major 
(breaking change) RPC version.


That’s assuming we have a clear mapping of objects onto current RPC interfaces, 
which is not obvious. Another problem we would need to solve is core resource 
extensions (currently available in ml2 only), like qos or port_security, that 
modify resources based on controller configuration.



d.  Indirection API – message from newer format should be translated to 
older version by neutron server.


For QoS, we used a new object agnostic subscriber mechanism to propagate 
changes applied to QoS objects into agents: 
http://docs.openstack.org/developer/neutron/devref/rpc_callbacks.html

It is already (expected) to downgrade objects based on agent version 

Re: [openstack-dev] Metadata via dhcp namespace not working for icehouse release

[Rossella Sblendido]

Hi Pradeep,

see inline please...

On 10/09/2015 09:00 AM, Pradeep kumar wrote:


Hii Guys,


and girls :)


I am trying to run Metadata via the DHCP namespace by following blog
post mentioned below:

http://techbackground.blogspot.in/2013/06/metadata-via-dhcp-namespace.html

Commandsmentioned on above link for debugging o/p is exactly same for my
setup. Also i am able to ping 169.254.169.254 metadata server ip. But
while running below command from VM i get

curl http://169.254.169.254

curl: (7) Failed to connect to 169.254.169.254 port 80: Connection timed out

and

curl http://169.254.169.254:53
gives empty response
&
from controller node if i run curl http://169.254.169.254 i get
curl http://169.254.169.254:8775
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
On controller node:
netstat -nap | grep 8775 gives
tcp0  0 0.0.0.0:8775 
0.0.0.0:*   LISTEN  13619/python

*Please suggest some pointers i am stuck at the same point from last 10
days.*


Can you try using another image to create a VM, the image you are using 
might not support DHCP option 121...


cheers,

Rossella



Regards
Pradeep Kumar



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



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

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

[Rossella Sblendido]

Very nice thread Ihar!

Here are my plans:

1. Get the last patches of the blueprint restructure-l2-agent  merged
and keep working on improving the agent. Some code refactor is
definitely needed and I'd like to add multiple workers.

2. Introducing oslo versioned objects

3. Make it easier to get started in Neutron.
   - mentor people
   - write docs/blog posts
   - in general simplify the current code when possible

4. Getting some performance data and store them for future reference


cheers,

Rossella

On Mon, 2015-10-05 at 18:29 +0900, Hirofumi Ichihara wrote:
> Hi,
> 
> 
> I have some plans in Mitaka cycle.
> 
> 
> 1. AZ support[1]
>  - I proposed AZ support in Liberty but the millstone is Mitaka now.
> The spec has been merged in Mitaka.
>I keep to propose the patches on Gerrit.
> 2. LinuxbrideDVR
>  - I'm trying to create concrete implementation and then I achieve it
> nearly. I will propose BP or RFE bug ASAP.
> 3. Router status update[2]
>  - I proposed it as bug[3] but some folks disagreed with this. I will
> classify the requirements and propose the implementation.
> 4. Devstack
>  - In Liberty cycle, I was aimed at removing plugin restriction from
> devstack so that vendor plugin maintainers easily keep to maintain the
> code in their tree.
>And also I tried to improve the quality for neutron. I’ve already
> finished some works.
>I will keep to contribute to devstack for neutron in Mitaka cycle
> including discussion about neutron repo vs devstack repo.
>If you have trouble with devstack related to neutron(especially
> devstack plugin), I can help you.
> 5. More
>  - I keep to contribute something else(especially logic for operators)
> for neutron :)
> 
> 
> [1]: https://blueprints.launchpad.net/neutron/+spec/add-availability-zone
> [2]: https://blueprints.launchpad.net/neutron/+spec/l3-router-status
> [3]: https://bugs.launchpad.net/neutron/+bug/1341290
> 
> 
> Thanks,
> Hirofumi
> 
> > On 2015/10/01, at 23:02, Ihar Hrachyshka 
> > wrote:
> > 
> > > On 01 Oct 2015, at 15:45, Ihar Hrachyshka 
> > > wrote:
> > > 
> > > Hi all,
> > > 
> > > I talked recently with several contributors about what each of us
> > > plans for the next cycle, and found it’s quite useful to share
> > > thoughts with others, because you have immediate yay/nay feedback,
> > > and maybe find companions for next adventures, and what not. So
> > > I’ve decided to ask everyone what you see the team and you
> > > personally doing the next cycle, for fun or profit.
> > > 
> > > That’s like a PTL nomination letter, but open to everyone! :) No
> > > commitments, no deadlines, just list random ideas you have in mind
> > > or in your todo lists, and we’ll all appreciate the huge pile of
> > > awesomeness no one will ever have time to implement even if
> > > scheduled for Xixao release.
> > > 
> > > To start the fun, I will share my silly ideas in the next email.
> > 
> > Here is my silly list of stuff to do.
> > 
> > - start adopting NeutronDbObject for core resources (ports,
> > networks) [till now, it’s used in QoS only];
> > 
> > - introduce a so called ‘core resource extender manager’ that would
> > be able to replace ml2 extension mechanism and become a plugin
> > agnostic way of extending core resources by additional plugins
> > (think of port security or qos available for ml2 only - that sucks!
> > );
> > 
> > - more changes with less infra tinkering! neutron devs should not
> > need to go to infra projects so often to make an impact;
> > -- make our little neat devstack plugin used for qos and sr-iov only
> > a huge pile of bash code that is currently stored in devstack and is
> > proudly called neutron-legacy now; and make the latter obsolete and
> > eventually removed from devstack;
> > -- make tempest jobs use a gate hook as we already do for api jobs;
> > 
> > - qos:
> > -- once we have gate hook triggered, finally introduce qos into
> > tempest runs to allow first qos scenarios merged;
> > -- remove RPC upgrade tech debt that we left in L (that should open
> > path for new QoS rules that are currently blocked by it);
> > -- look into races in rpc.callbacks notification pattern (Kevin
> > mentioned he had ideas in mind around that);
> > 
> > - oslo:
> > -- kill the incubator: we have a single module consumed from there
> > (cache); Mitaka is the time for the witch to die in pain;
> > -- adopt oslo.reports: that is something I failed to do in Liberty
> > so that I would have a great chance to do the same in Mitaka;
> > basically, allow neutron services to dump ‘useful info’ on SIGUSR2
> > sent; hopefully will make debugging a bit easier;
> > 
> > - upgrades:
> > -- we should return to partial job for neutron; it’s not ok our
> > upgrade strategy works by pure luck;
> > -- overall, I feel that it’s needed to provide more details about
> > how upgrades are expected to work in OpenStack (the order of service
> > upgrades; constraints; managing RPC versions and deprecations; etc.)
> > Probably devref should b

[openstack-dev] [Neutron] PTL Candidacy

[Rossella Sblendido]

Hi everyone,

I decided to run for the Neutron PTL position for the Mitaka release
cycle.

I have been contributing to Neutron since Havana and I am a member of
the control plane core review team. During these years I have touched
most parts of the Neutron code and in the last cycle my main focus has
been to restructure the OVS agent, adding the ability to use events
provided by ovsdb client and making it more resilient to failures.

Mentoring people and spreading knowledge about Neutron have been high
priorities for me in these years. I am a regular speaker at OpenStack
events (local meetups, Openstack days and summits), where my talks have
had high attendance and good feedback.
I have been a mentor for the Outreachy program [1] and the OpenStack
upstream training.

If I become PTL these are my main objectives for Mitaka:

* Make the community even more welcoming.
Neutron is still facing a big challenge in terms of review bandwidth.
Good features can't get merged because of this limit. Even if the
introduction of the Lieutenant system [2] has improved scalability, we
still need to create a better way to share knowledge.
In addition to improving the existing documentations and tutorials I'd
like to create a team of mentors that can help new contributors (the
quality of the proposed patches should increase so that the review time
needed to merge them should decrease) and form new reviewers (more good
people, more bandwidth).

* Keep working hard to increase the stability.
The introduction of functional tests and full stack tests was great, we
just need to keep going in that direction. Moreover I'd love to produce
and store some benchmark data so that we can also keep track of the
performance of Neutron during time.

* Continue getting feedback from operators.
I think it's very important to hear the opinions of the actual Neutron
users and to understand their concerns.

* Paying down technical debt
Introduce oslo versioned objects to improve RPC and keep refactoring
Neutron code to make it more readable and understandable.

Before proposing my candidacy I made sure I have the full support of my
employer for this role.

Neutron has a great team of contributors and great leaders, it would be
an honor for me to be able to coordinate our efforts and push Neutron
forward.


Thanks for reading so far and for considering this candidacy,

Rossella (rossella_s)

[1] https://wiki.openstack.org/wiki/Outreachy
[2]
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy



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

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

[Rossella Sblendido]

Hi Neil

On 07/10/2015 12:49 PM, Neil Jerram wrote:
> A pragmatic fix appears to be to explicitly requery the IPAllocation
> table, as you can see in the two commits here:
> https://github.com/Metaswitch/calico/commit/5512ce7dd50db414f161bddcef17b0846a1466ac
> 
> https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05
> 

in the second commit you actually set the right context, using context
instead of context._plugin_context. Why didn't you replace
context._plugin_context everywhere in that file, I think that might fix
the issue.

cheers,

Rossella

__
OpenStack Development Mailing 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

[Rossella Sblendido]

Huge +1 !!

On 07/06/2015 12:02 PM, Kevin Benton wrote:

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

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

[Rossella Sblendido]

Thanks everybody! I will do my best!

On 06/21/2015 03:56 AM, Paul Michali wrote:

Congratulations Rossella! Great addition to the team!
On Sat, Jun 20, 2015 at 12:13 PM Miguel Lavalle mailto:mig...@mlavalle.com>> wrote:

Complimenti per il nuovo lavoro!

On Fri, Jun 19, 2015 at 5:50 PM, Kevin Benton mailto:blak...@gmail.com>> wrote:

It's been a week with no negative feedback. Welcome to the team
Rossella!

On Mon, Jun 15, 2015 at 2:53 AM, Oleg Bondarev
mailto:obonda...@mirantis.com>> wrote:

+1

On Mon, Jun 15, 2015 at 12:14 PM, Ihar Hrachyshka
mailto: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

<http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#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://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://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://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:
o

Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

[Rossella Sblendido]

Salvatore,

I have never found your comments pedant, on the contrary they always
improved my patches and for sure Neutron in general.
It's a pity that you step down as a core but I am glad that you will
keep staying in the Neutron community!

Rossella

On 05/21/2015 05:58 PM, Salvatore Orlando wrote:
> After putting the whole OpenStack networking contributors community
> through almost 8 cycles of pedant comments and annoying "what if"
> questions, it is probably time for me to relieve neutron contributors
> from this burden.
> 
> It has been a pleasure for me serving the Neutron community (or Quantum
> as it was called at the time), and now it feel right - and probably
> overdue - to relinquish my position as a core team member in a spirit of
> rotation and alternation between contributors.
> 
> Note: Before you uncork your champagne bottles, please be aware that I
> will stay in the Neutron community as a contributors and I might still
> end up reviewing patches.
> 
> Thanks for being so understanding with my pedant remarks,
> Salvatore
> 
> 
> __
> OpenStack Development Mailing List (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]Fail to communicate new host when the first host for a new instance fails

[Rossella Sblendido]

Hi Neil,

what's the status of the port after the migration? You might be hitting
[1] . See also the patch that fixes the issue [2]

If you wait a bit longer, is the host_id updated by Nova?

cheers,

Rossella

[1] https://bugs.launchpad.net/neutron/+bug/1439857
[2] https://review.openstack.org/#/c/163178/

On 05/14/2015 11:29 AM, Neil Jerram wrote:
> Hi all, this is about a problem I'm seeing with my Neutron ML2 mechanism
> driver [1].  I'm expecting to see an update_port_postcommit call to
> signal that the binding:host_id for a port is changing, but I don't see
> that.
> 
> The scenario is launching a new instance in a cluster with two compute
> hosts, where we've rigged things so that one of the compute hosts will
> always be chosen first, but libvirt isn't correctly configured there and
> hence the instance launching attempt will fail.  Then Nova tries to use
> the other compute host instead, and that mostly works - except that my
> mechanism driver still thinks that the new instance's port is still
> bound to the first compute host.
> 
> Is anyone aware of a known problem in this area (in Juno-level code), or
> where I could like to start pinning this down in more detail?
> 
> Many thanks,
> Neil
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 

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

Re: [openstack-dev] [Neutron] Bump the RPC version required for port_update - AgentNotifierApi

[Rossella Sblendido]

On 04/28/2015 03:24 AM, Armando M. wrote:
> >> UnsupportedVersion error if the version is not bumped in their agent 
> too.
> >>
> >
> > Could the server fall back and keep on using the old version of the 
> API? I
> > think that would make for a much nicer experience, especially in face of
> > upgrades. Is this not possible? If it is, then the in vs out matter is 
> not
> > really an issue and out-of-tree code can reflect the change in API at 
> their
> > own pace.
> 
> while it's indeed nicer, it's difficult as port_update is
> an async call (cast) and does not wait for errors
> including UnsupportedVersion.
> 
> 
> Then, let's figure out how to change it!

Russell suggested a way to handle it using a version_cap. It doesn't
seem a trivial change and Russell already mentioned that it adds
complexity. If we feel that it's necessary I can look into it.

cheers,

Rossella



__
OpenStack Development Mailing List (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] Bump the RPC version required for port_update - AgentNotifierApi

[Rossella Sblendido]

Hello all,

I am working at the blueprint "Restructure the L2 agent" [1] .
One of the work item of this blueprint is to modify the port_update
message to include the attributes of the ports that were modified. This
is implemented in this patch [2] .

The client side of the RPC is in AgentNotifierApi , the server side is
implemented in the L2 agent. A problem arises since now the vendor
plugins are out of the tree. If they use a custom L2 agent (like for
example the Ryu plugin) when the patch is merged they will get an
UnsupportedVersion error if the version is not bumped in their agent too.

I am writing this email as heads up and also to ask a question. The
port_update signature on the server side is like this:

def port_update(self, context, **kwargs)

kwargs is used, no specific parameter is specified. If a new key is
added like in this case, the minor version of the RPC should be bumped
anyway? I think so.

cheers,

Rossella

[1] https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent
[2] https://review.openstack.org/#/c/155223

__
OpenStack Development Mailing 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] Generic question about synchronizing neutron agent on compute node with DB

[Rossella Sblendido]

> On 03/07/2015 01:10 PM, Leo Y wrote:
> What happens when neutron DB is updated to change network settings (e.g.
> via Dashboard or manually) when there are communication sessions opened
> in compute nodes. Does it influence those sessions? When the update is
> propagated to compute nodes?

Hi Leo,

when you say "change network settings" I think you mean a change in the
security group, is my assumption correct? In that case the Neutron
server will notify all the L2 agent (they reside on each compute node)
about the change. There are different kind of messages that the Neutron
server sends depending on the type of the update,
security_groups_rule_updated, security_groups_member_updated,
security_groups_provider_updated. Each L2 agent will process the message
and apply the required modification on the host. In the default
implementation we use iptables to implement security group, so the
update consists in some modifications of the iptables rules. Regarding
the existing connections in the compute nodes they might not be affected
by the change, which is a problem already discussed in this mail thread
[1] and there's a patch in review to fix that [2].
Hope that answers your question.

cheers,

Rossella

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-October/049055.html
[2] https://review.openstack.org/#/c/147713/

On 03/13/2015 04:10 AM, Kevin Benton wrote:
> Yeah, I was making a bad assumption for the l2 and l3. Sorry about that.
> It sounds like we don't have any protection against servers failing to
> send notifications.
> 
> On Mar 12, 2015 7:41 PM, "Assaf Muller"  > wrote:
> 
> 
> 
> - Original Message -
> > > However, I briefly looked through the L2 agent code and didn't see a
> > > periodic task to resync the port information to protect from a
> neutron
> > > server that failed to send a notification because it crashed or
> lost its
> > > amqp connection. The L3 agent has a period sync routers task
> that helps in
> > > this regard.
> 
> The L3 agent periodic sync is only if the full_sync flag was turned
> on, which
> is a result of an error.
> 
> > > Maybe another neutron developer more familiar with the L2
> > > agent can chime in here if I'm missing anything.
> >
> > i don't think you are missing anything.
> > periodic sync would be a good improvement.
> >
> > YAMAMAOTO Takashi
> >
> >
> __
> > OpenStack Development Mailing List (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] Update on "DB" IPAM driver

[Rossella Sblendido]

On 02/12/2015 02:36 PM, Salvatore Orlando wrote:
> - I promised a non blocking algorithm for IP allocation. The one I was
> developing was based on specifying the primary key on the ip_requests
> table in a way that it would prevent two concurrent requests from
> getting the same address, and would just retry getting an address until
> the primary key constraint was satisfied. However, recent information
> emerged on MySQL galera's (*) data set [2] certification  clarified that
> this kind of algorithm would still result in a deadlock error from
> failed data set certification. It is worth noting that in this case a
> solution based on traditional compare-and-swap is not possible because
> concurrent requests would be inserting data at the same time. I am now
> working on an alternative solution, and I would like to first implement
> a PoC for it (so that I can prove it works).

Would something like the following work: insert the data in the DB, if
any error is got open a new transaction and try again ? enikanorov
proposed a retry mechanism here [1] . Can't wait for your POC! I had
been playing a while in the past to try to remove the locking from the
IP allocation, it's hard!

cheers,

Rossella


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

__
OpenStack Development Mailing 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] Deprecating old security groups code / RPC.

[Rossella Sblendido]

On 12/04/2014 03:19 PM, Ihar Hrachyshka wrote:
> Is ipset support present in all supported distributions?

SUSE distributions support ipset.

+1 for Miguel Angel's proposal

cheers,

Rossella

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

Re: [openstack-dev] 答复: [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Rossella Sblendido]

On 11/27/2014 12:21 PM, marios wrote:
> Hi, so far we have this going
> https://etherpad.openstack.org/p/restructure-l2-agent

I finally pushed a design spec based on the etherpad above,
https://review.openstack.org/#/c/137808/ .
Anybody interested please comment on the review.

cheers,

Rossella

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

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Rossella Sblendido]

My name is also on the etherpad, I'd like to work on improving RPC and
ovslib. I am willing to take care of the BP, if somebody else is
interested we can do it together.

cheers,

Rossella


On 11/19/2014 12:01 AM, Kevin Benton wrote:
> My name is already on the etherpad in the RPC section, but I'll
> reiterate here that I'm very interested in optimizing a lot of the
> expensive ongoing communication between the L2 agent and the server on
> the message bus.
> 
> On Tue, Nov 18, 2014 at 9:12 AM, Carl Baldwin  > wrote:
> 
> At the recent summit, we held a session about debt repayment in the
> Neutron agents [1].  Some work was identified for the L2 agent.  We
> had a discussion in the Neutron meeting today about bootstrapping that
> work.
> 
> The first order of business will be to generate a blueprint
> specification for the work similar, in purpose, to the one that is
> under discussion for the L3 agent [3].  I personally am at or over
> capacity for BP writing this cycle.  We need a volunteer to take this
> on coordinating with others who have been identified on the etherpad
> for L2 agent work (you know who you are) and other volunteers who have
> yet to be identified.
> 
> This "task force" will use the weekly Neutron meeting, the ML, and IRC
> to coordinate efforts.  But first, we need to bootstrap the task
> force.  If you plan to participate, please reply to this email and
> describe how you will contribute, especially if you are willing to be
> the lead author of a BP.  I will reconcile this with the etherpad to
> see where gaps have been left.
> 
> I am planning to contribute as a core reviewer of blueprints and code
> submissions only.
> 
> Carl
> 
> [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
> [2]
> 
> http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html
> [3] https://review.openstack.org/#/c/131535/
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Kevin Benton
> 
> 
> ___
> 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] How to set port_filter in port binding?

[Rossella Sblendido]

Hi Alex,

a spoof filter is set by default to avoid that a VM can send packets
whose source address is different from the VM's address. There's no
option to change that.

cheers,

Rossella

On 09/25/2014 10:59 PM, Alexandre Levine wrote:
> Hi All,
> 
> I'm looking for a way to set port_filter flag to False for port binding.
> Is there a way to do this in IceHouse or in current Juno code? I use
> devstack with the default ML2 plugin and configuration.
> 
> According to this guide
> (http://docs.openstack.org/api/openstack-network/2.0/content/binding_ext_ports.html)
> it should be done via binding:profile but it gets only recorded in the
> dictionary of binding:profile and doesn't get reflected in vif_details
> as supposed to.
> 
> I tried to find any code in Neutron that can potentially do this
> transferring from incoming binding:profile into binding:vif_details and
> found none.
> 
> I'd be very grateful if anybody can point me in the right direction.
> 
> And by the by the reason I'm trying to do this is because I want to use
> one instance as NAT for another one in private subnet. As a result of
> ping 8.8.8.8 from private instance to NAT instance the reply gets
> Dropped by the security rule in iptables on TAP interface of NAT
> instance because the source is different from the NAT instance IP. So I
> suppose that port_filter is responsible for this behavior and will
> remove this restriction in iptables.
> 
> Best regards,
>   Alex Levine
> 
> ___
> 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] Not support dnsmasq < 2.63?

[Rossella Sblendido]

Hi Kyle,

SUSE Cloud ships dnsmasq 2.71 . For us it's fine to bump the minimum
version supported
to 2.63 .

cheers,

Rossella

On 07/30/2014 04:00 AM, Kyle Mestery wrote:
> On Tue, Jul 29, 2014 at 8:51 PM, Xuhan Peng  wrote:
>> We bumped the minimum version of dnsmasq to 2.63 a while ago by this code
>> change:
>>
>> https://review.openstack.org/#/c/105378/
>>
>> However, currently we still "kind of" support earlier version of dnsmasq
>> because we only give a warning and don't exit the program when we find
>> dnsmasq version is less than the minimum version. This causes some confusion
>> and complicates the code since we need to take care different syntax of
>> dnsmasq of different version in dhcp code (Note that the previous version
>> doesn't support tag).
>>
>> I wonder what's your opinion on NOT supporting dnsmasq version less than
>> 2.63 in Juno? I think we can prompt error message and exit the program when
>> we detect invalid version but I would like to gather more thoughts on this
>> one.
>>
> I'm personally ok with this hard limit, but I'd really like to hear
> from distribution people here to understand their thoughts, including
> what versions of dnsmasq ship with their products and how this would
> affect them.
>
> Thanks,
> Kyle
>
>> Thanks,
>> Xu Han
>>
>> ___
>> 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] Mid-cycle questions for folks

[Rossella Sblendido]

I had to call too. I got same conditions as Carl.

cheers,

Rossella

On 06/05/2014 04:45 PM, Kyle Mestery wrote:
> It would be ideal if folks could use the room block I reserved when
> booking, if their company policy allows it. I've gotten word from the
> hotel they may release the block if more people don't use it, just
> FYI.
>
> On Thu, Jun 5, 2014 at 5:46 AM, Paul Michali (pcm)  wrote:
>> I booked through our company travel and got a comparable rate ($111 or $114, 
>> I can’t recall the exact price).
>>
>> Regards,
>>
>> PCM (Paul Michali)
>>
>> MAIL …..…. p...@cisco.com
>> IRC ……..… pcm_ (irc.freenode.com)
>> TW ………... @pmichali
>> GPG Key … 4525ECC253E31A83
>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>>
>>
>>
>> On Jun 5, 2014, at 12:48 AM, Carl Baldwin  wrote:
>>
>>> Yes, I was able to book it for $114 a night with no prepayment.  I had
>>> to call.  The agent found the block under Cisco and the date range.
>>>
>>> Carl
>>>
>>> On Wed, Jun 4, 2014 at 4:43 PM, Kyle Mestery  
>>> wrote:
 I think it's even cheaper than that. Try calling the hotel to get the
 better rate, I think Carl was able to successfully acquire the room at
 the cheaper rate (something like $115 a night or so).

 On Wed, Jun 4, 2014 at 4:56 PM, Edgar Magana Perdomo (eperdomo)
  wrote:
> I tried to book online and it seems that the pre-payment is 
> non-refundable:
>
> "Hyatt.Com Rate Rate RulesFull prepayment required, non-refundable, no
> date changes."
>
>
> The price is $149 USD per night. Is that what you have blocked?
>
> Edgar
>
> On 6/4/14, 2:47 PM, "Kyle Mestery"  wrote:
>
>> Hi all:
>>
>> I was curious if people are having issues booking the room from the
>> block I have setup. I received word from the hotel that only one (1!)
>> person has booked yet. Given the mid-cycle is approaching in a month,
>> I wanted to make sure that people are making plans for travel. Are
>> people booking in places other than the one I had setup as reserved?
>> If so, I'll remove the room block. Keep in mind the hotel I had a
>> block reserved at is very convenient in that it's literally walking
>> distance to the mid-cycle location at the Bloomington, MN Cisco
>> offices.
>>
>> 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
>>
>> ___
>> 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] Need help to start contribute to Neutron

[Rossella Sblendido]

Hello chen,

You are already doing great, using irc and the mailing list is a good start.

Let me give you some links that can help you ramping up:

Neutron development:
https://wiki.openstack.org/wiki/NeutronDevelopment

If you wanna contribute fixing some bug I suggest you have a look at the
low hanging fruits:
https://wiki.openstack.org/wiki/NeutronStarterBugs

We are using Gerrit, read here how to set it up:
https://wiki.openstack.org/wiki/Gerrit_Workflow

If you are more interested into documentation please follow this guide:
https://wiki.openstack.org/wiki/Documentation/HowTo
I am not an expert here, maybe you should contact Edgar Magana, irc: emagana

Feel free to contact me on irc, my nick is rossella-s

thanks for your interest in Neutron!

Rossella

On 05/22/2014 10:56 AM, Li, Chen wrote:
>
> Hi list,
>
>  
>
> I have using Openstack/Neutron for a while.
>
> And now I hope I can do some contributions too.
>
> But neutron is too complicated, I don't know where to start.
>
>  
>
> In IRC, iwamoto suggested me to work with developer doc team.
>
> That sounds like a good idea.
>
> But I still doesn't know what/where I should start with.
>
> Can someone help me ?
>
>  
>
> Or just told me anything you think I can work on ?
>
>  
>
> Thanks.
>
> -chen
>
>  
>
> I used to working on CentOS, installing neutron directly using command
> "yum install neutron-xxx".
>
> Now, I have already download neutron code, and run successfully run
> unittest.
>
>  
>
>  
>
>  
>
>  
>
>
>
> ___
> 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][mysql] IMPORTANT: MySQL Galera does *not* support SELECT ... FOR UPDATE

[Rossella Sblendido]

Please see inline.

cheers,

Rossella

On 05/20/2014 12:26 AM, Salvatore Orlando wrote:
> Some comments inline.
>
> Salvatore
>
>
> On 19 May 2014 20:32, sridhar basam  > wrote:
>
>
>
>
> On Mon, May 19, 2014 at 1:30 PM, Jay Pipes  > wrote:
>
> Stackers,
>
> On Friday in Atlanta, I had the pleasure of moderating the
> database session at the Ops Meetup track. We had lots of good
> discussions and heard important feedback from operators on DB
> topics.
>
> For the record, I would not bring this point up so publicly
> unless I believed it was a serious problem affecting a large
> segment of users. When doing an informal survey of the
> users/operators in the room at the start of the session, out
> of approximately 200 people in the room, only a single person
> was using PostgreSQL, about a dozen were using standard MySQL
> master/slave replication, and the rest were using MySQL Galera
> clustering. So, this is a real issue for a large segment of
> the operators -- or at least the ones at the session. :)
>
>
> We are one of those operators that use Galera for replicating our
> mysql databases. We used to  see issues with deadlocks when having
> multiple mysql writers in our mysql cluster. As a workaround we
> have our haproxy configuration in an active-standby configuration
> for our mysql VIP. 
>
> I seem to recall we had a lot of the deadlocks happen through
> Neutron. When we go through our Icehouse testing, we will redo our
> multimaster mysql setup and provide feedback on the issues we see.
>
>
> The SELECT... FOR UPDATE issue is going to be a non trivial one for
> neutron as well. Some components, like IPAM, heavily rely on it.
> However, Neutron is a lot more susceptible to deadlock problems than
> nova because it does not implement at the moment a retry mechanism.
> This is something which should be added during the Juno release cycle
> regardless of all the other enhancement currently being planned, such
> as task oriented operations. 
>
>
> thanks,
>  Sridhar
>
>  
>
> Peter Boros, from Percona, was able to provide some insight on
> MySQL Galera topics, and one issue came up that is likely the
> cause of a lot of heartache for operators who use MySQL Galera
> (or Percona XtraDB Cluster).
>
> We were discussing whether people had seen deadlock issues [1]
> when using MySQL Galera in their deployment, and were
> brainstorming on why deadlocks might be seen. I had suggested
> that perhaps Nova's use of autoincrementing primary keys may
> have been the cause. Peter pretty quickly dispatched that
> notion, saying that Galera automatically handles
> autoincrementing keys using managed
> innodb_autoincrement_increment and innodb_autoincrement_offset
> config options.
>
> I think at that point I mentioned that there were a number of
> places that were using the SELECT ... FOR UPDATE construct in
> Nova (in SQLAlchemy, it's the with_lockmode('update')
> modification of the query object). Peter promptly said that
> was a problem. MySQL Galera does not support SELECT ... FOR
> UPDATE, since it has no concept of cross-node locking of
> records and results are non-deterministic.
>
> So... what to do?
>
> For starters, some information on the use of with_lockmode()
> in Nova and Neutron...
>
> Within Nova, there are actually only a few places where
> with_lockmode('update') is used. Unfortunately, the use of
> with_lockmode('update') is in the quota code, which tends to
> wrap largish blocks of code within the Nova compute execution
> code.
>
> Within Neutron, however, the use of with_lockmode('update') is
> all over the place. There are 44 separate uses of it in 11
> different files.
>
>
> I will report on a separate thread on this, so that we can have an
> assessment of where locking statements are used and why.
>  
>
> We have a number of options:
>
>
> I thin option 0 should be to rework/redesign the code, where possible,
> to avoid DB-level locking at all.

I totally agree. Is anybody already coordinating this rework? I'd like
to help. After redesigning, it is gonna be easier to make a decision
regarding a distributed lock manager.

>  
>
>
> 1) Stop using MySQL Galera for databases of projects that
> contain with_lockmode('update')
>
>
> This looks hideous, but I am afraid this is what all people wishing to
> deploy Icehouse should consider doing.
>  
>
>
> 2) Put a big old warning in the docs somewhere about the
> problem of potential deadlocks or odd behaviour with Galera in
> these proje

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

[Rossella Sblendido]

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


On 22 April 2014 14:58, Salvatore Orlando mailto: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] [qa] [neutron] Neutron Full Parallel job - Last 4 days failures

[Rossella Sblendido]

Hello all,

here is an update regarding the Neutron full parallel job.
I used the following Logstash query [1]  that checks the failures of the 
last

4 days (the last bug fix related with the full job was merged 4 days ago).
These are the results:

123 failure (25% of the total)

I took a sample of 50 failures and I obtained the following:

22% legitimate failures (they are due to the code change introduced by 
the patch)

22% infra issues
12% https://bugs.launchpad.net/openstack-ci/+bug/1291611
12% https://bugs.launchpad.net/tempest/+bug/1281969
8% https://bugs.launchpad.net/tempest/+bug/1294603
3% https://bugs.launchpad.net/neutron/+bug/1283522
3% https://bugs.launchpad.net/neutron/+bug/1291920
3% https://bugs.launchpad.net/nova/+bug/1290642
3% https://bugs.launchpad.net/tempest/+bug/1252971
3% https://bugs.launchpad.net/horizon/+bug/1257885
3% https://bugs.launchpad.net/tempest/+bug/1292242
3% https://bugs.launchpad.net/neutron/+bug/1277439
3% https://bugs.launchpad.net/neutron/+bug/1283599

cheers,

Rossella

[1] 
http://logstash.openstack.org/#eyJzZWFyY2giOiJidWlsZF9uYW1lOiBcImNoZWNrLXRlbXBlc3QtZHN2bS1uZXV0cm9uLWZ1bGxcIiBBTkQgbWVzc2FnZTpcIkZpbmlzaGVkOiBGQUlMVVJFXCIgQU5EIHRhZ3M6Y29uc29sZSIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiY3VzdG9tIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7ImZyb20iOiIyMDE0LTAzLTIwVDEzOjU0OjI1KzAwOjAwIiwidG8iOiIyMDE0LTAzLTI0VDEzOjU0OjI1KzAwOjAwIiwidXNlcl9pbnRlcnZhbCI6IjAifSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIiLCJzdGFtcCI6MTM5NTY3MDY2ODc0OX0=


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

[openstack-dev] [qa] [neutron] Neutron Full Parallel job - Last 48 hours failures

[Rossella Sblendido]

Hello devs,

I wanted the update the analysis performed by Salvatore Orlando few 
weeks ago [1]
I used the following query for Logstash [2] to detect the failures of 
the last 48 hours.


There were 77 failures (40% of the total).
I classified them and obtained the following:

21% due to infra issues
16% https://bugs.launchpad.net/tempest/+bug/1253896
14% https://bugs.launchpad.net/neutron/+bug/1291922
12% https://bugs.launchpad.net/tempest/+bug/1281969
10% https://bugs.launchpad.net/neutron/+bug/1291920
7% https://bugs.launchpad.net/neutron/+bug/1291918
7% https://bugs.launchpad.net/neutron/+bug/1291926
5% https://bugs.launchpad.net/neutron/+bug/1291947
3% https://bugs.launchpad.net/neutron/+bug/1277439
3% https://bugs.launchpad.net/neutron/+bug/1283599
2% https://bugs.launchpad.net/nova/+bug/1255627

I had to file 5 new bugs, that are on the previous list and can be 
viewed here [3].


cheers,

Rossella

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027862.html
[2] 
http://logstash.openstack.org/#eyJzZWFyY2giOiJidWlsZF9uYW1lOlwiY2hlY2stdGVtcGVzdC1kc3ZtLW5ldXRyb24tZnVsbFwiICBBTkQgcHJvamVjdDpcIm9wZW5zdGFjay9uZXV0cm9uXCIgQU5EIG1lc3NhZ2U6XCJGaW5pc2hlZDpcIiBBTkQgYnVpbGRfc3RhdHVzOlwiRkFJTFVSRVwiIEFORCBidWlsZF9icmFuY2g6XCJtYXN0ZXJcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiMTcyODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM5NDcwNzAzODk5NywibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==

[3] https://bugs.launchpad.net/neutron/+bugs?field.tag=neutron-full-job

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

Re: [openstack-dev] [qa] [neutron] Neutron Full Parallel job very close to voting - call to arms by neutron team

[Rossella Sblendido]

Ciao Salvatore,

thanks a lot for analyzing the failures!

This link is not working for me:
7) https://bugs.launchpad.net/neutron/+bug/1253533

I took a minor bug that was not assigned. Most of the bugs are assigned 
to you, I was wondering if you´d use some help. I guess we can 
coordinate better when you are online.


cheers,

Rossella

On 02/23/2014 03:14 AM, Salvatore Orlando wrote:

I have tried to collect more information on neutron full job failures.

So far there have been 219 failures and 891 successes, for an overall 
success rate of 19.8% which is inline with Sean's evaluation.
The count has performed exclusively on jobs executed against master 
branch. The failure rate for stable/havana is higher; indeed the job 
there still triggers bug 1273386 as it performs nbd mounting, and 
several fixes for the l2/l3 agents were not backported (or not 
backportable).


It is worth noting that actually some of the failures were because of 
infra issues. Unfortunately, it is not obvious to me how to define a 
logstash query for that. Nevertheless, it will be better to err on the 
side of safety and estimate failure rate to be about 20%.


I did then a classification of 63 failures, finding out the following:
- 25 failures were for infra issues, 1 failure was due to a flaw in a 
patch, leaving 37 "real" failures to analyse
   * In the same timeframe 203 jobs succeeded, giving a potential 
failure rate after excluding infra issues of 15.7%

- 2 bugs were responsible for 25 of these 37 failures
   * they are the "SSH protocol banner issue", and the well-knows DB 
lock timeouts
- bug 1253896 (the infamous SSH timeout bug) was hit only twice. The 
elastic recheck count is much higher because failures for the SSH 
protocol banner error (1265495) are being classified as bug 1253896.
   * actually in the past 48 hours only 2 voting neutron jobs hit this 
failure. This is probably a great improvement compared with a few 
weeks ago.
- Some failures are due to bug already known and tracked, other 
failures are due to bugs either unforeseen so far or not tracked. In 
the latter case a bug report has been filed.


It seems therefore that there are two high priority bugs to address:
1) https://bugs.launchpad.net/neutron/+bug/1283522 (16 occurrences, 
43.2% of failure, 6.67% globally)
* Check whether we can resume the split between API server and RPC 
server discussion)
2) https://bugs.launchpad.net/neutron/+bug/1265495 (9/37 = 24.3% of 
failures, 3.75% globally)


And several minor bugs (affecting tempest and/or neutron)
Each one of the following bugs was found no more than twice in our 
analysis:
3) https://bugs.launchpad.net/neutron/+bug/1254890 (possibly a nova 
bug, but it hit the neutron full job once)

4) https://bugs.launchpad.net/neutron/+bug/1283599
5) https://bugs.launchpad.net/neutron/+bug/1277439
6) https://bugs.launchpad.net/neutron/+bug/1253896
7) https://bugs.launchpad.net/neutron/+bug/1253533
8) https://bugs.launchpad.net/tempest/+bug/1283535 (possibly not a 
neutron bug)
9) https://bugs.launchpad.net/tempest/+bug/1253993 (need to devise new 
solutions for improving agent loop times)
   * there is already a patch under review for bulking device details 
requests

10) https://bugs.launchpad.net/neutron/+bug/1283518

In my humble opinion, it is therefore important to have immediately a 
plan for ensuring bugs #1 and #2 are solved or at least consistently 
mitigated by icehouse. It would also be good to identify assignees for 
bug #3 to bug #10.


Regards,
Salvatore


On 21 February 2014 14:44, Sean Dague > wrote:


Yesterday during the QA meeting we realized that the neutron full job,
which includes tenant isolation, and full parallelism, was passing
quite
often in the experimental queue. Which was actually news to most
of us,
as no one had been keeping a close eye on it.

I moved that to a non-voting job on all projects. A spot check
overnight
is that it's failing about twice as often as the regular neutron job.
Which is too high a failure rate to make it voting, but it's close.

This would be the time for a final hard push by the neutron team
to get
to the bottom of these failures to bring the pass rate to the level of
the existing neutron job, then we could make neutron full voting.

This is a *huge* move forward from where things were at the Havana
summit. I want to thank the Neutron team for getting so aggressive
about
getting this testing working. I was skeptical we could get there
within
the cycle, but a last push could actually get us neutron parity in the
gate by i3.

-Sean

--
Sean Dague
Samsung Research America
s...@dague.net  / sean.da...@samsung.com

http://dague.net


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Neutron]Contributing code to Neutron (ML2)

[Rossella Sblendido]

Hi Trinath,

you can find more info about third party testing here [1]
Every new driver or plugin is required to provide a testing system that
will test new patches and post
a +1/-1 to Gerrit .
There were meetings organized by Kyle to talk about how to set up the
system [2]
It will probably help you if you read the logs of the meeting.

cheers,

Rossella

[1]
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Testing_Requirements
[2]
http://lists.openstack.org/pipermail/openstack-dev/2013-December/021882.html


On Wed, Jan 29, 2014 at 7:50 AM, trinath.soman...@freescale.com <
trinath.soman...@freescale.com> wrote:

> Hi Akihiro-
>
> What kind of third party testing is required?
>
> I have written the driver, unit test case and checked the driver with
> tempest testing.
>
> Do I need to check with any other third party testing?
>
> Kindly help me in this regard.
>
> --
> Trinath Somanchi - B39208
> trinath.soman...@freescale.com | extn: 4048
>
> -Original Message-
> From: Akihiro Motoki [mailto:mot...@da.jp.nec.com]
> Sent: Friday, January 24, 2014 6:41 PM
> To: openstack-dev@lists.openstack.org
> Cc: kmest...@cisco.com
> Subject: Re: [openstack-dev] [Neutron]Contributing code to Neutron (ML2)
>
> Hi Trinath,
>
> Jenkins is not directly related to proposing a new code.
> The process to contribute the code is described in the links Andreas
> pointed. There is no difference even if you are writing a new ML2 mech
> driver.
>
> In addition to the above, Neutron now requires a third party testing for
> all new/existing plugins and drivers [1].
> Are you talking about third party testing for your ML2 mechanism driver
> when you say "Jenkins"?
>
> Both two things can be done in parallel, but you need to make your third
> party testing ready before merging your code into the master repository.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/019219.html
>
> Thanks,
> Akihiro
>
> (2014/01/24 21:42), trinath.soman...@freescale.com wrote:
> > Hi Andreas -
> >
> > Thanks you for the reply.. It helped me understand the ground work
> > required.
> >
> > But then, I'm writing a new Mechanism driver (FSL SDN Mechanism
> > driver) for ML2.
> >
> > For submitting new file sets, can I go with GIT or require Jenkins for
> > the adding the new code for review.
> >
> > Kindly help me in this regard.
> >
> > --
> > Trinath Somanchi - B39208
> > trinath.soman...@freescale.com | extn: 4048
> >
> > -Original Message-
> > From: Andreas Jaeger [mailto:a...@suse.com]
> > Sent: Friday, January 24, 2014 4:54 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Cc: Kyle Mestery (kmestery)
> > Subject: Re: [openstack-dev] [Neutron]Contributing code to Neutron
> > (ML2)
> >
> > On 01/24/2014 12:10 PM, trinath.soman...@freescale.com wrote:
> >> Hi-
> >>
> >>
> >>
> >> Need support for ways to contribute code to Neutron regarding the ML2
> >> Mechanism drivers.
> >>
> >>
> >>
> >> I have installed Jenkins and created account in github and launchpad.
> >>
> >>
> >>
> >> Kindly guide me on
> >>
> >>
> >>
> >> [1] How to configure Jenkins to submit the code for review?
> >>
> >> [2] What is the process involved in pushing the code base to the main
> >> stream for icehouse release?
> >>
> >>
> >>
> >> Kindly please help me understand the same..
> >
> > Please read this wiki page completely, it explains the workflow we use.
> >
> > https://wiki.openstack.org/wiki/GerritWorkflow
> >
> > Please also read the general intro at
> > https://wiki.openstack.org/wiki/HowToContribute
> >
> > Btw. for submitting patches, you do not need a local Jenkins running,
> >
> > Welcome to OpenStack, Kyle!
> >
> > Andreas
> > --
> >   Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
> >SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> > GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
> >  GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272
> > A126
> >
> > ___
> > 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] 答复: Proposed Logging Standards

[Rossella Sblendido]

Hi Sean,

good idea, count me in!
I think it makes more sense for me to help in Neutron, that's the project
that I'm more familiar with.

Rossella


On Tue, Jan 28, 2014 at 7:20 AM, Haiming Yang wrote:

>  I think it is also good for general i18n effort
>  --
> 发件人: Christopher Yeoh 
> 发送时间: 2014/1/28 11:02
> 收件人: OpenStack Development Mailing List (not for usage 
> questions)
> 主题: Re: [openstack-dev] Proposed Logging Standards
>
>  On Tue, Jan 28, 2014 at 12:55 AM, Sean Dague  wrote:
>
>> On 01/27/2014 09:07 AM, Macdonald-Wallace, Matthew wrote:
>> > Hi Sean,
>> >
>> > I'm currently working on moving away from the "built-in" logging to use
>> log_config= and the python logging framework so that we can start
>> shipping to logstash/sentry/.
>> >
>> > I'd be very interested in getting involved in this, especially from a
>> "why do we have log messages that are split across multiple lines"
>> perspective!
>>
>> Do we have many that aren't either DEBUG or TRACE? I thought we were
>> pretty clean there.
>>
>> > Cheers,
>> >
>> > Matt
>> >
>> > P.S. FWIW, I'd also welcome details on what the "Audit" level gives us
>> that the others don't... :)
>>
>> Well as far as I can tell the AUDIT level was a prior drive by
>> contribution that's not being actively maintained. Honestly, I think we
>> should probably rip it out, because I don't see any in tree tooling to
>> use it, and it's horribly inconsistent.
>>
>>
> For the uses I've seen of it in the nova api code INFO would be perfectly
> fine in place of AUDIT.
>
> I'd be happy to help out with patches to cleanup the logging in n-api.
>
> One other thing to look at - I've noticed with logs is that when something
> like glanceclient code (just as an example) is called from nova,
> we can get ERROR level messages for say image not found when its actually
> perfectly expected that this will occur.
> I'm not sure if we should be changing the error level in glanceclient or
> just forcing any error logging in glanceclient when
> called from Nova to a lower level though.
>
> Chris
>
> ___
> 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] Availability of external testing logs

[Rossella Sblendido]

Hi all,

going back to the original topic of making the logs public, I have a
question:

how long should the logs be kept? One week? One month?

cheers,

Rossella


On Tue, Jan 7, 2014 at 1:22 PM, Torbjorn Tornkvist wrote:

>  My problem seem to be the same as reported here:
>
>
> https://bitbucket.org/pypa/setuptools/issue/129/assertionerror-egg-info-pkg-info-is-not-a
>
> Not quite shure however how to bring in the fix into my setup.
>
> Cheers, Tobbe
>
>
> On 2014-01-07 10:38, Torbjorn Tornkvist wrote:
>
> Hi,
>
> Sorry for the problems.
> I've missed any direct mails to me (I'm drowning in Openstack mails...)
> I will make sure our Jenkins setup won't be left unattended in the future.
>
> How can I remove those '-1' votes?
>
> It seems that from:  Jan 2, 2014 5:46:26 PM
> after change: https://review.openstack.org/#/c/64696/
>
> something happend that makes the my tox crash with a traceback.
> I'll include the traceback below in case someone can give some help.
> (I'm afraid I don't know anything about python...)
> ---
> vagrant@quantal64:~/neutron$ sudo tox -e py27 -r --
> neutron.tests.unit.ml2.test_mechanism_ncs
>
> GLOB sdist-make: /home/vagrant/neutron/setup.py
> py27 create: /home/vagrant/neutron/.tox/py27
> ERROR: invocation failed, logfile:
> /home/vagrant/neutron/.tox/py27/log/py27-0.log
> ERROR: actionid=py27
> msg=getenv
> cmdargs=['/usr/bin/python2.7',
> '/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py',
> '--setuptools', '--python', '/usr/bin/python2.7', 'py27']
> env={'LC_NUMERIC': 'sv_SE.UTF-8', 'LOGNAME': 'root', 'USER': 'root',
> 'HOME': '/home/vagrant', 'LC_PAPER': 'sv_SE.UTF-8', 'PATH':
> '/home/vagrant/neutron/.tox/py27/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games',
> 'DISPLAY': 'localhost:10.0', 'LANG': 'en_US.utf8', 'TERM':
> 'xterm-256color', 'SHELL': '/bin/bash', 'LANGUAGE': 'en_US:',
> 'LC_MEASUREMENT': 'sv_SE.UTF-8', 'SUDO_USER': 'vagrant', 'USERNAME':
> 'root', 'LC_IDENTIFICATION': 'sv_SE.UTF-8', 'LC_ADDRESS': 'sv_SE.UTF-8',
> 'SUDO_UID': '1000', 'VIRTUAL_ENV': '/home/vagrant/neutron/.tox/py27',
> 'SUDO_COMMAND': '/usr/local/bin/tox -e py27 -r --
> neutron.tests.unit.ml2.test_mechanism_ncs', 'SUDO_GID': '1000',
> 'LC_TELEPHONE': 'sv_SE.UTF-8', 'LC_MONETARY': 'sv_SE.UTF-8', 'LC_NAME':
> 'sv_SE.UTF-8', 'MAIL': '/var/mail/root', 'LC_TIME': 'sv_SE.UTF-8',
> 'LS_COLORS':
> 'rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01
> ;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:'}
> Already using interpreter /usr/bin/python2.7
> New python executable in py27/bin/python2.7
> Also creating executable in py27/bin/python
> Installing setuptools, pip...
>   Complete output from command
> /home/vagrant/neutron/.tox/py27/bin/python2.7 -c "import sys, pip;
> pip...ll\"] + sys.argv[1:])" setuptools pip:
>   Traceback (most recent call last):
>   File "", line 1, in 
>   File
> "/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/__init__.py",
> line 9, in 
>   File
> "/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/log.py",
> line 8, in 
>   File
> "/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py",
> line 2696, in 
>   File
> "/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py",
> line 429, in __init__
>   File
> "/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py",
> line 443, in add_entry
> 

Re: [openstack-dev] [Tempest][Neutron] Network client and API tests refactoring.

[Rossella Sblendido]

Hi Eugene,

as you have already noticed there's already some overlap with your work
and the current tests development.
We should find a productive way to coordinate the efforts.
Thanks for starting the refactoring, in my opinion it's needed.

cheers,

Rossella


On Sat, Dec 14, 2013 at 4:53 PM, Jay Pipes  wrote:

> On Sat, 2013-12-14 at 19:09 +0400, Eugene Nikanorov wrote:
> > Hi Jay,
> >
> > Sure, that is understood. In fact such refactoring could be a big
> > change so I'd split it to two or more patches.
> > Hope this will not overlap with ongoing neutron API tests development.
>
> Hehe, given the sheer number of new tests that get added to Tempest
> every week, I'd say that any sort of base refactoring like this will
> need to be heavily coordinated with the Tempest core reviewers and other
> contributors pushing code!
>
> Best,
> -jay
>
>
>
> ___
> 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] Third party Neutron plugin testing meeting

[Rossella Sblendido]

Thanks Kyle for organizing this. I am attending too!


On Wed, Dec 11, 2013 at 7:50 AM, Irena Berezovsky wrote:

>  Please take guys and girls from Israel into account J.
>
>
>
>
>
> *From:* Yongsheng Gong [mailto:gong...@unitedstack.com]
> *Sent:* Wednesday, December 11, 2013 5:20 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron] Third party Neutron plugin
> testing meeting
>
>
>
> UTC 22:00+, which is 6:am beijing time，but if there are guys from Israel
> alike, I can get up one hour earlier, just like what I do for neutron
> meeting.
>
>
>
> On Wed, Dec 11, 2013 at 11:08 AM, Kyle Mestery 
> wrote:
>
> I suspect we'll need another meeting next week, I propose we have it
> at a time friendly to those in Asian timezones. Yong and Akihiro, can
> you guys propose a timeslot which works for you guys and I'll see
> about setting the followup meeting up.
>
> Thanks,
> Kyle
>
>
> On Dec 10, 2013, at 8:14 PM, Yongsheng Gong 
> wrote:
>
> > It is 1am beijing time, so I am afraid I will not join.
> >
> >
> > On Wed, Dec 11, 2013 at 10:10 AM, Akihiro Motoki 
> wrote:
> > Thanks Kyle for coordinating the meeting.
> >
> > The time is midnight to me, but it fits everyone except me. I'll try the
> time but not sure. Anyway I will follow the log.
> >
> > 2013年12月11日水曜日 Shiv Haris sha...@brocade.com:
> >
> > +1
> >
> >
> >
> > Will join via IRC or voice call
> >
> >
> >
> >
> >
> >
> >
> > From: Gary Duan [mailto:gd...@varmour.com]
> > Sent: Tuesday, December 10, 2013 10:59 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> testingmeeting
> >
> >
> >
> > I will be joining IRC too.
> >
> >
> >
> > Thanks,
> >
> > Gary
> >
> >
> >
> > On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana 
> wrote:
> >
> > Also joining!
> > Looking forward to hearing your ideas folks!
> >
> > Edgar
> >
> >
> > On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:
> >
> > >+1 ! I'll join.
> > >I'm also working on investigating how to use openstack gating system.
> > >(This document is still draft version)
> > >
> https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
> > >efQalL5Q0/edit#slide=id.p
> > >
> > >2013/12/10 Ivar Lazzaro :
> > >> +1 for 1700UTC Thursday on IRC
> > >>
> > >> -Original Message-
> > >> From: Kyle Mestery [mailto:mest...@siliconloons.com]
> > >> Sent: Tuesday, December 10, 2013 9:21 AM
> > >> To: OpenStack Development Mailing List (not for usage questions)
> > >> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
> > >>testing meeting
> > >>
> > >> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
> > >> wrote:
> > >>> -Original Message-
> > >>> From: Kyle Mestery 
> > >>> Reply-To: "OpenStack Development Mailing List (not for usage
> > >>>questions)"
> > >>> 
> > >>> Date: Tuesday, December 10, 2013 10:48
> > >>> To: "OpenStack Development Mailing List (not for usage questions)"
> > >>> 
> > >>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
> > >>> meeting
> > >>>
> >  Last week I took an action item to organize a meeting for everyone
> >  who is doing third-party testing in Neutron for plugins, whether
> this
> >  is vendor or Open Source based. The idea is to share ideas around
> >  setups and any issues people hit. I'd like to set this meeting up
> for
> >  this week, Thursday at 1700UTC. I would also like to propose we make
> >  this a dial in meeting using the Infrastructure Conferencing bridges
> >  [1]. If this time works, I'll set something up and reply to this
> >  thread with the dial in information.
> > >>>
> > >>> +1 for the meeting time.  Any particular reason for voice over IRC?
> > >>>
> > >> We kind of decided that doing this over voice initially would be
> > >>expedient, but I am fine with moving to IRC. If I don't hear
> objections,
> > >>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
> > >>
> > >>
> > 
> >  Also, I've started a etherpad page [2] with information. It would be
> >  good for people to add information to this etherpad as well. I've
> >  coupled this pad with information around multi-node gate testing for
> >  Neutron as well, as I suspect most of the third-party testing will
> >  require multiple nodes as well.
> > >>>
> > >>> I'll start filling out our setup.  I have some questions around
> > >>> Third-Party Testing in particular, and look forward to this
> discussion.
> > >>>
> > >> Awesome, thanks Anthony!
> > >>
> > 
> >  Thanks!
> >  Kyle
> > 
> >  [1]
> >
> >
> > ___
> > 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

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Rossella Sblendido]

Hi all,

sorry if this is a bit OT now.
I contacted some hotels to see if we could get a special price if we book
many rooms. According to my research the difference in price is not much.
Also, as Anita was saying, booking for everybody is more complicated.
So I decided to booked a room for myself.
I share the name of the hotel, in case you want to stay in the same place
http://www.lenouvelhotel.com/.
It's close to the meeting room and the price is one of the best I have
found.

cheers,

Rossella




On Sat, Nov 16, 2013 at 7:39 PM, Anita Kuno  wrote:

>  On 11/16/2013 01:14 PM, Anita Kuno wrote:
>
> On 11/16/2013 12:37 PM, Sean Dague wrote:
>
> On 11/15/2013 10:36 AM, Russell Bryant wrote:
>
>  On 11/13/2013 11:10 AM, Anita Kuno wrote:
>
>  Neutron Tempest code sprint
>
> In the second week of January in Montreal, Quebec, Canadathere will be a
> Neutron Tempest code sprint to improve the status of Neutron tests in
> Tempest and to add new tests.
>
>  First off, I think anything regarding putting more effort into this is
> great.  However, I *beg* the Neutron team not to wait until this week to
> make significant progress.
>
> To be clear, IMO, this is already painfully late.  It's one of the
> largest items blocking deprecation of nova-network and moving forward
> with Neutron.  This spring is just a couple weeks before icehouse-2.
> Come i2, mid-cycle, we're going to have make a call on whether or not
> nova-network deprecation seems likely.  If not, we really can't wait
> around and I will probably propose un-freezing nova-network.
>
>  100% agreed. Realistically this has to be a capping session, not when
> the real work starts. If the agent rewrite isn't done, and the parallel
> gate basically working before then, it won't work.
>
> Honestly, I think we're going to need to checkpoint before Christmas to
> figure out if the preconditions are met, because if they aren't, then
> it's not clear the 3 days of code sprint are really going to generate
> the results we need.
>
> I'm encouraged by the level of activity in the neutron channel, so I
> think right now planning for success is good. But again, we need some
> aggressive check points, and people need to realize this is not the
> beginning of this work, it is the closing session.
>
>   -Sean
>
>  Great. What kind of check points in a mutual location would we like to
> see?
>
> Etherpad?
>
> Meeting logs?
>
> Other suggestions?
>
> Thanks Sean,
> Anita.
>
> Actually I am going to answer my own question with a proposal.
>
> I would like to see a special sub-committee of the TC convened comprised
> of (5?) TC members and/or appointees for the express purpose of being
> available to help meet this goal, be available in the -neutron irc channel
> for questions and support and also to guide the process so the goal is
> achieved.
>
> Thoughts?
>
>
> Anita.
>
>
>
> ___
> 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] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Rossella Sblendido]

Hi all,

to avoid any misunderstanding let me specify it clearly. The event will
take place the second full week of January, 15th,16th,17th.

cheers,

Rossella


On Fri, Nov 15, 2013 at 12:33 PM, Anita Kuno  wrote:

>  On 11/15/2013 06:08 AM, Rossella Sblendido wrote:
>
>   Hi Anita,
>
>  thanks a lot for taking care of this, I realize it's hard to organize
> this kind of event.
>
>  I think I am going to have to go with attendees are on their own for
>> rooms. Less than an ideal situation in one sense, but much more doable from
>> an organization point of view for me - I just have to focus on the meeting
>> room and daily food, much easier to come to a reasonable budget in my mind.
>
>
>  I'd prefer that we are all in the same hotel. I can offer my help to
> contact some hotel and see what prices they propose. Would that help? Or do
> you think it would be more expensive anyway?
>
> I think that would be great. Please do.
>
> The address of the meeting room I have tentatively booked is:
>  3625 Avenue du Parc
>  Montréal, QC H2X, Canada 
>
> Let me know what else you need to support this direction.
>
> Thanks so much Rossella,
> Anita.
>
>
>  cheers,
>
> Rossella
>
>
>
> On Fri, Nov 15, 2013 at 11:33 AM, Anita Kuno  wrote:
>
>>  On 11/14/2013 06:45 PM, Miguel Lavalle wrote:
>>
>>  Anita,
>>
>>  I am interested in attending this event. I have already talked to my
>> manager and he is open to fund my trip.
>>
>>  Wonderful. This is great news, Miguel. I look forward to meeting you.
>>
>>   I need to put together a budget, though, in order to get final
>> approval.
>>
>>  That makes sense.
>>
>>   What is the estimated daily rate for the chosen hotel / venue?
>>
>>  I have looked at selecting a designated hotel and I don't think I am
>> going to go that route. I will explain why.
>>
>> If I go with a block of rooms at one location, and meeting rooms plus
>> daily food, I can't get comfortable with what they want to charge me on a
>> per person basis.
>>
>> If I go with a location by itself (which I have a tentative hold on) and
>> food by itself (awaiting a menu from a caterer) then I am feeling the
>> numbers will come in to a reasonable amount. This option would mean that
>> attendees are on their own for hotel bookings. Taking a quick look at
>> kayak.com and filtering for 10 km to the intended location, the prices
>> for some rooms will match or beat any prices I have gotten back from the
>> hotel I have contacted.
>>
>> http://www.ca.kayak.com/hotels/Montreal,QC,Canada-c6966/2014-01-14/2014-01-18
>>
>> I think I am going to have to go with attendees are on their own for
>> rooms. Less than an ideal situation in one sense, but much more doable from
>> an organization point of view for me - I just have to focus on the meeting
>> room and daily food, much easier to come to a reasonable budget in my mind.
>> This would cover breakfast, tea/coffee and lunch. I still don't know what
>> to do about dinner. I would like us to have the option to congregate as a
>> group - I don't think a sit down dinner is reasonable, something more
>> conducive to mingling. But I haven't gotten there yet, suggestions welcome.
>>
>> Having attendees organize their own accommodations worked fine for the
>> Infra Boot Camp in New York City in June, so I hope it will work as well
>> here.
>>
>> I hope this frees you up to make your own choices, Miguel, and submit
>> your budget for approval.
>>
>> Let me know your thoughts and if you need more from me.
>>
>> Thanks,
>> Anita.
>>
>>
>>  Looking forward to see you in Montreal
>>
>>  Cheers
>>
>>  Miguel
>>
>>
>> On Wed, Nov 13, 2013 at 10:10 AM, Anita Kuno wrote:
>>
>>> Neutron Tempest code sprint
>>>
>>> In the second week of January in Montreal, Quebec, Canadathere will be a
>>> Neutron Tempest code sprint to improve the status of Neutron tests in
>>> Tempest and to add new tests.
>>> It will be a 3 day event. Right now there are 14 peoplewho came forward
>>> when it was announced on the Friday at the summit. We need to know how many
>>> additional people are interested in attending.
>>>
>>> This is an impromptu event based on my assessment of the need for this
>>> to happen, so don't feel left out if you didn't know about it in advance.
>>>
>>> We picked Montreal for two main reasons:
>>> 1. All 4 people whose atten

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Rossella Sblendido]

Hi Anita,

thanks a lot for taking care of this, I realize it's hard to organize this
kind of event.

I think I am going to have to go with attendees are on their own for rooms.
> Less than an ideal situation in one sense, but much more doable from an
> organization point of view for me - I just have to focus on the meeting
> room and daily food, much easier to come to a reasonable budget in my mind.


I'd prefer that we are all in the same hotel. I can offer my help to
contact some hotel and see what prices they propose. Would that help? Or do
you think it would be more expensive anyway?

cheers,

Rossella



On Fri, Nov 15, 2013 at 11:33 AM, Anita Kuno  wrote:

>  On 11/14/2013 06:45 PM, Miguel Lavalle wrote:
>
>  Anita,
>
>  I am interested in attending this event. I have already talked to my
> manager and he is open to fund my trip.
>
> Wonderful. This is great news, Miguel. I look forward to meeting you.
>
>   I need to put together a budget, though, in order to get final approval.
>
> That makes sense.
>
>   What is the estimated daily rate for the chosen hotel / venue?
>
> I have looked at selecting a designated hotel and I don't think I am going
> to go that route. I will explain why.
>
> If I go with a block of rooms at one location, and meeting rooms plus
> daily food, I can't get comfortable with what they want to charge me on a
> per person basis.
>
> If I go with a location by itself (which I have a tentative hold on) and
> food by itself (awaiting a menu from a caterer) then I am feeling the
> numbers will come in to a reasonable amount. This option would mean that
> attendees are on their own for hotel bookings. Taking a quick look at
> kayak.com and filtering for 10 km to the intended location, the prices
> for some rooms will match or beat any prices I have gotten back from the
> hotel I have contacted.
>
> http://www.ca.kayak.com/hotels/Montreal,QC,Canada-c6966/2014-01-14/2014-01-18
>
> I think I am going to have to go with attendees are on their own for
> rooms. Less than an ideal situation in one sense, but much more doable from
> an organization point of view for me - I just have to focus on the meeting
> room and daily food, much easier to come to a reasonable budget in my mind.
> This would cover breakfast, tea/coffee and lunch. I still don't know what
> to do about dinner. I would like us to have the option to congregate as a
> group - I don't think a sit down dinner is reasonable, something more
> conducive to mingling. But I haven't gotten there yet, suggestions welcome.
>
> Having attendees organize their own accommodations worked fine for the
> Infra Boot Camp in New York City in June, so I hope it will work as well
> here.
>
> I hope this frees you up to make your own choices, Miguel, and submit your
> budget for approval.
>
> Let me know your thoughts and if you need more from me.
>
> Thanks,
> Anita.
>
>
>  Looking forward to see you in Montreal
>
>  Cheers
>
>  Miguel
>
>
> On Wed, Nov 13, 2013 at 10:10 AM, Anita Kuno  wrote:
>
>> Neutron Tempest code sprint
>>
>> In the second week of January in Montreal, Quebec, Canadathere will be a
>> Neutron Tempest code sprint to improve the status of Neutron tests in
>> Tempest and to add new tests.
>> It will be a 3 day event. Right now there are 14 peoplewho came forward
>> when it was announced on the Friday at the summit. We need to know how many
>> additional people are interested in attending.
>>
>> This is an impromptu event based on my assessment of the need for this to
>> happen, so don't feel left out if you didn't know about it in advance.
>>
>> We picked Montreal for two main reasons:
>> 1. All 4 people whose attendance is critical (markmclain, salv-orlando,
>> sdague and mtrenish) can get there. It was New York or Montreal.
>> 2. I can't think in New York, love it, can't compose a thought, so
>> Montreal it is.
>>
>> It turns out this location choice has some resultant effects:
>> 1. People who wouldn't have time to get a visa to attend an event in the
>> States have an easier time entering Canada.
>> US requires visa applications filed 2 months in advance of travel and
>> we are inside that timeframe.
>> 2. Montreal is cheaper than NYC.
>> 3. Being Canadian it is going to be easier for me to produce this event
>> in Canada since I am in Canada.
>> 4. It will be cold. We had few choices on the timing and this event can't
>> wait on good weather.
>>
>> There is no location that will make everyone happy, so people will be
>> disappointed by this choice and I accept that. It is my hope that this
>> event is a success and we can create a schedule of some sort so that people
>> who have a high possibility of attending can vote on the location. So that
>> is the future vision.
>>
>> I have a tenative hold on a venue and am working on getting a rate on a
>> block of rooms at a hotel.
>>
>> I am preparing a budget to submit to the Foundation in the hopes they
>> will sponsor the event. Since this was planned with no warning, 

Re: [openstack-dev] [Neutron] Port mirroring

[Rossella Sblendido]

Hi Edgar,

documentation is a great idea. I will make sure to have it. Shall I add it
to the blueprint or just have to keep that in mind?
Yes it will be configurable, if you look at the API I think it's quite
flexible but if you or others have ideas on how to make it better, please
add some comment.

Regarding the overhead, I could give only a vague answer now. Let me think
more through it and I will come back to you. I think the best way is to
provide more details about the implementation in the document so that
everybody can have a better idea of the changes required and can give
his/her feedback too. I will do that.

thanks a lot!

Rossella


On Thu, Nov 14, 2013 at 7:15 PM, Edgar Magana  wrote:

> Hello Rossella,
>
> Kyle has a very good point and I wanted to add the documentation request.
> Be sure you have a wiki/document (not a technical one) that we can easily
> transfer into the OpenStack Docs.
>
> This is a great feature, any idea of the overhead that it will cause?
> I assume that this is going to be totally configurable, right?  :-)
>
> Edgar
>
> On 11/14/13 8:34 AM, "Kyle Mestery (kmestery)"  wrote:
>
> >On Nov 14, 2013, at 8:46 AM, Rossella Sblendido 
> >wrote:
> >>
> >> Hello devs,
> >>
> >> I'd like to start working at this blueprint:
> >>
> >> https://blueprints.launchpad.net/neutron/+spec/port-mirroring
> >>
> >> I didn't receive much feedback so please have a look at it.
> >>
> >> It was not approved yet. What's the usual workflow? Shall I wait for
> >>approval before I start implementing it? Sorry for the trivial question
> >>but I'm new here.
> >>
> >Welcome Rossella!
> >
> >One issue I have with the design document linked in the blueprint is the
> >testing section has nothing in it all. Given we're trying hard to focus
> >on quality and testing, I'd like you to add some specific testing
> >information to the document before we approve it. It would be ideal to
> >have Tempest tests which test out the new API functionality as well.
> >That's my main issue with this BP as seen now, but I'd like others to
> >comment on this as well.
> >
> >Thanks!
> >Kyle
> >
> >> thanks,
> >>
> >> Rossella
> >>
> >> ___
> >> 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] Port mirroring

[Rossella Sblendido]

Hi Kyle,

thanks for your feedback. Good point! I have filled the tests section.

cheers,

Rossella


On Thu, Nov 14, 2013 at 5:34 PM, Kyle Mestery (kmestery)  wrote:

> On Nov 14, 2013, at 8:46 AM, Rossella Sblendido 
> wrote:
> >
> > Hello devs,
> >
> > I'd like to start working at this blueprint:
> >
> > https://blueprints.launchpad.net/neutron/+spec/port-mirroring
> >
> > I didn't receive much feedback so please have a look at it.
> >
> > It was not approved yet. What's the usual workflow? Shall I wait for
> approval before I start implementing it? Sorry for the trivial question but
> I'm new here.
> >
> Welcome Rossella!
>
> One issue I have with the design document linked in the blueprint is the
> testing section has nothing in it all. Given we're trying hard to focus on
> quality and testing, I'd like you to add some specific testing information
> to the document before we approve it. It would be ideal to have Tempest
> tests which test out the new API functionality as well. That's my main
> issue with this BP as seen now, but I'd like others to comment on this as
> well.
>
> Thanks!
> Kyle
>
> > thanks,
> >
> > Rossella
> >
> > ___
> > 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] Port mirroring

[Rossella Sblendido]

Hello devs,

I'd like to start working at this blueprint:

https://blueprints.launchpad.net/neutron/+spec/port-mirroring

I didn't receive much feedback so please have a look at it.

It was not approved yet. What's the usual workflow? Shall I wait for
approval before I start implementing it? Sorry for the trivial question but
I'm new here.

thanks,

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