[openstack-dev] Stepping down from Neutron core team

[Hirofumi Ichihara]

Hi all,


I’m stepping down from the core team because my role changed and I cannot
have responsibilities of neutron core.


My start of neutron was 5 years ago. I had many good experiences from
neutron team.

Today neutron is great project. Neutron gets new reviewers, contributors
and, users.

Keep on being a great community.


Thanks,

Hirofumi
__
OpenStack Development Mailing List (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] Bug deputy report week August 27 - September 2

[Hirofumi Ichihara]

Hi,

I was the bug deputy for the week of August 27 - September 2.

There is no Ctirical bug.

High:
https://bugs.launchpad.net/neutron/+bug/1789878
https://bugs.launchpad.net/neutron/+bug/1789846
https://bugs.launchpad.net/neutron/+bug/1789579
https://bugs.launchpad.net/neutron/+bug/1789434
https://bugs.launchpad.net/neutron/+bug/1789403

Medium:
https://bugs.launchpad.net/neutron/+bug/1790143
https://bugs.launchpad.net/neutron/+bug/1789499

New:
https://bugs.launchpad.net/neutron/+bug/1790084 This is needed to triage
by l3-dvr-backlog lieutenants.
https://bugs.launchpad.net/neutron/+bug/1790038 This is needed to triage
by l3-dvr-backlog lieutenants.
https://bugs.launchpad.net/neutron/+bug/1789334 This is needed to triage by
troubleshooting lieutenants or Osprofier forks.

Incomplete:
https://bugs.launchpad.net/neutron/+bug/1790023
https://bugs.launchpad.net/neutron/+bug/1789870
https://bugs.launchpad.net/neutron/+bug/1789844

Wishlist:
https://bugs.launchpad.net/neutron/+bug/1789378

RFE:
https://bugs.launchpad.net/neutron/+bug/1789592
https://bugs.launchpad.net/neutron/+bug/1789391

Thanks,
Hirofumi
__
OpenStack Development Mailing List (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] Bug deputy report

[Hirofumi Ichihara]

Hi all,

There is no critical bug but I'd like to report some bugs last week.

Three high priority bugs.

- https://bugs.launchpad.net/neutron/+bug/1741954 :
create_and_list_trunk_subports rally scenario failed with timeouts

- https://bugs.launchpad.net/neutron/+bug/1742401 : Fullstack tests
neutron.tests.fullstack.test_securitygroup.TestSecurityGroupsSameNetwork
fails often

- https://bugs.launchpad.net/neutron/+bug/1741889 : functional:
DbAddCommand sometimes times out after 10 seconds

The following bug is difficult to judge. Please feedback of Miguel as L3
Lieutenant.

https://bugs.launchpad.net/neutron/+bug/1742093 : ip_allocation attribute
is not accessible over REST requests

Thanks,
Hirofumi
__
OpenStack Development Mailing 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] Stepping down from core

[Hirofumi Ichihara]

Hi Armando,

It's been a great pleasure working with you. We appreciate your hard work
and dedication.
Best wishes and good luck at your new commitments.

Thanks,
Hirofumi

2017-12-16 4:01 GMT+09:00 Armando M. :

> Hi neutrinos,
>
> To some of you this email may not come as a surprise.
>
> During the past few months my upstream community engagements have been
> more and more sporadic. While I tried hard to stay committed and fulfill my
> core responsibilities I feel like I failed to retain the level of quality
> and consistency that I would have liked ever since I stepped down from
> being the Neutron PTL back at the end of Ocata.
>
> I stated many times when talking to other core developers that being core
> is a duty rather than a privilege, and I personally feel like it's way
> overdue for me to recognize on the mailing list that it's the time that I
> state officially my intention to step down due to other commitments.
>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing
> with the neutron quirks for which I might be (git) blamed :)
>
> Cheers,
> Armando
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Propose Slawek Kaplonski for Neutron core

[Hirofumi Ichihara]

+1

2017-11-30 4:21 GMT+09:00 Miguel Lavalle :

> Hi Neutron Team,
>
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
> has been an active contributor to the project since the Mitaka cycle. He
> has been instrumental in the development of the QoS capabilities in
> Neutron, becoming the lead of the sub-team focused on that set of features.
> More recently, he has collaborated in the implementation of OVO and is an
> active participant in the CI sub-team. His number of code reviews during
> the Queens cycle is on par with the leading core members of the team:
> http://stackalytics.com/?module=neutron
>
> In my opinion, his efforts are highly valuable to the team and we will be
> very lucky to have him as a fully voting core.
>
> I will keep this nomination open for a week as customary,
>
> Thank you,
>
> 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-Infra] First member of networking-lagopus gerrit group

[Hirofumi Ichihara]

On 2017/09/21 23:10, Paul Belanger wrote:

On Thu, Sep 21, 2017 at 10:17:20AM +0900, Hirofumi Ichihara wrote:

Hi Infra team,

I proposed networking-lagopus project[1] and then it looks like the project
was created[2, 3].
Could you add me into the groups?

[1]: https://review.openstack.org/#/c/501730/
[2]: https://review.openstack.org/#/admin/groups/1837,members
[3]: https://review.openstack.org/#/admin/groups/1838,members

Thanks,
Hirofumi


Done!



Thank you! :)


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

[OpenStack-Infra] First member of networking-lagopus gerrit group

[Hirofumi Ichihara]

Hi Infra team,

I proposed networking-lagopus project[1] and then it looks like the 
project was created[2, 3].

Could you add me into the groups?

[1]: https://review.openstack.org/#/c/501730/
[2]: https://review.openstack.org/#/admin/groups/1837,members
[3]: https://review.openstack.org/#/admin/groups/1838,members

Thanks,
Hirofumi


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

Re: [openstack-dev] [neutron-dynamic-routing] 4-byte AS Numbers Support

[Hirofumi Ichihara]

2017-08-30 16:37 GMT+09:00 Jens Harbott <j.harb...@x-ion.de>:

> 2017-08-30 9:04 GMT+02:00 Hirofumi Ichihara <ichihara.hirof...@gmail.com>:
> > Hi team,
> >
> > Currently neutron-dynamic-routing supports 2 byte AS numbers only[1].
> > Does team have a plan supporting 4 byte AS numbers?
> >
> > [1]:
> > https://github.com/openstack/neutron-dynamic-routing/blob/
> master/neutron_dynamic_routing/services/bgp/common/constants.py#L27
>
> Not a plan, but at least an RFE bug[1], lost track of it a bit, but
> happy to help in case someone wants to pursue it.
>
> [1] https://bugs.launchpad.net/neutron/+bug/1573092


Thank you for good pointer.

Thanks,
Hirofumi
__
OpenStack Development Mailing List (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-dynamic-routing] 4-byte AS Numbers Support

[Hirofumi Ichihara]

Hi team,

Currently neutron-dynamic-routing supports 2 byte AS numbers only[1].
Does team have a plan supporting 4 byte AS numbers?

[1]:
https://github.com/openstack/neutron-dynamic-routing/blob/master/neutron_dynamic_routing/services/bgp/common/constants.py#L27

Thanks,
Hirofumi
__
OpenStack Development Mailing 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] - are you attending the Boston summit?

[Hirofumi Ichihara]

Hi Miguel,

Unfortunately I already have a plan to attend another party. Please give
another attendee my seat.

Thanks,
Hirofumi

2017-05-08 18:18 GMT-04:00 Miguel Lavalle :

> Dear Neutrinos,
>
> I am working with Legal Sea Foods on a reservation for 30 people,
> Wednesday at 7pm. I am assuming the 30 people who registered in the
> etherpad will attend (https://etherpad.openstack.
> org/p/neutron-boston-summit-attendees). If your name is in the etherpad
> and you DON'T plan to attend, please let me know.
>
> Legal Sea Foods has several locations close to the convention center. I
> will send an update with the slected location as soon as I can finalize the
> the details with them. Please keep an eye on your inbox
>
> Cheers
>
> Miguel
>
> On Mon, May 8, 2017 at 7:57 AM, Kevin Benton  wrote:
>
>> Let's plan for a social Wednesday night. I'll update this with a location
>> once we find a place.
>>
>> On May 8, 2017 08:50, "MCCASLAND, TREVOR"  wrote:
>>
>>> Looking forward to it! RSVP? +1
>>>
>>>
>>>
>>> *From:* Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
>>> *Sent:* Saturday, May 06, 2017 12:31 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev@lists.openstack.org>
>>> *Subject:* Re: [openstack-dev] [neutron] - are you attending the Boston
>>> summit?
>>>
>>>
>>>
>>> Hey Neutron Folks,
>>>
>>>
>>>
>>> Following our past tradition, we should have Neutron dinner while we are
>>> all in Boston.
>>>
>>> Miguel has few places in mind. I would propose that we nominate him as
>>> the dinner organizer lieutenant.
>>>
>>>
>>>
>>> Miguel, I hope you will take us to some cool place.
>>>
>>>
>>>
>>> Thanks
>>>
>>> -Sukhdev
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Apr 20, 2017 at 4:31 PM, Kevin Benton  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> If you are a Neutron developer attending the Boston summit, please add
>>> your name to the etherpad here so we can plan a Neutron social and easily
>>> coordinate in person meetings: https://etherpad.ope
>>> nstack.org/p/neutron-boston-summit-attendees
>>> 
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Kevin Benton
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (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] [infra] Depends-on tag effect

[Hirofumi Ichihara]

On 2017/03/09 2:33, Armando M. wrote:



On 8 March 2017 at 07:39, Hirofumi Ichihara 
<ichihara.hirof...@lab.ntt.co.jp 
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:




On 2017/03/08 23:59, Andreas Jaeger wrote:

On 2017-03-08 15:40, ZZelle wrote:

Hi,

iiuc, neutron uses a released version of neutron-lib not
neutron-lib
master ... So the change should depends on a change in
requirements repo
incrementing neutron-lib version

This is documented also at - together with some other caveats:


https://docs.openstack.org/infra/manual/developers.html#limitations-and-caveats

<https://docs.openstack.org/infra/manual/developers.html#limitations-and-caveats>

Thank you for the pointer. I understand.


You can do the reverse as documented in [1]: i.e. file a dummy patch 
against neutron-lib that pulls in both neutron's and neutron-lib 
changes. One example is [2]


[1] 
https://docs.openstack.org/developer/neutron-lib/review-guidelines.html

[2] https://review.openstack.org/#/c/386846/

That makes sense. I missed the documentation. Thank you for your help.




Hirofumi




Note a depends-on requirements won't work either - you really
need to
release it. Or you need to change the test to pull neutron-lib
from source,

Andreas

On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara
<ichihara.hirof...@lab.ntt.co.jp
<mailto:ichihara.hirof...@lab.ntt.co.jp>
<mailto:ichihara.hirof...@lab.ntt.co.jp
<mailto:ichihara.hirof...@lab.ntt.co.jp>>> wrote:

 Hi,

 I thought that we can post neutron patch depending on
neutron-lib
 patch under review.
 However, I saw it doesn't work[1, 2]. In the patches,
neutron
 patch[1] has Depends-on tag with neutron-lib patch[2]
but the pep8
 and unit test fails because the test doesn't use the
neutron-lib patch.

 Please correct me if it's my misunderstanding.

 [1]: https://review.openstack.org/#/c/424340/
<https://review.openstack.org/#/c/424340/>
 <https://review.openstack.org/#/c/424340/
<https://review.openstack.org/#/c/424340/>>
 [2]: https://review.openstack.org/#/c/424868/
<https://review.openstack.org/#/c/424868/>
 <https://review.openstack.org/#/c/424868/
<https://review.openstack.org/#/c/424868/>>

 Thanks,
 Hirofumi



   
 __

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


<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
   
 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>





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

<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>






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




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


_

Re: [openstack-dev] [neutron] [infra] Depends-on tag effect

[Hirofumi Ichihara]

On 2017/03/08 23:59, Andreas Jaeger wrote:

On 2017-03-08 15:40, ZZelle wrote:

Hi,

iiuc, neutron uses a released version of neutron-lib not neutron-lib
master ... So the change should depends on a change in requirements repo
incrementing neutron-lib version

This is documented also at - together with some other caveats:

https://docs.openstack.org/infra/manual/developers.html#limitations-and-caveats

Thank you for the pointer. I understand.

Hirofumi




Note a depends-on requirements won't work either - you really need to
release it. Or you need to change the test to pull neutron-lib from source,

Andreas

On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara
<ichihara.hirof...@lab.ntt.co.jp
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:

 Hi,

 I thought that we can post neutron patch depending on neutron-lib
 patch under review.
 However, I saw it doesn't work[1, 2]. In the patches, neutron
 patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8
 and unit test fails because the test doesn't use the neutron-lib patch.

 Please correct me if it's my misunderstanding.

 [1]: https://review.openstack.org/#/c/424340/
 <https://review.openstack.org/#/c/424340/>
 [2]: https://review.openstack.org/#/c/424868/
 <https://review.openstack.org/#/c/424868/>

 Thanks,
 Hirofumi



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




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








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

[openstack-dev] [neutron] [infra] Depends-on tag effect

[Hirofumi Ichihara]

Hi,

I thought that we can post neutron patch depending on neutron-lib patch  
under review.
However, I saw it doesn't work[1, 2]. In the patches, neutron patch[1]  
has Depends-on tag with neutron-lib patch[2] but the pep8 and unit test  
fails because the test doesn't use the neutron-lib patch.


Please correct me if it's my misunderstanding.

[1]: https://review.openstack.org/#/c/424340/
[2]: https://review.openstack.org/#/c/424868/

Thanks,
Hirofumi



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

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

[Hirofumi Ichihara]

+1

On 2016/12/16 8:58, Armando M. wrote:

Hi neutrinos,

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


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


Cheers,
Armando

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


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


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

[Hirofumi Ichihara]

+1

On 2016/12/16 8:14, Armando M. wrote:

Hi neutrinos,

Miguel Lavalle has been driving the project forward consistently and 
reliably. I would like to propose him to be entrusted with +2/+A 
rights in the areas he's been most prolific, which are L3 and DHCP.


At the same time, I'd like to propose Brian Haley as our next Chief L3 
Officer. Both of them have worked with Carl Baldwin extensively and 
that can only be a guarantee of quality.


Cheers,
Armando

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


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


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

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

[Hirofumi Ichihara]

+1

On 2016/12/14 11:56, Kevin Benton wrote:

+1

On Dec 13, 2016 17:27, "Armando M." > wrote:


Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient
has helped moving a few efforts along in the right direction. I
would like to suggest we double down on core firepower for the
neutronclient repo alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but
also improve the number of folks who can effectively liasion with
the OSC team, and look after the needs of neutron's client repo.

Many thanks,
Armando

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


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (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] Stepping down from core

[Hirofumi Ichihara]

Hi Carl,

Your great work always helped Neutron community.
Thank you so much for all your help.

Hirofumi

On 2016/11/18 3:42, Carl Baldwin wrote:

Neutron (and Openstack),

It is with regret that I report that my work situation has changed 
such that I'm not able to keep up with my duties as a Neutron core 
reviewer, L3 lieutenant, and drivers team member. My participation has 
dropped off considerably since Newton was released and I think it is 
fair to step down and leave an opening for others to fill. There is no 
shortage of talent in Neutron and Openstack and I know I'm leaving it 
in good hands.


I will be more than happy to come back to full participation in 
Openstack and Neutron in the future if things change again in that 
direction. This is a great community and I've had a great time 
participating and learning with you all.


Well, I don't want to drag this out. I will still be around on IRC and 
will be happy to help out where I am able. Feel free to ping me.


Carl


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


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

Re: [openstack-dev] [Neutron] Retiring stale stadium projects

[Hirofumi Ichihara]

On 2016/09/28 10:18, Armando M. wrote:

Hi Neutrinos,

I wanted to double check with you the state of these following projects:

- networking-ofagent
I think that ofagent is ready for retirement. I have seen the 
declaration as "OFAgent is decomposed and deprecated in the Mitaka 
cycle." in Mitaka release note.



- python-neutron-pd-driver

It's my understanding that they are ready for retirement or 
thereabouts. Please confirm, and I'll kick off the countdown sequence [1].


Cheers,
Armando

[1] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project


__
OpenStack Development Mailing List (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 port status to error from l2 agent

[Hirofumi Ichihara]

The use-case is similar to the spec[1].

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

On 2016/08/22 15:48, Edan David wrote:


Hi all,

It seems today that the ml2 rpc API only supports reporting that a 
port is up\down,


There may be situations when the l2 agent can fail,

For example SR-IOV agent can report failure when configuring a port on 
the wrong physnet.


In these cases we should how would one report port failed status with 
the rpc messages?


Should we add a new rpc call?

Also it’s not clear to me why the documentation in the 
plugins/ml2/rpc.py file


States that the method ‘update_device_down’  function is: “Device no 
longer exists on agent”, when it stets the port status to down in 
admin_state_down.




__
OpenStack Development Mailing List (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] [searchlight] What do we need in notification payload?

[Hirofumi Ichihara]

Thank you for your quick reply.

On 2016/08/01 23:31, McLellan, Steven wrote:

In our (Searchlight's) ideal world, every notification about a resource
would contain the full representation of that resource (for instance,
equivalent to the API response for a resource), because it means that each
notification on its own can be treated as the current state at that time
without having to potentially handle multiple incremental updates to a
resource. That isn't the case at the moment in lots of places either for
historic reasons or because the implementation would be complex or
expensive.
It seems current neutron implementation just adds API response body into 
notification's payload. Therefore, in Neutron, the payload depends on 
each extension's implementation and it's not surely the full 
representation of that resource now.



With tags as an example, while I understand why that's the case (the API
treats tags as a separate entity and it's implemented as a separate
database table) it doesn't make a lot of logical sense to me to treat
adding a tag to a network as a separate event from (for instance) renaming
it. In both cases as far as a consumer of notifications is concerned, some
piece of information about the network changed. That said, it's obviously
up to each project how they generate notifications for events (and thanks
for taking this one on), and I understand why you don't want to add a huge
amount of complexity to the plugin code.

Thanks for summarizing main points. That's right.


One thing that would be useful is if adding a tag changes the resource's
'updated_at', and have that included in the notification. That allows us
to determine whether a notification is more up-to-date than a request at
some point in the near past to the API. I guess though that this will also
be difficult in terms of how the plugin interacts with the core code?
This is another point. I can understand your opinion. I will try to add 
'updated_at' into tag notification's payload in future. However, now tag 
and other extensions resources cannot be used with the 
feature(timestamp). I think that it's next step after implementing tag 
notification.


Thanks,
Hirofumi



Thanks,

Steve

On 8/1/16, 3:33 AM, "Hirofumi Ichihara" <ichihara.hirof...@lab.ntt.co.jp>
wrote:


Hi,

I'm trying to solve a issue[1, 2] which doesn't send a notification when
Tag is updated. I'm worried about the payload. My solution just outputs
added tag, resource type, and resource id as payload. However, there was
a comment which mentioned the payload should have more information. I
guess that it means, for instance, when we added a tag to a network, we
can accept the network's name, status, description, share, and so on as
notification payload.

If Tag plugin already has such information, I might not disagree the
opinion but the plugin doesn't have it now. So we will need to add
reading DB process to each Tag API for notification only. I wouldn't go
as far as to add such extra process.

Is my current solution enough information for searchlight or other
notification systems?

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

Thanks,
Hirofumi



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


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







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

[openstack-dev] [neutron] [searchlight] What do we need in notification payload?

[Hirofumi Ichihara]

Hi,

I'm trying to solve a issue[1, 2] which doesn't send a notification when  
Tag is updated. I'm worried about the payload. My solution just outputs  
added tag, resource type, and resource id as payload. However, there was  
a comment which mentioned the payload should have more information. I  
guess that it means, for instance, when we added a tag to a network, we  
can accept the network's name, status, description, share, and so on as  
notification payload.


If Tag plugin already has such information, I might not disagree the  
opinion but the plugin doesn't have it now. So we will need to add  
reading DB process to each Tag API for notification only. I wouldn't go  
as far as to add such extra process.


Is my current solution enough information for searchlight or other  
notification systems?


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

Thanks,
Hirofumi



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

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

[Hirofumi Ichihara]

I think that the implementation is complex for me and maybe reviewer.
Could you propose devref like vlan-aware-vms[1]?

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

Thanks,
Hirofumi

On 2016/06/24 18:10, Alonso Hernandez, Rodolfo wrote:


Hello:

Ichihara, thank you for your answer. It was just a test to find out 
how to setup correctly the egress traffic shaping. I was facing this 
situation and I found the problem: I was using bridges with 
datapath_type = netdev, instead of system. That was the main problem. 
Now I can correctly apply a QoS and a queue, and assign a traffic to 
this queue.


To avoid using veth between bridges, I’m implementing the following 
solution:


-Create a new queue for each min-qos rule applied to a port (the same 
min-qos rule could be applied to several ports, of course).


-Because ovs only shapes traffic in the egress direction (ovs point of 
view):


oCreate a qos policy for each port in br-int in the same network of 
the port to apply the qos; then assign the created queue to this qos 
policy.


oCreate a qos policy for the external port in br-tun, and then assign 
the queue


oCreate a qos policy for the external port for the br-phy in the same 
network, and assign the queue


-In br-int, table 0, enqueue all traffic going into ovs from the port 
with qos policy assigned to the queue created.


With this implementation, you don’t need to use veth and all traffic 
going from the port with the qos policy assigned to other VM or 
external port (physical bridge, tunnel) will be shaped. Of course, 
this implementation is a bit tangled, so please be gentle in the 
code-review.


Regards.

*From:*Hirofumi Ichihara [mailto:ichihara.hirof...@lab.ntt.co.jp]
*Sent:* Tuesday, June 21, 2016 10:27 AM
*To:* OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth 
assurance


On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote:

Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a
POC of this feature.

Scenario 1:

3 VM connected to br-int, sending traffic through br-physical to
other host (an external physical machine).

The first VM will have a min BW of 15 Mb. The physical port will
be limited to 20 Mb, so for VM2 and VM3 should be only 5 Mb of
available BW.

Those three VM are using iperf to inject traffic against the
external host.

A) One qos policy and queue is created at VM1 port (with
other_config:{min-rate=1500}). The traffic is not shapped.

B) Another qos policy and queue with this minimum BW is created at
int-phy-patchport. The traffic is not shapped.

C) Another qos policy and queue with this minimum BW is created at
phy-int-phy-patchport. The traffic is not shapped.

D) Another qos policy and queue with this minimum BW is created at
physical port. The traffic is still not shapped.

In OVS all traffic from VM1 is filtered to match the correct qos
and queues at the ports.

It seems that this scenario doesn't expect some scenarios like DVR and 
multiple NIC. I thought that the queue should be set in br-int with 
veth(instead of patch port) between br-int and bt-tun. However, I 
guess that this may occur a issue that traffic cannot turn back in 
br-int. That may happen in Scenario2 case.


Therefore, I think that we should set the queue to physical port but 
we have a problem how do we specify the NIC in some cases(vlan, vxlan, 
DVR mode router and DVR FloatingIP).




Scenario 2:

Similar to scenario 1, but using a fourth VM to act as server. In
this case, traffic only goes through br-int.

A) One qos policy and queue is created at VM1 port (with
other_config:{min-rate=1500}). The traffic is not shapped.

B) Another qos policy and queue with this minimum BW is created at
output port (VM4 server port). The traffic is still not shapped.



I think we cannot manage this case because we doesn't know MAX 
bandwidth of traffic in br-int and the bandwidth is usually enough.
We should focus our attention on a case that the traffic goes out to 
other nodes.


Thanks,
Hirofumi


I need some help with this implementation, because I’m running out
of time an ideas!

Thank you in advance.




__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance

[Hirofumi Ichihara]

On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote:


Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a POC 
of this feature.


Scenario 1:

3 VM connected to br-int, sending traffic through br-physical to other 
host (an external physical machine).


The first VM will have a min BW of 15 Mb. The physical port will be 
limited to 20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW.


Those three VM are using iperf to inject traffic against the external 
host.


A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.


B) Another qos policy and queue with this minimum BW is created at 
int-phy-patchport. The traffic is not shapped.


C) Another qos policy and queue with this minimum BW is created at 
phy-int-phy-patchport. The traffic is not shapped.


D) Another qos policy and queue with this minimum BW is created at 
physical port. The traffic is still not shapped.


In OVS all traffic from VM1 is filtered to match the correct qos and 
queues at the ports.


It seems that this scenario doesn't expect some scenarios like DVR and 
multiple NIC. I thought that the queue should be set in br-int with 
veth(instead of patch port) between br-int and bt-tun. However, I guess 
that this may occur a issue that traffic cannot turn back in br-int. 
That may happen in Scenario2 case.


Therefore, I think that we should set the queue to physical port but we 
have a problem how do we specify the NIC in some cases(vlan, vxlan, DVR 
mode router and DVR FloatingIP).




Scenario 2:

Similar to scenario 1, but using a fourth VM to act as server. In this 
case, traffic only goes through br-int.


A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.


B) Another qos policy and queue with this minimum BW is created at 
output port (VM4 server port). The traffic is still not shapped.



I think we cannot manage this case because we doesn't know MAX bandwidth 
of traffic in br-int and the bandwidth is usually enough.
We should focus our attention on a case that the traffic goes out to 
other nodes.


Thanks,
Hirofumi

I need some help with this implementation, because I’m running out of 
time an ideas!


Thank you in advance.



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


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

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

[Hirofumi Ichihara]

Thank you all!

I'm happy to be part of the Neutron core.
I will try my best helping Neutron project.

Thanks,
Hirofumi

On 2016/04/15 11:40, Akihiro Motoki wrote:

It's been over a week.
I'd like to welcome Hirofumi to the neutron core reviewer team!

Akihiro

2016-04-08 13:34 GMT+09:00 Akihiro Motoki <amot...@gmail.com>:

Hi Neutrinos,

As the API Lieutenant of Neutron team,
I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
Neutron core reviewer team mainly focuing on the API/DB area.

Hirofumi has been contributing neutron actively in the recent two
releases constantly.
He was involved in key features in API/DB areas in Mitaka such as
tagging support and network availability zones.
I believe his knowledge and involvement will be great addition to our team.
He have been reviewing constantly [1] and I expect he continue to work
for Newton or later.

Existing API/DB core reviews (and other Neutron core reviewers),
please vote +1/-1 for the addition of Hirofumi to the team.

Thanks!
Akihiro


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

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







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

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

[Hirofumi Ichihara]

On 2016/04/12 8:02, Kevin Benton wrote:
Oh right, I'm definitely for eliminating these values from Devstack 
and just telling people to use post-config. I was just hesitant about 
advocating for their removal from neutron.
Yeah, my point is eliminating useless options from Devstack since we can 
change them in post-config of local.conf if need.





On Mon, Apr 11, 2016 at 3:55 PM, Brandon Logan 
<brandon.lo...@rackspace.com <mailto:brandon.lo...@rackspace.com>> wrote:


On Mon, 2016-04-11 at 15:30 -0700, Kevin Benton wrote:
> >[1]:

https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178
> >[2]:
https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166
>
>
> This is a Nova option to decide how long to wait for Neutron to
> callback before considering a port failed to be wired. The time this
> will take will depend quite a bit on how heavily loaded the
system is.
> We can certainly try to get rid of it, but it means that we have to
> force assumptions about how quickly a system should give up waiting
> for wiring. It would be similar to getting rid of the option to
choose
> a timeout value for the API clients.
>
>
>
> >[3]:

https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162
> >[4]:

https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53
>
>
> Neutron does not need to be deployed with keystone. This is how you
> disable it. Some operators do not have Neutron exposed to tenants so
> keystone is stripped away for performance since the only things
> communicating with Neutron are internal trusted services.

This is correct. In a large deployment the number of requests going to
keystone dramatically affects performance.  Do you think this needs to
be a devstack config option though?  I kind of don't think it does for
no better reason than it's easy to just change the option in the
neutron.conf and restart.

>
> On Mon, Apr 11, 2016 at 12:42 PM, Hirofumi Ichihara
> <ichihara.hirof...@lab.ntt.co.jp
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:
> I agree. Throughout I was reviewing Devstack over 3 cycles,
> I thought the same thing. Devstack often accepted
patches just
> adding option although we're not sure who really needs the
> options.
> There are many useless stuff in the options.
> For example, default value of devstack option is the same
> value as
> default in Projects. Please look at [1] and [2], [3] and
[4].
> Who uses these options?
>
> We can see such options in devstack throughout. I agree we
> will adjust default configurations and
> that documents in Neutron side. However, let's eliminate
such
> options are clearly useless first.
> And then we should do after we made necessary options clear.
>
> [1]:
>

https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178
> [2]:
>
https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166
> [3]:
>

https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162
> [4]:
>

https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53
>
> Thanks,
> Hirofumi
>
>
> On 2016/04/09 0:07, Sean M. Collins wrote:
> Prior to the introduction of local.conf, the
only way
> to configure
> OpenStack components was to introduce code directly
> into DevStack, so
> that DevStack would pick it up then inject it
into the
> configuration
> file.
>
> This was because DevStack writes out new
configuration
> files on each
> run, so it wasn't possible for you to make
changes to
> any configuration
> file (nova.conf, neutron.conf, ml2_plugin.ini,
etc..).
>
> So, someone who wanted to set the Linux Bridge
Agent's
> physical_interface_mappings setting for Neutron
would
> have to use
> $LB_INTERFACE_MAPPINGS in DevStack, which would then
> be invoked by
> DevStack[1].
>
> The local.c

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

[Hirofumi Ichihara]

I agree. Throughout I was reviewing Devstack over 3 cycles,
I thought the same thing. Devstack often accepted patches just
adding option although we're not sure who really needs the options.
There are many useless stuff in the options.
For example, default value of devstack option is the same value as
default in Projects. Please look at [1] and [2], [3] and [4]. Who uses 
these options?


We can see such options in devstack throughout. I agree we will adjust 
default configurations and
that documents in Neutron side. However, let's eliminate such options 
are clearly useless first.

And then we should do after we made necessary options clear.

[1]: 
https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178
[2]: 
https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166
[3]: 
https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162
[4]: 
https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53


Thanks,
Hirofumi

On 2016/04/09 0:07, Sean M. Collins wrote:

Prior to the introduction of local.conf, the only way to configure
OpenStack components was to introduce code directly into DevStack, so
that DevStack would pick it up then inject it into the configuration
file.

This was because DevStack writes out new configuration files on each
run, so it wasn't possible for you to make changes to any configuration
file (nova.conf, neutron.conf, ml2_plugin.ini, etc..).

So, someone who wanted to set the Linux Bridge Agent's
physical_interface_mappings setting for Neutron would have to use
$LB_INTERFACE_MAPPINGS in DevStack, which would then be invoked by
DevStack[1].

The local.conf functionality was introduced quite a while back, and
I think it's time to have a conversation about why we should start
moving away from the previous practice of declaring variables in
DevStack, and then having them injected into the configuration files.

The biggest issue is: There is a disconnect between the developers
using DevStack and someone who is an operator or who has been editing
OpenStack conf files directly. So, for example I can tell you all about
how DevStack has a bunch of variables for configuring Neutron (which is
Not a Good Thing™), and how those go into DevStack and then end up coming
out the other side in a Neutron configuration file.

Really, I would like to get rid of the intermediate layer (DevStack)
and get both Devs and Deployers to be able to just say: Here's my
neutron.conf - let's diff mine and yours and see what we need to sync.

Matt Kassawara and I have had this issue, since he's coming from the
OSAD side, and I'm coming from the DevStack side. We both know what the
Neutron configuration should end up as, but DevStack having its own set
of variables and how those variables are handled and eventually rendered
as a Neutron config file makes things more difficult than it needs to
be, since Matt has to now go and learn about how DevStack handles all
these Neutron specific variables.

The Neutron refactor[2] that I am working on, I am trying to configure
as little as possible in DevStack. Neutron should be able to, out of the
box, Just Work™. If it can't, then that needs to be fixed in Neutron.

Secondly, the Neutron refactor will be getting rid of all the things
like $LB_INTERFACE_MAPPINGS - I would *much* prefer that someone using
DevStack actually set the apropriate line in their local.conf

Such as:

 [[post-config|/$Q_PLUGIN_CONF_FILE]]
 [linux_bridge]
 physical_interface_mappings = foo:bar


The advantage of this is, when someone is working with DevStack, the
things they are configuring are the same as all the other OpenStack 
documentation.

For example, someone could read the Networking Guide, read the example
configuration[3] and the only thing they'd need to learn is our syntax
for specifying what file the contents go in (the 
"[[post-config|/$Q_PLUGIN_CONF_FILE]]" piece).

Thoughts?

[1]: 
https://github.com/openstack-dev/devstack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/lib/neutron_plugins/linuxbridge_agent#L63

[2]: https://review.openstack.org/168438

[3]: 
http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration






__
OpenStack Development Mailing 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] [magnum][neutron] AttributeError: 'str' object has no attribute 'strftime'

[Hirofumi Ichihara]

On 2016/04/08 12:10, Kevin Benton wrote:

Try depending on I2a10a8f15cdd5a144b172ee44fc3efd9b95d5b7e

I tried. Let's wait for the result.




On Thu, Apr 7, 2016 at 8:02 PM, Hongbin Lu > wrote:




> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com
]
> Sent: April-07-16 12:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][neutron] AttributeError: 'str'
> object has no attribute 'strftime'
>
> Hongbin Lu > wrote:
>
> > Hi all,
> > Magnum gate recently broke with error: “AttributeError: 'str'
object
> > has no attribute 'strftime'” (here is a full log [1]). I would
like
> to
> > confirm if there is a recent commit in Neutron that causes the
> breakage.
> > If yes, a quick fix is greatly appreciated.
> >
> > [1]
> > http://logs.openstack.org/91/301891/1/check/gate-functional-dsvm-
> magnu
> > m-api/ea0d4ba/logs/screen-q-lbaas.txt.gz
> >
>
> The fix should be: https://review.openstack.org/#/c/302904/

This patch doesn't resolve the problem. I depends on the patch and
re-ran the tests [1], but the tests still failed with the same
error [2].

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

http://logs.openstack.org/79/303179/1/check/gate-functional-dsvm-magnum-k8s/711813d/logs/screen-q-lbaas.txt.gz#_2016-04-08_02_19_30_027

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

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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


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

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

[Hirofumi Ichihara]

On 2016/04/05 22:23, Ihar Hrachyshka wrote:

Hirofumi Ichihara <ichihara.hirof...@lab.ntt.co.jp> wrote:


Hi Ihar,

On 2016/04/05 7:57, Ihar Hrachyshka wrote:

Hi all,

in neutron, we have a bunch of configuration options to control 
advanced filtering features for API, f.e. allow_sorting, 
allow_pagination, allow_bulk, etc. Those options have default False 
values.
I saw allow_bulk option is set default True in 
https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L66

Well, I don't think there's someone sets False to the option.


Yes, indeed only allow_sorting and allow_pagination are disabled by 
default.




In the base API controller class, we have support for both native 
sorting/pagination/bulk operations [implemented by the plugin 
itself], as well as a generic implementation for plugins without 
native support. But if corresponding allow_* options are left with 
their default False values, those advanced search/filtering criteria 
just don’t work, no matter whether the plugin support native 
filters, or not.


It seems weird to me that our API behaves differently depending on 
configuration options, and that we have those useful features 
disabled by default.


My immediate interest is to add native support for 
sorting/pagination for QoS service plugin; I have a patch for that, 
and I planned to add some API tests to validate that the features 
work, but I hit failures because those features are not enabled for 
the -api job.


Some questions:
- can we enable those features in -api job?
- is there any reason to keep default values for allow_* as False, 
and if not, can we switch to True?
- why do we even need to control those features with configuration 
options? can we deprecate and remove them?
I agree we will deprecate and remove the option but I think that we 
need more tests if we support it as default.

It looks like there are very few tests(UT only).


That’s a good suggestion. I started a patch to enable those two 
options, plus add first tests for the feature:


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

For now it covers only for networks. I wonder how we envision the 
coverage. Do we want to have test cases per resource? Any ideas on how 
to make the code more generic to avoid code duplication? For example, 
I could move those test cases into a base class that would require 
some specialization for each resource that we want to cover 
(get/create methods, primary key, …).
The patch is reasonable for me as first step. Second, I agree to make it 
more generic. I think that we should have test per resource but we will 
do in future work.




Also, do we maybe want to split the patch into two pieces:
- first one adding tests [plus enabling those features for API job];
- second one changing the default value for the options.

+1

Thanks,
Hirofumi



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][api] advanced search criteria

[Hirofumi Ichihara]

Hi Ihar,

On 2016/04/05 7:57, Ihar Hrachyshka wrote:

Hi all,

in neutron, we have a bunch of configuration options to control 
advanced filtering features for API, f.e. allow_sorting, 
allow_pagination, allow_bulk, etc. Those options have default False 
values.
I saw allow_bulk option is set default True in 
https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L66

Well, I don't think there's someone sets False to the option.



In the base API controller class, we have support for both native 
sorting/pagination/bulk operations [implemented by the plugin itself], 
as well as a generic implementation for plugins without native 
support. But if corresponding allow_* options are left with their 
default False values, those advanced search/filtering criteria just 
don’t work, no matter whether the plugin support native filters, or not.


It seems weird to me that our API behaves differently depending on 
configuration options, and that we have those useful features disabled 
by default.


My immediate interest is to add native support for sorting/pagination 
for QoS service plugin; I have a patch for that, and I planned to add 
some API tests to validate that the features work, but I hit failures 
because those features are not enabled for the -api job.


Some questions:
- can we enable those features in -api job?
- is there any reason to keep default values for allow_* as False, and 
if not, can we switch to True?
- why do we even need to control those features with configuration 
options? can we deprecate and remove them?
I agree we will deprecate and remove the option but I think that we need 
more tests if we support it as default.

It looks like there are very few tests(UT only).

Thanks,
Hirofumi



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]: Neutron naming legal issues

[Hirofumi Ichihara]

We should go back to our roots so it's better to rename "Neutron" to 
"Nova Network".


Thanks,
Hirofumi

On 2016/04/01 15:24, Akihiro Motoki wrote:

IIRC 'Quantum' was renamed to 'Neutron' due to the trademark issue.
I don't think reverting it to 'Quantum' resolves the issue.
When we chose a new name, the foundation checked the legal/trademark issue,
so I think it is better to contact the OpenStack foundation or discuss
it in the legal-discuss ML.

"Newton" release of "neutron" is confusing though :(

Akihiro

2016-04-01 14:46 GMT+09:00 Jimmy Akin :

Dear Neutrinos,

We've been following the project for quite some time.
To our satisfaction the project seems to have done well; the base line of
features that were available to the networking component of OpenStack
(then nova-network) has grown quite a bit and seem to have gained a
successful momentum with the communities, both development and
operators.

However, Neutron appears to be a trademarked name [1], and after thoroughly
discussing the issue with our and Marvel' legal departments
both sides have reached the conclusion that a naming scheme is an obligatory
amendment and unfortunately is the only viable option.

An obvious resolution to this issue is reverting the old "Quantum" name
back.
However, this is subject to change and review from the PTL and as such,
we'll shortly propose a relevant change to the review system.
We anticipate the review process to be be swift, to avoid further legal
implications.

Sincerely,
Jimmy J. Akin,
CIO,John F. Kennedy Space Center.

[1] https://en.wikipedia.org/wiki/Neutron_(Marvel_Comics)


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

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







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

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

[Hirofumi Ichihara]

Hi Gary,

You can look at the discussion in here[1, 2]

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

Thanks,
Hirofumi

On 2016/03/28 15:36, Gary Kotton wrote:

Hi,
In the M cycle BGP support was added in tree. I have seen specs in the 
L2 GW project for this support too. Are we planning to consolidate the 
efforts? Will the BGP code be moved from the Neutron git to the L2-GW 
project? Will a new project be created?
Sorry, a little in the dark here and it would be nice if someone could 
please provide some clarity here. It would be a pity that there were 
competing efforts and my take would be that the Neutron code would be 
the single source of truth (until we decide otherwise).
I think that the L2-GW project would be a very good place for that 
service code to reside. It can also have MPLS etc. support. So it may 
be a natural fit.

Thanks
Gary


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


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

Re: [openstack-dev] [Neutron][python-neutronclient] Adding new options to the existing Neutron CLIs

[Hirofumi Ichihara]

Hi reedip,

On 2016/03/18 12:06, reedip banerjee wrote:

Dear All Neutron Developers and Reviewers,

I have a query/concern related to the parsing of options in 
python-neutronclient.
I would like to bring this up, as it "may" also impact the transition 
of the CLIs to the openstack client as well.


NeutronClient is pretty special in its behavior, and has one pretty 
powerful feature of parsing extra options. This feature states that, 
if the CLI does not support an option but the API does, and the user 
passes a value for this option, then the "unsupported" CLI option is 
parsed , and forwarded to the Neutron Server for processing.


Example:
Currently "neutron net-create" does not support --router:external. If 
you see the output of "neutron net-create -h" you would not find 
"--router-external". However, this option is supported in the API 
since Juno [2]. So therefore , if a user executes the following CLI

/" neutron net-create TestNetwork --router-external" /

then [1] would be observed as an output.

Now the query/concern comes next
Any option which is not supported by the CLI is open to the above parsing.
Therefore , for net-create and net-update, all the following are possible:

/neutron net-create --router:external=True TESTNetwork --(A)
/
/neutron net-create --router:external TESTNetwork  --(B)//
/
/neutron net-create //TESTNetwork //--router:external //--(C)/
/neutron net-create //TESTNetwork //--router:external=True //--(D)//
/
/neutron net-create //TESTNetwork //--router:external True //--(E)//
/

However, user is not aware of the --router:external option because it 
is not visible in the HELP section ( this is true for other CLI 
options as well).


In order to demonstrate these options to the User, we have to update 
add_known_arguments function to display them. And once they are known 
to the CLI, the parsing changes, and some of the options from (A) to 
(E) may not be supported ( Please see [3] for an ongoing, though now 
dormant, discussion ).


Note that this discussion is not limited only to net-create, but 
possibly other CLIs as well which do not completely expose the Options 
which the API can support.I am , however, taking the/net-create/ 
example as a case-study.


I would like to know how we can move forward in this regards:

-- Should NeutronClient continue to support all options from (A) to 
(E), but deprecate some of them in Openstack Client?


-- Should we deprecate them in NeutronClient itself, so that the users 
are comfortable with the options when the migration to Openstack 
Client occurs?




IMO, we shouldn't support various methods to manage resources because I 
don't believe community keep maintaining all of them forever. It will 
collapse someday. We will have periods(two cycle?) for deprecation and 
then we should remove them from NeutronClient itself.


Thanks,
Hirofumi


-- Any other suggestions

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

[2]: 
http://docs.openstack.org/juno/install-guide/install/apt/content/neutron_initial-external-network.html


[3]: https://review.openstack.org/#/c/137279/

--
Thanks and Regards,
Reedip Banerjee
IRC: reedip






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


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

Re: [openstack-dev] [neutron]Where did the flows go in ovs bridge?

[Hirofumi Ichihara]

Which version did you use? Neutron had the issue once.

On 2016/03/13 10:54, Zhi Chang wrote:

hi, guys.

I deployed DVR in my local environment by following  this 
document(https://wiki.openstack.org/wiki/Neutron/DVR).  And I have 
three compute nodes which running DVR l3-agent and two network nodes 
which running DVR_SNAT l3-agent.


I created a vm in one of the computes nodes. And flows was 
generated normally. But, all flows are gone when I  restart 
"neutron-openvswitch-agent"!. I wait a few minutes but I can't see any 
flows were generated.


Could someone tell me why the flows are gone and they can't 
generated anymore?



Thanks
Zhi Chang



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


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

Re: [openstack-dev] [Neutron] DocImpact flag: a kind reminder

[Hirofumi Ichihara]

On 2016/03/01 9:00, Armando M. wrote:



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


Hi Armando,

I didn't know and I have such patch now.
Thank you for your message.

I have seen that neutron spec has the flag in the Commit Message.
In such case, we don't need to add the flag into the
implementation patch, do we?


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

I agree with you.



Thanks,
Hirofumi


On 2016/03/01 7:18, Armando M. wrote:

Hi Neutrinos,

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

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

Cheers,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080294.html
[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/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




__
OpenStack Development Mailing List (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] DocImpact flag: a kind reminder

[Hirofumi Ichihara]

Hi Armando,

I didn't know and I have such patch now.
Thank you for your message.

I have seen that neutron spec has the flag in the Commit Message.
In such case, we don't need to add the flag into the implementation 
patch, do we?


Thanks,
Hirofumi

On 2016/03/01 7:18, Armando M. wrote:

Hi Neutrinos,

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


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


Cheers,
Armando

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

[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc


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


__
OpenStack Development Mailing 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] [api][neutron] question on putting an existing tag

[Hirofumi Ichihara]

I'm considering the tag implementation in neutron.
Although I proposed server returns 409 in tag existing case, on the 
basis of the above discussion, server should return the same response code.

I will change current implementation to returning 201.

Thanks,
Hirofumi

On 2016/02/27 2:24, Akihiro Motoki wrote:

2016-02-27 1:02 GMT+09:00 Sean Dague :

On 02/26/2016 10:52 AM, Chris Dent wrote:

On Fri, 26 Feb 2016, Jay Pipes wrote:

On 02/26/2016 09:02 AM, Akihiro Motoki wrote:

We can create a tag by PUT'ing an individual tag:
What status code should be returned if a requested tag already exists?

PUT /servers/1234567890/tags/qux

The guideline defines 201 (+ Location header) on success.
In the current neutron implementation proposed, 409 is returned
when a requested tag already exists.

409 Conflict.

/me gets some paint

Stricly speaking, PUT should be idempotent so every time you put a
qux tag on 123456789 it should return (the same) 2xx.

In the real world things get messy and some implementations return
201 on create and some other 2xx when it is already there. It
shouldn't be an error though.

The time a 409 might be reasonable is if via a header, like an ETag,
we have declared that qux must have a certain state before we accept
a PUT of it.

In some implementations things like 'Etag: 0' are used to say "Only
let this PUT happen if it is a create." That's a bit of a hack but
is useful.

Agree. PUT is an update. The should be no issue updating an existing
tag. That should be success

Thanks. I agree PUT should be success in general.
Honestly I am confused with a situation that a tag is created by PUT
(not by POST)
and applied the semantics around POST to PUT case.


Adding a tag should really be semantically:

POST /servers/1234567890/tags

to create tags and

PUT /servers/1234567890/tags/qux to update them

The above combination of POST and PUT is really easy to understand to me.

Do we need to use POST to create a new tag,
or can we keep using PUT to create a tag?

If we keep using PUT, what status code should be returned?
201 Created is now returned for PUT operation.
Is it okay to return 201 even when a tag already exists?


You should not PUT to any url that you can't GET. And it looks like GET
/servers/1234567890/tags/qux would be a 404 here.

Yes, I totally agree.

Akihiro


 -Sean

--
Sean Dague
http://dague.net

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

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







__
OpenStack Development Mailing 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] documenting configuration option segregation between services and agents

[Hirofumi Ichihara]

On 2016/02/08 18:17, Ihar Hrachyshka wrote:

Kevin Benton  wrote:


Propose it as a devref patch!


+1. Has it happened already?

Here https://review.openstack.org/#/c/275381/






On Wed, Jan 27, 2016 at 12:30 PM, Dustin Lundquist 
 wrote:
We should expand services_and_agents devref to describe how and why 
configuration options should be segregated between services and 
agents. I stumbled into this recently while trying to remove a 
confusing duplicate configuration option [1][2][3]. The present 
separation appears to be 'tribal knowledge', and not consistently 
enforced. So I'll take a shot at explaining the status quo as I 
understand it and hopefully some seasoned contributors can fill in 
the gaps.


=BEGIN PROPOSED DEVREF SECTION=
Configuration Options
-

In addition to database access, configuration options are segregated 
between neutron-server and agents. Both services and agents may load 
the main neutron.conf since this file should contain the Oslo message 
configuration for internal Neutron RPCs and may contain host specific 
configuration such as file paths. In addition neutron.conf contains 
the database, keystone and nova credentials and endpoints strictly 
for use by neutron-server.


In addition neutron-server may load a plugin specific configuration 
file, yet the agents should not. As the plugin configuration is 
primarily site wide options and the plugin provides the persistence 
layer for Neutron, agents should instructed to act upon these values 
via RPC.


Each individual agent may have its own configuration file. This file 
should be loaded after the main neutron.conf file, so the agent 
configuration takes precedence. The agent specific configuration may 
contain configurations which vary between hosts in a Neutron 
deployment such as the external_network_bridge for a L3 agent. If any 
agent requires access to additional external services beyond the 
Neutron RPC, those endpoints should be defined in the agent specific 
configuration file (e.g. nova metadata for metadata agent).



==END PROPOSED DEVREF SECTION==

Disclaimers: this description is informed my by own experiences 
reading existing documentation and examining example configurations 
including various devstack deployments. I've tried to use RFC style 
wording: should, may, etc.. I'm relatively confused on this subject, 
and my goal in writing this is to obtain some clarity myself and 
share it with others in the form of documentation.



[1] https://review.openstack.org/262621
[2] https://bugs.launchpad.net/neutron/+bug/1523614
[3] https://review.openstack.org/268153

__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton
__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__ 


OpenStack Development Mailing List (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

[Hirofumi Ichihara]

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?





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

>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 Is it just me, or when you use .ics file from eavesdrop, it
says the
 meeting is today?

 http://eavesdrop.openstack.org/calendars/neutron-team-meeting.ics

 Is it the same issue as described in:



http://lists.openstack.org/pipermail/openstack-dev/2015-December/082902.html

 and that is suggested to fix by readding your events from
updated .ics
 file:



http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html

 Ihar



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

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

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

Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

On 2015/12/16 17:16, Kevin Benton wrote:
What will the availability zones API tell the user about the zones? 
Are they just opaque strings that the user doesn't really understand?

They shows available zones in the time.



What I'm a little worried about is that it seems like we are having 
the user doing the work of the scheduler.
I understand your worry. However, I think that AZ feature includes a use 
case that users can specify zone which their resource is scheduled.




Is this is for getting affinity or anti-affinity with resources for 
another network? If so, why not just have the user explicitly say in 
the API request 'anti-affinity=network_id' or 'affinity=network_id'. 
Then the scheduler would use the zones info to either place resources 
on a different zone or the same zone, depending on which was requested.



I like it. But we may have other issues, for example,

1. We have NW1(with anti-affinity=NW2) and NW2(with anti-affinity=NW1)
2. We delete NW1 and then create NW3(with anti-affinity=NW2) instead of NW1
3. NW2(with anti-affinity=NW1) is rescheduled because of some reasons
4. Neutron cannot find NW1 in anti-affinit of NW2. How does neutron also 
schedule NW2 to a zone which doesn't have NW3?


Of course, we can find a way of solving this issue itself. But the 
similar issue may happen.


I think that we must remove the filed if it always happens performance 
issue.
However, we should find out another solution for the issue as long as 
there are use cases that are needed by operators and users.


On Sun, Dec 13, 2015 at 11:25 PM, Hirofumi Ichihara 
<ichihara.hirof...@lab.ntt.co.jp 
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:




On 2015/12/14 15:58, Kevin Benton wrote:

What decision would lead the user to request AZ1 and AZ2 in the
first place? Especially since when it fails to get AZ2, they just
request again with AZ1 and AZ3 instead.

I expected that user gets AZ1 and AZ2 (and AZ3) via GET
Availability zones API first. There is a gap between the time user
threw and the time his resource is scheduled. After user threw API
request with AZ1 and AZ2, if all agents of AZ2 are dead before
scheduling, the resource is scheduled in AZ1 only.





On Sun, Dec 13, 2015 at 10:31 PM, Hirofumi Ichihara
<ichihara.hirof...@lab.ntt.co.jp
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:



On 2015/12/14 14:52, Kevin Benton wrote:

I see, so regular users are supposed to use this information
as well. But how are they supposed to use it? For example,
if they see that their network has availability zones 1 and
4, but their instance is hosted in zone 3, what are they
supposed to do?

I don't think that there is what they should do in the case
because Neutron AZ is different from Nova AZ. For example,
there may be a case like the following.

1. User throws POST Network API and Subnet API with
availability_zone_hints [AZ1, AZ2]
2. Neutron server tries to schedule the resource on both AZ1
and AZ2 but the resource are scheduled on AZ1 only by some
reasons
3. User confirms via GET Network API where his resource is
hosted and he knows it's AZ1 only
4. User also can know AZ is ready via GET Availability zones
API: AZ1, AZ3
5. User deletes previous resource and he recreates his
resource with availability_zone_hints [AZ1, AZ3]




On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara
<ichihara.hirof...@lab.ntt.co.jp
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:

Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the
network API that shows the availability zones of a
network. This caused a pretty big performance impact to
get_networks calls because it resulted in a database
lookup for every network.[1]

I already put a patch up to join the information ahead
of time in the network model.[2]

I agree with your suggestion. I believe that the patch
can solve the performance issue.


However, before we go forward with that, I think we
should consider the removal of that field from the API.

Having to always join to the DHCP agents table to
lookup which zones a network has DHCP agents on is
expensive and is duplicating information available with
other API calls.

Additionally, the field is just called
'availability_zones' but it's being derived solely from
AZ definitions in DHCP agent bindings for that network.
To me that doesn't represent where the network is
available, it just says which zones its scheduled DHCP

Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the network API that 
shows the availability zones of a network. This caused a pretty big 
performance impact to get_networks calls because it resulted in a 
database lookup for every network.[1]


I already put a patch up to join the information ahead of time in the 
network model.[2]
I agree with your suggestion. I believe that the patch can solve the 
performance issue.


However, before we go forward with that, I think we should consider 
the removal of that field from the API.


Having to always join to the DHCP agents table to lookup which zones a 
network has DHCP agents on is expensive and is duplicating information 
available with other API calls.


Additionally, the field is just called 'availability_zones' but it's 
being derived solely from AZ definitions in DHCP agent bindings for 
that network. To me that doesn't represent where the network is 
available, it just says which zones its scheduled DHCP instances live 
in. If that's the purpose, then we should just be using the DHCP agent 
API for this info and not impact the network API.

I don't think so. I have three points.

1. Availability zone is implemented in just a case with Agent now, but 
it's reference implementation. For example, we should expect that 
availability zone will be used by plugin without agent.


2. In users view, availability zone is related to network resource. On 
the other hand, users doesn't need to consider Agent or operators 
doesn't like to enable users to do in the first place. So I don't agree 
with using Agent API.


3. We should consider whether users want to know the field. Originally, 
the field doesn't exist in Spec[3] but I added it according with 
reviewer's opinion(maybe Akihiro?). This is about discussion of use 
case. After users create resources via API with availability_zone_hints 
so that they achieve HA for their service, they want to know which zones 
are their resources hosted on because their resources might not be 
distributed on multiple availability zones by any reasons. In the case, 
they need to know "availability_zones" for the resources via Network API.


Thanks,
Hirofumi

[3]: https://review.openstack.org/#/c/169612/31



Thoughts?

1. https://bugs.launchpad.net/neutron/+bug/1525740
2. https://review.openstack.org/#/c/257086/

--
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] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

On 2015/12/14 15:58, Kevin Benton wrote:
What decision would lead the user to request AZ1 and AZ2 in the first 
place? Especially since when it fails to get AZ2, they just request 
again with AZ1 and AZ3 instead.
I expected that user gets AZ1 and AZ2 (and AZ3) via GET Availability 
zones API first. There is a gap between the time user threw and the time 
his resource is scheduled. After user threw API request with AZ1 and 
AZ2, if all agents of AZ2 are dead before scheduling, the resource is 
scheduled in AZ1 only.





On Sun, Dec 13, 2015 at 10:31 PM, Hirofumi Ichihara 
<ichihara.hirof...@lab.ntt.co.jp 
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:




On 2015/12/14 14:52, Kevin Benton wrote:

I see, so regular users are supposed to use this information as
well. But how are they supposed to use it? For example, if they
see that their network has availability zones 1 and 4, but their
instance is hosted in zone 3, what are they supposed to do?

I don't think that there is what they should do in the case
because Neutron AZ is different from Nova AZ. For example, there
may be a case like the following.

1. User throws POST Network API and Subnet API with
availability_zone_hints [AZ1, AZ2]
2. Neutron server tries to schedule the resource on both AZ1 and
AZ2 but the resource are scheduled on AZ1 only by some reasons
3. User confirms via GET Network API where his resource is hosted
and he knows it's AZ1 only
4. User also can know AZ is ready via GET Availability zones API:
AZ1, AZ3
5. User deletes previous resource and he recreates his resource
with availability_zone_hints [AZ1, AZ3]




On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara
<ichihara.hirof...@lab.ntt.co.jp
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:

Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the network
API that shows the availability zones of a network. This
caused a pretty big performance impact to get_networks calls
because it resulted in a database lookup for every network.[1]

I already put a patch up to join the information ahead of
time in the network model.[2]

I agree with your suggestion. I believe that the patch can
solve the performance issue.


However, before we go forward with that, I think we should
consider the removal of that field from the API.

Having to always join to the DHCP agents table to lookup
which zones a network has DHCP agents on is expensive and is
duplicating information available with other API calls.

Additionally, the field is just called 'availability_zones'
but it's being derived solely from AZ definitions in DHCP
agent bindings for that network. To me that doesn't
represent where the network is available, it just says which
zones its scheduled DHCP instances live in. If that's the
purpose, then we should just be using the DHCP agent API for
this info and not impact the network API.

I don't think so. I have three points.

1. Availability zone is implemented in just a case with Agent
now, but it's reference implementation. For example, we
should expect that availability zone will be used by plugin
without agent.

2. In users view, availability zone is related to network
resource. On the other hand, users doesn't need to consider
Agent or operators doesn't like to enable users to do in the
first place. So I don't agree with using Agent API.

3. We should consider whether users want to know the field.
Originally, the field doesn't exist in Spec[3] but I added it
according with reviewer's opinion(maybe Akihiro?). This is
about discussion of use case. After users create resources
via API with availability_zone_hints so that they achieve HA
for their service, they want to know which zones are their
resources hosted on because their resources might not be
distributed on multiple availability zones by any reasons. In
the case, they need to know "availability_zones" for the
resources via Network API.

Thanks,
Hirofumi

[3]: https://review.openstack.org/#/c/169612/31



Thoughts?

1. https://bugs.launchpad.net/neutron/+bug/1525740
2. https://review.openstack.org/#/c/257086/

-- 
Kevin Benton




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

Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field

[Hirofumi Ichihara]

On 2015/12/14 14:52, Kevin Benton wrote:
I see, so regular users are supposed to use this information as well. 
But how are they supposed to use it? For example, if they see that 
their network has availability zones 1 and 4, but their instance is 
hosted in zone 3, what are they supposed to do?
I don't think that there is what they should do in the case because 
Neutron AZ is different from Nova AZ. For example, there may be a case 
like the following.


1. User throws POST Network API and Subnet API with 
availability_zone_hints [AZ1, AZ2]
2. Neutron server tries to schedule the resource on both AZ1 and AZ2 but 
the resource are scheduled on AZ1 only by some reasons
3. User confirms via GET Network API where his resource is hosted and he 
knows it's AZ1 only

4. User also can know AZ is ready via GET Availability zones API: AZ1, AZ3
5. User deletes previous resource and he recreates his resource with 
availability_zone_hints [AZ1, AZ3]




On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara 
<ichihara.hirof...@lab.ntt.co.jp 
<mailto:ichihara.hirof...@lab.ntt.co.jp>> wrote:


Hi Kevin,

On 2015/12/14 11:10, Kevin Benton wrote:

Hi all,

The availability zone code added a new field to the network API
that shows the availability zones of a network. This caused a
pretty big performance impact to get_networks calls because it
resulted in a database lookup for every network.[1]

I already put a patch up to join the information ahead of time in
the network model.[2]

I agree with your suggestion. I believe that the patch can solve
the performance issue.


However, before we go forward with that, I think we should
consider the removal of that field from the API.

Having to always join to the DHCP agents table to lookup which
zones a network has DHCP agents on is expensive and is
duplicating information available with other API calls.

Additionally, the field is just called 'availability_zones' but
it's being derived solely from AZ definitions in DHCP agent
bindings for that network. To me that doesn't represent where the
network is available, it just says which zones its scheduled DHCP
instances live in. If that's the purpose, then we should just be
using the DHCP agent API for this info and not impact the network
API.

I don't think so. I have three points.

1. Availability zone is implemented in just a case with Agent now,
but it's reference implementation. For example, we should expect
that availability zone will be used by plugin without agent.

2. In users view, availability zone is related to network
resource. On the other hand, users doesn't need to consider Agent
or operators doesn't like to enable users to do in the first
place. So I don't agree with using Agent API.

3. We should consider whether users want to know the field.
Originally, the field doesn't exist in Spec[3] but I added it
according with reviewer's opinion(maybe Akihiro?). This is about
discussion of use case. After users create resources via API with
availability_zone_hints so that they achieve HA for their service,
they want to know which zones are their resources hosted on
because their resources might not be distributed on multiple
availability zones by any reasons. In the case, they need to know
"availability_zones" for the resources via Network API.

Thanks,
Hirofumi

[3]: https://review.openstack.org/#/c/169612/31



Thoughts?

1. https://bugs.launchpad.net/neutron/+bug/1525740
2. https://review.openstack.org/#/c/257086/

-- 
Kevin Benton



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


__
OpenStack Development Mailing 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 Social Meetup in Tokyo

[Hirofumi Ichihara]

Although the restaurant is announced, the place is hard to go for us.
I and Akihiro will take you to the place.
Please gather in registration hall at 6:30.
Don’t mind about RSVP. You can come freely.

IMPORTANT THING: Don’t leave your wallet. We don’t have sponsor ;)


> On 2015/10/27, at 15:07, Takashi Yamamoto  wrote:
> 
> hi,
> 
> On Tue, Oct 27, 2015 at 10:31 AM, Sukhdev Kapur  > wrote:
>> Hey Akihiro,
>> 
>> Thanks for arranging this. I did not see any link to RSVP.
>> I would love to attend this event - please add me to the list.
> 
> at this point just go to the venue is fine.
> 
> here's a RSVP link in case you still want to register for some reason.
> http://neutrontokyo.app.rsvpify.com/ 
> 
>> 
>> Thanks
>> -Sukhdev
>> 
>> 
>> On Fri, Oct 23, 2015 at 9:23 AM, Akihiro Motoki  wrote:
>>> 
>>> Hi Neutron folks,
>>> 
>>> We are pleased to announce Neutron social meet-up in Tokyo.
>>> Thanks Takashi and Hirofumi for the big help.
>>> 
>>> I hope many of you will be there and enjoy the time.
>>> If you have made RSVP, don't miss it!
>>> We recommend  to join the beginning, but come and join us even if you
>>> arrive late.
>>> 
>>> 
>>> 
>>> Thursday, Oct 29 19:00-22:00
>>> Hokkaido (北海道 品川インターシティー店)
>>> 
>>> Location:
>>> 
>>> https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0=sharing
>>> 5th floor at the "shop and restaurant building" (between A and B
>>> buildings).
>>> It is at the opposite side of JR Shinagawa Station from the Summit side.)
>>> 
>>> Approximately it costs ~5000 (Japanese) Yen depending on the number of
>>> folks who join.
>>> Note that we have no sponsors.
>>> 
>>> If you have any trouble in reaching there or some question, reach me
>>> @ritchey98 on Twitter.
>>> 
>>> 
>>> 
>>> See you in Tokyo!
>>> Akihiro
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __
> OpenStack Development Mailing List (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] Do not merge until further notice

[Hirofumi Ichihara]

> On 2015/10/14, at 4:07, Armando M.  wrote:
> 
> Hi folks,
> 
> We are in the last hours of Liberty, let's pause for a second and consider 
> merging patches only if absolutely necessary. The gate is getting clogged and 
> we need to give priority to potential RC3 fixes or gate stability fixes.
Gate only? Should we prevent jenkins check from running too? In other words, 
shouldn’t we upload new commit?



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


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

[Hirofumi Ichihara]

Hi Gary,

Thank you for your suggestion.
In Liberty cycle[1], I have discussed about these points with neutron folks and 
network operators.


> On 2015/10/05, at 15:54, Gary Kotton  wrote:
> 
> Hi,
> Yes, you are correct. That patch is the culprit (my bad and once again humble 
> apologies)
> 
> Regarding the AZ support I think that we need to do the following:
> Have this in a separate topic until it is complete. I have a number of 
> concerns here:
> The upgrade impact on Nova. Today in Nova one can have N AZ’s and they will 
> all work on the same virtual networks. It is not clear how this will work 
> here and if the networks can be shared across AZ’s (maybe this was discussed 
> and I am missing somehing)
> A few weeks ago Monty raised concerns about floating IP support. I think that 
> this will be required for AZ support. In the past one could have a shared 
> network between AZ’s and now they will need two isolated networks
I guess that this is similar to “Segment” discussion[2].
I tried to include this point to Availability Zone spec so that we can deploy 
an environment has network unreachable AZs.
However, some folks disagreed with this because availability zone must be 
something to give users High Availability not manage isolated network with AZ.

> 
> In Nova on of the top priority features over the last few cycles has been 
> cells. At the moment there is no cell support for Neutron. I feel that the AZ 
> support is someone what related and maybe we should try and kill 2 birds with 
> one stone here and have the cell support combined if possible. I think that 
> this is certainly something that should be a cross project summit discussion.
I think too that Neutron Cell Support is important. However, neutron quite 
depends on the backend unlike nova.
It’s hard to combine it and it will take a long time. AZ support is also 
different from Cell support.
We should not discuss these to connect Neutron AZ support with Cell support 
because I’m afraid to fall between two stools.
I agree that we have a cross project summit discussion to connect Nova Cell 
support with Neutron Cell support.

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

[2]: https://bugs.launchpad.net/neutron/+bug/1458890 


Thanks,
Hirofumi


> Thanks
> Gary
> 
> From: "Armando M." >
> Reply-To: OpenStack List  >
> Date: Sunday, October 4, 2015 at 8:18 PM
> To: OpenStack List  >
> Subject: Re: [openstack-dev] [Neutron] AZ Support
> 
> 
> 
> On 4 October 2015 at 10:00, Gary Kotton  > wrote:
>> The DHCP agent has the following exception:
>> 
>> 2015-10-02 23:57:05.787 ERROR neutron.agent.dhcp.agent 
>> [req-17c3aa12-41fd-41f8-8e23-2f9740e50746 None None] Failed reporting state!
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent Traceback (most 
>> recent call last):
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 572, in _report_state
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent 
>> self.state_rpc.report_state(ctx, self.agent_state, self.use_call)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/opt/stack/neutron/neutron/agent/rpc.py", line 86, in report_state
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent return 
>> method(context, 'report_state', **kwargs)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 
>> 158, in call
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent retry=self.retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 
>> 90, in _send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent timeout=timeout, 
>> retry=retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>>  line 431, in send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent retry=retry)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>>  line 420, in _send
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent result = 
>> self._waiter.wait(msg_id, timeout)
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File 
>> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
>>  line 318, in wait
>> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent message = 
>> self.waiters.get(msg_id, 

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

[Hirofumi Ichihara]

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 be a good start. I talked to some nova folks involved in upgrades 
> there, and we may join the armies on that since general upgrade strategy 
> should be similar throughout the meta-project.
> 
> - stable:
> -- with a stadium of the size we have, it becomes a burden for 
> neutron-stable-maint to track backports for all projects; we should think of 
> opening doors for more per-sub-project stable cores for those subprojects 
> that seem sane in terms of development practices and stable awareness side; 
> that way we offload 

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

[Hirofumi Ichihara]

Good work and thank you for your help with my patch.

Anyway, I don’t know when does bp owner have to merge the code by.
I can see the following sentence in bp rule[1]
“The PTL will create a -backlog directory during the RC window and 
move all specs which didn’t make the  there.”
Did we have to merge the implementation by L-3? Or can we merge it in RC-1?

[1]: 
http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-bp-and-spec-notes

Thanks,
Hirofumi

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

[Openstack-operators] [Neutron] Metaplugin removal in Liberty

[Hirofumi Ichihara]

Hi Operator folks,
(I apologize for overlapping mail)

Does anyone use metaplugin of Neutron?
I want to remove it.

I have maintained metaplugin in Neutron.
The plugin enables users to use multiple plugins at the same time.
However, we can use ML2 plugin in order to do now.
I know that there is nobody using metaplugin and besides, It’s still 
experimental[1].
Therefore, I want to remove metapugin in Liberty cycle by a patch[2]
although it must be maintained in Liberty according to cycle deprecating plugin.

Could you respond me if you disagree with the proposal?

[1]: 
http://docs.openstack.org/admin-guide-cloud/content/section_limitations.html 
http://docs.openstack.org/admin-guide-cloud/content/section_limitations.html
[2]: https://review.openstack.org/#/c/192056/ 
https://review.openstack.org/#/c/192056/

thanks,
Hiro___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [Neutron] Metaplugin deprecation in Liberty

[Hirofumi Ichihara]

Hi folks,

I have maintained metaplugin in Neutron.
The plugin enables users to use multiple plugins at the same time.
However, we can use ML2 plugin in order to do now.
I know that there is nobody using metaplugin and besides, It’s still 
experimental[1].
Therefore, I want to deprecate metapugin in Liberty cycle although it must be 
maintained in Liberty according to cycle deprecating plugin.

Could you respond me if you disagree with the proposal?

[1]: 
http://docs.openstack.org/admin-guide-cloud/content/section_limitations.html

thanks,
Hiro

-
Hirofumi Ichihara


__
OpenStack Development Mailing 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] Metaplugin deprecation in Liberty

[Hirofumi Ichihara]

 On 2015/06/11, at 11:05, Kyle Mestery mest...@mestery.com wrote:
 
 On Wed, Jun 10, 2015 at 8:56 PM, Hirofumi Ichihara 
 ichihara.hirof...@lab.ntt.co.jp mailto:ichihara.hirof...@lab.ntt.co.jp 
 wrote:
 Hi folks,
 
 I have maintained metaplugin in Neutron.
 The plugin enables users to use multiple plugins at the same time.
 However, we can use ML2 plugin in order to do now.
 I know that there is nobody using metaplugin and besides, It’s still 
 experimental[1].
 Therefore, I want to deprecate metapugin in Liberty cycle although it must be 
 maintained in Liberty according to cycle deprecating plugin.
 
 Could you respond me if you disagree with the proposal?
 
 
 Hi Hirofumi:
 
 Deprecating the metaplugin should be fine. We can mark it as deprecated in 
 Liberty, and in fact, I've already done so in the Liberty release notes [2].
Awesome!
Thank you for your quick response! :)

I will push a patch for deprecation as soon as possible.

Thanks,
Hiro


 Thanks!
 Kyle
 
 [2] https://wiki.openstack.org/wiki/ReleaseNotes/Liberty 
 https://wiki.openstack.org/wiki/ReleaseNotes/Liberty
  
 [1]: 
 http://docs.openstack.org/admin-guide-cloud/content/section_limitations.html 
 http://docs.openstack.org/admin-guide-cloud/content/section_limitations.html
 
 thanks,
 Hiro
 
 -
 Hirofumi Ichihara
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [DevStack][Neutron] PHYSICAL_NETWORK vs. PUBLIC_PHYSICAL_NETWORK - rant

[Hirofumi Ichihara]

 Thanks for the clarification. Do you think that there are cases where
 the value for PHYSICAL_NETWORK and PUBLIC_PHYSICAL_NETWORK will be different? 
No, I cannot find the cases. I think it’s traditional something.

 Perhaps we can change the default value for PUBLIC_PHYSICAL_NETWORK from
 public to just pulling in what PHYSICAL_NETWORK is set to, if it is
 set?

Do you expect anything like the following?

PUBLIC_PHYSICAL_NETWORK=${PUBLIC_PHYSICAL_NETWORK:-$PHYSICAL_NETWORK}
PUBLIC_PHYSICAL_NETWORK=${PUBLIC_PHYSICAL_NETWORK:-public}

I guess it’s a simple solution even though it’s not essential.
The issue probably is caused by two points.
1) PHYSICAL_NETWORK and PUBLIC_PHYSICAL_NETWORK confuse users.
2) Devstack lacks the condition for avoiding the issue in 
https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/openvswitch_agent#L58

If I solve the issue, I would unify the two parameters.
I would leave the following for backward compatibility.
PUBLIC_PHYSICAL_NETWORK=${PUBLIC_PHYSICAL_NETWORK:-$PHYSICAL_NETWORK}
and
change PHYSICAL_NETWORK into PUBLIC_PHYSICAL_NETWORK in all the code.

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

Re: [openstack-dev] [DevStack][Neutron] PHYSICAL_NETWORK vs. PUBLIC_PHYSICAL_NETWORK - rant

[Hirofumi Ichihara]

Hi Sean,

 We have a *lot* of configuration knobs in DevStack for Neutron. I am not
 a smart man, so I think we may need to wrap our arms around this and
 simplify.
I agree with you. I want to fix the confused configure too.

PHYSICAL_NETWORK is a option in order to setup L2 public network only without 
L3 and private network.
PUBLIC_PHYSICAL_NETWORK is a option in order to setup public L2 network with L3 
and private network.

You can look at simple document in neutron-legacy[1].

According with the comment, therefore, you should fix your local.conf as the 
following.
PHYSICAL_NETWORK=default - PUBLIC_PHYSICAL_NETWORK=public
and add
OVS_BRIDGE_MAPPINGS=public:br-ex

[1]: 
https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L171-190

-
Hirofumi Ichihara__
OpenStack Development Mailing 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] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

[Hirofumi Ichihara]

 Sure, though on the other hand, doesn't current discussion seem to indicate 
 that OVS with DVR is not a viable replacement for nova-network multi-host HA 
 (eg due to complexity), and this is why folks were working towards linux 
 bridge?
Some openstacker doesn’t believe ovs performance is higher than linuxbridge.
So they don’t want to use OVS. Surely old OVS has many performance problems.
Currently, the problems almost might be solved. But they aren’t sure about it.
If that is a point of the discussion, we should show it to them.

In any case, we need to know why do they prefer linuxbridge rather than OVS.

Hirofumi

On 2015/04/16, at 11:09, Tom Fifield t...@openstack.org wrote:

 On 16/04/15 10:54, Fox, Kevin M wrote:
 Yes, but if stuff like dvr is the only viable replacement to
 nova-network in production, then learning the non representitive config
 of neutron with linuxbridge might be misleading/counter productive since
 ovs looks very very different.
 
 Sure, though on the other hand, doesn't current discussion seem to indicate 
 that OVS with DVR is not a viable replacement for nova-network multi-host HA 
 (eg due to complexity), and this is why folks were working towards linux 
 bridge?
 
 In essence: if linux bridge was a viable nova-network multi-host HA 
 replacement, you'd be OK with this change?
 
 
 Kevin *
 *
 
 *From:* Tom Fifield
 *Sent:* Wednesday, April 15, 2015 5:58:43 PM
 *To:* openstack-dev@lists.openstack.org
 *Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the
 default in DevStack [was: Status of the nova-network to Neutron
 migration work]
 
 
 
 On 14/04/15 23:36, Dean Troyer wrote:
 On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo
 mangel...@redhat.com mailto:mangel...@redhat.com wrote:
 
Why would operators install from devstack? that’s not going to be
the case.
 
 
 If they do they need more help than we can give...
 
 So, ummm, there is actually a valid use case for ops on devstack: it's
 part of the learning process.
 
 In my rounds, I've had feedback from more than a few whose first
 OpenStack experience was to run up a devstack, so they could run ps
 aufx, brctl, iptables, etc just to see what was going on under the
 covers before moving on to something more 'proper'.
 
 
 While acknowledging that the primary purpose and audience of devstack is
 and should remain development and developers, if there is something we
 can do to improve the experience for those ops first-timers that doesn't
 have a huge impact on devs, it would be kinda nice.
 
 After all, one of the reasons this thread exists is because of problems
 with that ramp up process, no?
 
 
 
I believe we should have both LB  OVS well tested, if LB is a good
option for
some operators willing to migrate from nova, that’s great, let’s
make sure LB
is perfectly tested upstream.
 
 
 +1
 
But by doing such change we can’t let OVS code rot and we would be
neglecting
a big customer base which is now making use of the openvswitch
mechanism.
(may be I’m miss understanding  the scope of the change).
 
 
 Changing DevStack's default doesn't remove anything OVS-related, nor
 does it by itself remove any OVS jobs.  It gives everyone who is happy
 with nova-net (or more correctly doesn't think about it) a new default
 that changes their experience the least for when nova-net disappears.
 
 dt
 
 --
 
 Dean Troyer
 dtro...@gmail.com mailto:dtro...@gmail.com
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Devstack] What is neutron-legacy?

[Hirofumi Ichihara]

Hi Dean,

Thank you for your response.
I’ve forgotten the sprint. I looked etherpad log and got it clearly.

thanks,
Hirofumi

2015/03/27 12:46、Dean Troyer dtro...@gmail.com のメール：

 On Thu, Mar 26, 2015 at 8:00 PM, Hirofumi Ichihara 
 ichihara.hirof...@lab.ntt.co.jp wrote:
 I found lib/neutron-legacy in master branch today.
 I didn’t know this important change because I couldn’t watch for the last few 
 days.
 Could someone tell me what is neutron-legacy?
 How do we manage and develop it?
 
 lib/neutron-legacy is a renamed lib/neutron, moved to make way for a new 
 lib/neutron that will a) follow the existing patterns of the rest of 
 DevStack's project modules, and b) be the first of the modules to get the 
 renamed services so you'll see neutron-api instead of q-svc for example.
  
 I would also like to know where is the change decided, IRC or ML? I probably 
 missed it.
 
 The final disposition of this was worked out this week at the QA code sprint 
 where we have Matt, Sean, Sean and myself (along with a handful of folk 
 working on Tempest and other QA tasks) in the same room sorting out how to 
 get Neutron usable as the default networking for DevStack.  One of the things 
 we decided was that it was necessary to refactor DevStack's Neutron support 
 so it is more maintainable.
 
 Both versions of the Neutron support will be available for a time, but the 
 new lib/neutron is what will implement the default configuration when that 
 change is made.  We will be making further communication when we are ready as 
 some details are still under consideration.
 
 dt
 
 -- 
 
 Dean Troyer
 dtro...@gmail.com
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Devstack] What is neutron-legacy?

[Hirofumi Ichihara]

Hi Devstack folks,

I found lib/neutron-legacy in master branch today. 
I didn’t know this important change because I couldn’t watch for the last few 
days.
Could someone tell me what is neutron-legacy?
How do we manage and develop it?

I would also like to know where is the change decided, IRC or ML? I probably 
missed it.

thanks,
Hirofumi
__
OpenStack Development Mailing 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] Behavior of default security group

[Hirofumi Ichihara]

Thank you for your response.

 That's a fair point. But I think it's because you're not expected to
 run as admin, and having a way to drop the group as admin can be of
 value for e.g. debugging or cleaning up after some bugs [1].
You’re right. 
Regenerate logic seems strange to me. But I’m not sure the logic must be fixed.

 This is because original neutron/nova authors thought that following
 the AWS way [2] is essential for project success.
 
 Since [3], neutron allows default group to be renamed. Though nova
 still assumes 'default' is the only way the group can be named [4].
I got it. It may be worth fixing.

Thanks,
Hirofumi

2015/02/24 2:00、Ihar Hrachyshka ihrac...@redhat.com ：

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 02/20/2015 11:45 AM, Hirofumi Ichihara wrote:
 Neutron experts,
 
 I caught a bug report[1].
 
 Currently, Neutron enable admin to delete default security group.
 But Neutron doesn’t allow default security group to keep deleted.
 Neutron regenerates default security group as security group api is
 called next.
 
 I actually believe the design is unfortunate, and instead of this,
 keystone would better notify services about new tenant, and services
 would create resources like default security groups for them. AFAIK
 keystone does not notify at the moment, so we had few options.
 Speaking of current design, ...
 
 I have two questions about the behavior.
 
 1. Why does Neutron regenerate default security group? If default 
 security group is essential, we shouldn’t enable admin to delete
 it.
 
 That's a fair point. But I think it's because you're not expected to
 run as admin, and having a way to drop the group as admin can be of
 value for e.g. debugging or cleaning up after some bugs [1].
 
 2. Why is security group named “default essential? Users may want
 to change its name.
 
 
 This is because original neutron/nova authors thought that following
 the AWS way [2] is essential for project success.
 
 Since [3], neutron allows default group to be renamed. Though nova
 still assumes 'default' is the only way the group can be named [4].
 
 [1]: https://bugs.launchpad.net/neutron/+bug/1194579
 [2]:
 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#default-security-group
 [3]:
 http://git.openstack.org/cgit/openstack/neutron/commit/?id=79c97120de9cff4d0992b5d41ff4bbf05e890f89
 [4]:
 https://git.openstack.org/cgit/openstack/nova/tree/nova/compute/api.py#n1074
 
 /Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 
 iQEcBAEBAgAGBQJU61zHAAoJEC5aWaUY1u57UE4H/30jKnhrQthzuw0xuKJ3VDu7
 Fi+eqbhis7/ntGSQLlDFEPzsHjCxjkwXVN7kdPPaftp6RsnpwJNko+Zbvv2gWEMj
 qS3dxsCYiQVAjmbDIXrlz1K/za+QYJL3FvD9hP/ixA90ZeL0l6VFs2KwKAr35AEP
 EmkBK237tlHBJfqVh9H81cMn36iPKMd/g+4cAuysxajEFiWSqBBegngGpCiUJ6Vm
 51AeOBR4bwR585XvIRyDQIfQD/rLSYHzTZSn+ChLy6It14x7WHs/xgTn5V3EqNKB
 VIHhiU6j2QuW07wDa1/HEGaTao8Np1OcL7IuEdDb6ioCZRMaC3cpuTOE3OoVeW4=
 =8BCo
 -END PGP SIGNATURE-
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

[openstack-dev] [Neutron] Behavior of default security group

[Hirofumi Ichihara]

Neutron experts,

I caught a bug report[1].

Currently, Neutron enable admin to delete default security group. But Neutron 
doesn’t allow default security group to keep deleted. Neutron regenerates 
default security group as security group api is called next. I have two 
questions about the behavior.

1. Why does Neutron regenerate default security group? If default security 
group is essential, we shouldn’t enable admin to delete it.
2. Why is security group named “default essential? Users may want to change 
its name.

I'd like neutron experts' suggestions.

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

Thanks,
Hirofumi


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

Re: [openstack-dev] [devstack][VMware NSX CI] VMware NSX CI fails and don't recheck

[Hirofumi Ichihara]

Hi Salvatore,

Thank you for good news.
I looked VMware NSX CI voted for my patch.

Thanks,
Hirofumi 

2015/01/02 3:07、Salvatore Orlando sorla...@nicira.com のメール：

 Hi VMware NSX CI for Neutron was disabled but unfortunately it kept voting on 
 a few set of patches, always failing for a number of reasons.
 
 It seems everything is fixed now and all the jobs have been reinstated.
 
 Salvatore
 
 On 25 December 2014 at 08:32, Hirofumi Ichihara 
 ichihara.hirof...@lab.ntt.co.jp wrote:
 Hi Gary,
 
 Thank you for your response.
 I understand. I’m expecting good news.
 
 Thanks,
 Hirofumi
 
 2014/12/25 15:57、Gary Kotton gkot...@vmware.com のメール：
 
 Hi,
 We have a few CI issues. We are working on them at the moment. I hope that 
 we get to the bottom of this soon.
 Thanks
 Gary
 
 From: Hirofumi Ichihara ichihara.hirof...@lab.ntt.co.jp
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Thursday, December 25, 2014 at 5:41 AM
 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [devstack][VMware NSX CI] VMware NSX CI fails and 
 don't recheck
 
 Hi,
 
 My patch(https://review.openstack.org/#/c/124011/) received verified-1 from 
 VMware NSX CI.
 But my patch isn’t related to VMware so I added comment 
 “vmware-recheck-patch” according to VMware NSX CI comment.
 However, VMware NSX CI don’t recheck.
 
 I don’t know recheck word was wrong or CI broke.
 
 Could someone help me?
 
 Thanks,
 Hirofumi
 ___
 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] [devstack][VMware NSX CI] VMware NSX CI fails and don't recheck

[Hirofumi Ichihara]

Hi,

My patch(https://review.openstack.org/#/c/124011/) received verified-1 from 
VMware NSX CI.
But my patch isn’t related to VMware so I added comment “vmware-recheck-patch” 
according to VMware NSX CI comment.
However, VMware NSX CI don’t recheck.

I don’t know recheck word was wrong or CI broke.

Could someone help me?

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

Re: [openstack-dev] [devstack][VMware NSX CI] VMware NSX CI fails and don't recheck

[Hirofumi Ichihara]

Hi Gary,

Thank you for your response.
I understand. I’m expecting good news.

Thanks,
Hirofumi

2014/12/25 15:57、Gary Kotton gkot...@vmware.com のメール：

 Hi,
 We have a few CI issues. We are working on them at the moment. I hope that we 
 get to the bottom of this soon.
 Thanks
 Gary
 
 From: Hirofumi Ichihara ichihara.hirof...@lab.ntt.co.jp
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Thursday, December 25, 2014 at 5:41 AM
 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [devstack][VMware NSX CI] VMware NSX CI fails and 
 don't recheck
 
 Hi,
 
 My patch(https://review.openstack.org/#/c/124011/) received verified-1 from 
 VMware NSX CI.
 But my patch isn’t related to VMware so I added comment 
 “vmware-recheck-patch” according to VMware NSX CI comment.
 However, VMware NSX CI don’t recheck.
 
 I don’t know recheck word was wrong or CI broke.
 
 Could someone help me?
 
 Thanks,
 Hirofumi
 ___
 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] Can ofagent connect to switches other than OVS?

[Hirofumi Ichihara]

Hi, all

I’m trying to connect ofagent to switches other than OVS.
But, it’s not going. I think that the ofagent cannot connect their switches.
Is there anyone tried?

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

Re: [openstack-dev] [neutron] Can ofagent connect to switches other than OVS?

[Hirofumi Ichihara]

Yamamoto,

 ofagent is still OVS-only.
 to support non-OVS switches, there are some todo items including
 nova/neutron interface drivers.
 https://wiki.openstack.org/wiki/Neutron/OFAgent/Todo
I understand.
Thank you.

Hirofumi Ichihara

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

Re: [Openstack] [Neutron] what is notification_driver?

[Hirofumi Ichihara]

 neutron can push notifications to ampq, then you can use stuff like
 stacktach to monitor your cloud operations.
 
 it is enterely optional, you can run without notifications
I understand.

Thank you very much for your help.

Hirofumi

On 2014/06/10, at 1:42, gustavo panizzo gfa g...@zumbi.com.ar wrote:

 On 06/06/2014 05:51 AM, Hirofumi Ichihara wrote:
 Hi, All
 
 I am examining notification_driver in neutron.conf.
 
 According the following link, it is used to support DHCP agent.
 http://docs.openstack.org/admin-guide-cloud/content/section_adv_notification_overview.html
 
 So I set neutron.openstack.common.notifier.no_op_notifier and observed
 no_op_notifier is the default, it disables notification
 
 
 neutron_dhcp_agent.
 But problem didn't occur (net-create/delete, subnet-create/delete,
 port-create/delete, boot vm).
 
 I don't know for what notification_driver is used.
 
 neutron can push notifications to ampq, then you can use stuff like
 stacktach to monitor your cloud operations.
 
 it is enterely optional, you can run without notifications
 
 
 -- 
 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [Neutron] what is notification_driver?

[Hirofumi Ichihara]

Hi, All

I am examining notification_driver in neutron.conf.

According the following link, it is used to support DHCP agent.
http://docs.openstack.org/admin-guide-cloud/content/section_adv_notification_overview.html

So I set neutron.openstack.common.notifier.no_op_notifier and observed 
neutron_dhcp_agent.
But problem didn't occur (net-create/delete, subnet-create/delete, 
port-create/delete, boot vm).

I don't know for what notification_driver is used.
Is there anybody that can give me some informations about notification_driver?

thanks,
Hirofumi

-
Hirofumi Ichihara
NTT Software Innovation Center
Tel:+81-422-59-2843  Fax:+81-422-59-2699
Email:ichihara.hirof...@lab.ntt.co.jp
-



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Neutron] Introducing task oriented workflows

[Hirofumi Ichihara]

Hi, Salvatore

 It is totally correct that most Neutron resources have a sloppy status 
 management. Mostly because, as already pointed out, the 'status' for most 
 resource was conceived to be a 'network fabric' status rather than a resource 
 synchronisation status.
Exactly, I reckon that neutron needs resource synchronization status.

 As it emerged from previous posts in this thread, I reckon we have three 
 choices:
 1) Add a new attribute for describing configuration state. For instance 
 this will have values such as PENDING_UPDATE, PENDING_DELETE, IN_SYNC, 
 OUT_OF_SYNC, etc.
 2) Merge status and configuration statuses in a single attribute. This will 
 probably result simpler from a client perspective, but there are open 
 questions such as whether a resource for which a task is in progress and is 
 down should be reported as 'down' or 'pending_updage'.
 3) Not use any new flags, and use tasks to describe whether there are 
 operations in progress on a resource.
 The status attribute will describe exclusively the 'fabric' status of a 
 resources; however tasks will be exposed through the API - and a resource in 
 sync will be a resource with no PENDING or FAILED task active on it.
Good suggestions.
I reckon that choice (3) is discussion about new API and choice (1) (2) are 
discussion about current API.
It is not good the problem of current API continues remaining in the future.
So they should be discussed individually and improve the fabric status by (1) 
or (2). 
When (3) will be achieved, if neutron has same fabric status problem, users may 
be confused about the difference between resource status and task status. 
Additionally, to be exact, the task show not resource status but API process 
status.

I reckon we should improve the fabric status, then add task to neutron.
Also, I think (2) is good. Because there is performance of LBaaS model.

thanks,
Hirofumi

-
市原 裕史 (Ichihara Hirofumi)
NTTソフトウェアイノベーションセンタ
Tel:0422-59-2843  Fax:0422-59-2699
Email:ichihara.hirof...@lab.ntt.co.jp
-


On 2014/05/30, at 17:57, Salvatore Orlando sorla...@nicira.com wrote:

 Hi Hirofumi,
 
 I reckon this has been immediately recognised as a long term effort.
 However, I just want to clarify that by long term I don't mean pushing it 
 back until we get to the next release cycle and we realize we are in the same 
 place where we are today!
 
 It is totally correct that most Neutron resources have a sloppy status 
 management. Mostly because, as already pointed out, the 'status' for most 
 resource was conceived to be a 'network fabric' status rather than a resource 
 synchronisation status.
 
 As it emerged from previous posts in this thread, I reckon we have three 
 choices:
 1) Add a new attribute for describing configuration state. For instance 
 this will have values such as PENDING_UPDATE, PENDING_DELETE, IN_SYNC, 
 OUT_OF_SYNC, etc.
 2) Merge status and configuration statuses in a single attribute. This will 
 probably result simpler from a client perspective, but there are open 
 questions such as whether a resource for which a task is in progress and is 
 down should be reported as 'down' or 'pending_updage'.
 3) Not use any new flags, and use tasks to describe whether there are 
 operations in progress on a resource.
 The status attribute will describe exclusively the 'fabric' status of a 
 resources; however tasks will be exposed through the API - and a resource in 
 sync will be a resource with no PENDING or FAILED task active on it.
 
 The above are just options at the moment; I tend to lean toward the latter, 
 but it would be great to have your feedback.
 
 Salvatore
 
 
 
 On 28 May 2014 11:20, Hirofumi Ichihara ichihara.hirof...@lab.ntt.co.jp 
 wrote:
 Hi, Salvatore
 
 I think neutron needs the task management too.
 
 IMO, the problem of neutron resource status should be discussed individually.
 Task management enable neutron to roll back API operation and delete trash of 
 resource, try API operation again in one API process.
 Of course, we can use task to correct inconsistency between neutron 
 DB(resource status) and actual resource configuration.
 But, we should add resource status management to some resources before task.
 For example, LBaaS has resource status management[1].
 Neutron router, port don't mange status is basic problem.
 
 For instance a port is UP if it's been wired by the OVS agent; it often 
 does not tell us whether the actual resource configuration is exactly the 
 desired one in the database. For instance, if the ovs agent fails to apply 
 security groups to a port, the port stays ACTIVE and the user might never 
 know there was an error and the actual state diverged from the desired one.
 So, we should solve this problem by resource status management such LBaaS 
 rather than task.
 
 I don't deny task, but we need to discuss for task long term, I hope the 
 status management

Re: [openstack-dev] [Neutron] Introducing task oriented workflows

[Hirofumi Ichihara]

Hi, Salvatore

I think neutron needs the task management too.

IMO, the problem of neutron resource status should be discussed individually.
Task management enable neutron to roll back API operation and delete trash of 
resource, try API operation again in one API process.
Of course, we can use task to correct inconsistency between neutron DB(resource 
status) and actual resource configuration.
But, we should add resource status management to some resources before task.
For example, LBaaS has resource status management[1].
Neutron router, port don't mange status is basic problem.

 For instance a port is UP if it's been wired by the OVS agent; it often 
 does not tell us whether the actual resource configuration is exactly the 
 desired one in the database. For instance, if the ovs agent fails to apply 
 security groups to a port, the port stays ACTIVE and the user might never 
 know there was an error and the actual state diverged from the desired one.
So, we should solve this problem by resource status management such LBaaS 
rather than task.

I don't deny task, but we need to discuss for task long term, I hope the status 
management will be modified right away.

[1] 
https://wiki.openstack.org/wiki/Neutron/LBaaS/API_1.0#Synchronous_versus_Asynchronous_Plugin_Behavior

thanks,
Hirofumi

-
Hirofumi Ichihara
NTT Software Innovation Center
Tel:+81-422-59-2843  Fax:+81-422-59-2699
Email:ichihara.hirof...@lab.ntt.co.jp
-


On 2014/05/23, at 7:34, Salvatore Orlando sorla...@nicira.com wrote:

 As most of you probably know already, this is one of the topics discussed 
 during the Juno summit [1].
 I would like to kick off the discussion in order to move towards a concrete 
 design.
 
 Preamble: Considering the meat that's already on the plate for Juno, I'm not 
 advocating that whatever comes out of this discussion should be put on the 
 Juno roadmap. However, preparation (or yak shaving) activities that should be 
 identified as pre-requisite might happen during the Juno time frame assuming 
 that they won't interfere with other critical or high priority activities.
 This is also a very long post; the TL;DR summary is that I would like to 
 explore task-oriented communication with the backend and how it should be 
 reflected in the API - gauging how the community feels about this, and 
 collecting feedback regarding design, constructs, and related 
 tools/techniques/technologies.
 
 At the summit a broad range of items were discussed during the session, and 
 most of them have been reported in the etherpad [1].
 
 First, I think it would be good to clarify whether we're advocating a 
 task-based API, a workflow-oriented operation processing, or both.
 
 -- About a task-based API
 
 In a task-based API, most PUT/POST API operations would return tasks rather 
 than neutron resources, and users of the API will interact directly with 
 tasks.
 I put an example in [2] to avoid cluttering this post with too much text.
 As the API operation simply launches a task - the database state won't be 
 updated until the task is completed.
 
 Needless to say, this would be a radical change to Neutron's API; it should 
 be carefully evaluated and not considered for the v2 API.
 Even if it is easily recognisable that this approach has a few benefits, I 
 don't think this will improve usability of the API at all. Indeed this will 
 limit the ability of operating on a resource will a task is in execution on 
 it, and will also require neutron API users to change the paradigm the use to 
 interact with the API; for not mentioning the fact that it would look weird 
 if neutron is the only API endpoint in Openstack operating in this way.
 For the Neutron API, I think that its operations should still be manipulating 
 the database state, and possibly return immediately after that (*) - a task, 
 or to better say a workflow will then be started, executed asynchronously, 
 and update the resource status on completion.
 
 -- On workflow-oriented operations
 
 The benefits of it when it comes to easily controlling operations and 
 ensuring consistency in case of failures are obvious. For what is worth, I 
 have been experimenting introducing this kind of capability in the NSX plugin 
 in the past few months. I've been using celery as a task queue, and writing 
 the task management code from scratch - only to realize that the same 
 features I was implementing are already supported by taskflow.
 
 I think that all parts of Neutron API can greatly benefit from introducing a 
 flow-based approach.
 Some examples:
 - pre/post commit operations in the ML2 plugin can be orchestrated a lot 
 better as a workflow, articulating operations on the various drivers in a 
 graph
 - operation spanning multiple plugins (eg: add router interface) could be 
 simplified using clearly defined tasks for the L2 and L3 parts
 - it would be finally possible to properly

[OpenStack-Infra] Request for Service Account for Neutron LVS

[Hirofumi Ichihara]

Hi,

I would like to request a service account for LVS 3rd-party testing.

Account Name: lvstest
Display Name: LVS CI Test
Contact: lbaast...@gmail.com

Public Key:
ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCdC9e87kF17GCzzdVpUlPPMLaiimCcA3kKynYJF4Ym90So3bp/izJrFRfpnEsUPFiijo3XcYqcdXKo9KoM70qsvBl+FsnmbbQFv/O1BjqWKcrrVd0cOr4tXmLafkIpcBknWjE/iYcPGAuz6TuLGsEk6cJP5n1o5Iinf+u/fBgkPt68zaCSeulGLqiGIFczke9qcWEjNOrsI4l6pF99+vYfFfojGH3qVjipCDBFB+E97gFrvMXjeUydXdnaw9uEsmkS6o6SEEzeuEEWsePLhQlSBiS4SFqIsuVY07+sP8Uj7IWLA3ahl/kc9gCA8WedSVsHmRxFCtm98PH8VvqCmucn
 lvs@lbaas

Thanks,
Hirofumi

-
市原 裕史 (Ichihara Hirofumi)
NTTソフトウェアイノベーションセンタ
Tel:0422-59-2843  Fax:0422-59-2699
Email:ichihara.hirof...@lab.ntt.co.jp
-


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