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 horizoners),
>
> As the title
uesday, 11 April 2017 at 17:01
> To: "OpenStack Development Mailing List (not for usage questions)"
>
>
>
> Subject: 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"
Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would
we like to have horizon dashboard for neutron stadium projects?
Date
Hi,
I think (a) is also good from TaaS dashboard.
Regards,
Kaz
From: Akihiro Motoki
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
> Hi neutrinos (and horizoners),
17:01
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would
we like to have horizon dashboard for neutron stadium projects?
Hi All:
From and FWaaS perspective – we also think (a) would be ideal
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 ho
o: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 probably the way to go since we can mainly rely on existing
horizon guides for creating new dashb
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
> neutron stadium p
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 suppo
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. Stable branch is created.
>
> __
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 Development Mailing List (not for
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 with ou
Great! Thanks for the update
From: "Armando M."
Reply-To: OpenStack List
Date: Monday, March 6, 2017 at 5:03 PM
To: OpenStack List
Subject: Re: [openstack-dev] [neutron][sfc][release] stable/ocata version
On 5 March 2017 at 23:24, Ihar Hrachyshka
mailto:ihrac...@redhat.com>
41654
> >>
> >>
> >>
> >> So I suggest cutting a stable ASAP and then cherrypicking patches
> >>
> >>
> >>
> >> From: Gary Kotton
> >> Reply-To: OpenStack List
> >> Date: Sunday, March 5, 2017 at 9:36 AM
> >&g
cutting a stable ASAP and then cherrypicking patches
>>
>>
>>
>> From: Gary Kotton
>> Reply-To: OpenStack List
>> Date: Sunday, March 5, 2017 at 9:36 AM
>>
>>
>> To: OpenStack List
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/oca
o: *OpenStack List
> *Date: *Sunday, March 5, 2017 at 9:36 AM
>
> *To: *OpenStack List
> *Subject: *Re: [openstack-dev] [neutron][sfc] stable/ocata version
>
>
>
> Thanks!
>
>
>
> *From: *Jeffrey Zhang
> *Reply-To: *OpenStack List
> *Date: *Sunday, Ma
Kotton
Reply-To: OpenStack List
Date: Sunday, March 5, 2017 at 9:36 AM
To: OpenStack List
Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
Thanks!
From: Jeffrey Zhang
Reply-To: OpenStack List
Date: Sunday, March 5, 2017 at 9:12 AM
To: OpenStack List
Subject: Re: [openstack
Thanks!
From: Jeffrey Zhang
Reply-To: OpenStack List
Date: Sunday, March 5, 2017 at 9:12 AM
To: OpenStack List
Subject: 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
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 pretty blocked at the mom
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, and then I will submit the
release request.
There is a new patch o
Thanks,
Akihiro
>
>
>>
>> Thanks,
>> Cathy
>>
>> -Original Message-----
>> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
>> Sent: Wednesday, July 27, 2016 1:24 PM
>> To: OpenStack Development Mailing List (not for usage questions)
&
ase at all. That’s to follow the ‘release often’
mantra, and boost adoption.
Thanks,
Cathy
-Original Message-
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: [ope
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
On
hyshka [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 wrote:
>
>> On Wed, Jul 06, 2016 at 12:40:48PM +,
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 wrote:
> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>> Hi,
>> Is anyone looking at
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 rel
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
managers
to create it.
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.
signature.a
urity, security_group will block the packets to
>>>>>> enter tab interface if the destination ip not its vm ip . So make sure
>>>>>> you
>>>>>> disabled "security_group" and "port_security" and check the same
>>>>
nt Mailing List (not for usage questions)"
Date:2016/06/10 22:28
Subject: Re: [openstack-dev] [neutron][SFC]
Hi Mohan,
Even if I clone the master branch of networking-sfc project,I get the
following errir when creating flow-classifier, therefore I do precise the
logical-s
gt;
> From:Alioune
> To:"OpenStack Development Mailing List (not for usage questions)"
>
> Date: 2016/06/10 22:28
> Subject:Re: [openstack-dev] [neutron][SFC]
> --
>
>
>
> Hi Mohan,
> Even if I cl
Park, Pudong New
District, Shanghai, China (201203)
From: Alioune
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 2016/06/10 22:28
Subject: Re: [openstack-dev] [neutron][SFC]
Hi Mohan,
Even if I clone the master branch of networking-sfc pro
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)
> *Subject:
(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
Alioune,
If you use networking-sfc master code , you can use create
flow-classifier without logical-source-port specified . But
if back-end driver is OVS , you will end up failure in ovs_driver checks .
If i remembered correct , logical_source_port restriction is
to avoid retrun packets to g
Mohan,
I would like to redirect all http flows in tenant network to the port-chain
and according to your explanation I do specify the neutron-port of source
vm in the classifier.
is there a generic way to to put into the chain all traffc going to a web
server the tenant network ? (to avoide sett
Alioune,
logical-source-port is egress neutron-port of source vm , typically
flow-classifier will classifies packets coming to this neutron port and
forwards to the rest of port-chain if other classifier conditions are
matches.
Thanks.,
Mohankumar.N
On Thu, Jun 9, 2016 at 7:20 PM, Alioune
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 --ethertype IPv4 --source-ip-prefix
55.55.55.2/32 --destination-ip-prefix
Alioune,
networking-sfc resources not installed / not reachable , If installation
is okay, Possibly you may missed service_plugins entry in *neutron.conf *(
in case of manual networking-sfc installation)
it should be ,
*service_plugins =
neutron.services.l3_router.l3_router_plugin.L3RouterPlugi
I've switched from devstack to a normal deployment of openstack/mitaka and
neutron-l2 agent is working fine with sfc. I can boot instances, create
ports.
However I can not create neither flow-classifier nor port-pair ...
neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix
22.1.20.1/
Hi Mohan/Cathy
I've installed now ovs 2.4.0 and followed
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining but I
got this error :
Regards,
+ neutron-ovs-cleanup
2016-06-07 11:25:36.465 22147 INFO neutron.common.config [-] Logging
enabled!
2016-06-07 11:25:36.468 22147 INFO neutr
Hi shihanzhang / Alioune ,
*your kernel (check with uname -r ) should support OVS version , below
table compare kern*el versions 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
Hi Alioune and Cathy,
For devstack on ubuntu14.04, the default ovs version is 2.0.2, so there
was the error as Alioune said.
Do we need to install speical ovs version in networking-sfc devstack
plugin.sh?
在 2016-06-07 07:48:26，"Cathy Zhang" 写道：
Hi Alioune,
Which OVS ver
Hi Alioune,
Which OVS version are 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.org
Cc: Cathy Zhang
Subject: [open
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, and
Hi Oguz,
I will forward you the email on the steps of using DevStack to set up SFC.
As you mentioned, the DevStack support patch for networking-sfc is being worked
on and under review.
The codes that support this feature including unit test codes have been
developed and uploaded for review. W
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
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 don’t believe it’s in conflic
ing behavior".
>
> 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][sf
M
To: 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
&g
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] https://etherpad.openstack.org/p/l2
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
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 port). Rpc operations bet
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.
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 on team me
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"
ma
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 on
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 just yet. I will try
>
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 Ihar,
Ihar Hrachyshka :
(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 drive
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 l
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
deal.
> 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 options with which the
> DHCP
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 co
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 sub-pr
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
On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka
wrote:
> > On 28 Aug 2015, at 14:08, Paul Carver 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 quest
> On 28 Aug 2015, at 14:08, Paul Carver 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.
packaging.
> In
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 c
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 p
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 wor
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 current
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
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'
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
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
76 matches
Mail list logo
