Re: [openstack-dev] [neutron] Backup port info to restore the flow rules

[Jian Wen]

On Mon, Feb 22, 2016 at 7:03 PM, Ihar Hrachyshka 
wrote:

> Agent could probably try to restore the state from its internal state. If
> that’s the missing bit you want to have, I think that could stand for a
> proper RFE.
>
Good point. Thanks.

-- 
Best,

Jian
__
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] Backup port info to restore the flow rules

[Jian Wen]

   I don't think it's enough for a large scale cloud.

   When the neutron server is not available and the flow rules are gone,
   we need the backup to restore the flow rules.

   We have more than a thousand physical servers in our production
environment.
   Rare events will occur where combined failures or unanticipated failures
   require human interaction. For example, a cron job accidentlly killed the
   OvS service(flows will be gone) when one of RabbitMQ, MySQL and neutron
   server is down/unavailable.


On Mon, Feb 22, 2016 at 5:44 PM, Ihar Hrachyshka <ihrac...@redhat.com>
wrote:

> Jian Wen <wenjia...@gmail.com> wrote:
>
> Hello,
>>
>> If we restart OvS/ovs-agent when one or more of Neutron, MySQL and
>> RabbitMQ is not available, the flow rules in OvS will be gone. If
>> Neutron/MySQL/RabbitMQ doesn't become available in time, the VMs
>> will lose their network connections. It's not easy for an
>> operations engineer to manually restore the flow rules. An
>> operations engineer working under pressure at 2 a.m. will make
>> mistakes.
>>
>> We can backup the ports info to a local file. In case of emergency
>> the ovs-agent can use it to restore the flow rules. What do you
>> think of this feature?
>>
>> Related bugs:
>> Restarting neutron openvswitch agent causes network hiccup by
>> throwing away all flows
>> https://bugs.launchpad.net/neutron/+bug/1383674
>>
>> Restarting OVS agent drops VMs traffic when using VLAN provider
>> bridges
>> https://bugs.launchpad.net/neutron/+bug/1514056
>>
>> After restarting an ovs agent, it still drops useful flows if the
>> neutron server is busy/down
>> https://bugs.launchpad.net/neutron/+bug/1515075
>>
>> Ovs agent loses OpenFlow rules if OVS gets restarted while Neutron is
>> disconnected from SQL
>> https://bugs.launchpad.net/neutron/+bug/1531210
>>
>>
> Most of those bugs are fixed (at least for stable/liberty+). Isn’t it
> enough to avoid data plane reset when the agent fails to fetch new port
> data from its controller? Why do we need another mechanism here?
>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best,

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

[openstack-dev] [neutron] Backup port info to restore the flow rules

[Jian Wen]

Hello,

If we restart OvS/ovs-agent when one or more of Neutron, MySQL and
RabbitMQ is not available, the flow rules in OvS will be gone. If
Neutron/MySQL/RabbitMQ doesn't become available in time, the VMs
will lose their network connections. It's not easy for an
operations engineer to manually restore the flow rules. An
operations engineer working under pressure at 2 a.m. will make
mistakes.

We can backup the ports info to a local file. In case of emergency
the ovs-agent can use it to restore the flow rules. What do you
think of this feature?

Related bugs:
Restarting neutron openvswitch agent causes network hiccup by throwing
away all flows
https://bugs.launchpad.net/neutron/+bug/1383674

Restarting OVS agent drops VMs traffic when using VLAN provider bridges
https://bugs.launchpad.net/neutron/+bug/1514056

After restarting an ovs agent, it still drops useful flows if the
neutron server is busy/down
https://bugs.launchpad.net/neutron/+bug/1515075

Ovs agent loses OpenFlow rules if OVS gets restarted while Neutron is
disconnected from SQL
https://bugs.launchpad.net/neutron/+bug/1531210


-- 
Best,

Jian
__
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] [chef] A new Core member!

[Jian Wen]

Congrats

On Sat, Apr 18, 2015 at 5:42 AM, JJ Asghar jasg...@chef.io wrote:
 Hey everyone!

 I’d like to announce that Zhiwei Chen has stepped up as a new Core Member. 
 Please take a moment to congratulate him!

 Thanks Zhiwei!

 JJ Asghar
 __
 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



-- 
Best,

Jian

__
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] HA of dhcp agents?

[Jian Wen]

See dhcp_agents_per_network in neutron.conf.

https://bugs.launchpad.net/neutron/+bug/1174132

2014-10-21 6:47 GMT+08:00 Noel Burton-Krahn n...@pistoncloud.com:

 I've been working on failover for dhcp and L3 agents.  I see that in [1],
 multiple dhcp agents can host the same network.  However, it looks like I
 have to manually assign networks to multiple dhcp agents, which won't
 work.  Shouldn't multiple dhcp agents automatically fail over?

 [1]
 http://docs.openstack.org/trunk/config-reference/content/multi_agent_demo_configuration.html



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




-- 
Best,

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

Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?

[Jian Wen]

Ordering of vNICs is not 100% guaranteed for the cloud images which are not
shipped with
/etc/udev/rules.d/70-persistent-net.rules.
e.g. attaching a port and deattaching another port, then reboot the
instance.


2014-08-12 15:52 GMT+08:00 Aaron Rosen aaronoro...@gmail.com:

 This bug was true in grizzly and older (and was reintroduced in icehouse
 for a few days but was fixed before the nova icehouse shipped).

 Aaron


 On Mon, Aug 11, 2014 at 7:10 AM, CARVER, PAUL pc2...@att.com wrote:

 Armando M. [mailto:arma...@gmail.com] wrote:



 On 9 August 2014 10:16, Jay Pipes jaypi...@gmail.com wrote:

 Paul, does this friend of a friend have a reproduceable test

 script for this?



 We would also need to know the OpenStack release where this issue
 manifest

 itself. A number of bugs have been raised in the past around this type of

 issue, and the last fix I recall is this one:

 

 https://bugs.launchpad.net/nova/+bug/1300325

 

 It's possible that this might have regressed, though.



 The reason I called it friend of a friend is because I think the info

 has filtered through a series of people and is not firsthand observation.

 I'll ask them to track back to who actually observed the behavior, how

 long ago, and with what version.



 It could be a regression, or it could just be old info that people have

 continued to assume is true without realizing it was considered a bug

 all along and has been fixed.



 Thanks! The moment I first heard it my first reaction was that it was

 almost certainly a bug and had probably already been fixed.



 ___
 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




-- 
Best,

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

Re: [openstack-dev] [nova] nova bug scrub web page

[Jian Wen]

Awesome!

Any plan to add the neutron project?



2014-07-04 5:00 GMT+08:00 Tracy Jones tjo...@vmware.com:

  Hi Folks – I have taken a script from the infra folks and jogo, made
 some tweaks and have put it into a web page.  Please see it here
 http://54.201.139.117/demo.html


  This is all of the new, confirmed, triaged, and in progress bugs that we
 have in nova as of a couple of hours ago.  I have added ways to search it,
 sort it, and filter it based on

  1.  All bugs
 2.  Bugs that have not been updated in the last 30 days
 3.  Bugs that have never been updated
 4.  Bugs in progress
 5.  Bugs without owners.


  I chose this as they are things I was interested in seeing, but there
 are obviously a lot of other things I can do here.  I plan on adding a cron
 job to update the data ever hour or so.  Take a look and let me know if
 your have feedback.

  Tracy



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




-- 
Best,

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

[openstack-dev] [eventlet] should we use spawn instead of spawn_n?

[Jian Wen]

eventlet.spawn_n is the same as eventlet.spawn, but it’s not possible
to know how the function terminated (i.e. no return value or exceptions)[1].
If an exception is raised in the function, spawn_n prints a stack trace.
The stack trace will not be written to the log file. It will be lost if we
restart the daemon.

Maybe we need to replace spawn_n with spawn. If an exception is raised in
the
function, we can log it if needed. Any thoughts?

related bug: https://bugs.launchpad.net/neutron/+bug/1254984

[1] http://eventlet.net/doc/basic_usage.html

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

Re: [openstack-dev] Reg : Security groups implementation using openflows in quantum ovs plugin

[Jian Wen]

I don't think we can implement a stateful firewall[1] now.

Once connection tracking capability[2] is added to the Linux OVS, we
could start to implement the ovs-firewall-driver blueprint.

[1] http://en.wikipedia.org/wiki/Stateful_firewall
[2]
http://wiki.xenproject.org/wiki/Xen_Development_Projects#Add_connection_tracking_capability_to_the_Linux_OVS


On Tue, Nov 26, 2013 at 2:23 AM, Mike Wilson geekinu...@gmail.com wrote:

 Adding Jun to this thread since gmail is failing him.


 On Tue, Nov 19, 2013 at 10:44 AM, Amir Sadoughi 
 amir.sadou...@rackspace.com wrote:

  Yes, my work has been on ML2 with neutron-openvswitch-agent.  I’m
 interested to see what Jun Park has. I might have something ready before he
 is available again, but would like to collaborate regardless.

  Amir



  On Nov 19, 2013, at 3:31 AM, Kanthi P pavuluri.kan...@gmail.com wrote:

  Hi All,

  Thanks for the response!
 Amir,Mike: Is your implementation being done according to ML2 plugin

  Regards,
 Kanthi


 On Tue, Nov 19, 2013 at 1:43 AM, Mike Wilson geekinu...@gmail.comwrote:

 Hi Kanthi,

  Just to reiterate what Kyle said, we do have an internal
 implementation using flows that looks very similar to security groups. Jun
 Park was the guy that wrote this and is looking to get it upstreamed. I
 think he'll be back in the office late next week. I'll point him to this
 thread when he's back.

  -Mike


 On Mon, Nov 18, 2013 at 3:39 PM, Kyle Mestery (kmestery) 
 kmest...@cisco.com wrote:

 On Nov 18, 2013, at 4:26 PM, Kanthi P pavuluri.kan...@gmail.com
 wrote:
   Hi All,
 
  We are planning to implement quantum security groups using openflows
 for ovs plugin instead of iptables which is the case now.
 
  Doing so we can avoid the extra linux bridge which is connected
 between the vnet device and the ovs bridge, which is given as a work around
 since ovs bridge is not compatible with iptables.
 
  We are planning to create a blueprint and work on it. Could you
 please share your views on this
 
  Hi Kanthi:

 Overall, this idea is interesting and removing those extra bridges
 would certainly be nice. Some people at Bluehost gave a talk at the Summit
 [1] in which they explained they have done something similar, you may want
 to reach out to them since they have code for this internally already.

 The OVS plugin is in feature freeze during Icehouse, and will be
 deprecated in favor of ML2 [2] at the end of Icehouse. I would advise you
 to retarget your work at ML2 when running with the OVS agent instead. The
 Neutron team will not accept new features into the OVS plugin anymore.

 Thanks,
 Kyle

 [1]
 http://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/towards-truly-open-and-commoditized-software-defined-networks-in-openstack
 [2] https://wiki.openstack.org/wiki/Neutron/ML2

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



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



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


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



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



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




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

Re: [openstack-dev] run_tests in debug mode fails

[Jian Wen]

Hello,

I can confirm this is a bug.
I use nosetests instead for the moment.

nosetests -s test.module
nosetests -s another.test:TestCase.test_method
nosetests -s a.test:TestCase
nosetests -s /path/to/test/file.py:test_function



On Mon, Sep 9, 2013 at 7:20 PM, Rosa, Andrea (HP Cloud Services) 
andrea.r...@hp.com wrote:

 Hi all

 I need to debug a specific test but when I try to run it in debug mode
 using the run_tests -d (I need to attach pdb) that command fails but if I
 run the script without the -d option that works.
 I created a brand-new env so I don't think it's related to my local env.
 Anyone is experiencing the same issue?
 Should I file a nova bug for that?

 Error details:
 ./run_tests.sh -d
 nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server
 Traceback (most recent call last):
   File nova/tests/integrated/test_servers.py, line 43, in setUp
 super(ServersTest, self).setUp()
   File nova/tests/integrated/integrated_helpers.py, line 87, in setUp
 self.consoleauth = self.start_service('consoleauth')
   File nova/test.py, line 279, in start_service
 svc = self.useFixture(ServiceFixture(name, host, **kwargs))
   File
 /home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 591, in useFixture
 fixture.setUp()
   File nova/test.py, line 174, in setUp
 self.service = service.Service.create(**self.kwargs)
   File nova/service.py, line 245, in create
 manager = CONF.get(manager_cls, None)
   File /home/ubuntu/nova/.venv/lib/python2.7/_abcoll.py, line 342, in get
 return self[key]
   File
 /home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
 line 1610, in __getitem__
 return self.__getattr__(key)
   File
 /home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
 line 1606, in __getattr__
 return self._get(name)
   File
 /home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
 line 1930, in _get
 value = self._substitute(self._do_get(name, group, namespace))
   File
 /home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
 line 1948, in _do_get
 info = self._get_opt_info(name, group)
   File
 /home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
 line 2029, in _get_opt_info
 raise NoSuchOptError(opt_name, group)
 NoSuchOptError: no such option: consoleauth_manager

 Ran 1 test in 11.296s
 FAILED (failures=1)

 Thanks
 --
 Andrea

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




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