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 <richardwoo2...@gmail.com>
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 <ihrac...@redhat.com>
> wrote:
>
>> Richard Woo <richardwoo2...@gmail.com> 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 2446

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 <ihrac...@redhat.com>
wrote:

> Richard Woo <richardwoo2...@gmail.com> 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/

[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 

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 s...@coreitpro.com
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 dek...@gmail.com 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 c...@ecbaldwin.net 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 dek...@gmail.com 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 mathieu.ro...@gmail.com
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 devv...@gmail.com 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 c...@ecbaldwin.net wrote:
 
  Yes, let's discuss this in the meeting on Thursday.
 
  Carl
 
  On Oct 29, 2014 5:27 AM, Jaume Devesa devv...@gmail.com 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


[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] [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 erik@ericsson.com 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 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 erik@ericsson.com 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 infrastructure where all networks are trunks, I can find out
 that a network is a 

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 cor...@inaugust.com 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
+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 m...@us.ibm.com 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 stef...@openstack.org
 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] 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 sorla...@nicira.com 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 blak...@gmail.com wrote:

 I think we should merge it and just prefix the API for now with
 '/your_application_will_break_after_juno_if_you_use_this/'
  On Aug 6, 2014 4:41 PM, Armando M. arma...@gmail.com 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 aaronoro...@gmail.com wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com
 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 made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to
 a declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the 

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 jaypi...@gmail.com 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 jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:

 On 08/06/2014 07:08 PM, CARVER, PAUL wrote:

 On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi m...@us.ibm.com
 mailto:m...@us.ibm.commailto:mb@us.__ibm.com

 mailto:m...@us.ibm.com
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
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
 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] 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,

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=pbSP=MCrID=73520027rKey=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][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 richardwoo2...@gmail.com 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=pbSP=MCrID=73520027rKey=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