Re: [openstack-dev] [neutron] upgrade from liberty to mitaka

2016-10-16 Thread Richard Woo 
Ihar,

After looking at version of python-neutron-fwaas package, I found it is
still the old one. I upgraded this package to mitaka version, the problem
went away.

Thanks for your help.

Richard

On Sun, Oct 16, 2016 at 12:00 PM, Richard Woo 
wrote:

> Ihar,
>
> Thanks for your reply, seems like the fwaas is install when installed
> neutron server:
>
> root@controller-01:~# dpkg -l | grep neutron
> ii  neutron-common   2:8.2.0-0ubuntu1~cloud0
> all  Neutron is a virtual network service for Openstack - common
> ii  neutron-plugin-ml2   2:8.2.0-0ubuntu1~cloud0
> all  Neutron is a virtual network service for Openstack - ML2
> plugin
> ii  neutron-server   2:8.2.0-0ubuntu1~cloud0
> all  Neutron is a virtual network service for Openstack - server
> ii  python-neutron   2:8.2.0-0ubuntu1~cloud0
> all  Neutron is a virtual network service for Openstack -
> Python library
> ii  python-neutron-fwaas 1:7.1.1-0ubuntu1~cloud0
> all  Firewall-as-a-Service driver for OpenStack Neutron
> ii  python-neutron-lib   0.0.2-2~cloud0
>  all  Neutron shared routines and utilities - Python 2.7
> ii  python-neutronclient 1:3.1.0-0ubuntu1~cloud0
> all  client API library for Neutron
> root@controller-01:~# apt-get remove python-neutron-fwaas
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages were automatically installed and are no longer
> required:
>   ipset libipset3 libmnl0 python-neutron python-neutron-lib
> python-openvswitch
> Use 'apt-get autoremove' to remove them.
> The following packages will be REMOVED:
>   neutron-common neutron-plugin-ml2 neutron-server python-neutron-fwaas
> 0 upgraded, 0 newly installed, 4 to remove and 30 not upgraded.
> After this operation, 1,149 kB disk space will be freed.
> Do you want to continue? [Y/n] n
> Abort.
> root@controller-01:~#
>
> I checked service_plugins value in 'neutron.conf', 'router' is enabled but
> not fwaas:
>
> # The core plugin Neutron will use (string value)
> core_plugin = ml2
>
> # The service plugins Neutron will use (list value)
> service_plugins = router
>
>
> Richard
>
>
> On Sun, Oct 16, 2016 at 3:36 AM, Ihar Hrachyshka 
> wrote:
>
>> Richard Woo  wrote:
>>
>> Hello, folks,
>>>
>>> I have a small cluster running openstack liberty, today I am starting to
>>> upgrading to Mitaka.
>>>
>>> I am having a problem to launch l3 agent on network node.
>>>
>>> I got the following error:
>>> Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward
>>> compatibility. SIGUSR1 will no longer be registered in a future release, so
>>> please use SIGUSR2 to generate reports.
>>> Option "verbose" from group "DEFAULT" is deprecated for removal.  Its
>>> value may be silently ignored in the future.
>>> 2016-10-15 22:13:20.800 24466 INFO neutron.common.config [-] Logging
>>> enabled!
>>> 2016-10-15 22:13:20.801 24466 INFO neutron.common.config [-]
>>> /usr/bin/neutron-l3-agent version 8.2.0
>>> 2016-10-15 22:13:20.801 24466 DEBUG neutron.common.config [-] command
>>> line: /usr/bin/neutron-l3-agent --config-file=/etc/neutron/neutron.conf
>>> --config-file=/etc/neutron/l3_agent.ini 
>>> --log-file=/var/log/neutron/l3-agent.log
>>> setup_logging /usr/lib/python2.7/dist-packag
>>> es/neutron/common/config.py:269
>>> 2016-10-15 22:13:20.923 24466 DEBUG oslo_messaging._drivers.amqpdriver
>>> [req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] CALL msg_id:
>>> 0b6eb35b95ec4edca605b2d3c6a76d37 exchange 'neutron' topic 'q-l3-plugin'
>>> _send /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amq
>>> pdriver.py:454
>>> /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py:187:
>>> RuntimeWarning: You have iterated over the result of
>>> pkg_resources.parse_version. This is a legacy behavior which is
>>> inconsistent with the new version class introduced in setuptools 8.0. In
>>> most cases, conversion to a tuple is unnecessary. For comparison of
>>> versions, sort the Version instances directly. If you have another use case
>>> requiring the tuple, please file a bug with the setuptools project
>>> describing that need.
>>>   stacklevel=1,
>>> 2016-10-15 22:13:20.951 24466 DEBUG oslo_messaging._drivers.amqpdri

Re: [openstack-dev] [neutron] upgrade from liberty to mitaka

2016-10-16 Thread Richard Woo 
Ihar,

Thanks for your reply, seems like the fwaas is install when installed
neutron server:

root@controller-01:~# dpkg -l | grep neutron
ii  neutron-common   2:8.2.0-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - common
ii  neutron-plugin-ml2   2:8.2.0-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - ML2
plugin
ii  neutron-server   2:8.2.0-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - server
ii  python-neutron   2:8.2.0-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack -
Python library
ii  python-neutron-fwaas 1:7.1.1-0ubuntu1~cloud0
all  Firewall-as-a-Service driver for OpenStack Neutron
ii  python-neutron-lib   0.0.2-2~cloud0
   all  Neutron shared routines and utilities - Python 2.7
ii  python-neutronclient 1:3.1.0-0ubuntu1~cloud0
all  client API library for Neutron
root@controller-01:~# apt-get remove python-neutron-fwaas
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  ipset libipset3 libmnl0 python-neutron python-neutron-lib
python-openvswitch
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  neutron-common neutron-plugin-ml2 neutron-server python-neutron-fwaas
0 upgraded, 0 newly installed, 4 to remove and 30 not upgraded.
After this operation, 1,149 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
root@controller-01:~#

I checked service_plugins value in 'neutron.conf', 'router' is enabled but
not fwaas:

# The core plugin Neutron will use (string value)
core_plugin = ml2

# The service plugins Neutron will use (list value)
service_plugins = router


Richard


On Sun, Oct 16, 2016 at 3:36 AM, Ihar Hrachyshka 
wrote:

> Richard Woo  wrote:
>
> Hello, folks,
>>
>> I have a small cluster running openstack liberty, today I am starting to
>> upgrading to Mitaka.
>>
>> I am having a problem to launch l3 agent on network node.
>>
>> I got the following error:
>> Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward
>> compatibility. SIGUSR1 will no longer be registered in a future release, so
>> please use SIGUSR2 to generate reports.
>> Option "verbose" from group "DEFAULT" is deprecated for removal.  Its
>> value may be silently ignored in the future.
>> 2016-10-15 22:13:20.800 24466 INFO neutron.common.config [-] Logging
>> enabled!
>> 2016-10-15 22:13:20.801 24466 INFO neutron.common.config [-]
>> /usr/bin/neutron-l3-agent version 8.2.0
>> 2016-10-15 22:13:20.801 24466 DEBUG neutron.common.config [-] command
>> line: /usr/bin/neutron-l3-agent --config-file=/etc/neutron/neutron.conf
>> --config-file=/etc/neutron/l3_agent.ini 
>> --log-file=/var/log/neutron/l3-agent.log
>> setup_logging /usr/lib/python2.7/dist-packages/neutron/common/config.py:
>> 269
>> 2016-10-15 22:13:20.923 24466 DEBUG oslo_messaging._drivers.amqpdriver
>> [req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] CALL msg_id:
>> 0b6eb35b95ec4edca605b2d3c6a76d37 exchange 'neutron' topic 'q-l3-plugin'
>> _send /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/
>> amqpdriver.py:454
>> /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py:187:
>> RuntimeWarning: You have iterated over the result of
>> pkg_resources.parse_version. This is a legacy behavior which is
>> inconsistent with the new version class introduced in setuptools 8.0. In
>> most cases, conversion to a tuple is unnecessary. For comparison of
>> versions, sort the Version instances directly. If you have another use case
>> requiring the tuple, please file a bug with the setuptools project
>> describing that need.
>>   stacklevel=1,
>> 2016-10-15 22:13:20.951 24466 DEBUG oslo_messaging._drivers.amqpdriver
>> [-] received reply msg_id: 0b6eb35b95ec4edca605b2d3c6a76d37 __call__
>> /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/
>> amqpdriver.py:302
>> 2016-10-15 22:13:20.953 24466 DEBUG neutron.callbacks.manager
>> [req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] Subscribe:
>>  router after_create
>> subscribe /usr/lib/python2.7/dist-packages/neutron/callbacks/manager.
>> py:41
>> 2016-10-15 22:13:20.954 24466 DEBUG neutron.callbacks.manager
>> [req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] Subscribe:
>>  router before_delete
>> subscribe /usr/lib/python2.7/dist-packages/neutron/callb

[openstack-dev] [neutron] upgrade from liberty to mitaka

2016-10-15 Thread Richard Woo 
Hello, folks,

I have a small cluster running openstack liberty, today I am starting to
upgrading to Mitaka.

I am having a problem to launch l3 agent on network node.

I got the following error:
Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward
compatibility. SIGUSR1 will no longer be registered in a future release, so
please use SIGUSR2 to generate reports.
Option "verbose" from group "DEFAULT" is deprecated for removal.  Its value
may be silently ignored in the future.
2016-10-15 22:13:20.800 24466 INFO neutron.common.config [-] Logging
enabled!
2016-10-15 22:13:20.801 24466 INFO neutron.common.config [-]
/usr/bin/neutron-l3-agent version 8.2.0
2016-10-15 22:13:20.801 24466 DEBUG neutron.common.config [-] command line:
/usr/bin/neutron-l3-agent --config-file=/etc/neutron/neutron.conf
--config-file=/etc/neutron/l3_agent.ini
--log-file=/var/log/neutron/l3-agent.log setup_logging
/usr/lib/python2.7/dist-packages/neutron/common/config.py:269
2016-10-15 22:13:20.923 24466 DEBUG oslo_messaging._drivers.amqpdriver
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] CALL msg_id:
0b6eb35b95ec4edca605b2d3c6a76d37 exchange 'neutron' topic 'q-l3-plugin'
_send
/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:454
/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py:187:
RuntimeWarning: You have iterated over the result of
pkg_resources.parse_version. This is a legacy behavior which is
inconsistent with the new version class introduced in setuptools 8.0. In
most cases, conversion to a tuple is unnecessary. For comparison of
versions, sort the Version instances directly. If you have another use case
requiring the tuple, please file a bug with the setuptools project
describing that need.
  stacklevel=1,
2016-10-15 22:13:20.951 24466 DEBUG oslo_messaging._drivers.amqpdriver [-]
received reply msg_id: 0b6eb35b95ec4edca605b2d3c6a76d37 __call__
/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:302
2016-10-15 22:13:20.953 24466 DEBUG neutron.callbacks.manager
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] Subscribe:  router after_create subscribe
/usr/lib/python2.7/dist-packages/neutron/callbacks/manager.py:41
2016-10-15 22:13:20.954 24466 DEBUG neutron.callbacks.manager
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] Subscribe:  router before_delete subscribe
/usr/lib/python2.7/dist-packages/neutron/callbacks/manager.py:41
2016-10-15 22:13:20.955 24466 DEBUG
neutron_fwaas.services.firewall.agents.l3reference.firewall_l3_agent
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] Initializing firewall
agent __init__
/usr/lib/python2.7/dist-packages/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py:55
2016-10-15 22:13:20.956 24466 CRITICAL neutron
[req-8c392909-20ed-45f4-b997-9302008d0075 - - - - -] AttributeError:
'module' object has no attribute 'FIREWALL_PLUGIN'
2016-10-15 22:13:20.956 24466 ERROR neutron Traceback (most recent call
last):
2016-10-15 22:13:20.956 24466 ERROR neutron   File
"/usr/bin/neutron-l3-agent", line 10, in 
2016-10-15 22:13:20.956 24466 ERROR neutron sys.exit(main())
2016-10-15 22:13:20.956 24466 ERROR neutron   File
"/usr/lib/python2.7/dist-packages/neutron/cmd/eventlet/agents/l3.py", line
17, in main
2016-10-15 22:13:20.956 24466 ERROR neutron l3_agent.main()
2016-10-15 22:13:20.956 24466 ERROR neutron   File
"/usr/lib/python2.7/dist-packages/neutron/agent/l3_agent.py", line 57, in
main
2016-10-15 22:13:20.956 24466 ERROR neutron manager=manager)
2016-10-15 22:13:20.956 24466 ERROR neutron   File
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 331, in create
2016-10-15 22:13:20.956 24466 ERROR neutron
periodic_fuzzy_delay=periodic_fuzzy_delay)
2016-10-15 22:13:20.956 24466 ERROR neutron   File
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 264, in __init__
2016-10-15 22:13:20.956 24466 ERROR neutron self.manager =
manager_class(host=host, *args, **kwargs)
2016-10-15 22:13:20.956 24466 ERROR neutron   File
"/usr/lib/python2.7/dist-packages/neutron/agent/l3/agent.py", line 635, in
__init__
2016-10-15 22:13:20.956 24466 ERROR neutron
super(L3NATAgentWithStateReport, self).__init__(host=host, conf=conf)
2016-10-15 22:13:20.956 24466 ERROR neutron   File
"/usr/lib/python2.7/dist-packages/neutron/agent/l3/agent.py", line 243, in
__init__
2016-10-15 22:13:20.956 24466 ERROR neutron super(L3NATAgent,
self).__init__(conf=self.conf)
2016-10-15 22:13:20.956 24466 ERROR neutron   File
"/usr/lib/python2.7/dist-packages/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py",
line 77, in __init__
2016-10-15 22:13:20.956 24466 ERROR neutron self.fwplugin_rpc =
FWaaSL3PluginApi(topics.FIREWALL_PLUGIN,
2016-10-15 22:13:20.956 24466 ERROR neutron AttributeError: 'module' object
has no attribute 'FIREWALL_PLUGIN'
2016-10-15 22:13:20.956 24466 ERROR neutron

On our setup, we did not use any FWaaS service, please give us hints what
may cause this pro

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

2015-07-16 Thread Richard Woo 
Sean, I agreed with you. But after I read Yan's user case. I think the
FWaaS API may become too complex for that case.

By extending security group is better option.


On Thu, Jul 16, 2015 at 11:48 AM, Sean M. Collins 
wrote:

> On Tue, Jul 14, 2015 at 03:31:49AM PDT, Kevin Benton wrote:
> > Unfortunately the security groups API does not have mac-level rules right
> > now.
>
> There is also the fact that the Security Group API is limited (by
> design) to do fairly simple things, and also that the model has similar
> fields to the AWS API for Security Groups.
>
> Overall, I want to try and minimize (or even avoid) any changes to the
> Security Group API, and try and collect usecases for more complex
> filtering to see if the FwaaS API can satisfy - since it is an API that
> we have more freedom to change and modify compared to an API that is
> named the same as something in AWS - and it is meant for more complex
> usecases.
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html
> --
> Sean M. Collins
>
> __
> 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] - the setup of a DHCP sub-group

2014-11-27 Thread Richard Woo 
Don, the spec is location at:
http://git.openstack.org/cgit/openstack/neutron-specs/


On Wed, Nov 26, 2014 at 11:55 PM, Don Kehn  wrote:

> Sure, will try and gen to it over the holiday, do you have a link to the
> spec repo?
>
> On Mon, Nov 24, 2014 at 3:27 PM, Carl Baldwin  wrote:
>
>> Don,
>>
>> Could the spec linked to your BP be moved to the specs repository?
>> I'm hesitant to start reading it as a google doc when I know I'm going
>> to want to make comments and ask questions.
>>
>> Carl
>>
>> On Thu, Nov 13, 2014 at 9:19 AM, Don Kehn  wrote:
>> > If this shows up twice sorry for the repeat:
>> >
>> > Armando, Carl:
>> > During the Summit, Armando and I had a very quick conversation concern a
>> > blue print that I submitted,
>> > https://blueprints.launchpad.net/neutron/+spec/dhcp-cpnr-integration
>> and
>> > Armando had mention the possibility of getting together a sub-group
>> tasked
>> > with DHCP Neutron concerns. I have talk with Infoblox folks (see
>> > https://blueprints.launchpad.net/neutron/+spec/neutron-ipam), and
>> everyone
>> > seems to be in agreement that there is synergy especially concerning the
>> > development of a relay and potentially looking into how DHCP is
>> handled. In
>> > addition during the Fridays meetup session on DHCP that I gave there
>> seems
>> > to be some general interest by some of the operators as well.
>> >
>> > So what would be the formality in going forth to start a sub-group and
>> > getting this underway?
>> >
>> > DeKehn
>> >
>> >
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> 
> Don Kehn
> 303-442-0060
>
> ___
> 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] BGP - VPN BoF session in Kilo design summit

2014-11-04 Thread Richard Woo 
Did we have room for this discussion?

On Tue, Nov 4, 2014 at 6:09 PM, Mathieu Rohon 
wrote:

> Hi,
>
> Thanks Jaume, it make sense since those use cases need l3-agent
> refectoring.
> I've updated the BGPVPN etherpad [1] with materials used during
> today's techtalk.
>
> I hope this will help everyone to better uderstand our use cases.
>
> [1]https://etherpad.openstack.org/p/bgpvpn
>
> On Tue, Nov 4, 2014 at 2:43 PM, Jaume Devesa  wrote:
> > Hello,
> >
> > BoF will be Wednesday 5 at 15:00 pm at Design Summit building. We will
> have
> > the chance to talk about it into the Kilo L3 refactoring BoF
> >
> > https://etherpad.openstack.org/p/kilo-l3-refactoring
> >
> > Cheers,
> >
> > On 30 October 2014 07:28, Carl Baldwin  wrote:
> >>
> >> Yes, let's discuss this in the meeting on Thursday.
> >>
> >> Carl
> >>
> >> On Oct 29, 2014 5:27 AM, "Jaume Devesa"  wrote:
> >>>
> >>> Hello,
> >>>
> >>> it seems like the BGP dynamic routing it is in a good shape to be
> >>> included in Neutron during Kilo[1]. There is quite interest in offer
> BGP-VPN
> >>> too. Mathieu Rohon's spec[2] goes in this direction. Of course it makes
> >>> sense that his development leverages the BGP one.
> >>>
> >>> I would like to have a BoF session and invite anyone interested on
> these
> >>> blueprints to join us or even add a new related one. I've created an
> >>> etherpad[3] to share ideas and agree with session schedule. I propose
> >>> Wednesday afternoon.
> >>>
> >>> If Carl Baldwin is agree, we can talk about it also during the open
> >>> discussion of today's L3 subteam meeting.
> >>>
> >>> [1]: https://review.openstack.org/#/c/125401/
> >>> [
> >>> 2]: https://review.openstack.org/#/c/125401/
> >>> [3]: https://etherpad.openstack.org/p/bgp-vpn-dynamic-routing
> >>>
> >>> Cheers,
> >>> --
> >>> Jaume Devesa
> >>> Software Engineer at Midokura
> >>>
> >>> ___
> >>> 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
> >>
> >
> >
> >
> > --
> > Jaume Devesa
> > Software Engineer at Midokura
> >
> > ___
> > 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] VM-based VLAN trunking blueprints

2014-11-03 Thread Richard Woo 
Hello, will this topic be discussed in the design session?

Richard

On Mon, Nov 3, 2014 at 10:36 PM, Erik Moe  wrote:

>
>
> I created an etherpad and added use cases (so far just the ones in your
> email).
>
>
>
> https://etherpad.openstack.org/p/tenant_vlans
>
>
>
> /Erik
>
>
>
>
>
> *From:* Erik Moe [mailto:erik@ericsson.com]
> *Sent:* den 2 november 2014 23:12
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking
> blueprints
>
>
>
>
>
>
>
> *From:* Ian Wells [mailto:ijw.ubu...@cack.org.uk ]
>
> *Sent:* den 31 oktober 2014 23:35
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking
> blueprints
>
>
>
>
> On 31 October 2014 06:29, Erik Moe  wrote:
>
>
>
>
>
> I thought Monday network meeting agreed on that “VLAN aware VMs”, Trunk
> network + L2GW were different use cases.
>
>
>
> Still I get the feeling that the proposals are put up against each other.
>
>
>
> I think we agreed they were different, or at least the light was beginning
> to dawn on the differences, but Maru's point was that if we really want to
> decide what specs we have we need to show use cases not just for each spec
> independently, but also include use cases where e.g. two specs are required
> and the third doesn't help, so as to show that *all* of them are needed.
> In fact, I suggest that first we do that - here - and then we meet up one
> lunchtime and attack the specs in etherpad before submitting them.  In
> theory we could have them reviewed and approved by the end of the week.
> (This theory may not be very realistic, but it's good to set lofty goals,
> my manager tells me.)
>
> Ok, let’s try. I hope you theory turns out to be realistic. J
>
>  Here are some examples why bridging between Neutron internal networks
> using trunk network and L2GW IMO should be avoided. I am still fine with
> bridging to external networks.
>
>
>
> Assuming VM with trunk port wants to use floating IP on specific VLAN.
> Router has to be created on a Neutron network behind L2GW since Neutron
> router cannot handle VLANs. (Maybe not too common use case, but just to
> show what kind of issues you can get into)
>
> neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID
>
> The code to check if valid port has to be able to traverse the L2GW.
> Handing of IP addresses of VM will most likely be affected since VM port is
> connected to several broadcast domains. Alternatively new API can be
> created.
>
>
>
> Now, this is a very good argument for 'trunk ports', yes.  It's not
> actually an argument against bridging between networks.  I think the
> bridging case addresses use cases (generally NFV use cases) where you're
> not interested in Openstack managing addresses - often because you're
> forwarding traffic rather than being an endpoint, and/or you plan on
> disabling all firewalling for speed reasons, but perhaps because you wish
> to statically configure an address rather than use DHCP.  The point is
> that, in the absence of a need for address-aware functions, you don't
> really care much about ports, and in fact configuring ports with many
> addresses may simply be overhead.  Also, as you say, this doesn't address
> the external bridging use case where what you're bridging to is not
> necessarily in Openstack's domain of control.
>
> I know that many NFVs currently prefer to manage everything themselves. At
> the same time, IMO, I think they should be encouraged to become
> Neutronified.
>
>  In “VLAN aware VMs” trunk port mac address has to be globally unique
> since it can be connected to any network, other ports still only has to be
> unique per network. But for L2GW all mac addresses has to be globally
> unique since they might be bridged together at a later stage.
>
>
>
> I'm not sure that that's particularly a problem - any VM with a port will
> have one globally unique MAC address.  I wonder if I'm missing the point
> here, though.
>
> Ok, this was probably too specific, sorry. Neutron can reuse MAC addresses
> among Neutron networks. But I guess this is configurable.
>
>  Also some implementations might not be able to take VID into account
> when doing mac address learning, forcing at least unique macs on a trunk
> network.
>
>
>
> If an implementation struggles with VLANs then the logical thing to do
> would be not to implement them in that driver.  Which is fine: I would
> expect (for instance) LB-driver networking to work for this and leave
> OVS-driver networking to never work for this, because there's little point
> in fixing it.
>
> Same as above, this is related to reuse of MAC addresses.
>
>  Benefits with “VLAN aware VMs” are integration with existing Neutron
> services.
>
> Benefits with Trunk networks are less consumption of Neutron networks,
> less management per VLAN.
>
>
>
> Actually, the benefit of trunk networks is:
>
> - if I use an infra

[openstack-dev] [neutron][opendaylight]OpenDaylight Neutron Plugin design session etherpad

2014-11-03 Thread Richard Woo 
Hi, what is etherpad link for opendaylight neutron plugin design session?

http://kilodesignsummit.sched.org/event/5a430f46842e9239ea6c29a69cbe4e84#.VFdhdPTF-0E

Thanks,

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

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-28 Thread Richard Woo 
I have another question about incubator proposal, for CLI and GUI. Do we
imply that the incubator feature will need to branch python-neutron client,
Horizon, and or Nova ( if changes are needed)?




On Tue, Aug 26, 2014 at 7:09 PM, James E. Blair  wrote:

> Hi,
>
> After reading https://wiki.openstack.org/wiki/Network/Incubator I have
> some thoughts about the proposed workflow.
>
> We have quite a bit of experience and some good tools around splitting
> code out of projects and into new projects.  But we don't generally do a
> lot of importing code into projects.  We've done this once, to my
> recollection, in a way that preserved history, and that was with the
> switch to keystone-lite.
>
> It wasn't easy; it's major git surgery and would require significant
> infra-team involvement any time we wanted to do it.
>
> However, reading the proposal, it occurred to me that it's pretty clear
> that we expect these tools to be able to operate outside of the Neutron
> project itself, to even be releasable on their own.  Why not just stick
> with that?  In other words, the goal of this process should be to create
> separate projects with their own development lifecycle that will
> continue indefinitely, rather than expecting the code itself to merge
> into the neutron repo.
>
> This has advantages in simplifying workflow and making it more
> consistent.  Plus it builds on known integration mechanisms like APIs
> and python project versions.
>
> But more importantly, it helps scale the neutron project itself.  I
> think that a focused neutron core upon which projects like these can
> build on in a reliable fashion would be ideal.
>
> -Jim
>
> ___
> 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] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

2014-08-06 Thread Richard Woo 
I agreed with Jay. Nova is one of the consumer of Neutron project, someone
from Nova project should participate reviewing related blueprint in neutron
project.

Richard


On Wed, Aug 6, 2014 at 8:28 PM, Jay Pipes  wrote:

> On 08/06/2014 07:54 PM, Kevin Benton wrote:
>
>> I'm curious, how would having Nova reviewers look at this have helped?
>>
>
> As I mentioned on a previous email, Nova is the pre-eminent consumer of
> Neutron's API.
>
> Best,
> -jay
>
>  On Wed, Aug 6, 2014 at 5:41 PM, Jay Pipes > > wrote:
>>
>> On 08/06/2014 07:08 PM, CARVER, PAUL wrote:
>>
>> On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi > >
>> >>
>>wrote:
>>
>> Yes, indeed.
>> I do not want to be over dramatic but the discussion on the
>> original "Group
>> Based Policy and the way forward" thread is nothing short of
>> heartbreaking.
>> After months and months of discussions, three presentations
>> at the past three
>> summits, a design session at the last summit, and (most
>> relevant to this
>> thread) the approval of the spec, why are we talking about
>> the merits of the
>> work now?
>>
>> I understand if people think this is not a good idea or this
>> is not a good
>> time. What I do not understand is why these concerns were
>> not raised clearly
>> and openly earlier.
>>
>>
>> I have to agree here. I'm not sure whether my organization needs
>> GBP or not.
>> It's certainly not our top priority for Neutron given a variety
>> of other more
>> important functional gaps. However, I saw their demo at the
>> summit and it was
>> clear that a lot of work had gone into it even before Icehouse.
>>  From the demo
>> it was clearly a useful enhancement to Neutron even if it wasn't
>> at the top
>> of my priority list.
>>
>> For people to be asking to justify the "why" this far into the
>> Juno cycle
>> when the spec was approved and the code was demoed at the summit
>> really
>> brings the OpenStack process into question. It's one thing to
>> discuss
>> technical merits of contributions but it's totally different to
>> pull the rug
>> out from under a group of contributors at the last minute after
>> such a long
>> period of development, discussion, and demo.
>>
>> Seeing this sort of last minute rejection of a contribution
>> after so much
>> time has been invested in it could very easily have a chilling
>> effect on
>> contributors.
>>
>>
>> I don't disagree with you, Paul.
>>
>> I blame myself for not paying the attention I should have to this
>> earlier in the process.
>>
>> FWIW, I had a good conversation with Sumit and Kevin on
>> #openstack-neutron this afternoon about this particular topic. We
>> agree on some things; disagree on others.
>>
>> Bottom line, I go back to what I said in a previous email: the Nova
>> and Neutron development teams need to do a much better job in being
>> directly involved in each other's spec discussions and design
>> conversations.
>>
>> 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Richard Woo 
+1
On Aug 6, 2014 7:07 PM, "Salvatore Orlando"  wrote:

> I was asked beforehand what I mean with
>
> * consider GBP an 'experimental' V3 tenant API (this was mentioned
> somewhere in this thread) and treat it accordingly
>
> The group based policies, although implemented as a service plugin, are
> quite different from the ones we have now. Things like firewall, load
> balancer, etc. add something that will be run alongside the "core" API.
> This service plugin instead define a different kind of abstractive
> (declarative vs imperative as it has been mentioned several times) and it
> won't be wrong to say it can replace the core API. To this aim I think it's
> fair to consider it an experimentation around a new tenant API.
>
> In this hypothesis, how should this be treated? The decision ultimately
> does not lie with me.
> I would merely point out that:
> 1) The neutron core team should not stop innovation. If a consistent part
> of the community feels that a declarative base model is that way forward
> and we should experiment with it, than we should do everything we can to
> help this part of the community.
> 2) On the other hand, innovation and experimentation should not deprive
> the core team of significant resources which should be directed first and
> foremost to address the areas identified by the TC as in need of improvement
> In the light of the above, and reflecting on the ultimate question which
> is whether this code should be merged or not. Allow me to say that my final
> thought is that I don't care whether is merged in the main neutron repo or
> somewhere else, as long as it does not constitute additional burden for the
> core team in terms of reviews, maintainability, gate failures (it won't be
> the first time I or other core team members had to chase failures for some
> service plugins digging into logs), and future design decisions (ie: having
> to ask the question - "what about group policy" for every future API
> decision)
>
> Salvatore
>
> PS: did I make post #100?
>
>
>
> On 7 August 2014 00:47, Kevin Benton  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/'
>>  On Aug 6, 2014 4:41 PM, "Armando M."  wrote:
>>
>>> This thread is moving so fast I can't keep up!
>>>
>>> The fact that troubles me is that I am unable to grasp how we move
>>> forward, which was the point of this thread to start with. It seems we have
>>> 2 options:
>>>
>>> - We make GBP to merge as is, in the Neutron tree, with some minor
>>> revision (e.g. naming?);
>>> - We make GBP a stackforge project, that integrates with Neutron in some
>>> shape or form;
>>>
>>> Another option, might be something in between, where GBP is in tree, but
>>> in some sort of experimental staging area (even though I am not sure how
>>> well baked this idea is).
>>>
>>> Now, as a community we all need make a decision; arguing about the fact
>>> that the blueprint was approved is pointless. As a matter of fact, I think
>>> that blueprint should be approved, if and only if the code has landed
>>> completely, but I digress!
>>>
>>> Let's together come up with pros and cons of each approach and come up
>>> with an informed decision.
>>>
>>> Just reading free form text, how are we expected to do that? At least I
>>> can't!
>>>
>>> My 2c.
>>> Armando
>>>
>>>
>>> On 6 August 2014 15:03, Aaron Rosen  wrote:
>>>



 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton 
 wrote:

> >I believe the referential security group rules solve this problem
> (unless I'm not understanding):
>
> I think the disconnect is that you are comparing the way to current
> mapping driver implements things for the reference implementation with the
> existing APIs. Under this light, it's not going to look like there is a
> point to this code being in Neutron since, as you said, the abstraction
> could happen at a client. However, this changes once new mapping drivers
> can be added that implement things differently.
>
> Let's take the security groups example. Using the security groups API
> directly is imperative ("put a firewall rule on this port that blocks this
> IP") compared to a higher level declarative abstraction ("make sure these
> two endpoints cannot communicate"). With the former, the ports must 
> support
> security groups and there is nowhere except for the firewall rules on that
> port to implement it without violating the user's expectation. With the
> latter, a mapping driver could determine that communication between these
> two hosts can be prevented by using an ACL on a router or a switch, which
> doesn't violate the user's intent and buys a performance improvement and
> works with ports that don't support security groups.
>
> Group based policy is trying to move the requests into the declarative
> abstraction so optimizations like the one above can be m

Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

2014-08-06 Thread Richard Woo 
+1,

I think in future we should invite the other project(i.e. Nova) core member
to review the blueprint if it is related to that specific project.





On Wed, Aug 6, 2014 at 5:01 PM, Mohammad Banikazemi  wrote:

> Yes, indeed.
> I do not want to be over dramatic but the discussion on the original "Group
> Based Policy and the way forward" thread is nothing short of heartbreaking.
> After months and months of discussions, three presentations at the past
> three summits, a design session at the last summit, and (most relevant to
> this thread) the approval of the spec, why are we talking about the merits
> of the work now?
>
> I understand if people think this is not a good idea or this is not a good
> time. What I do not understand is why these concerns were not raised
> clearly and openly earlier.
>
> Best,
>
> Mohammad
>
>
> [image: Inactive hide details for Stefano Maffulli ---08/06/2014 04:47:21
> PM---On Wed 06 Aug 2014 01:21:26 PM PDT, Eugene Nikanorov wro]Stefano
> Maffulli ---08/06/2014 04:47:21 PM---On Wed 06 Aug 2014 01:21:26 PM PDT,
> Eugene Nikanorov wrote: > So I don't think it's fair to blame re
>
> From: Stefano Maffulli 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 08/06/2014 04:47 PM
> Subject: Re: [openstack-dev] How to improve the specs review process (was
> Re: [Neutron] Group Based Policy and the way forward)
> --
>
>
>
> On Wed 06 Aug 2014 01:21:26 PM PDT, Eugene Nikanorov wrote:
> > So I don't think it's fair to blame reviewers here.
>
> Just want to be super clear: there is no 'blaming' here. This is a
> request to regroup and look at why we are having this conversation about
> GBP now, this late in cycle, and about such fundamental topics (the
> choice of 'endpoint' as name is only one of them), after in-person
> conversations over more than one release cycle and summits.
>
> I am available for the meeting on Monday, Kyle.
>
> In order to prepare for the meeting we should agree on the scope of the
> root cause analysis. I think the problem should be framed around the
> message Mark McClain sent, especially the "Why this email" which I quote
> below:
>
> > Our community has been discussing and working on Group Based Policy
> > (GBP) for many months.  I think the discussion has reached a point
> > where we need to openly discuss a few issues before moving forward.
> [...]
>
> I think the fact that this very fair question has been raised so late is
> the problem we need to find the cause for. Would you agree?
>
> We'll use time during the meeting on Monday to use a simple technique to
> investigate this deeply, no need to spend time now and via email.
>
> /stef
>
> --
> Ask and answer questions on https://ask.openstack.org
>
> ___
> 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] DVR and FWaaS integration

2014-06-28 Thread Richard Woo 
Regarding of user case of this feature, are you referring E-W traffic or
N-S traffic?


On Wed, Jun 25, 2014 at 4:00 PM, Yi Sun  wrote:

> All,
> During last summit, we were talking about the integration issues between
> DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But
> after that meeting I was tight up with my work and did not get time to
> continue to follow up the issue. To not slow down the discussion, I'm
> forwarding out the email that I sent out as the follow up to the IRC
> meeting here, so that whoever may be interested on the topic can continue
> to discuss about it.
>
> First some background about the issue:
> In the normal case, FW and router are running together inside the same box
> so that FW can get route and NAT information from the router component. And
> in order to have FW to function correctly, FW needs to see the both
> directions of the traffic.
> DVR is designed in an asymmetric way that each DVR only sees one leg of
> the traffic. If we build FW on top of DVR, then FW functionality will be
> broken. We need to find a good method to have FW to work with DVR.
>
> ---forwarding email---
>  During the IRC meeting, we think that we could force the traffic to the
> FW before DVR. Vivek had more detail; He thinks that since the br-int
> knowns whether a packet is routed or switched, it is possible for the
> br-int to forward traffic to FW before it forwards to DVR. The whole
> forwarding process can be operated as part of service-chain operation. And
> there could be a FWaaS driver that understands the DVR configuration to
> setup OVS flows on the br-int.
> The concern is that normally firewall and router are integrated together
> so that firewall can make right decision based on the routing result. But
> what we are suggesting is to split the firewall and router into two
> separated components, hence there could be issues. For example, FW will
> not be able to get enough information to setup zone. Normally Zone contains
> a group of interfaces that can be used in the firewall policy to enforce
> the direction of the policy. If we forward traffic to firewall before DVR,
> then we can only create policy based on subnets not the interface.
> Also, I’m not sure if we have ever planed to support SNAT on the DVR, but
> if we do, then it depends on at which point we forward traffic to the FW,
> the subnet may not even work for us anymore (even DNAT could have problem
> too).
> Another thing that I may have to get detail is that how we handle the
> overlap subnet, it seems that the new namespaces are required.
>
> --- end of forwarding 
>
> YI
>
>
> ___
> 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] DVR blueprint document locked / private

2014-02-18 Thread Richard Woo 
Hello, Swami,

Would you mind to forward the powerpoint slide link again?

Thanks,
Richard


On Tue, Feb 18, 2014 at 1:03 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hp.com> wrote:

> Hi Assaf,
> Thanks for letting me know.
> This document was completely open and accessible by everyone till last
> week.
> Someone might have changed the settings on this document.
>
> I don't remember that I changed any settings on this document.
> The Powerpoint slides link that I forwarded yesterday also captures the
> same details and still that is accessible.
>
> I have opened it again for the public.
>
> If it would have caused any trouble for you to participate in the upstream
> discussions for the last two days, I feel sorry for it.
>
> Feel free to send an email to me, if you have any other issues or concerns.
>
> Thanks
> Swami
>
> -Original Message-
> From: Assaf Muller [mailto:amul...@redhat.com]
> Sent: Tuesday, February 18, 2014 2:33 AM
> To: openstack-dev@lists.openstack.org
> Cc: Vasudevan, Swaminathan (PNB Roseville); Baldwin, Carl (HPCS Neutron);
> mmccl...@yahoo-inc.com; Livnat Peer; Sylvain Afchain
> Subject: [Neutron] DVR blueprint document locked / private
>
> Regarding the DVR blueprint [1], I noticed that its corresponding Google
> Doc [2] has been private / blocked for nearly a week now. It's very
> difficult to participate in upstream design discussions when the document
> is literally locked.
>
> I would appreciate the re-opening of the document, especially considering
> the recent face to face meeting and the contested discussion points that
> were raised.
>
> [1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
> [2]
> https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit
>
>
> Thank you,
> Assaf Muller, Cloud Networking Engineer Red Hat
> ___
> 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] Webex Recording of IPv6 / Neutron Sync-up

2013-12-04 Thread Richard Woo 
Shixiong,

Thanks for the updating.

Richard


On Thu, Dec 5, 2013 at 10:44 AM, Shixiong Shang <
sparkofwisdom.cl...@gmail.com> wrote:

> Hi, Richard:
>
> Sorry it took me a while to reply your email. I was swamped today to
> prepare for the presentation that Randy and I jointly delivered tonight to
> local OpenStack community in the meet-up sponsored by Cisco. As matter of
> fact, we used the same slide and you can find a copy at:
>
> http://www.slideshare.net/shixiongshang1/openstack-havana-over-ipv6
>
> Please don’t feel hesitate to let us know if you have any questions. We
> will be more than happy to help.
>
> Thanks for showing the interests in our work!
>
> Shixiong
>
>
>
>
>
>
> On Dec 4, 2013, at 10:27 AM, Richard Woo  wrote:
>
> Shixiong,
>
> Thank you for the updates, do you mind to share the slide to the openstack
> mailing list?
>
> Richard
>
>
> On Tue, Dec 3, 2013 at 11:30 PM, Shixiong Shang <
> sparkofwisdom.cl...@gmail.com> wrote:
>
>> Hi, guys:
>>
>> We had a great discussion tonight with stackers from Comcast, IBM, HP,
>> Cisco and Nephos6! Here is the debrief of what we discussed during this
>> 1-hr session:
>>
>> 1) Sean from Comcast provided clarification of his short-term and
>> mid-term goals in the proposed blueprint.
>> 2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and
>> bug fixes they submitted.
>> 3) Brian from HP shared his view to support IPv6 and HA in the near
>> future.
>> 4) Shixiong from Nephos6 and Randy from Cisco presented a slide to
>> summarize the issues they encountered during POC together with the
>> solutions.
>> 5) We reached consensus to leverage the work Sean, Da Zhao have done
>> previously and integrate it with the L3 agent efforts brought by Shixiong
>> and Randy.
>>
>>
>> Please see below for Webex recording.
>>
>>
>> https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=73520027&rKey=8e508b63604bb9d0
>>
>> IPv6 / Neutron synch-up-20131204 0204-1
>> Tuesday, December 3, 2013 9:04 pm New York Time
>> 1 Hour 4 Minutes
>>
>> Thanks!
>>
>> Shixiong
>>
>> ___
>> 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] Webex Recording of IPv6 / Neutron Sync-up

2013-12-04 Thread Richard Woo 
Shixiong,

Thank you for the updates, do you mind to share the slide to the openstack
mailing list?

Richard


On Tue, Dec 3, 2013 at 11:30 PM, Shixiong Shang <
sparkofwisdom.cl...@gmail.com> wrote:

> Hi, guys:
>
> We had a great discussion tonight with stackers from Comcast, IBM, HP,
> Cisco and Nephos6! Here is the debrief of what we discussed during this
> 1-hr session:
>
> 1) Sean from Comcast provided clarification of his short-term and mid-term
> goals in the proposed blueprint.
> 2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and
> bug fixes they submitted.
> 3) Brian from HP shared his view to support IPv6 and HA in the near future.
> 4) Shixiong from Nephos6 and Randy from Cisco presented a slide to
> summarize the issues they encountered during POC together with the
> solutions.
> 5) We reached consensus to leverage the work Sean, Da Zhao have done
> previously and integrate it with the L3 agent efforts brought by Shixiong
> and Randy.
>
>
> Please see below for Webex recording.
>
>
> https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=73520027&rKey=8e508b63604bb9d0
>
> IPv6 / Neutron synch-up-20131204 0204-1
> Tuesday, December 3, 2013 9:04 pm New York Time
> 1 Hour 4 Minutes
>
> Thanks!
>
> Shixiong
>
> ___
> 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] [ml2] devstack now defaults to the ML2 plugin

2013-10-01 Thread Richard Woo 
Kyle, what is the proper way to configure ML2 plugin (I plan to use OVS
with VLAN) in localrc?

Thanks,
Richard


On Tue, Oct 1, 2013 at 5:12 PM, Kyle Mestery (kmestery)
wrote:

> Folks:
>
> Just an update regarding the change to move devstack to default
> to the ML2 Neutron plugin instead of the OVS plugin. The patch [1]
> merged yesterday. Full tempest tests were passed with this, but
> just a heads up for those using devstack without specifying a
> Neutron plugin specifically.
>
> Thanks,
> Kyle
>
> [1] https://review.openstack.org/#/c/47837/
>
> ___
> 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