Re: [openstack-dev] [Neutron][networking-sfc] OpenStack Summit Barcelona: networking-sfc project team lunch meetup

[Stephen Wong]

Hi Cathy,

Sorry, I won't be attending the summit. Will there be an etherpad to
capture what is going to be discussed regarding networking-sfc during the
summit? If so, please post the link.

Thanks,
- Stephen

On Tue, Oct 25, 2016 at 6:38 AM, Cathy Zhang 
wrote:

> Let’s meet for lunch at the AC Buffet lunch room (not the CCIN buffet
> lunch area) at 1pm Wednesday.
>
> Anyone interested in service function chaining solution is welcomed to
> join.
>
>
>
> Thanks,
>
> Cathy
>
__
OpenStack Development Mailing 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] [tacker] Proposing Yong Sheng Gong for Tacker core team

[Stephen Wong]

+1

On Tue, Aug 23, 2016 at 8:55 AM, Sridhar Ramaswamy 
wrote:

> Tackers,
>
> I'd like to propose Yong Sheng Gong to join the Tacker core team. Yong is
> a seasoned OpenStacker and has been contributing to Tacker project since
> Nov 2015 (early Mitaka). He has been the major force in helping Tacker to
> shed its *Neutronisms*. He has low tolerance on unevenness in the code
> base and he fixes them as he goes. Yong also participated in the Enhanced
> Placement Awareness (EPA) blueprint in the Mitaka cycle. For Newton he took
> up himself cleaning up the DB schema and in numerous reviews to keep the
> project going. He has been a dependable member of the Tacker community [1].
>
> Please chime in with your +1 / -1 votes.
>
> thanks,
> Sridhar
>
> [1] http://stackalytics.com/report/contribution/tacker/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] [tacker] Proposing Kanagaraj Manickam to Tacker core team

[Stephen Wong]

+1. Great addition to the team indeed!

On Wed, Jun 15, 2016 at 6:31 PM, Sridhar Ramaswamy 
wrote:

> Tackers,
>
> It gives me great pleasure to propose Kanagaraj Manickam to join the
> Tacker core team. In a short time, Kanagaraj has grown into a key member of
> the Tacker team. His enthusiasm and dedication to get Tacker code base on
> par with other leading OpenStack projects is very much appreciated. He is
> already working on two important specs in Newton cycle and many more fixes
> and RFEs [1]. Kanagaraj is also a core member in the Heat project and this
> lends well as we heavily use Heat for many Tacker features.
>
> Please provide your +1/-1 votes.
>
> - Sridhar
>
> [1]
> http://stackalytics.com/?module=tacker-group_id=kanagaraj-manickam=marks
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core

[Stephen Wong]

+1. Great addition to the team!

On Mon, Jun 13, 2016 at 11:48 AM, Henry Fourie 
wrote:

> +1
>
>
>
> *From:* Cathy Zhang
> *Sent:* Monday, June 13, 2016 11:36 AM
> *To:* openstack-dev@lists.openstack.org; Cathy Zhang
> *Subject:* [openstack-dev] [neutron][networking-sfc] Proposing Mohan
> Kumar for networking-sfc core
>
>
>
> Mohan has been working on networking-sfc project for over one year. He is
> a key contributor to the design/coding/testing of SFC CLI,  SFC Horizon, as
> well as ONOS controller support for SFC functionality. He has been great at
> helping out with bug fixes, testing, and reviews of all components of
> networking-sfc. He is also actively providing guidance to the users on
> their SFC setup, testing, and usage. Mohan showed a very good understanding
> of the networking-sfc design, code base, and its usage scenarios.
> Networking-sfc could use more cores as our user base and features have
> grown and I think he'd be a valuable addition.
>
>
>
> Please respond with your +1 votes to approve this change or -1 votes to
> oppose.
>
>
>
> Thanks,
>
> Cathy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [tacker] Proposing Bharath Thiruveedula to Tacker core team

[Stephen Wong]

+1

On Fri, Jun 3, 2016 at 9:23 PM, Haddleton, Bob (Nokia - US) <
bob.haddle...@nokia.com> wrote:

> +1
>
> Bob
>
> On Jun 3, 2016, at 8:24 PM, Sridhar Ramaswamy  wrote:
>
> Tackers,
>
> I'm happy to propose Bharath Thiruveedula (IRC: tbh) to join the tacker
> core team. Bharath has been contributing to Tacker from the Liberty cycle,
> and he has grown into a key member of this project. His contribution has
> steadily increased as he picked up bigger pieces to deliver [1].
> Specifically, he contributed the automatic resource creation blueprint [2]
> in the Mitaka release. Plus tons of other RFEs and bug fixes [3]. Bharath
> is also a key contributor in tosca-parser and heat-translator projects
> which is an added plus.
>
> Please provide your +1/-1 votes.
>
> Thanks Bharath for your contributions so far and much more to come !!
>
> [1]
> http://stackalytics.com/?project_type=openstack=all=commits_id=bharath-ves=tacker-group
> [2]
> https://blueprints.launchpad.net/tacker/+spec/automatic-resource-creation
> [3] https://bugs.launchpad.net/bugs/+bugs?field.assignee=bharath-ves
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [tacker] Proposing Lin Cheng for tacker-horizon core team

[Stephen Wong]

+1. Great addition!

On Thu, May 26, 2016 at 10:51 AM, Sripriya Seetharam 
wrote:

> +1 , glad to have Lin Cheng on board.
>
>
>
> *From:* Sridhar Ramaswamy [mailto:sric...@gmail.com]
> *Sent:* Thursday, May 26, 2016 7:45 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [tacker] Proposing Lin Cheng for
> tacker-horizon core team
>
>
>
> Tackers,
>
>
>
> I'd like to propose Lin Cheng to join as a tacker-horizon core team
> member. Lin has been our go-to person for all guidance related to UI
> enhancements for Tacker. He has been actively reviewing patchsets in
> this area [1] and also contributed to setup the unit test framework for
> tacker-horizon repo.
>
>
>
> Please provide your +1/-1 votes.
>
>
>
> - Sridhar
>
>
>
> [1]
> http://stackalytics.com/?project_type=all=marks=all=tacker-group_id=lin-hua-cheng
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Stephen Wong]

Hi Cathy,

A technical discussion on networking-sfc tomorrow? Really? When and
where? Is this going to be the same one as the common flow classifier
discussion?

Thanks,
- Stephen

On Wed, Apr 27, 2016 at 3:55 PM, Cathy Zhang 
wrote:

> We will have a technical discussion tomorrow and record our meeting
> minutes in the etherpad.
> Tuesday is more a f2f social meet-up.
>
> Thanks,
> Cathy
>
> -Original Message-
> From: Elzur, Uri [mailto:uri.el...@intel.com]
> Sent: Wednesday, April 27, 2016 12:42 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc
> project f2f2 meet-up place and time
>
> Can you pls add more detailed minutes as to emerging
> agreements/understandings?
>
> Thx
>
> Uri ("Oo-Ree")
> C: 949-378-7568
>
>
> -Original Message-
> From: Akihiro Motoki [mailto:amot...@gmail.com]
> Sent: Tuesday, April 26, 2016 11:50 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc
> project f2f2 meet-up place and time
>
> 2016-04-26 12:31 GMT-05:00 Henry Fourie :
> > All,
> >Please use the networking-sfc etherpad to record discussions at the
> > meetups:
> >
> > https://etherpad.openstack.org/p/networking-sfc-austin-summit-meeting
> >
> >  - Louis
> >
> > -Original Message-
> > From: Paul Carver [mailto:pcar...@paulcarver.us]
> > Sent: Tuesday, April 26, 2016 10:20 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc
> > project f2f2 meet-up place and time
> >
> > On 4/26/2016 00:35, Akihiro Motoki wrote:
> >> Hi Cathy and folks interested in SFC and classifers!
> >>
> >> Can't we use a different room like Salon D?
> >> Salon C is a lunch room and at that time there are no sessions in other
> rooms.
> >> It would be great if we can use Salon D or E (after looking at the
> >> first day's session) I think we can gather more easily and
> >> concentrate the discussion if we use some different space.
> >> Thought?
> >>
> >
> > Akihiro,
> >
> > Unless I've misunderstood the emails, the plan for Tuesday is a social
> lunch for the SFC team to get together. The plan for Wednesday is a working
> lunch to discuss flow classifiers in various projects and figure out how to
> converge on a single flow classifier API/model that can be shared by
> everything that needs to specify flows.
> >
> > If that's correct, then meeting in Salon C for lunch on Tuesday makes
> sense. For Wednesday we probably ought to grab boxed lunches and find a
> quiet room.
>
> I was confused with networking-sfc f2f meeting and flow classifier one.
> My previous mail is a suggestion for wednesday flow classifier meeting.
> Thanks for point it out.
>
> 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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Stephen Wong]

Hi,

Unfortunately I will miss this f2f meeting since I won't arrive until
late evening on Tuesday. But I did update the etherpad LouisF posted [1]
(during the last IRC meeting) with some topics of interest. If any of them
happens to be discussed during Tuesday's meetup, please update the etherpad
accordingly. Thanks!

Actually, in general, please take notes in the etherpad so we can
review as topics of interest (and corresponding discussion points) for
development planning for the next cycle.

Thanks,
- Stephen

[1]  https://etherpad.openstack.org/p/networking-sfc-austin-summit-meeting

On Fri, Apr 22, 2016 at 3:30 PM, Cathy Zhang 
wrote:

> Hi Everyone,
>
>
>
> As we discussed in our project meeting, we should have a f2f meeting
> during the summit.
>
> let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
>
> Since Salon C is a big room, I will put a sign “Networking-SFC Project
> Meet-Up” on the table.
>
>
>
> Thanks,
>
> Cathy
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Stephen Wong]

+1 on Wednesday lunch

On Thu, Apr 21, 2016 at 12:02 PM, Ihar Hrachyshka 
wrote:

> Cathy Zhang  wrote:
>
> Hi everyone,
>>
>> We have room 400 at 3:10pm on Thursday available for discussion of the
>> two topics.
>> Another option is to use the common room with roundtables in "Salon C"
>> during Monday or Wednesday lunch time.
>>
>> Room 400 at 3:10pm is a closed room while the Salon C is a big open room
>> which can host 500 people.
>>
>> I am Ok with either option. Let me know if anyone has a strong preference.
>>
>
> On Monday, I have two talks to do. First one is 2:50-3:30pm, second one is
> 4:40-5:20pm. But lunch time should probably be fine if it leaves time for
> the actual lunch...
>
> Thursday at 3:10pm also works for me.
>
>
> 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

[Stephen Wong]

Wait... is this April's Fool?

(hard to believe project name change resulting from name clashing with a
Marvel comic character)

On Fri, Apr 1, 2016 at 11:57 AM, Carl Baldwin  wrote:

> On Fri, Apr 1, 2016 at 2:24 AM, Ihar Hrachyshka 
> wrote:
> > We could play words, like Quantron or Neutrum. Actually, it makes perfect
> > sense to me, since the change to rename all project name references will
> be
> > half the size of the proposed solution, and may even save us some git
> > conflicts, assuming we hack Gerrit to use word-based conflict merging
> > engine.
>
> Quantron!  I like it.  :)
>
> 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] [tacker] Proposing Sripriya Seetharam to Tacker core

[Stephen Wong]

+1

On Mon, Nov 9, 2015 at 6:22 PM, Sridhar Ramaswamy  wrote:

> I'd like to propose Sripriya Seetharam to join the Tacker core team.
> Sripriya
> ramped up quickly in early Liberty cycle and had become an expert in the
> Tacker
> code base. Her major contributions include landing MANO API blueprint,
> introducing unit test framework along with the initial unit-tests and
> tirelessly
> squashing hard to resolve bugs (including chasing the recent nova-neutron
> goose
> hunt). Her reviews are solid fine tooth comb and constructive [1].
>
> I'm glad to welcome Sripriya to the core team. Current cores members,
> please vote
> with your +1 / -1.
>
> [1]
> http://stackalytics.com/?release=libertyuser_id=sseethaproject_type=openstack-others
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [Tacker] Proposing Bob Haddleton to core team

[Stephen Wong]

+1

- Stephen

On Thu, Oct 15, 2015 at 8:47 AM, Sridhar Ramaswamy 
wrote:

> I would like to nominate Bob Haddleton to the Tacker core team.
>
> In the current Liberty cycle Bob made significant, across the board
> contributions to Tacker [1]. Starting with many usability enhancements and
> squashing bugs Bob has shown commitment and consistently produced high
> quality code. To cap he recently landed Tacker's health monitoring
> framework to enable loadable VNF monitoring. His knowledge in NFV area is a
> huge plus for Tacker as we embark onto even greater challenges in the
> Mitaka cycle.
>
> Along the lines, we are actively looking to expand Tacker's core reviewer
> team. If you are interested in the NFV Orchestration / VNF Manager space
> please stop by and explore Tacker project [2].
>
> Tacker team,
>
> Please provide your -1 / +1 votes.
>
> - Sridhar
>
> [1]  
> http://stackalytics.com/report/users/bob-haddleton
> [2]  
> https://wiki.openstack.org/wiki/Tacker
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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][Kuryr] - Bringing Dockers networking to Neutron

[Stephen Wong]

+1 for Monday

On Wed, Jul 22, 2015 at 10:29 PM, Mohammad Banikazemi m...@us.ibm.com wrote:

 Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I
 realize there are several networking related weekly meetings, but I would
 like to see if we can find a different time. I suggest the same time, that
 is 1600 UTC but either on Mondays or Thursdays.

 Please note there is the Ironic/Neutron Integration meeting at the same
 time on Mondays but that conflict may be a smaller conflict. Looking at the
 meetings listed at [2] I do not see any other conflict.

 Best,

 Mohammad

 [1] https://wiki.openstack.org/wiki/Meetings/ML2
 [2] http://eavesdrop.openstack.org


 [image: Inactive hide details for Gal Sagie ---07/22/2015 12:31:46
 PM---Hello Everyone, Project Kuryr is now officially part of Neutron]Gal
 Sagie ---07/22/2015 12:31:46 PM---Hello Everyone, Project Kuryr is now
 officially part of Neutron's big tent.

 From: Gal Sagie gal.sa...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org, Eran Gampel 
 eran.gam...@toganetworks.com, Antoni Segura Puimedon t...@midokura.com,
 Irena Berezovsky ir...@midokura.com
 Date: 07/22/2015 12:31 PM
 Subject: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking
 to Neutron
 --




 Hello Everyone,

 Project Kuryr is now officially part of Neutron's big tent.
 Kuryr is aimed to be used as a generic docker remote driver that connects
 docker to Neutron API's
 and provide containerised images for the common Neutron plugins.
 We also plan on providing common additional networking services API's from
 other sub projects
 in the Neutron big tent.

 We hope to get everyone on board with this project and leverage this joint
 effort for the many different solutions out there (instead of everyone
 re-inventing the wheel for each different project).

 We want to start doing a weekly IRC meeting to coordinate the different
 requierments and
 tasks, so anyone that is interested to participate please share your time
 preference
 and we will try to find the best time for the majority.

 Remember we have people in Europe, Tokyo and US, so we won't be able to
 find time that fits
 everyone.

 The currently proposed time is  *Wedensday at 16:00 UTC *

 Please reply with your suggested time/day,
 Hope to see you all, we have an interesting and important project ahead of
 us

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



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


__
OpenStack Development Mailing List (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] [Tacker][Telco][NFV] Reminder: Tacker (VNF Manager) Team Meeting June 11

[Stephen Wong]

Meeting on #openstack-meeting @ 1600UTC (9am PDT)

Agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_June_11.2C_2015

Thanks,
- Stephen
__
OpenStack Development Mailing List (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] [Tacker] Tacker (NFV MANO VNFM) team meeting June 4th

[Stephen Wong]

Please note the change in time (and day of the week) and channel:

Meeting on #openstack-meeting at 1600 UTC (9:00am PDT)

Agenda can be found here (feel free to add yours):
https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_June_4.2C_2015

Thanks,
- Stephen
__
OpenStack Development Mailing 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] [NFV][Telco] Service VM v/s its basic framework

[Stephen Wong]

Hi Murali,

There is already a ServiceVM project (Tacker), currently under
development on stackforge:

https://wiki.openstack.org/wiki/ServiceVM

If you are interested in this topic, please take a look at the wiki
page above and see if the project's goals align with yours. If so, you are
certainly welcome to join the IRC meeting and start to contribute to the
project's direction and design.

Thanks,
- Stephen


On Wed, Dec 10, 2014 at 7:01 AM, Murali B mbi...@gmail.com wrote:

 Hi keshava,

 We would like contribute towards service chain and NFV

 Could you please share the document if you have any related to service VM

 The service chain can be achieved if we able to redirect the traffic to
 service VM using ovs-flows

 in this case we no need to have routing enable on the service VM(traffic
 is redirected at L2).

 All the tenant VM's in cloud could use this service VM services  by adding
 the ovs-rules in OVS


 Thanks
 -Murali




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


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

Re: [openstack-dev] [controller-dev] Group-Based Policy Understanding and Queries

[Stephen Wong]

CC'ed ODL GBP --- although this doesn't concern them at this point, it may
be of interest to the team

On Fri, Sep 26, 2014 at 12:10 AM, Sachi Gupta sachi.gu...@tcs.com wrote:

 Hi All,

 Request you all to provide inputs of the below queries:

- As per my understanding GBP constructs are mapped to neutron calls
for example - creating an endpoint, the neutron mapping driver will map it
to the existing port creation method. Similarly to achieve the complete
functionality of GBP openstack, I have checked for the neutron calls and it
includes network, subnet, port, router, security group.

 Correct.



1. Creating a contract - policy rules..Will this include a call to
firewall rules or only security group calls will be done?

 At this point, only security group calls.




1.
2. I need to integrate Openstack with Opendaylight(ODL). To achieve
the interface between two will it be done by ML2 plugin and neutron mapping
driver of Openstack or something additional is required?


That should be enough.


1.
2. The neutron northbound APIs of ODL include network, subnet, port,
router, security groups, firewall calls. Any other call that needs to be
included a part from these in ODL.


Even FWaaS APIs are supported in ODL now? If so, I guess ODL is even
ready to do (basic) 'redirect' action once it is implemented on the mapping
driver then.

And no, you should not need any other APIs.



1.
2. Do the neutron calls that will be mapped by the neutron mapping
driver of openstack are something different from the previous neutron calls
that were being made without using GBP??? For example: The network create
call that was used previously with ODL without using GBP in openstack. Will
it be different from the network call to ODL that will be made by GBP
mapping driver of openstack.

 No. The intent of mapping driver is to allow network policies to be
rendered by current Neutron plugins. So the ODL calls should NOT be any
different from before, the magic happens in the mapping driver layer.




1.
2. How the GBP project in openstack will be affecting the Opendaylight
neutron calls??


It doesn't. That said, I fully expect the ODL Neutron handling layer to
support GBP APIs in the (near) future. When that happens, instead of using
the mapping driver, you will have an additional choice of using the ODL GBP
driver.

Hope it helps,
- Stephen






 Thanks in Advance
 Sachi Gupta



 From:Sumit Naiksatam sumitnaiksa...@gmail.com
 To:OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date:09/23/2014 04:33 AM
 Subject:Re: [openstack-dev] Group-Based Policy Understanding and
 Queries
 --



 Thanks for your interest in GBP, responses inline.

 On Sun, Sep 21, 2014 at 11:35 PM, Sachi Gupta sachi.gu...@tcs.com wrote:
  Hi All,
 
  Request you all to provide inputs on below understanding:
 
  Openstack: Group-based policy is a blueprint for Juno-3 release of
  Openstack. It will extend OpenStack Networking with policy and
 connectivity
  abstractions that enable significantly more simplified and
  application-oriented interfaces than with the current Neutron API model.
  When will be the code ready for Group-based policy as an open source?

 The code has been in review in gerrit for a while now, you can find
 all the links to all the patches here:
 https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
 We are also consolidating this code in Stackforge so that its usable
 starting  from the Juno release.

  Openstack group policy API will be an extension to the Neutron APIs.
 There
  will be a policy manager to manage the policy and policy rules. Will GBP
 a
  part of neutron?? If yes, then will GBP be a part of Horizon under
 neutron?

 The wiki page above has links to client, Horizon and Heat patches.

  Policy driver which will act as an interface(ODL Policy Driver). For eg.
 we
  used neutron ML2 plugin as an interface between Openstack neutron and ODL
  neutron northbound. When will the policy driver for ODL available?
  Openstack policy driver for ODL will act as an interface to ODL. Which
 API
  in ODL, Policy calls from Openstack ODL Policy driver will be hitting??
 

 I know that this was planned, so you would probably need to check with
 the author of the following patch for the status on this:
 https://review.openstack.org/#/c/105606/
 We can also bring this up for discussion during the weekly IRC:
 https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

 
 
  Thanks  Regards
  Sachi Gupta
 
  =-=-=
  Notice: The information contained in this e-mail
  message and/or attachments to it may contain
  confidential or privileged information. If you are
  not the intended recipient, any dissemination, use,
  review, distribution, printing or copying of the
  

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

[Stephen Wong]

I agree with Kevin. Like in Juno, we as a subteam will be shooting for
option 1 (again) for Kilo - ideally we can land in Kilo, and we will work
closely with the community to try to accomplish that. In the meantime, we
need to have a repo to iterate our implementations, build package (Juno
based) to early adopters, and be as transparent as if the code is on
gerrit. With option 2 never picking up momentum when Bob suggested it on
the ML, option 3 being more like an idea discussed by several cores during
the mid-cycle meetup, and option 4 is currently on holding pattern without
any detail but tons of concern raised on ML --- option 5 (stackforge) seems
like the best available option at this point.

Thanks,
- Stephen

On Thu, Sep 11, 2014 at 10:02 AM, Kevin Benton blak...@gmail.com wrote:

 Thanks. This is good writeup.

 Of course this all assumes there is consensus that we should proceed
 with GBP, that we should continue by iterating the currently proposed
 design and code, and that GBP should eventually become part of Neutron.
 These assumptions may still be the real issues :-( .

 Unfortunately I think this is the real root cause. Most of the people that
 worked on GBP definitely want to see it merged into Neutron and is in
 general agreement there. However, some of the other cores disagreed and now
 GBP is sitting in limbo. IIUC, this thread was started to just get GBP to
 some location where it can be developed on and tested that isn't a big
 string of rejected gerrit patches.

 Does the above make some sense? What have I missed?

 Option 1 is great, but I don't see how the same thing that happened in
 Juno would be avoided.

 Option 2 is also good, but that idea didn't seem to catch on. If this
 option is on the table, this seems like the best way to go.

 Option 3 sounded like it brought up a lot of tooling (gerrit) issues with
 regard to how the merging workflow would work.

 Option 4 is unknown until the incubator details are hashed out.

 Option 5 is stackforge. I see this as a better place just to do what is
 already being done right now. You're right that patches would occur without
 core reviewers, but that's essentially what's happening now since nothing
 is getting merged.




 On Thu, Sep 11, 2014 at 7:57 AM, Robert Kukura kuk...@noironetworks.com
 wrote:


 On 9/10/14, 6:54 PM, Kevin Benton wrote:

 Being in the incubator won't help with this if it's a different repo as
 well.

 Agreed.

 Given the requirement for GBP to intercept API requests, the potential
 couplings between policy drivers, ML2 mechanism drivers, and even service
 plugins (L3 router), and the fact Neutron doesn't have a stable [service]
 plugin API, along with the goal to eventually merge GBP into Neutron, I'd
 rank the options as follows in descending order:

 1) Merge the GBP patches to the neutron repo early in Kilo and iterate,
 just like we had planned for Juno ;-) .

 2) Like 1, but with the code initially in a preview subtree to clarify
 its level of stability and support, and to facilitate packaging it as an
 optional component.

 3) Like 1, but merge to a feature branch in the neutron repo and iterate
 there.

 4) Develop in an official neutron-incubator repo, with neutron core
 reviews of each GBP patch.

 5) Develop in StackForge, without neutron core reviews.


 Here's how I see these options in terms of the various considerations
 that have come up during this discussion:

 * Options 1, 2 and 3 most easily support whatever coupling is needed with
 the rest of Neutron. Options 4 and 5 would sometimes require synchronized
 changes across repos since dependencies aren't in terms of stable
 interfaces.

 * Options 1, 2 and 3 provide a clear path to eventually graduate GBP into
 a fully supported Neutron feature, without loss of git history. Option 4
 would have some hope of eventually merging into the neutron repo due to the
 code having already had core reviews. With option 5, reviewing and merging
 a complete GBP implementation from StackForge into the neutron repo would
 be a huge effort, with significant risk that reviewers would want design
 changes not practical to make at that stage.

 * Options 1 and 2 take full advantage of existing review, CI, packaging
 and release processes and mechanisms. All the other options require extra
 work to put these in place.

 * Options 1 and 2 can easily make GBP consumable by early adopters
 through normal channels such as devstack and OpenStack distributions. The
 other options all require the operator or the packager to pull GBP code
 from a different source than the base Neutron code.

 * Option 1 relies on the historical understanding that new Neutron
 extension APIs are not initially considered stable, and incompatible
 changes can occur in future releases. Options 2, 3 and 4 make this
 explicit. Option 5 really has nothing to do with Neutron.

 * Option 5 allows rapid iteration by the GBP team, without waiting for
 core review. This is essential during 

Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

[Stephen Wong]

I agree with Prasad here.

There remains lots of unknown about Neutron incubator and its workflow at
this point, and the idea of Neutron feature branch is at best in embryonic
stage. It seems like among the three options, the most well-defined one is
indeed through stackforge.

When and if the Neutron incubator and/or feature branch process and policy
are better defined, we as a community can assess whether it make sense for
GBP to apply for one of those programs. In the meantime, let's get this
feature in the hands of the early adopters and iterate on our
implementation and further enhancements accordingly.

- Stephen



On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki 
prasad.vella...@oneconvergence.com wrote:

 Sumit
 Thanks for initiating this and also good discussion today on the IRC.

 My thoughts are that it is important to make this available to potential
 users and customers as soon as possible so that we can get the necessary
 feedback. Considering that the neutron cores and community are battling
 nova parity and stability now, I would think it would be tough to get any
 time for incubator or neutron feature branch any time soon.
 I would think it would be better to move GBP into stackforge and then look
 at incubator or neutron feature branch when available.

 prasadv


 On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
 wrote:

 Hi,

 There's been a lot of lively discussion on GBP a few weeks back and we
 wanted to drive forward the discussion on this a bit more. As you
 might imagine, we're excited to move this forward so more people can
 try it out.  Here are the options:

 * Neutron feature branch: This presumably allows the GBP feature to be
 developed independently, and will perhaps help in faster iterations.
 There does seem to be a significant packaging issue [1] with this
 approach that hasn’t been completely addressed.

 * Neutron-incubator: This allows a path to graduate into Neutron, and
 will be managed by the Neutron core team. That said, the proposal is
 under discussion and there are still some open questions [2].

 * Stackforge: This allows the GBP team to make rapid and iterative
 progress, while still leveraging the OpenStack infra. It also provides
 option of immediately exposing the existing implementation to early
 adopters.

 Each of the above options does not preclude moving to the other at a
 later time.

 Which option do people think is more preferable?

 (We could also discuss this in the weekly GBP IRC meeting on Thursday:
 https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy)

 Thanks!

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html

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



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


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

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

[Stephen Wong]

policy target sounds good. +1



On Fri, Aug 8, 2014 at 12:44 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
wrote:

 Thanks Jay for your constructive feedback on this. I personally think
 that 'policy-target' is a good option. I am not sure what the rest of
 the team thinks, perhaps they can chime in.

 On Fri, Aug 8, 2014 at 8:43 AM, Jay Pipes jaypi...@gmail.com wrote:
  On 08/07/2014 01:17 PM, Ronak Shah wrote:
 
  Hi,
  Following a very interesting and vocal thread on GBP for last couple of
  days and the GBP meeting today, GBP sub-team proposes following name
  changes to the resource.
 
 
  policy-point for endpoint
  policy-group for endpointgroup (epg)
 
  Please reply if you feel that it is not ok with reason and suggestion.
 
 
  Thanks Ronak and Sumit for sharing. I, too, wasn't able to attend the
  meeting (was in other meetings yesterday and today).
 
  I'm very happy with the change from endpoint-group - policy-group.
 
  policy-point is better than endpoint, for sure. The only other
 suggestion I
  might have would be to use policy-target instead of policy-point,
 since
  the former clearly delineates what the object is used for (a target for a
  policy).
 
  But... I won't raise a stink about this. Sorry for sparking long and
  tangential discussions on GBP topics earlier this week. And thanks to the
  folks who persevered and didn't take too much offense to my questioning.
 
  Best,
  -jay
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Stephen Wong]

Hi,

Thanks to Armando for steering the discussion back to the original
intent.


On Wed, Aug 6, 2014 at 3:56 PM, Armando M. arma...@gmail.com wrote:


 On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote:

 I think we should merge it and just prefix the API for now with
 '/your_application_will_break_after_juno_if_you_use_this/'


 And you make your call based and what pros and cons exactly, If I am ask?

 Let me start:

 Option 1:
   - pros
 - immediate delivery vehicle for consumption by operators


Buried inside these 100+ posts are posts from two OpenStack users
pleading for their desire to use GBP APIs for their Juno deployments. While
that is a small sample size, it does prove that there is legitimate
interests from our user base to get their hands on this feature.

User feedback is the best way to evolve the APIs moving forward - as
long as these APIs/implementation do not jeopardize the stability of
Neutron. And as many folks in the thread had pointed out, the GBP
implementation currently has really gone the extra mile to ensure it does
NOT do that.



   - cons
 - code is burder from a number of standpoints (review, test, etc)


This is a legitimate concern - that said, if you take a look at the
first patch:

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

there are 30 human reviewers (non-CI) signed up to review the patch at
this time, and among them 9 Neutron core members (8 if you don't count
Sumit, who is the author), as well as a Nova core. From the reception, I
believe the community does not generally treat reviewing GBP related
patches as a burden, but likely as an item of interest. Additionally, with
such board and strong community base willing to involve in reviewing the
code, I think with these many eyes it will hopefully help lessen the
burden on Neutron cores to review and merge these set of patches.




 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster



As a subgroup, we have already iterated the model and APIs for about a
year, with around 40 IRC meetings for community discussions, a PoC demo
that was presented to about 300 audiences back at J-Summit, and actual
implementations in gerrit for months now. Indeed with about 35+ people
responding to this thread, I have yet to see anyone making a claim that
GBP model and APIs as they are now are crap, we have to scrap it and
rethink. I would like to think that we are at a point where we will do
phase by phase enhancements - as should practically any other APIs in
OpenStack - rather than rapid iterations within a cycle. While we already
have some user feedbacks, we would love to get more and more user and
developer community feedbacks to evolve GBP to better fit their needs, and
stackforge unfortunately does not serve that purpose well.



   - cons
 - integration burden with other OpenStack projects (keystone, nova,
 neutron, etc)



That is indeed a major con - evidenced by the fact that the number of
Nova folks joining the discussion on this thread to express integration
concern. We would like to get GBP integration with other OpenStack projects
done as soon as possible. As you pointed out, stackforge is a terrible
option as it pushes the burden of this integration to much later, which
inevitably will incur much higher integration costs moving forward.

Thanks,
- Stephen




 Cheers,
 Armando

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


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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Stephen Wong]

Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
integration, and the preliminary idea, as Bob alluded to, is to add
endpoint as an option in place of Neutron port. But if we can make Nova
EPG-aware, it would be great.


On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam sumitnaiksa...@gmail.com
wrote:

 That's right Kevin, EPG (and its association to the L2/3_Policy)
 capture the attributes which would represent the network-template
 being referenced here.

 Jay, what Bob mentioned here was an option to use the endpoint as a
 one-to-one replacement for the option of using a Neutron port. This is
 more so in the context of providing an evolutionary path (from the way
 Nova currently does it using a pre-defined port). However, if it makes
 sense to make Nova aware of the EPG right at the outset, then that is
 even better.

 I have also noted your suggestion on clarifying the endpoint
 terminology. This was already done in one of the patches you had
 reviewed earlier, and will do that in the first patch as well (where
 you pointed it out now).

 Thanks,
 ~Sumit.

 On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton blak...@gmail.com wrote:
  Specifying an endpoint group would achieve the --networking-template
 effects
  you described. The endpoint group would have all of the security
 policies,
  IP allocation policies, connectivity policies, etc. already setup.
 
 
  On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/05/2014 01:13 PM, Robert Kukura wrote:
 
 
  On 8/5/14, 11:04 AM, Gary Kotton wrote:
 
  Hi,
  Is there any description of how this will be consumed by Nova. My
  concern is this code landing there.
 
  Hi Gary,
 
  Initially, an endpoint's port_id is passed to Nova using nova boot ...
  --nic port-id=port-uuid ..., requiring no changes to Nova. Later,
  slight enhancements to Nova would allow using commands such as nova
  boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
  epg-id=endpoint-group-uuid 
 
 
  Hi Bob,
 
  How exactly is the above a friendlier API for the main user of Neutron,
  which is Nova? I thought one of the main ideas behind the GBP stuff was
 to
  create a more declarative and intuitive API for users of Neutron -- i.e.
  Nova -- to use in constructing needed networking objects. The above just
  seems to me to be exchanging one low-level object (port) with another
  low-level object (endpoint or endpoint group)?
 
  Perhaps the disconnect is due to the term endpoint being used, which,
  everywhere else in the OpenStack universe, means something entirely
  different from GBP.
 
  I guess, based on my understanding of the *intent* of the GBP API, I
 would
  have expected an API more like:
 
   nova boot ... --networking-template UUID
 
  where --networking-template would refer to a network, subnet topology,
 IP
  assignment policy, collection of security groups and firewall policies
 that
  the tenant had established prior to booting an instance... thereby
 making
  the API more intuitive and less cluttered.
 
  Or is it that I just don't understand this new endpoint terminology?
 
  Best,
  -jay
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
  Kevin Benton
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

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

Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy

[Stephen Wong]

I agree with Hemanth also - that this suggestion should be a different
patch. And we should proceed with the current CLI patch.

Thanks,
- Stephen


On Wed, Jul 30, 2014 at 11:13 AM, Hemanth Ravi hemanthrav...@gmail.com
wrote:

 Hi,

 Adding this CLI command seems to be a good way to provide support for the
 second model. This can be submitted as a new review patch to work through
 the approaches to implement this. I suggest the current CLI patch [1] be
 reviewed for the existing spec and completed.

 Ryan, would it possible for you to start a new review submit for the new
 command(s). Could you also provide any references for profiled API in
 IETF, CCITT.

 Thanks,
 -hemanth

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


 On Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats rmo...@us.ibm.com wrote:

 As promised in Monday's Neutron IRC minutes [1], this mail is a trip
 down memory lane looking at the history of the
 Neutron GP project..  The original GP google doc [2] included specifying
 policy via both a produce/consume 1-group
 approach and as a link between two groups.  There was an email thread [3]
 that discussed the relationship between
 these models early on, but that discussion petered out and during a later
 IRC meeting [4] the concept of contracts
 were added, but without changing the basic use case requirements from the
 original document.  A followup meeting [5]
 began the discussion of how to express the original model from the
 contract data model but that discussion doesn't
 appear to have been completed either.  The PoC in Atlanta raised a set of
 issues [6],[7] around the complexity of the
 resulting PoC code.

 The good news is that having looked through the proposed GP code commits
 (links to which can be found at [8) I
 believe that folks that want to be able to specify policies via the
 2-group approach (and yes, I'm one of them) can have
 that without changing the model encoded in those commits. Rather, it can
 be done via the WiP CLI code commit by
 providing a profiled API - this is a technique used by the IETF, CCITT,
 etc. to allow a rich API to be consumed in
 common ways.  In this case, what I'm envisioning is something like

 neutron policy-apply [policy rule] [src group] [destination group]

 in this case, the CLI would perform the contract creation for the policy
 rule, and assigning the proper produce/consume
 edits to the specified source and destination groups.  Note:  this is in
 addition to the CLI providing direct access to the
 underlying data model.  I believe that this is the simplest way to
 bridge the gap and provide support to folks who want
 to specify policy as something between two groups.

 Ryan Moats (regXboi)

 References:
 [1]
 http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt
 [2]
 https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#
 [3]
 http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html
 [4]
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html
 [5]
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html
 [6]
 http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html
 [7]
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html
 [8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

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



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


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

Re: [openstack-dev] mid-cycle policy summit

[Stephen Wong]

Hi Sean,

Yes - please make sure it is going to be in the Bay Area this time :-)

Thanks,
- Stephen


On Thu, Jul 10, 2014 at 5:56 PM, Sean Roberts seanrobert...@gmail.com
wrote:

 I'm thinking location as yahoo Sunnyvale or VMware Palo Alto.

 ~sean

 On Jul 10, 2014, at 5:12 PM, sean roberts seanrobert...@gmail.com wrote:

 The Congress team would like to get us policy people together to discuss
 how each project is approaching policy and our common future prior to the
 Paris summit. More details about the Congress can be found here
 https://wiki.openstack.org/wiki/Congress.

 I have discussed the idea with mestery and mikal, but I wanted to include
 as many other projects as possible.

 I propose this agenda

1. first day each project talks about their policy approach
2. second day whiteboarding and discussion about integrating our
policy approaches

 I propose a few dates

- 11-12 September
- 18-19 September

 ~Sean Roberts


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


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

Re: [openstack-dev] [Neutron][LBaaS] Flavor meeting log captured?

[Stephen Wong]

Hi Vijay,

Yes, it was logged under advanced service:

http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-06-27-17.30.log.html

http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-06-27-17.30.html

- Stephen


On Wed, Jul 2, 2014 at 6:56 AM, Vijay Venkatachalam 
vijay.venkatacha...@citrix.com wrote:

  Hi,

I didn't attend the flavor framework meeting that was scheduled on irc
 #openstack-meeting-3  last Friday. Will be interested to see the meeting
 log/minutes. Was it captured?

 Thanks,
 Vijay V



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


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

Re: [openstack-dev] [ovs-dev] [PATCH 0/7] Basic Geneve Support

[Stephen Wong]

sorry, please ignore


On Wed, Jun 11, 2014 at 10:27 AM, Stephen Wong s3w...@midokura.com wrote:

 Hey,

 What Dan has been waiting for, Geneve support in OVS!!!

 - Stephen


 -- Forwarded message --
 From: Jesse Gross je...@nicira.com
 Date: Tue, Jun 10, 2014 at 4:47 PM
 Subject: [ovs-dev] [PATCH 0/7] Basic Geneve Support
 To: d...@openvswitch.org


 This series implements support for Geneve
 (http://tools.ietf.org/html/draft-gross-geneve-00) in OVS.

 It has two caveats:
  * It is not integrated with upstream yet. The intention is to
upstream this but it requires some refactoring of the UDP tunnel
layer to avoid code duplication, which Andy Zhou is currently
working on. For the time being, this is structured as a purely
out-of-tree protocol and has redundant code with other protocol
of this type (LISP). I expect that this will be addressed by the
time code review is complete on the other portions.

  * Userspace does not fully take advantage of all the features of
Geneve, particularly options. However, the kernel is fully
flexible and can support even unknown options. Additional
capabilities are planned to be added shortly but this provides
a solid starting point.

 Jesse Gross (7):
   lisp: Use IP addresses rather than flow on hash failure.
   datapath: Eliminate memset() from flow_extract.
   datapath: Wrap struct ovs_key_ipv4_tunnel in a new structure.
   tunnel: Add support for matching on OAM packets.
   netdev-vport: Truncate long names for tunnel backing ports.
   datapath: Factor out allocation and verification of actions.
   datapath: Add support for Geneve tunneling.

  datapath/Modules.mk|   1 +
  datapath/actions.c |   6 +-
  datapath/datapath.c|  38 +-
  datapath/datapath.h|   2 +-
  datapath/flow.c|  61 +++-
  datapath/flow.h|  38 +-
  datapath/flow_netlink.c| 153 +++-
  datapath/linux/Modules.mk  |   1 +
  datapath/linux/compat/include/net/geneve.h |  23 ++
  datapath/linux/compat/include/net/ip_tunnels.h |   5 +
  datapath/vport-geneve.c| 464
 +
  datapath/vport-gre.c   |  38 +-
  datapath/vport-lisp.c  |  36 +-
  datapath/vport-vxlan.c |  29 +-
  datapath/vport.c   |   7 +-
  datapath/vport.h   |   3 +-
  include/linux/openvswitch.h|   6 +-
  lib/dpif-linux.c   |   5 +
  lib/flow.c |   2 +
  lib/flow.h |   1 +
  lib/netdev-vport.c |  26 +-
  lib/odp-util.c |  53 ++-
  lib/packets.h  |  18 +
  tests/ovs-vsctl.at |   6 +-
  tests/tunnel.at|  12 +
  vswitchd/vswitch.xml   |  15 +-
  26 files changed, 926 insertions(+), 123 deletions(-)
  create mode 100644 datapath/linux/compat/include/net/geneve.h
  create mode 100644 datapath/vport-geneve.c

 --
 1.9.1

 ___
 dev mailing list
 d...@openvswitch.org
 http://openvswitch.org/mailman/listinfo/dev


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

[openstack-dev] Fwd: [ovs-dev] [PATCH 0/7] Basic Geneve Support

[Stephen Wong]

Hey,

What Dan has been waiting for, Geneve support in OVS!!!

- Stephen

-- Forwarded message --
From: Jesse Gross je...@nicira.com
Date: Tue, Jun 10, 2014 at 4:47 PM
Subject: [ovs-dev] [PATCH 0/7] Basic Geneve Support
To: d...@openvswitch.org


This series implements support for Geneve
(http://tools.ietf.org/html/draft-gross-geneve-00) in OVS.

It has two caveats:
 * It is not integrated with upstream yet. The intention is to
   upstream this but it requires some refactoring of the UDP tunnel
   layer to avoid code duplication, which Andy Zhou is currently
   working on. For the time being, this is structured as a purely
   out-of-tree protocol and has redundant code with other protocol
   of this type (LISP). I expect that this will be addressed by the
   time code review is complete on the other portions.

 * Userspace does not fully take advantage of all the features of
   Geneve, particularly options. However, the kernel is fully
   flexible and can support even unknown options. Additional
   capabilities are planned to be added shortly but this provides
   a solid starting point.

Jesse Gross (7):
  lisp: Use IP addresses rather than flow on hash failure.
  datapath: Eliminate memset() from flow_extract.
  datapath: Wrap struct ovs_key_ipv4_tunnel in a new structure.
  tunnel: Add support for matching on OAM packets.
  netdev-vport: Truncate long names for tunnel backing ports.
  datapath: Factor out allocation and verification of actions.
  datapath: Add support for Geneve tunneling.

 datapath/Modules.mk|   1 +
 datapath/actions.c |   6 +-
 datapath/datapath.c|  38 +-
 datapath/datapath.h|   2 +-
 datapath/flow.c|  61 +++-
 datapath/flow.h|  38 +-
 datapath/flow_netlink.c| 153 +++-
 datapath/linux/Modules.mk  |   1 +
 datapath/linux/compat/include/net/geneve.h |  23 ++
 datapath/linux/compat/include/net/ip_tunnels.h |   5 +
 datapath/vport-geneve.c| 464
+
 datapath/vport-gre.c   |  38 +-
 datapath/vport-lisp.c  |  36 +-
 datapath/vport-vxlan.c |  29 +-
 datapath/vport.c   |   7 +-
 datapath/vport.h   |   3 +-
 include/linux/openvswitch.h|   6 +-
 lib/dpif-linux.c   |   5 +
 lib/flow.c |   2 +
 lib/flow.h |   1 +
 lib/netdev-vport.c |  26 +-
 lib/odp-util.c |  53 ++-
 lib/packets.h  |  18 +
 tests/ovs-vsctl.at |   6 +-
 tests/tunnel.at|  12 +
 vswitchd/vswitch.xml   |  15 +-
 26 files changed, 926 insertions(+), 123 deletions(-)
 create mode 100644 datapath/linux/compat/include/net/geneve.h
 create mode 100644 datapath/vport-geneve.c

--
1.9.1

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

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

[Stephen Wong]

Hi,

Sorry for the late reply. Some comments on Maru's and Amando's points
below:

(1) this model is more complex than linked based

--- as one of the three original members who had action items during the
very first network-policy IRC meeting, I can say that we actually
originally went with the linked-based model. However, as we tried to verify
the model with use cases, we found that while the linked-based is more
intuitive for us infrastructure people (especially networking, as it is
natural for us to apply policy to traffic from src - dst groups), the
group-based model is more intuitive for app-owners (who deal with
app-boundaries).

The ultimate validation (for me at least) came after our conference
presentation where I had a discussion with an operator (from a carrier,
thus apps are likely network functions), and he likes group-policy on two
fronts: (a) separation of control with hierarchical contracts, and (b) very
intuitive for app deployment standpoint (wrap the app, or app-tier, with a
policy).

In terms of implementation complexity - without the optional features
such as label (which we aren't going to add during Juno), I don't think
there is much difference between the two models (APIs, number of new
resources...etc). Mohammad and I did some db and API code initially with
the old model, and the code complexity isn't that much different from what
we have today (sans the label related constructs).

(2) we should iterate code and make them available on gerrit for review as
we have digestible and functional chunks

--- absolutely agreed. And we have reached that agreement during the IRC
meeting yesterday [1]. Particularly for the mapping driver, both Bob
(Kukura) and I reported (also during the IRC meeting[1]) there are still a
lot of work before it is ready. And as we refactor and develop the mapping
driver, we will certainly make it available on gerrit in functional pieces
(along with unit tests).

(3) the mapping driver should utilize Neutron REST API, or more abstract
constructs

--- this is an extremely constructive feedback from Amando. We will
definitely keep this in mind as we refactor and continue development on the
mapping driver. Thanks for that feedback.

(4) why is this project High-Priority?

--- I don't have enough visibility into how Neutron projects are classified
in terms of priority. That said, the effort in general has been on-going
since around H-3 timeframe, and more than 10 developers from seven
different companies have invested to make group-policy what it is today.
Furthermore, from last week's summit, a number of operators and OpenStack
users have shown interest for this feature in OpenStack. So we collectively
as community members would like to plead to the PTL and the rest of the
core team to take these into consideration when making decision on the
relative priority of this project.

Thanks,
- Stephen



[1]
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html


On Fri, May 23, 2014 at 12:31 AM, Prasad Vellanki 
prasad.vella...@oneconvergence.com wrote:

 Great to see the discussions on the ML.
 Mohammad - Good summary.

 I would like to make few  points
 1) The current GP API is tuned towards person deploying the application as
 opposed to the networking person. This is probably a better way as one
 starts to think about self service infrastructure model and person
 deploying applications. We had debated about this on IRC and thought that
 policies/contract applied to the end point group would be easier
 abstraction. The complexity of networking is transformed to the
 implementation while still retaining the flexibility for network admin to
 provide additional policies.
 2) I agree with mohammad that the feedback received for policy driven
 model was very positive. I heard in one of the BOF sessions a large
 operator commenting on this specifically in a very positive way. It would
 be sad to see this relegated to lesser priority. I am not saying that we
 should not address other issues in neutron but this should be addressed
 with equal priority. Especially when a lot of thought and PoC is already
 being done.
 3) It was to good see consensus on the IRC today about the process
 particularly around code simplification, checkins and reviews as raised in
 the emails.

 thanks
 prasadv


 On Thu, May 22, 2014 at 9:10 PM, Mohammad Banikazemi m...@us.ibm.comwrote:

 Thanks to everyone who participated in the Group Policy meeting [1]
 earlier today. A lot of good discussion that hopefully will continue with
 participation from the larger community. I wanted to first make a comment
 about how the Group Policy work was received outside the Neutron community
 and then focus on finding a way for us to make progress.

 I think we had a really good feedback from the larger OpenStack community
 and I would say a wide support for addition of policy abstractions to
 Neutron. If the feedback we received at the summit in 

Re: [openstack-dev] [Neutron][QoS] Weekly IRC Meeting?

[Stephen Wong]

Hi Sean,

Sounds good! +1

- Stephen


On Wed, May 21, 2014 at 7:56 AM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:

 Hi,

 The session that we had on the Quality of Service API extension was well
 attended - I would like to keep the momentum going by proposing a weekly
 IRC meeting.

 How does Tuesdays at 1800 UTC in #openstack-meeting-alt sound?

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

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

Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

[Stephen Wong]

Hi,

I am part of the ServiceVM team and I will attend the NFV IRC meetings.

Thanks,
- Stephen


On Tue, May 20, 2014 at 8:59 AM, Chris Wright chr...@sous-sol.org wrote:

 * balaj...@freescale.com (balaj...@freescale.com) wrote:
   -Original Message-
   From: Kyle Mestery [mailto:mest...@noironetworks.com]
   Sent: Tuesday, May 20, 2014 12:19 AM
   To: OpenStack Development Mailing List (not for usage questions)
   Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
  
   On Mon, May 19, 2014 at 1:44 PM, Ian Wells ijw.ubu...@cack.org.uk
   wrote:
I think the Service VM discussion resolved itself in a way that
reduces the problem to a form of NFV - there are standing issues
 using
VMs for services, orchestration is probably not a responsibility that
lies in Neutron, and as such the importance is in identifying the
problems with the plumbing features of Neutron that cause
implementation difficulties.  The end result will be that VMs
implementing tenant services and implementing NFV should be much the
same, with the addition of offering a multitenant interface to
   Openstack users on the tenant service VM case.
   
Geoff Arnold is dealing with the collating of information from people
that have made the attempt to implement service VMs.  The problem
areas should fall out of his effort.  I also suspect that the key
points of NFV that cause problems (for instance, dealing with VLANs
and trunking) will actually appear quite high up the service VM list
 as
   well.
--
   There is a weekly meeting for the Service VM project [1], I hope some
   representatives from the NFB sub-project can make it to this meeting
 and
   participate there.
  [P Balaji-B37839] I agree with Kyle, so that we will have enough synch
 between Service VM and NFV goals.

 Makes good sense.  Will make sure to get someone there.

 thanks,
 -chris

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

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

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

[Stephen Wong]

Hi Sumit,

Srinivasa has agreed to join the advanced service meeting to kick off
the discussion on this topic at our regular meeting[1]. Looking forward to
working with him and others that are interested in getting this tap
service effort started in Neutron.

Thanks,
- Stephen


[1]
https://wiki.openstack.org/wiki/Meetings#Neutron_Advanced_Services.27_Common_requirements_team_meeting


On Sat, May 17, 2014 at 9:05 PM, Sumit Naiksatam
sumitnaiksa...@gmail.comwrote:

 Hi, Unfortunately I could not participate in this discussion. As
 requested in this thread earlier, it would be good to get a summary of
 the discussion.

 We, in the advanced services team in Neutron, have long discussed[1]
 the possibility of accommodating a tap service. So I would like to
 understand if/how this discussion is aligning with that goal.

 Thanks,
 ~Sumit.

 [1]
 https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering

 On Thu, May 15, 2014 at 6:52 PM, Anil Rao anil@gigamon.com wrote:
  See you all there tomorrow.
 
 
 
  Regards,
 
  Anil
 
 
 
  From: Vinay Yadhav [mailto:vinayyad...@gmail.com]
  Sent: Thursday, May 15, 2014 12:51 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring
  Extension in Neutron
 
 
 
  Hi,
 
 
 
  Booked a slot tomorrow at 9:20 AM at the neutron pod.
 
 
 
 
 
  Cheers,
 
  main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}
 
 
 
  On Thu, May 15, 2014 at 2:50 PM, Stephen Wong s3w...@midokura.com
 wrote:
 
  Hi Vinay,
 
 
 
  I am interested. Please sign up a slot on Neutron pod for tomorrow
  (Friday) and announce the timeslot to the ML.
 
 
 
  Thanks,
 
  - Stephen
 
 
 
 
 
  On Thu, May 15, 2014 at 7:13 AM, Vinay Yadhav vinayyad...@gmail.com
 wrote:
 
  Hi,
 
 
 
  I am Vinay, working with Ericsson.
 
 
 
  I am interested in the following blueprint regarding port mirroring
  extension in neutron:
  https://blueprints.launchpad.net/neutron/+spec/port-mirroring
 
 
 
  I am close to finishing an implementation for this extension in OVS
 plugin
  and would be submitting a neutron spec related to the blueprint soon.
 
 
 
  I would like to know other who are also interested in introducing Port
  Mirroring extension in neutron.
 
 
 
  It would be great if we can discuss and collaborate in development and
  testing this extension
 
 
 
  I am currently attending the OpenStack Summit in Atlanta, so if any of
 you
  are interested in the blueprint, we can meet here in the summit and
 discuss
  how to proceed with the blueprint.
 
 
 
  Cheers,
 
  main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

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

Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

[Stephen Wong]

Hi Chris,

A good number of people involved in Neutron advanced service /
group-policy / individual services subteams will be at the Group Policy
conference session (at 1:30pm). Is it possible to reschedule this to a
different time?

Thanks,
- Stephen


On Wed, May 14, 2014 at 10:06 AM, Chris Wright chr...@redhat.com wrote:

 Thursday at 1:30 PM in the Neutron Pod we'll do
 an NFV BoF.  If you are at design summit and
 interested in Neutron + NFV please come join us.

 thanks,
 -chris

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

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

Re: [openstack-dev] [NFV] New Sub-team and Meeting

[Stephen Wong]

Hi Russ,

Are you in Atlanta? If so, should we find a time to meet at (for
example) the Neutron pod area for face to face meeting over the next two
days?

Thanks,
- Stephen



On Thu, May 15, 2014 at 6:43 AM, Russell Bryant rbry...@redhat.com wrote:

 It is clear that a number of us have been working independently on NFV
 related features.  It would be beneficial to start doing some
 coordination in this area.  To do that, I think we should form an NFV
 group with a regular IRC meeting.  I'd like to see this group be a
 collaboration of developers, deployers, and end users working together
 to make sure we are successful in supporting NFV use cases.

 Proposed set of goals for this group:

  * Organize documentation on the OpenStack wiki of use cases and gaps to
 be filled in OpenStack.

  * Identify relevant development efforts across OpenStack (designs,
 code) and track their progress.

- Provide a page for interested parties to quickly see the status
  across these efforts

- Highlight areas that need additional help.

  * Provide a meeting where people can get together and discuss this work
on a regular basis.

 To get us started, I have created the following wiki page with some
 information on some of the efforts already under way.  I welcome help
 filling it in with more details.

 https://wiki.openstack.org/wiki/Meetings/NFV

 For the IRC meeting, I propose we start meeting in a couple weeks with
 the first one on Wednesday, June 4 at 1400 UTC in #openstack-meeting.
 It's going to be tough to pick a date/time that works for everyone, but
 if this absolutely does not work for you and you'd like to participate,
 feedback is welcome.

 For discussions outside of the meeting about these features, I think we
 should use the openstack-dev mailing list.  When posting about NFV,
 please use the [NFV] tag in the message subject.

 Thanks!

 --
 Russell Bryant

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

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

Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

[Stephen Wong]

+1 for lunch break tomorrow (Friday) - we can still meet at the Neutron pod


On Thu, May 15, 2014 at 7:27 AM, Steve Gordon sgor...@redhat.com wrote:

 - Original Message -
  From: Alan Kavanagh alan.kavan...@ericsson.com
  To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
  Cc: iawe...@cisco.com
  Sent: Thursday, May 15, 2014 10:02:49 AM
  Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
 
  +1 can we reschedule to push this forward Chris please?
 
  Alan

 There are a number of other NFV-related sessions later in the day today as
 well (both on the general and design tracks), perhaps the best option would
 be to meet during the lunch break tomorrow instead, will enough interested
 people still be around?

 Thanks,

 Steve

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

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

Re: [openstack-dev] [Openstack-dev][Neutron] Port Mirroring Extension in Neutron

[Stephen Wong]

Hi Vinay,

I am interested. Please sign up a slot on Neutron pod for tomorrow
(Friday) and announce the timeslot to the ML.

Thanks,
- Stephen



On Thu, May 15, 2014 at 7:13 AM, Vinay Yadhav vinayyad...@gmail.com wrote:

 Hi,

 I am Vinay, working with Ericsson.

 I am interested in the following blueprint regarding port mirroring
 extension in neutron:
 https://blueprints.launchpad.net/neutron/+spec/port-mirroring

 I am close to finishing an implementation for this extension in OVS plugin
 and would be submitting a neutron spec related to the blueprint soon.

 I would like to know other who are also interested in introducing Port
 Mirroring extension in neutron.

 It would be great if we can discuss and collaborate in development and
 testing this extension

 I am currently attending the OpenStack Summit in Atlanta, so if any of you
 are interested in the blueprint, we can meet here in the summit and discuss
 how to proceed with the blueprint.

 Cheers,
 main(i){putchar((5852758((i-1)/2)*8)-!(1i)*'\r')^89main(++i);}

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


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

Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

[Stephen Wong]

Hi Chris,

Lunch time is 12:30pm (or couple minutes after that such that folks can
grab lunch?)?

Thanks,
- Stephen



On Thu, May 15, 2014 at 10:22 AM, Chris Wright chr...@sous-sol.org wrote:

 * Fawad Khaliq (fa...@plumgrid.com) wrote:
  +1 at lunch tomorrow
  On May 15, 2014 12:31 PM, Hoban, Adrian adrian.ho...@intel.com
 wrote:
 
   +1 for lunch tomorrow

 OK.  Let's do lunch tomorow, as Stephen suggested, in the Neutron Pod.

 I still plan to come today at 1:30pm, and will relay any discussion today
 to tomorrow's group for those that are leaving and can't come tomorrow.

   -Original Message-
   From: Chris Wright [mailto:chr...@sous-sol.org]
   Sent: Thursday, May 15, 2014 11:06 AM
   To: Steve Gordon; CARVER, PAUL; Stephen Wong; Alan Kavanagh
   Cc: OpenStack Development Mailing List (not for usage questions);
   iawe...@cisco.com
   Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
  
   * Stephen Wong (s3w...@midokura.com) wrote:
A good number of people involved in Neutron advanced service /
group-policy / individual services subteams will be at the Group
Policy conference session (at 1:30pm). Is it possible to reschedule
this to a different time?
  
   Urgh, we were looking at design summit sessions only.
  
   * Steve Gordon (sgor...@redhat.com) wrote:
 From: Alan Kavanagh alan.kavan...@ericsson.com
 +1 can we reschedule to push this forward Chris please?

There are a number of other NFV-related sessions later in the day
 today
   as well (both on the general and design tracks), perhaps the best
 option
   would be to meet during the lunch break tomorrow instead, will enough
   interested people still be around?
  
   Neutron pod has 2:30 session on QoS that Sean Collins is leading.
   5:00 on VLANs and gateways, (and there's a 4:10 session on SR-IOV
 that's
   related as well).
  
   I think it's hard to move this one.  But happy to find a time to meet
   again tomorrow w/ folks that couldn't make 1:30.
  
   Lunch break works for me, what about others?
  
   thanks,
   -chris
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   --
   Intel Shannon Limited
   Registered in Ireland
   Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
   Registered Number: 308263
   Business address: Dromore House, East Park, Shannon, Co. Clare
  
   This e-mail and any attachments may contain confidential material for
 the
   sole use of the intended recipient(s). Any review or distribution by
 others
   is strictly prohibited. If you are not the intended recipient, please
   contact the sender and delete all copies.
  
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  

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


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

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

Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit

[Stephen Wong]

Hi Steve,

Agreed. I believe Chris already suggested this meeting will reconvene
tomorrow (Friday) at lunchtime - and a number of folks already stated that
they will come.

Thanks,
- Stephen


On Thu, May 15, 2014 at 12:29 PM, Steve Gordon sgor...@redhat.com wrote:

 - Original Message -
  From: IWAMOTO Toshihiro iwam...@valinux.co.jp
  To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
  Sent: Wednesday, May 14, 2014 5:53:23 PM
  Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
 
  At Wed, 14 May 2014 14:40:03 -0700,
  punal patel wrote:
  
   [1  multipart/alternative (7bit)]
   [1.1  text/plain; UTF-8 (7bit)]
   Will this be recorded? or can I join webex?
  
 
  There's no official recording facility.  You may be able to ask
  someone to record or stream.
  BTW, I think it is a good idea to try to take discussion memo on
  etherpad, just as official design summit programs.

 I arrived slightly late, but an etherpad was used to record some notes:

 https://etherpad.openstack.org/p/juno-nfv-bof

 Still hoping to reconvene at lunch tomorrow with the addition of those who
 couldn't make it.

 Steve

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

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

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Stephen Wong]

Hi Sean,

Perfect (I assume it is local time, i.e. 2:30pm EDT).

And I also assume this will be at the Neutron pod?

- Stephen


On Thu, May 8, 2014 at 9:22 AM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:

 On Tue, May 06, 2014 at 07:17:26PM EDT, Mohammad Banikazemi wrote:
 
  There are networking talks in the general session in the afternoon on
  Thursday including the talk on Network Policies from 1:30 to 2:10pm.
  Anything after that is ok with me.

 How does 2:30PM on Thursday sound to everyone?

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

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

Re: [openstack-dev] [neutron] [group-based-policy] Moving the meeting time

[Stephen Wong]

Hi Kyle,

Is 1730UTC available on that channel? If so, and if it is OK with
everyone, it would be great to have it at 1730 UTC instead (10:30am PDT /
1:30pm EDT, which would also be at the same time on a different day of the
week as the advanced service meeting).

Thanks,
- Stephen



On Thu, Apr 10, 2014 at 11:10 AM, Kyle Mestery mest...@noironetworks.comwrote:

 Per our meeting last week, I'd like to propose moving the weekly
 Neutron GBP meeting to 1800UTC (11AM PDT / 2PM EDT) on Thursdays in
 #openstack-meeting-3. If you're not ok with this timeslot, please
 reply on this thread. If I don't hear any dissenters, I'll officially
 move the meeting on the wiki and reply here in a few days.

 Thanks!
 Kyle

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

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

Re: [openstack-dev] [Neutron] advanced servicevm framework: meeting time slot proposal 5:00UTC (Tue) and minutes (was Re: [Neutron] advanced servicevm framework IRC meeting March 18(Tuesday) 23:00 UTC

[Stephen Wong]

Hi Mohammad,

I am sorry to say that the new schedule is indeed 1am EST...

- Stephen


On Wed, Mar 19, 2014 at 9:04 AM, Mohammad Banikazemi m...@us.ibm.com wrote:

 Isaku Yamahata isaku.yamah...@gmail.com wrote on 03/19/2014 04:38:34 AM:

  From: Isaku Yamahata isaku.yamah...@gmail.com
  To: OpenStack Development Mailing List 
 openstack-dev@lists.openstack.org,
  Cc: isaku.yamah...@gmail.com
  Date: 03/19/2014 04:48 AM
  Subject: [openstack-dev] [Neutron] advanced servicevm framework:
  meeting time slot proposal 5:00UTC (Tue) and minutes (was Re:
  [Neutron] advanced servicevm framework IRC meeting March
 18(Tuesday)23:00 UTC)

 
 
  * Time slot
  Weekly Tuesday 5:00UTC-
  Next meeting: March 24, 5:00UTC-
 
  Since there were many requests for new time slots, the proposed time slot
  at the meeting is 5:00UTC.
  The related timezones are
  JST(UTC+9), IST(UTC+5.30), CED(UTC+1), EST(UTC-5), PDT(UTC-7), PST(UTC-8)

 Just wanted to note that if the EST refers to the Eastern Standard Time,
 the conversion for this time zone (UTC-5) and some of the others are not
 correct; for the EST time zone it should be UTC-4 which means a 1:00am EST
 meeting time. I realize it is difficult to have a time slot that works for
 everybody. Will be following this activity through the IRC logs and the ML.

 Best,

 Mohammad


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


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

Re: [openstack-dev] [Neutron] Service VM: irc discussion?

[Stephen Wong]

Hi Isaku,

Seems like you had the meeting at 22:00 UTC instead of 23:00 UTC?

[15:01] yamahata hello? is anybody there for servicevm meeting?
[15:02] yamahata #startmeeting neutron/servicevm
[15:02] openstack Meeting started Tue Mar 11 22:02:14 2014 UTC and is due
to finish in 60 minutes.  The chair is yamahata. Information about MeetBot
at http://wiki.debian.org/MeetBot.
[snip]
[15:24] yamahata #endmeeting
[15:24] *** openstack sets the channel topic to  (Meeting topic: project).
[15:24] openstack Meeting ended Tue Mar 11 22:24:08 2014 UTC.
 Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)

To clarify, are you looking at Tuesdays at 22:00 UTC or 23:00 UTC?

Thanks,
- Stephen



On Wed, Mar 5, 2014 at 9:57 AM, Isaku Yamahata isaku.yamah...@gmail.comwrote:

 Since I received some mails privately, I'd like to start weekly IRC
 meeting.
 The first meeting will be

   Tuesdays 23:00UTC from March 11, 2014
   #openstack-meeting
   https://wiki.openstack.org/wiki/Meetings/ServiceVM
   If you have topics to discuss, please add to the page.

 Sorry if the time is inconvenient for you. The schedule will also be
 discussed, and the meeting time would be changed from the 2nd one.

 Thanks,

 On Mon, Feb 10, 2014 at 03:11:43PM +0900,
 Isaku Yamahata isaku.yamah...@gmail.com wrote:

  As the first patch for service vm framework is ready for review[1][2],
  it would be a good idea to have IRC meeting.
  Anyone interested in it? How about schedule?
 
  Schedule candidate
  Monday  22:00UTC-, 23:00UTC-
  Tuesday 22:00UTC-, 23:00UTC-
  (Although the slot of servanced service vm[3] can be resuled,
   it doesn't work for me because my timezone is UTC+9.)
 
  topics for
  - discussion/review on the patch
  - next steps
  - other open issues?
 
  [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms
  [2] https://review.openstack.org/#/c/56892/
  [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
  --
  Isaku Yamahata isaku.yamah...@gmail.com

 --
 Isaku Yamahata isaku.yamah...@gmail.com

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

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

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

[Stephen Wong]

+1 - that is a good idea! Having it several days before the J-Summit in
Atlanta would be great.

- Stephen


On Fri, Mar 7, 2014 at 1:33 AM, Eugene Nikanorov enikano...@mirantis.comwrote:

 I think mini summit is no worse than the summit itself.
 Everyone who wants to participate can join.
 In fact what we really need is a certain time span of focused work.
 ML, meetings are ok, it's just that dedicated in person meetings (design
 sessions) could be more productive.
 I'm thinking what if such mini-summit is held in Atlanta 1-2-3 days prior
 to the OS summit?
 That could save attendees a lot of time/money.

 Thanks,
 Eugene.



 On Fri, Mar 7, 2014 at 9:51 AM, Mark McClain mmccl...@yahoo-inc.comwrote:


 On Mar 6, 2014, at 4:31 PM, Jay Pipes jaypi...@gmail.com wrote:

  On Thu, 2014-03-06 at 21:14 +, Youcef Laribi wrote:
  +1
 
  I think if we can have it before the Juno summit, we can take
  concrete, well thought-out proposals to the community at the summit.
 
  Unless something has changed starting at the Hong Kong design summit
  (which unfortunately I was not able to attend), the design summits have
  always been a place to gather to *discuss* and *debate* proposed
  blueprints and design specs. It has never been about a gathering to
  rubber-stamp proposals that have already been hashed out in private
  somewhere else.

 You are correct that is the goal of the design summit.  While I do think
 it is wise to discuss the next steps with LBaaS at this point in time, I am
 not a proponent of in person mini-design summits.  Many contributors to
 LBaaS are distributed all over the global, and scheduling a mini summit
 with short notice will exclude valuable contributors to the team.  I'd
 prefer to see an open process with discussions on the mailing list and
 specially scheduled IRC meetings to discuss the ideas.

 mark


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



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


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

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

[Stephen Wong]

I agree with that, and it should take place before the J-Summit.

Location is key here :-)


On Thu, Mar 6, 2014 at 7:32 AM, Jorge Miramontes 
jorge.miramon...@rackspace.com wrote:

   Hi everyone,

  I'd like to gauge everyone's interest in a possible mini-summit for
 Neturon LBaaS. If enough people are interested I'd be happy to try and set
 something up. The Designate team just had a productive mini-summit in
 Austin, TX and it was nice to have face-to-face conversations with people
 in the Openstack community. While most of us will meet in Atlanta in May, I
 feel that a focused mini-summit will be more productive since we won't have
 other Openstack distractions around us. Let me know what you all think!

  Cheers,
 --Jorge

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


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

Re: [openstack-dev] [neutron] [group-policy] Changing the meeting time

[Stephen Wong]

Hi,

On Sun, Feb 16, 2014 at 8:37 PM, Isaku Yamahata isaku.yamah...@gmail.comwrote:

 I'd like to make it sure.
 The followings pages seems still have old time.
 Which is correct? 1700UTC or 1900UTC Thursday?


Per our agreement from the previous meeting, starting from this coming
Thursday (Feb. 20th), the group-policy meeting will take place at 1900 UTC
on Thursdays.

- Stephen




 https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

 https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting

 Thanks,

 On Tue, Feb 11, 2014 at 02:25:12PM -0600,
 Kyle Mestery mest...@siliconloons.com wrote:

  FYI, I've made the change on the meeting pages as well [1]. The Neutron
  Group Policy meeting is now at 1700UTC Thursday's on
 #openstack-meeting-alt.
 
  Thanks!
  Kyle
 
  [1]
 https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting
 
  On Feb 11, 2014, at 11:30 AM, Sumit Naiksatam sumitnaiksa...@gmail.com
 wrote:
 
   Hi Kyle,
  
   The new time sounds good to me as well, thanks for initiating this.
  
   ~sumit.
  
   On Tue, Feb 11, 2014 at 9:02 AM, Stephen Wong s3w...@midokura.com
 wrote:
   Hi Kyle,
  
  Almost missed this - sounds good to me.
  
   Thanks,
   - Stephen
  
  
  
   On Mon, Feb 10, 2014 at 7:30 PM, Kyle Mestery 
 mest...@siliconloons.com
   wrote:
  
   Folks:
  
   I'd like to propose moving the Neutron Group Policy meeting going
   forward, starting with this Thursday. The meeting has been at 1600
   UTC on Thursdays, I'd like to move this to 1700UTC Thursdays
   on #openstack-meeting-alt. If this is a problem for anyone who
   regularly attends this meeting, please reply here. If I don't hear
   any replies by Wednesday, I'll officially move the meeting.
  
   Thanks!
   Kyle
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 Isaku Yamahata isaku.yamah...@gmail.com

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

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

Re: [openstack-dev] [Neutron] Group Policy questions

[Stephen Wong]

Hi Carlos,


On Wed, Feb 12, 2014 at 9:37 AM, Carlos Gonçalves m...@cgoncalves.ptwrote:

 Hi,

 I've a couple of questions regarding the ongoing work on Neutron Group
 Policy proposed in [1].

 1. One of the described actions is redirection to a service chain. How do
 you see BPs [2] and [3] addressing service chaining? Will this BP implement
 its own service chaining mechanism enforcing traffic steering or will it
 make use of, and thus depending on, those BPs?


We plan to support both specifying Neutron native service chain
(reference [2] from your email below) as the object to 'redirect' traffic
to as well as actually setting an ordered chain of services specified
directly via the 'redirect' list. In the latter case we would need the
plugins to perform traffic steering across these services.


2. In the second use case presented in the BP document, Tired application
 with service insertion/chaining, do you consider that the two firewalls
 entities can represent the same firewall instance or two running and
 independent instances? In case it's a shared instance, how would it support
 multiple chains? This is, HTTP(s) traffic from Inet group would be
 redirected to the firewall and then passes through the ADC; traffic from
 App group with destination DB group would also be redirected to the very
 same firewall instance, although to a different destination group as the
 chain differs.


We certainly do not restrict users from setting the same firewall
instance on two different 'redirect' list - but at this point, since the
group-policy project has no plan to perform actual configurations for the
services, it is therefore the users' responsibility to set the rules
correctly on the firewall instance such that the correct firewall rules
will be applied for traffic from group A - B as well as group C - D.

- Stephen



 Thanks.

 Cheers,
 Carlos Gonçalves

 [1]
 https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
 [2]
 https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
 [3]
 https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation


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


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

Re: [openstack-dev] [neutron] [group-policy] Changing the meeting time

[Stephen Wong]

Hi Kyle,

Almost missed this - sounds good to me.

Thanks,
- Stephen



On Mon, Feb 10, 2014 at 7:30 PM, Kyle Mestery mest...@siliconloons.comwrote:

 Folks:

 I'd like to propose moving the Neutron Group Policy meeting going
 forward, starting with this Thursday. The meeting has been at 1600
 UTC on Thursdays, I'd like to move this to 1700UTC Thursdays
 on #openstack-meeting-alt. If this is a problem for anyone who
 regularly attends this meeting, please reply here. If I don't hear
 any replies by Wednesday, I'll officially move the meeting.

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

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

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

[Stephen Wong]

Hi Subra,

On Sun, Dec 15, 2013 at 9:32 PM, Subrahmanyam Ongole osm...@gmail.com wrote:
 Hi Stephan

 Comments inline for redirect action. Perhaps we may want to discuss each
 section in different email threads.


 On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong s3w...@midokura.com wrote:

 Hi,

 During Thursday's  group-policy meeting[1], there are several
 policy-rules related issues which we agreed should be posted on the
 mailing list to gather community comments / consensus. They are:




 (3) Prasad asked for clarification on 'redirect' action, I propose to
 add the following text to document regarding 'redirect' action:

 'redirect' action is used to mirror traffic to other destinations
 - destination can be another endpoint group, a service chain, a port,
 or a network. Note that 'redirect' action type can be used with other
 forwarding related action type such as 'security'; therefore, it is
 entirely possible that one can specify {'security':'deny'} and still
 do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination
 specified on the list CANNOT be the endpoint-group who provides this
 policy. Also, in case of destination being another endpoint-group, the
 policy of this new destination endpoint-group will still be applied

 Please discuss.


 a. In Neutron, I am not sure whether there is a way to get an object given a
 UUID without knowing the type of the object, be it a port, network or a
 specific type of Neutron service.

 I am less likely to err if uuid is qualified by a type or some human
 readable name.

Excellent point. I will add a type field for each redirect object.
Thanks for pointing it out.


 b. Is chain definition (how you build a chain of services) within the scope
 of Global policy BP? A chain may need to be more than an ordered list of
 UUIDs. It needs be a graph with branches anywhere in the chain.  Each path
 could be considered as a separate chain as well.

Service chain as defined by the following:

https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#

which is a Neutron object (service_graph is encapsulated inside
this object; see service_chain resource).

Thanks,
- Stephen



 Thanks
 Subra



 I will gather all the feedback by Wednesday and update the
 document before this coming Thursday's meeting.

 Thanks,
 - Stephen

 [1]
 http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html
 [2]
 https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n

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



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


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

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

[Stephen Wong]

Hi Prasad,

Thanks for the comments, please see responses inline.

On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
prasad.vella...@oneconvergence.com wrote:
 Hi
 Please see inline 


 On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong s3w...@midokura.com wrote:

 Hi,

 During Thursday's  group-policy meeting[1], there are several
 policy-rules related issues which we agreed should be posted on the
 mailing list to gather community comments / consensus. They are:

 (1) Conflict resolution between policy-rules
 --- a priority field was added to the policy-rules attributes
 list[2]. Is this enough to resolve conflict across policy-rules (or
 even across policies)? Please state cases where a cross policy-rules
 conflict can occur.
 --- conflict resolution was a major discussion point during
 Thursday's meeting - and there was even suggestion on setting priority
 on endpoint groups; but I would like to have this email thread focused
 on conflict resolution across policy-rules in a single policy first.

 (2) Default policy-rule actions
 --- there seems to be consensus from the community that we need to
 establish some basic set of policy-rule actions upon which all
 plugins/drivers would have to support
 --- just to get the discussion going, I am proposing:


 Or should this be a query the plugin for supported actions and thus the user
 knows what functionality the plugin can support.  Hence there is no default
 supported list.

I think what we want is a set of must-have actions which
application can utilize by default while using the group-policy APIs.
Without this, application would need to perform many run time checks
and have unpredictable behavior across different deployments.

As for querying for a capability list - I am not against having
such API, but what is the common use case? Having a script querying
for the supported action list and generate policies based on that?
Should we expect policy definition to be so dynamic?


 a.) action_type: 'security'action: 'allow' | 'drop'
 b.) action_type: 'qos'action: {'qos_class': {'critical' |
 'low-priority' | 'high-priority' |

'low-immediate' | 'high-immediate' |

'expedite-forwarding'}
  (a subset of DSCP values - hopefully in language that can
 be well understood by those performing application deployments)
 c.) action_type:'redirect'   action: {UUID, [UUID]...}
  (a list of Neutron objects to redirect to, and the list
 should contain at least one element)


 I am not sure making the UUIDs a list of neutron objects or endpoints will
 work well. It seems that it should more higher level such as list of
 services that form a chain. Lets say one forms a chain of services,
 firewall, IPS, LB. It would be tough to expect user to derive the neutron
 ports create a chain of them. It could be a VM UUID.

Service chain is a Neutron object with UUID:

https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#

so this is not defined by the group-policy subgroup, but from a
different project. We expect operator / tenant to define a service
chain for the users, and users simply pick that as one of the
redirect action object to send traffic to.



 Please discuss. In the document, there is also 'rate-limit' and
 'policing' for 'qos' type, but those can be optional instead of
 required for now

 (3) Prasad asked for clarification on 'redirect' action, I propose to
 add the following text to document regarding 'redirect' action:

 'redirect' action is used to mirror traffic to other destinations
 - destination can be another endpoint group, a service chain, a port,
 or a network. Note that 'redirect' action type can be used with other
 forwarding related action type such as 'security'; therefore, it is
 entirely possible that one can specify {'security':'deny'} and still
 do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination
 specified on the list CANNOT be the endpoint-group who provides this
 policy. Also, in case of destination being another endpoint-group, the
 policy of this new destination endpoint-group will still be applied


 As I said above one needs clarity on what these UUIDs mean. Also do we need
 a call to manage the ordered list around adding, deleting.listing the
 elements in the list.
 One other issue that comes up whether the classifier holds up along the
 chain. The classifier that goes into the chain might not be the same on the
 reverse path.

The redirect list does not define a service chain, a service chain
is defined via other Neutron APIs. The redirect list itself is not
order sensitive.

Thanks,
- Stephen


 Please discuss.

 (4)  We didn't get a chance to discuss this during last Thursday's
 meeting, but there has been discussion on the document regarding
 adding IP address fields in the classifier of a policy-rule. Email may
 be a better forum to state the use cases. Please discuss

[openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

[Stephen Wong]

Hi,

During Thursday's  group-policy meeting[1], there are several
policy-rules related issues which we agreed should be posted on the
mailing list to gather community comments / consensus. They are:

(1) Conflict resolution between policy-rules
--- a priority field was added to the policy-rules attributes
list[2]. Is this enough to resolve conflict across policy-rules (or
even across policies)? Please state cases where a cross policy-rules
conflict can occur.
--- conflict resolution was a major discussion point during
Thursday's meeting - and there was even suggestion on setting priority
on endpoint groups; but I would like to have this email thread focused
on conflict resolution across policy-rules in a single policy first.

(2) Default policy-rule actions
--- there seems to be consensus from the community that we need to
establish some basic set of policy-rule actions upon which all
plugins/drivers would have to support
--- just to get the discussion going, I am proposing:

a.) action_type: 'security'action: 'allow' | 'drop'
b.) action_type: 'qos'action: {'qos_class': {'critical' |
'low-priority' | 'high-priority' |

   'low-immediate' | 'high-immediate' |

   'expedite-forwarding'}
 (a subset of DSCP values - hopefully in language that can
be well understood by those performing application deployments)
c.) action_type:'redirect'   action: {UUID, [UUID]...}
 (a list of Neutron objects to redirect to, and the list
should contain at least one element)

Please discuss. In the document, there is also 'rate-limit' and
'policing' for 'qos' type, but those can be optional instead of
required for now

(3) Prasad asked for clarification on 'redirect' action, I propose to
add the following text to document regarding 'redirect' action:

'redirect' action is used to mirror traffic to other destinations
- destination can be another endpoint group, a service chain, a port,
or a network. Note that 'redirect' action type can be used with other
forwarding related action type such as 'security'; therefore, it is
entirely possible that one can specify {'security':'deny'} and still
do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination
specified on the list CANNOT be the endpoint-group who provides this
policy. Also, in case of destination being another endpoint-group, the
policy of this new destination endpoint-group will still be applied

Please discuss.

(4)  We didn't get a chance to discuss this during last Thursday's
meeting, but there has been discussion on the document regarding
adding IP address fields in the classifier of a policy-rule. Email may
be a better forum to state the use cases. Please discuss here.

I will gather all the feedback by Wednesday and update the
document before this coming Thursday's meeting.

Thanks,
- Stephen

[1] 
http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html
[2] 
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n

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

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

[Stephen Wong]

Hi Eugene,

LBaaS meeting on #openstack-meeting was previously schedule on
Thursdays 1400UTC. And indeed it is still listed on
https://wiki.openstack.org/wiki/Meetings as such, so I believe keeping
it in that timeslot should be fine.

- Stephen


On Tue, Nov 12, 2013 at 7:40 AM, Eugene Nikanorov
enikano...@mirantis.com wrote:
 I agree that it would be better to hold it on a channel with a bot which
 keeps logs.

 I just found that most convenient slots are already taken on both
 openstack-meeting and openstack-meeting-alt.
 14-00 UTC is convenient for me so I'd like to hear other opinions.

 Thanks,
 Eugene.




 On Tue, Nov 12, 2013 at 7:27 PM, Akihiro Motoki amot...@gmail.com wrote:

 Hi Eugene,

 In my opinion, it is better the LBaaS meeting is held on
 #openstack-meeting or #openstack-meeting-alt
 as most OpenStack projects do.

 In addition, information on
 https://wiki.openstack.org/wiki/Meetings#LBaaS_meeting is not
 up-to-date.
 The time is 1400UTC and the channel is #openstack-meeting.
 I saw someone asked is there LBaaS meeting today? on
 #openstack-meeting channel several times.

 Thanks,
 Akihiro


 On Wed, Nov 13, 2013 at 12:08 AM, Eugene Nikanorov
 enikano...@mirantis.com wrote:
  Hi neutron and lbaas folks!
 
  We have a plenty of work to do for the Icehouse, so I suggest we start
  having regular weekly meetings to track our progress.
  Let's meet at #neutron-lbaas on Thursday, 14 at 15-00 UTC
 
  The agenda for the meeting is the following:
  1. Blueprint list to be proposed for the icehouse-1
  2. QA  third-party testing
  3. dev resources evaluation
  4. Additional features requested by users.
 
  Thanks,
  Eugene.
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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



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


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

Re: [openstack-dev] [Neutron] IPv6 sub-team?

[Stephen Wong]

+1 for me as well.

So have we finalized on the meeting time?

Thanks,
- Stephen


On Mon, Nov 11, 2013 at 6:56 AM, Kyle Mestery (kmestery)
kmest...@cisco.com wrote:

 On Nov 8, 2013, at 12:01 AM, Brian Haley brian.ha...@hp.com wrote:

 On 11/08/2013 11:21 AM, Collins, Sean (Contractor) wrote:
 How about scheduling an IRC meeting in close proximity to the other
 Neutron meetings on Mondays?

 * 20:00 to 21:00 UTC, before the Neutron meeting

 +0

 OR

 * 23:00 UTC - after the distributed virtual router meeting?

 -1

 I'd prefer a different day altogether since three meetings in a row would be 
 tough, but that's just my opinion…

 +1 to this.

 -Brian


 ___
 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