Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Thanks for your feedback, all! It seems we have a consensus and the route is "(a) dashboard repository per project". I would suggest -dashboard as a repository name where is your main repo name. 2017-04-11 0:09 GMT+09:00 Akihiro Motoki : > Hi neutrinos (and

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

t for usage questions)" > <openstack-dev@lists.openstack.org> > Date: Tuesday, 11 April 2017 at 17:01 > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > > > Subject: Re: [openstack-dev] [neut

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Hi, > I think (a) is also good from TaaS dashboard. This opinion is agreed as a TaaS project. Regards, Kaz From: "SUZUKI, Kazuhiro" <k...@jp.fujitsu.com> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Hi, I think (a) is also good from TaaS dashboard. Regards, Kaz From: Akihiro Motoki <amot...@gmail.com> Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects? Date: Tue, 11 Apr 2017 00:09:10 +0900

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

stack-dev@lists.openstack.org> Date: Tuesday, 11 April 2017 at 17:01 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Akihiro, Option (a) would have my vote. - Louis -Original Message- From: Akihiro Motoki [mailto:amot...@gmail.com] Sent: Monday, April 10, 2017 8:09 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

, April 10, 2017 at 4:20 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects? I think 'a' is pro

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

I think 'a' is probably the way to go since we can mainly rely on existing horizon guides for creating new dashboard repos. On Apr 10, 2017 08:11, "Akihiro Motoki" wrote: > Hi neutrinos (and horizoners), > > As the title says, where would we like to have horizon dashboard for

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Excerpts from Akihiro Motoki's message of 2017-04-11 00:09:10 +0900: > Hi neutrinos (and horizoners), > > As the title says, where would we like to have horizon dashboard for > neutron stadium projects? > There are several projects under neutron stadium and they are trying > to add dashboard

[openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Hi neutrinos (and horizoners), As the title says, where would we like to have horizon dashboard for neutron stadium projects? There are several projects under neutron stadium and they are trying to add dashboard support. I would like to raise this topic again. No dashboard support lands since

Re: [openstack-dev] [neutron][sfc] stable/ocata version

great. thanks. On Tue, Mar 7, 2017 at 3:14 AM, Dariusz Śmigiel wrote: > 2017-03-06 11:27 GMT-06:00 Henry Fourie : > > Gary, > > > >Awaiting approval: > > > > https://review.openstack.org/#/c/439200 > > > > -Louis > > > It's merged.

Re: [openstack-dev] [neutron][sfc] stable/ocata version

2017-03-06 11:27 GMT-06:00 Henry Fourie : > Gary, > >Awaiting approval: > > https://review.openstack.org/#/c/439200 > > -Louis > It's merged. Stable branch is created. __ OpenStack

Re: [openstack-dev] [neutron][sfc] stable/ocata version

Gary, Awaiting approval: https://review.openstack.org/#/c/439200 -Louis From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Saturday, March 04, 2017 11:01 PM To: OpenStack List Subject: [openstack-dev] [neutron][sfc] stable/ocata version Hi, We are pretty blocked at the moment

Re: [openstack-dev] [neutron][sfc][release] stable/ocata version

Great! Thanks for the update From: "Armando M." <arma...@gmail.com> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> Date: Monday, March 6, 2017 at 5:03 PM To: OpenStack List <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][sfc][r

Re: [openstack-dev] [neutron][sfc][release] stable/ocata version

he cutting > of > >> the stable version. One example is https://review.openstack.org/441654 > >> > >> > >> > >> So I suggest cutting a stable ASAP and then cherrypicking patches > >> > >> > >> > >> From: Gary Kotton <gkot.

Re: [openstack-dev] [neutron][sfc][release] stable/ocata version

441654 >> >> >> >> So I suggest cutting a stable ASAP and then cherrypicking patches >> >> >> >> From: Gary Kotton <gkot...@vmware.com> >> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> >> Date: Sunday,

Re: [openstack-dev] [neutron][sfc][release] stable/ocata version

*From: *Gary Kotton <gkot...@vmware.com> > *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org> > *Date: *Sunday, March 5, 2017 at 9:36 AM > > *To: *OpenStack List <openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [neutron][sfc] stabl

Re: [openstack-dev] [neutron][sfc] stable/ocata version

Kotton <gkot...@vmware.com> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> Date: Sunday, March 5, 2017 at 9:36 AM To: OpenStack List <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version Thanks! From: Jeffre

Re: [openstack-dev] [neutron][sfc] stable/ocata version

Thanks! From: Jeffrey Zhang <zhang.lei@gmail.com> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> Date: Sunday, March 5, 2017 at 9:12 AM To: OpenStack List <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version Th

Re: [openstack-dev] [neutron][sfc] stable/ocata version

This is talked in [0]. sfc team said ​> we will pull a stable/ocata branch around end of Feb or early March the latest. [0] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton wrote: > Hi, > > We are

[openstack-dev] [neutron][sfc] stable/ocata version

Hi, We are pretty blocked at the moment with our gating on stable/ocata. This is due to the fact that there is no networking-sfc version tagged for ocata. Is there any ETA for this? Thanks Gary __ OpenStack Development

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Akihiro Motoki wrote: 2016-07-29 18:34 GMT+09:00 Ihar Hrachyshka : Cathy Zhang wrote: Hi Ihar and all, Yes, we have been preparing for such a release. We will do one more round of testing to make sure everything works fine,

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

ut you need to be careful when cutting stable/mitaka branch. Thanks, Akihiro > > >> >> Thanks, >> Cathy >> >> -----Original Message- >> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] >> Sent: Wednesday, July 27, 2016 1:24 PM >> To: OpenStac

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

estions) Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version Tony Breeds <t...@bakeyournoodle.com> wrote: On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote: Hi, Is anyone looking at creating a stable/mitaka version? What if someone want to use this for stable/mitaka?

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Hi Assaf, Yes, that makes sense. Thanks, Cathy -Original Message- From: Assaf Muller [mailto:as...@redhat.com] Sent: Thursday, July 28, 2016 1:06 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] > Sent: Wednesday, July 27, 2016 1:24 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version > > Tony Breeds <t...@bakeyournoodle.com>

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Wednesday, July 27, 2016 1:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version Tony Breeds <t...@bakeyournoodle.com> wrote: > On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote: >>

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

On Wed, Jul 27, 2016 at 10:23:30PM +0200, Ihar Hrachyshka wrote: > I only suggest Armando is not dragged into it, the release liaison > (currently me) should be able to handle the request if it comes from the > core team for the subproject. Good point. I defaulted to PTL but you're right the

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Tony Breeds wrote: On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote: Hi, Is anyone looking at creating a stable/mitaka version? What if someone want to use this for stable/mitaka? If that's a thing you need it's a matter of Armando asking the release

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote: > Hi, > Is anyone looking at creating a stable/mitaka version? What if someone want > to use this for stable/mitaka? If that's a thing you need it's a matter of Armando asking the release managers to create it. Yours Tony.

[openstack-dev] [Neutron] SFC stable/mitaka version

Hi, Is anyone looking at creating a stable/mitaka version? What if someone want to use this for stable/mitaka? Thanks Gary __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [neutron][SFC]

port-update p1 --port-security-enabled=False >>>>>> >>>>>> p1 ==> neutron-port >>>>>> >>>>>> Thanks., >>>>>> Mohankumar.N >>>>>> >>>>>> >>>>>> >>>>&g

Re: [openstack-dev] [neutron][SFC]

openstack.org> Date: 2016/06/13 15:49 Subject: Re: [openstack-dev] [neutron][SFC] Hi Alioune / nazhu, Logical-source-port is not mandatory in API , you can create Flow_classifier without logical-source-port , This restriction is moved to OVS driver . Please refer review link https:

Re: [openstack-dev] [neutron][SFC]

na (201203) > > > > From:Alioune <baliou...@gmail.com> > To:"OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date:2016/06/10 22:28 > Subject:Re: [openstack-dev] [neutro

Re: [openstack-dev] [neutron][SFC]

Park, Pudong New District, Shanghai, China (201203) From: Alioune <baliou...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 2016/06/10 22:28 Subject: Re: [openstack-dev] [neutron][SFC]

Re: [openstack-dev] [neutron][SFC]

nates the traffic that is to be processed by the port-chain. > > -Louis > > > > *From:* Alioune [mailto:baliou...@gmail.com] > *Sent:* Thursday, June 09, 2016 6:50 AM > *To:* Mohan Kumar > *Cc:* OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [neutron][SFC]

(not for usage questions) Subject: Re: [openstack-dev] [neutron][SFC] Thanks Mohan, After setting service_plugins and adding sfc tables to neutrondb, I can create port-pair, port-pair-group but classifier creation still claim a logical-source-port parameter. neutron flow-classifier-create

Re: [openstack-dev] [neutron][SFC]

eError(m) >>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron RuntimeError: >>>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron Command: ['sudo', >>>>>>> 'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', >>>>>

Re: [openstack-dev] [neutron][SFC]

tron Exit code: 1 >>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron >>>>>> 2016-06-07 11:25:36.512 22147 ERROR neutron >>>>>> + exit_trap >>>>>> + local r=1 >>>>>> ++ jobs -p >>>>>> + job

Re: [openstack-dev] [neutron][SFC]

evstack/tools/worlddump.py -d /opt/stack/logs >>>>> World dumping... see /opt/stack/logs/worlddump-2016-06-07-112537.txt >>>>> for details >>>>> + exit 1 >>>>> >>>>> >>>>> On 7 June 2016 at 12:08, Mohan Kumar <nmo

Re: [openstack-dev] [neutron][SFC]

ns and corresponding Open vSwitch >>>>> release support >>>>> >>>>> | Open vSwitch | Linux kernel >>>>> |::|:-: >>>>> |1.4.x | 2.6.18 to 3.2 >>>>> |1.5.x | 2.6.18 to 3.

Re: [openstack-dev] [neutron][SFC]

3.2 >>>> |1.6.x | 2.6.18 to 3.2 >>>> |1.7.x | 2.6.18 to 3.3 >>>> |1.8.x | 2.6.18 to 3.4 >>>> |1.9.x | 2.6.18 to 3.8 >>>> |1.10.x| 2.6.18 to 3.8 >>>> |1.11.x| 2.6.18 to 3.8 >>>&

Re: [openstack-dev] [neutron][SFC]

tch release work with?) >>> >>> I installed SFC with OVS 2.4.0 and 2.5.0 and not seen any issue >>> >>> Please check SFC wiki for installation guidelines : >>> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining >>> >>> &

Re: [openstack-dev] [neutron][SFC]

> >> >> >> >> >> 在 2016-06-07 07:48:26，"Cathy Zhang" <cathy.h.zh...@huawei.com> 写道： >> >> Hi Alioune, >> >> >> >> Which OVS version are you using? >> >> Try openvswitch version 2.4.0 and restart the ope

Re: [openstack-dev] [neutron][SFC]

you using? > > Try openvswitch version 2.4.0 and restart the openvswitch-server before > installing the devstack. > > > > Cathy > > > > *From:* Alioune [mailto:baliou...@gmail.com] > *Sent:* Friday, June 03, 2016 9:07 AM > *To:* openstack-dev@lists.openstack.o

Re: [openstack-dev] [neutron][SFC]

hy Zhang Subject: [openstack-dev][neutron][SFC] Probleme with OpenStack SFC Hi all, I've installed Openstack SFC with devstack and all module are corretly running except the neutron L2-agent After a "screen -rd", it seems that there is a conflict between l2-agent and SFC (se

Re: [openstack-dev] [neutron][SFC]

: [openstack-dev][neutron][SFC] Probleme with OpenStack SFC Hi all, I've installed Openstack SFC with devstack and all module are corretly running except the neutron L2-agent After a "screen -rd", it seems that there is a conflict between l2-agent and SFC (see trace bellow). I solved

[openstack-dev] [neutron][SFC]

Probleme with OpenStack SFC Hi all, I've installed Openstack SFC with devstack and all module are corretly running except the neutron L2-agent After a "screen -rd", it seems that there is a conflict between l2-agent and SFC (see trace bellow). I solved the issue with "sudo ovs-vsctl set bridge br

[openstack-dev] [neutron][sfc] Is there a bug in networking-sfc?

Hi Cathy and other guys I am a beginner that use networking-sfc. I create a port-chain-list that want to steer a flow that is from public-net to private-net to SF node. The DVR is enable in my test environment. The test result is the flow was steered from destination node to SF node and

Re: [openstack-dev] [neutron][sfc] A standards-compliant SFC API

On 20 April 2016 at 09:31, Duarte Cardoso, Igor < igor.duarte.card...@intel.com> wrote: > Dear OpenStack Community, > > > > We've been investigating options in/around OpenStack for supporting > Service Function Chaining. The networking-sfc project has made significant > progress in this space,

[openstack-dev] [neutron][sfc] A standards-compliant SFC API

Dear OpenStack Community, We've been investigating options in/around OpenStack for supporting Service Function Chaining. The networking-sfc project has made significant progress in this space, and we see lots of value in what has been completed. However, when we looked at the related IETF

Re: [openstack-dev] [neutron][sfc]

Mailing List (not for usage questions) Subject: [openstack-dev] [neutron][sfc] Hi, Is there any working Devstack configuration for sfc testing? I just saw one commit that is waiting review. __ OpenStack Development Mailing

[openstack-dev] [neutron][sfc]

Hi, Is there any working Devstack configuration for sfc testing? I just saw one commit that is waiting review. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

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

Perfect. The agent will have all static hooks for the extensions in place, like they are used in todays agents (the modular agent was derived from existing lb agent). The knowledge which concrete extension implementation to chose (e.g. lb) comes from the implementation specific manager class that

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

ot;. > > Thanks, > Cathy > > -Original Message- > From: Paul Carver [mailto:pcar...@paulcarver.us] > Sent: Monday, November 16, 2015 7:50 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron][sfc] How could an

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

Andreas Scheuring wrote: Hi all, I wonder if this is somehow in conflict with the modular l2 agent approach I'm currently following up for linuxbridge, macvtap and sriov? - RFE: [1] - Frist patchset [2] I don't think so, but to be sure I wanted to raise it up. I

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

On 11/13/2015 7:03 PM, Henry Fourie wrote: I wonder whether just pushing flows into the existing tables at random points in time can be unstable and break the usual flow assumed by the main agent loop. LF> No not expect any issues. Am I making sense? [1]

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

OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ? On 11/13/2015 7:03 PM, Henry Fourie wrote: > > I wonder whether just pushing flows into the existing tables at random >

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

Ihar, See inline. - Louis -Original Message- From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] Sent: Thursday, November 12, 2015 1:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension

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

Henry Fourie wrote: Ihar, Networking-sfc installs flows on br-int and br-tun for steering traffic to the SFC port-pairs. On each bridge additional tables are used for an egress forwarding pipeline (from the service VM port) and an ingress pipeline (to the service VM

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

On 11/9/2015 9:59 PM, Vikram Choudhary wrote: Hi Cathy, Could you please check on this. My mother passed away yesterday and I will be on leave for couple of weeks. I'm very sorry to hear that. Please take all the time you need.

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

questions) Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ? Thanks Thomas, much appreciated. I need to admit that we haven’t heard from SFC folks just yet. I will try to raise awareness that we wait for their feedback today on team meeting

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

List (not for usage questions) Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ? Thanks Thomas, much appreciated. I need to admit that we haven’t heard from SFC folks just yet. I will try to raise awareness that we wait for their feedback today

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

Zhang Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ? Hi Cathy, Could you please check on this. My mother passed away yesterday and I will be on leave for couple of weeks. Thanks Vikram On 09-Nov-2015 6:15 pm, "Ihar Hrachyshka&quo

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

Thanks Thomas, much appreciated. I need to admit that we haven’t heard from SFC folks just yet. I will try to raise awareness that we wait for their feedback today on team meeting. Adding [sfc] tag to the topic to get more attention. Ihar Thomas Morin wrote: Hi

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

Hi Cathy, Could you please check on this. My mother passed away yesterday and I will be on leave for couple of weeks. Thanks Vikram On 09-Nov-2015 6:15 pm, "Ihar Hrachyshka" wrote: > Thanks Thomas, much appreciated. > > I need to admit that we haven’t heard from SFC folks

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

No, I wouldn't consider that to be monkey-patching. That's something that we have a pluggable driver interface for. As Ihar pointed out, you will have to be careful maintaining it since the class you are subclassing may move or alter the '_build_cmdline_callback' method, but that isn't a huge

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

On 08/31/2015 01:50 AM, Kevin Benton wrote: The purpose of big tent isn't to have a bunch of sub-projects change the neutron core APIs and reference in ways they deem necessary. That will lead to a terrible user experience where the core functionality changes depending on which sub-projects are

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

(not for usage questions) Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging No, I wouldn't consider that to be monkey-patching. That's something that we have a pluggable driver interface

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

Hi Kevin, I currently have an example of this kind of thing that I'm working on, and I'd appreciate hearing your view on what is the best solution. My requirement was to change some of the command line options with which the DHCP agent invokes Dnsmasq. My first implementation of this was in

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

> On 31 Aug 2015, at 13:36, Neil Jerram wrote: > > Hi Kevin, > > I currently have an example of this kind of thing that I'm working on, and > I'd appreciate hearing your view on what is the best solution. > > My requirement was to change some of the command line

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

If your sub-project requires changes to the Neutron API or client, then those need to be made in the in the main neutron and client projects. monkey-patching or completely replacing components of the main neutron project is not the way to go. The purpose of big tent isn't to have a bunch of

[openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

Has anyone written anything up about expectations for how Big Tent or Neutron Stadium projects are expected to be installed/distributed/packaged? In particular, I'm wondering how we're supposed to handle changes to Neutron components. For the networking-sfc project we need to make additions

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

On 28 Aug 2015, at 14:08, Paul Carver pcar...@paulcarver.us wrote: Has anyone written anything up about expectations for how Big Tent or Neutron Stadium projects are expected to be installed/distributed/packaged? Seems like your questions below are more about extendability than e.g.

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: On 28 Aug 2015, at 14:08, Paul Carver pcar...@paulcarver.us wrote: Has anyone written anything up about expectations for how Big Tent or Neutron Stadium projects are expected to be installed/distributed/packaged?

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

It's possible that I've misunderstood Big Tent/Stadium, but I thought we were talking about enhancements to Neutron, not separate unrelated projects. We have several efforts focused on adding capabilities to Neutron. This isn't about polluting the Neutron namespace but rather about adding

Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

On Fri, Jul 24, 2015 at 04:27:57PM EDT, Cathy Zhang wrote: Do you know the process of getting the API spec published at http://specs.openstack.org/openstack/neutron-specs/? We can port the merged networking-sfc API spec and the latest patch over. Or we have to wait until we have some

Re: [openstack-dev] [Neutron][SFC]The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

On Sun, Jul 26, 2015 at 12:34:29AM EDT, Paul Carver wrote: I would, however, like input on the idea of CLI and API shortcuts. I don't think the API proposed in 186663 should be a completely separate implementation of creating flow table entries, but I can see the appeal of CLI options and

Re: [openstack-dev] [Neutron][SFC]The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

On 7/27/2015 4:49 PM, Sean M. Collins wrote: I think when the API is too complex, where python-neutronclient is expected to create a better UX, that means that the API itself may need some further thinking and simplification. I think you are right however, that Get me a network is the first

Re: [openstack-dev] [Neutron][SFC]The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

On 7/24/2015 6:50 PM, Cathy Zhang wrote: Hi Everyone, In our last networking-sfc project IRC meeting, an issue was brought up that the API proposed in https://review.openstack.org/#/c/186663/ has a lot of duplication to the SFC API https://review.openstack.org/#/c/192933/ that is being

Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

On Thu, Jul 23, 2015 at 10:45:50PM EDT, Paul Carver wrote: On a general topic of wiki cleanup, what's the preferred mechanism for documenting APIs? I prefer that the APIs be submitted in a spec, so that they are published on http://specs.openstack.org/openstack/neutron-specs/ At least there,

Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

Hi Paul, -Original Message- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Thursday, July 23, 2015 7:46 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API On a general topic of wiki cleanup, what's

Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

Hi Sean, -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: Friday, July 24, 2015 7:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API On Thu, Jul 23, 2015 at 10:45

Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

On a general topic of wiki cleanup, what's the preferred mechanism for documenting APIs? Wiki page [1] largely duplicates the content of the spec in [2] I dislike duplication of information because it's likely to get out of sync. I'd rather use hyperlinks whenever possible. However, linking to

[openstack-dev] [Neutron][SFC] Launchpad cleanup

Is it possible to delete dead blueprints or at least change the section at the top to just provide a URL to the blueprint that supersedes it? Blueprint [1] links to a bunch of abandoned reviews and references its parent Blueprint [2] which also links to abandoned work. The current work on

[openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

As a courtesy to anyone who may have worked on it, I wanted to notify the list that I'm going to delete [1] from wiki page [2]. I may actually delete [2] completely. I'm going to update the content on [3] to reference the new SFC API spec that has just been merged. Currently [3] links to [2]