<div dir="ltr">+1 "NFTablesDriver"!<div><br></div><div>Also, NFTables, AFAIK, improves IDS systems, like Suricata, for example: <a href="https://home.regit.org/2014/02/suricata-and-nftables/">https://home.regit.org/2014/02/suricata-and-nftables/</a></div>
<div><br></div><div>Then, I'm wondering here... What benefits might come for OpenStack Nova / Neutron, if it comes with a NFTables driver, instead of the current IPTables?!</div><div><br></div><div>* E<font face="arial, sans-serif">fficient Security Group design?</font></div>
<div><font face="arial, sans-serif">* Better FWaaS, maybe with NAT(44/66) support?</font></div><div><font face="arial, sans-serif">* Native support for IPv6, with the defamed NAT66 built-in, simpler "Floating IP" implementation, for both v4 and v6 networks under a single implementation </font><span style="font-family:arial,sans-serif">(</span><font size="1" style="font-family:arial,sans-serif"><b>I don't like NAT66, I prefer a `routed Floating IPv6` version</b></font><span style="font-family:arial,sans-serif">)</span><span style="font-family:arial,sans-serif">?</span></div>
<div><span style="font-family:arial,sans-serif">* Metadata over IPv6 still using NAT(66) (</span><font size="1" style="font-family:arial,sans-serif"><b>I don't like NAT66</b></font><span style="font-family:arial,sans-serif">), single implementation?</span></div>
<div><span style="font-family:arial,sans-serif">* Suricata-as-a-Service?!</span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">It sounds pretty cool! :-)</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 August 2014 23:16, Baohua Yang <span dir="ltr"><<a href="mailto:yangbaohua@gmail.com" target="_blank">yangbaohua@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Great！<div>We met similar problems.</div><div>The current mechanisms produce too many <span>iptables</span> rules, and it's hard to debug.</div>
<div>Really look forward to seeing a more efficient security group design.</div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Jul 10, 2014 at 11:44 PM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Jul 10, 2014 at 4:30 AM, shihanzhang <<a href="mailto:ayshihanzhang@126.com" target="_blank">ayshihanzhang@126.com</a>> wrote:<br>
><br>
> With the deployment 'nova + neutron + openvswitch', when we bulk create<br>
> about 500 VM with a default security group, the CPU usage of neutron-server<br>
> and openvswitch agent is very high, especially the CPU usage of openvswitch<br>
> agent will be 100%, this will cause creating VMs failed.<br>
><br>
> With the method discussed in mailist:<br>
><br>
> 1) ipset optimization (<a href="https://review.openstack.org/#/c/100761/" target="_blank">https://review.openstack.org/#/c/100761/</a>)<br>
><br>
> 3) sg rpc optimization (with fanout)<br>
> (<a href="https://review.openstack.org/#/c/104522/" target="_blank">https://review.openstack.org/#/c/104522/</a>)<br>
><br>
> I have implement these two scheme in my deployment, when we again bulk<br>
> create about 500 VM with a default security group, the CPU usage of<br>
> openvswitch agent will reduce to 10%, even lower than 10%, so I think the<br>
> iprovement of these two options are very efficient.<br>
><br>
> Who can help us to review our spec?<br>
><br>
</div>This is great work! These are on my list of things to review in detail<br>
soon, but given the Neutron sprint this week, I haven't had time yet.<br>
I'll try to remedy that by the weekend.<br>
<br>
Thanks!<br>
<span><font color="#888888">Kyle<br>
</font></span><div><div><br>
> Best regards,<br>
> shihanzhang<br>
><br>
><br>
><br>
><br>
><br>
> At 2014-07-03 10:08:21, "Ihar Hrachyshka" <<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>> wrote:<br>
>>-----BEGIN PGP SIGNED MESSAGE-----<br>
>>Hash: SHA512<br>
>><br>
>>Oh, so you have the enhancement implemented? Great! Any numbers that<br>
>>shows how much we gain from that?<br>
>><br>
>>/Ihar<br>
>><br>
>>On 03/07/14 02:49, shihanzhang wrote:<br>
>>> Hi, Miguel Angel Ajo! Yes, the ipset implementation is ready, today<br>
>>> I will modify my spec, when the spec is approved, I will commit the<br>
>>> codes as soon as possilbe!<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> At 2014-07-02 10:12:34, "Miguel Angel Ajo" <<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Nice Shihanzhang,<br>
>>>><br>
>>>> Do you mean the ipset implementation is ready, or just the<br>
>>>> spec?.<br>
>>>><br>
>>>><br>
>>>> For the SG group refactor, I don't worry about who does it, or<br>
>>>> who takes the credit, but I believe it's important we address<br>
>>>> this bottleneck during Juno trying to match nova's scalability.<br>
>>>><br>
>>>> Best regards, Miguel Ángel.<br>
>>>><br>
>>>><br>
>>>> On 07/02/2014 02:50 PM, shihanzhang wrote:<br>
>>>>> hi Miguel Ángel and Ihar Hrachyshka, I agree with you that<br>
>>>>> split the work in several specs, I have finished the work (<br>
>>>>> ipset optimization), you can do 'sg rpc optimization (without<br>
>>>>> fanout)'. as the third part(sg rpc optimization (with fanout)),<br>
>>>>> I think we need talk about it, because just using ipset to<br>
>>>>> optimize security group agent codes does not bring the best<br>
>>>>> results!<br>
>>>>><br>
>>>>> Best regards, shihanzhang.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> At 2014-07-02 04:43:24, "Ihar Hrachyshka" <<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>><br>
>>>>> wrote:<br>
>>> On 02/07/14 10:12, Miguel Angel Ajo wrote:<br>
>>><br>
>>>> Shihazhang,<br>
>>><br>
>>>> I really believe we need the RPC refactor done for this cycle,<br>
>>>> and given the close deadlines we have (July 10 for spec<br>
>>>> submission and July 20 for spec approval).<br>
>>><br>
>>>> Don't you think it's going to be better to split the work in<br>
>>>> several specs?<br>
>>><br>
>>>> 1) ipset optimization (you) 2) sg rpc optimization (without<br>
>>>> fanout) (me) 3) sg rpc optimization (with fanout) (edouard, you<br>
>>>> , me)<br>
>>><br>
>>><br>
>>>> This way we increase the chances of having part of this for the<br>
>>>> Juno cycle. If we go for something too complicated is going to<br>
>>>> take more time for approval.<br>
>>><br>
>>><br>
>>> I agree. And it not only increases chances to get at least some of<br>
>>> those highly demanded performance enhancements to get into Juno,<br>
>>> it's also "the right thing to do" (c). It's counterproductive to<br>
>>> put multiple vaguely related enhancements in single spec. This<br>
>>> would dim review focus and put us into position of getting<br>
>>> 'all-or-nothing'. We can't afford that.<br>
>>><br>
>>> Let's leave one spec per enhancement. @Shihazhang, what do you<br>
>>> think?<br>
>>><br>
>>><br>
>>>> Also, I proposed the details of "2", trying to bring awareness<br>
>>>> on the topic, as I have been working with the scale lab in Red<br>
>>>> Hat to find and understand those issues, I have a very good<br>
>>>> knowledge of the problem and I believe I could make a very fast<br>
>>>> advance on the issue at the RPC level.<br>
>>><br>
>>>> Given that, I'd like to work on this specific part, whether or<br>
>>>> not we split the specs, as it's something we believe critical<br>
>>>> for neutron scalability and thus, *nova parity*.<br>
>>><br>
>>>> I will start a separate spec for "2", later on, if you find it<br>
>>>> ok, we keep them as separate ones, if you believe having just 1<br>
>>>> spec (for 1 & 2) is going be safer for juno-* approval, then we<br>
>>>> can incorporate my spec in yours, but then<br>
>>>> "add-ipset-to-security" is not a good spec title to put all this<br>
>>>> together.<br>
>>><br>
>>><br>
>>>> Best regards, Miguel Ángel.<br>
>>><br>
>>><br>
>>>> On 07/02/2014 03:37 AM, shihanzhang wrote:<br>
>>>>><br>
>>>>> hi Miguel Angel Ajo Pelayo! I agree with you and modify my<br>
>>>>> spes, but I will also optimization the RPC from security group<br>
>>>>> agent to neutron server. Now the modle is<br>
>>>>> 'port[rule1,rule2...], port...', I will change it to 'port[sg1,<br>
>>>>> sg2..]', this can reduce the size of RPC respose message from<br>
>>>>> neutron server to security group agent.<br>
>>>>><br>
>>>>> At 2014-07-01 09:06:17, "Miguel Angel Ajo Pelayo"<br>
>>>>> <<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> Ok, I was talking with Édouard @ IRC, and as I have time to<br>
>>>>>> work into this problem, I could file an specific spec for<br>
>>>>>> the security group RPC optimization, a masterplan in two<br>
>>>>>> steps:<br>
>>>>>><br>
>>>>>> 1) Refactor the current RPC communication for<br>
>>>>>> security_groups_for_devices, which could be used for full<br>
>>>>>> syncs, etc..<br>
>>>>>><br>
>>>>>> 2) Benchmark && make use of a fanout queue per security<br>
>>>>>> group to make sure only the hosts with instances on a<br>
>>>>>> certain security group get the updates as they happen.<br>
>>>>>><br>
>>>>>> @shihanzhang do you find it reasonable?<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> ----- Original Message -----<br>
>>>>>>> ----- Original Message -----<br>
>>>>>>>> @Nachi: Yes that could a good improvement to factorize<br>
>>>>>>>> the RPC<br>
>>>>>>> mechanism.<br>
>>>>>>>><br>
>>>>>>>> Another idea: What about creating a RPC topic per<br>
>>>>>>>> security group (quid of the<br>
>>>>>>> RPC topic<br>
>>>>>>>> scalability) on which an agent subscribes if one of its<br>
>>>>>>>> ports is<br>
>>>>>>> associated<br>
>>>>>>>> to the security group?<br>
>>>>>>>><br>
>>>>>>>> Regards, Édouard.<br>
>>>>>>>><br>
>>>>>>>><br>
>>><br>
>>><br>
>>>>>>> Hmm, Interesting,<br>
>>><br>
>>>>>>> @Nachi, I'm not sure I fully understood:<br>
>>><br>
>>><br>
>>>>>>> SG_LIST [ SG1, SG2] SG_RULE_LIST = [SG_Rule1, SG_Rule2] ..<br>
>>>>>>> port[SG_ID1, SG_ID2], port2 , port3<br>
>>><br>
>>><br>
>>>>>>> Probably we may need to include also the SG_IP_LIST =<br>
>>>>>>> [SG_IP1, SG_IP2] ...<br>
>>><br>
>>><br>
>>>>>>> and let the agent do all the combination work.<br>
>>><br>
>>>>>>> Something like this could make sense?<br>
>>><br>
>>>>>>> Security_Groups = {SG1:{IPs:[....],RULES:[....],<br>
>>>>>>> SG2:{IPs:[....],RULES:[....]} }<br>
>>><br>
>>>>>>> Ports = {Port1:[SG1, SG2], Port2: [SG1] .... }<br>
>>><br>
>>><br>
>>>>>>> @Edouard, actually I like the idea of having the agent<br>
>>>>>>> subscribed to security groups they have ports on... That<br>
>>>>>>> would remove the need to include all the security groups<br>
>>>>>>> information on every call...<br>
>>><br>
>>>>>>> But would need another call to get the full information of<br>
>>>>>>> a set of security groups at start/resync if we don't<br>
>>>>>>> already have any.<br>
>>><br>
>>><br>
>>>>>>>><br>
>>>>>>>> On Fri, Jun 20, 2014 at 4:04 AM, shihanzhang <<br>
>>>>>>> <a href="mailto:ayshihanzhang@126.com" target="_blank">ayshihanzhang@126.com</a> ><br>
>>>>>>>> wrote:<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> hi Miguel Ángel, I am very agree with you about the<br>
>>>>>>>> following point:<br>
>>>>>>>>> * physical implementation on the hosts (ipsets,<br>
>>>>>>>>> nftables, ... )<br>
>>>>>>>> --this can reduce the load of compute node.<br>
>>>>>>>>> * rpc communication mechanisms.<br>
>>>>>>>> -- this can reduce the load of neutron server can you<br>
>>>>>>>> help me to review my BP specs?<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> At 2014-06-19 10:11:34, "Miguel Angel Ajo Pelayo" <<br>
>>>>>>> <a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a> ><br>
>>>>>>>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Hi it's a very interesting topic, I was getting ready<br>
>>>>>>>>> to raise the same concerns about our security groups<br>
>>>>>>>>> implementation,<br>
>>>>>>> shihanzhang<br>
>>>>>>>>> thank you for starting this topic.<br>
>>>>>>>>><br>
>>>>>>>>> Not only at low level where (with our default security<br>
>>>>>>>>> group rules -allow all incoming from 'default' sg- the<br>
>>>>>>>>> iptable rules will grow in ~X^2 for a tenant, and, the<br>
>>>>>>>>> "security_group_rules_for_devices" rpc call from<br>
>>>>>>>>> ovs-agent to neutron-server grows to message sizes of<br>
>>>>>>>>>> 100MB,<br>
>>>>>>>>> generating serious scalability issues or<br>
>>>>>>>>> timeouts/retries that totally break neutron service.<br>
>>>>>>>>><br>
>>>>>>>>> (example trace of that RPC call with a few instances<br>
>>>>>>>>> <a href="http://www.fpaste.org/104401/14008522/" target="_blank">http://www.fpaste.org/104401/14008522/</a> )<br>
>>>>>>>>><br>
>>>>>>>>> I believe that we also need to review the RPC calling<br>
>>>>>>>>> mechanism for the OVS agent here, there are several<br>
>>>>>>>>> possible approaches to<br>
>>>>>>> breaking<br>
>>>>>>>>> down (or/and CIDR compressing) the information we<br>
>>>>>>>>> return via this<br>
>>>>>>> api<br>
>>>>>>>>> call.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> So we have to look at two things here:<br>
>>>>>>>>><br>
>>>>>>>>> * physical implementation on the hosts (ipsets,<br>
>>>>>>>>> nftables, ... ) * rpc communication mechanisms.<br>
>>>>>>>>><br>
>>>>>>>>> Best regards, Miguel Ángel.<br>
>>>>>>>>><br>
>>>>>>>>> ----- Mensaje original -----<br>
>>>>>>>>><br>
>>>>>>>>>> Do you though about nftables that will replace<br>
>>>>>>> {ip,ip6,arp,eb}tables?<br>
>>>>>>>>>> It also based on the rule set mechanism. The issue<br>
>>>>>>>>>> in that proposition, it's only stable since the<br>
>>>>>>>>>> begin<br>
>>>>>>> of the<br>
>>>>>>>>>> year and on Linux kernel 3.13. But there lot of pros<br>
>>>>>>>>>> I don't list here (leverage iptables<br>
>>>>>>> limitation,<br>
>>>>>>>>>> efficient update rule, rule set, standardization of<br>
>>>>>>>>>> netfilter commands...).<br>
>>>>>>>>><br>
>>>>>>>>>> Édouard.<br>
>>>>>>>>><br>
>>>>>>>>>> On Thu, Jun 19, 2014 at 8:25 AM, henry hly <<br>
>>>>>>>>>> <a href="mailto:henry4hly@gmail.com" target="_blank">henry4hly@gmail.com</a> > wrote:<br>
>>>>>>>>><br>
>>>>>>>>>>> we have done some tests, but have different<br>
>>>>>>>>>>> result: the<br>
>>>>>>> performance is<br>
>>>>>>>>>>> nearly the same for empty and 5k rules in iptable,<br>
>>>>>>>>>>> but huge gap between enable/disable iptable hook<br>
>>>>>>>>>>> on linux bridge<br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>> On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang <<br>
>>>>>>> <a href="mailto:ayshihanzhang@126.com" target="_blank">ayshihanzhang@126.com</a><br>
>>>>>>>>>>>><br>
>>>>>>>>>>> wrote:<br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>>> Now I have not get accurate test data, but I can<br>
>>>>>>>>>>>> confirm the following points?<br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>> 1. In compute node, the iptable's chain of a VM<br>
>>>>>>>>>>>> is liner,<br>
>>>>>>> iptable<br>
>>>>>>>>>>>> filter it one by one, if a VM in default<br>
>>>>>>>>>>>> security group and this default security group<br>
>>>>>>>>>>>> have many members, but ipset chain is set, the<br>
>>>>>>>>>>>> time<br>
>>>>>>> ipset<br>
>>>>>>>>>>>> filter one and many member is not much<br>
>>>>>>>>>>>> difference.<br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>> 2. when the iptable rule is very large, the<br>
>>>>>>>>>>>> probability of<br>
>>>>>>> failure<br>
>>>>>>>>>>>> that iptable-save save the iptable rule is very<br>
>>>>>>>>>>>> large.<br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>>> At 2014-06-19 10:55:56, "Kevin Benton" <<br>
>>>>>>>>>>>> <a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a><br>
>>>>>>>> wrote:<br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>>>> This sounds like a good idea to handle some of<br>
>>>>>>>>>>>>> the<br>
>>>>>>> performance<br>
>>>>>>>>>>>>> issues until the ovs firewall can be<br>
>>>>>>>>>>>>> implemented down the the line.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>>> Do you have any performance comparisons?<br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>>> On Jun 18, 2014 7:46 PM, "shihanzhang" <<br>
>>>>>>> <a href="mailto:ayshihanzhang@126.com" target="_blank">ayshihanzhang@126.com</a> ><br>
>>>>>>>>>>>>> wrote:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>>>>> Hello all,<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>>>>> Now in neutron, it use iptable implementing<br>
>>>>>>>>>>>>>> security<br>
>>>>>>> group, but<br>
>>>>>>>>>>>>>> the performance of this implementation is<br>
>>>>>>>>>>>>>> very poor, there<br>
>>>>>>> is a bug:<br>
>>>>>>>>>>>>>> <a href="https://bugs.launchpad.net/neutron/+bug/1302272" target="_blank">https://bugs.launchpad.net/neutron/+bug/1302272</a><br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>><br>
>>to<br>
>>>>>>> reflect this<br>
>>>>>>>>>>>>>> problem. In his test, w ith default security<br>
>>>>>>>>>>>>>> groups(which has remote security group),<br>
>>>>>>>>>>>>>> beyond 250-300 VMs, there were around 6k<br>
>>>>>>>>>>>>>> Iptable rules<br>
>>>>>>> on evry<br>
>>>>>>>>>>>>>> compute node, although his patch can reduce<br>
>>>>>>>>>>>>>> the processing time, but<br>
>>>>>>> it don't<br>
>>>>>>>>>>>>>> solve this problem fundamentally. I have<br>
>>>>>>>>>>>>>> commit a BP to solve this<br>
>>>>>>> problem:<br>
>>>>>>>>>>>>>><br>
>>>>>>> <a href="https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security" target="_blank">https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security</a><br>
>>><br>
>>>>>>><br>
>>><br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>>>> There are other people interested in this<br>
>>>>>>>>>>>>>> it?<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>>>>> _______________________________________________<br>
>>><br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a> >> > > ><br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>>>><br>
>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>>>>>><br>
>>><br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a> >> ><br>
>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>>><br>
>>>>>>><br>
>>>><br>
>>>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>><br>
>>>>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>>>><br>
>>>>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a> >><br>
>>>>>>>>>>><br>
>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>>><br>
>>>>>>><br>
>>>><br>
>>>>>>>>><br>
>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a> >><br>
>>>>>>>>>><br>
>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>>><br>
>>>>>>><br>
>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a> ><br>
>>>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>><br>
>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> OpenStack-dev mailing list<br>
>>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>>>>>><br>
>>>>>><br>
>>>>>><br>
>>><br>
>>> _______________________________________________<br>
>>>>>> OpenStack-dev mailing list <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>>><br>
>>><br>
>>>>>><br>
>>_______________________________________________<br>
>>>>> OpenStack-dev mailing list <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>><br>
>>>>><br>
>>>>><br>
>>>> _______________________________________________ OpenStack-dev<br>
>>>> mailing list <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>>_______________________________________________<br>
>>>>>>OpenStack-dev<br>
>>>><br>
>>mailing list<br>
>>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>>><br>
>>_______________________________________________<br>
>>>>> OpenStack-dev mailing list <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>><br>
>>>>_______________________________________________<br>
>>>>OpenStack-dev<br>
>>>>><br>
>>mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________ OpenStack-dev<br>
>>> mailing list <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>-----BEGIN PGP SIGNATURE-----<br>
>>Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br>
>>Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
>><br>
>>iQEcBAEBCgAGBQJTtWPVAAoJEC5aWaUY1u57PyMH/3Honqp3NQN5d1crkgn2y4zR<br>
>>IiMlTMoeloaLx84Fv7Ya44evA+ZX1dDIfozrig+/uuWlVXql4EIl9vcGQ2T0xvoE<br>
>>WXo7eu6D4ysca1Bx0AAmNi3IY0jC3QP46V3slmOWYHW2GAwRrrWHLyuOfCubPros<br>
>>7zlOEC5MRZsh1KY3fj+bX1a7dmR6QdKqnya/JdP8I0bkkYxOXAivX+gFJCTGeB23<br>
>>1Ss//rr781W9mynwB2rXssUQZU3ySK7PQmMEAVZUPkPAIzbtlTfq7nbV1GPzL3Di<br>
>>/qEXL0cEx57fv9l8SvqYHqVpeh09dbh3h7kKKovwgNKCpiD1oMDoWgCS+PelZFc=<br>
>>=TxAT<br>
>>-----END PGP SIGNATURE-----<br>
>><br>
>>_______________________________________________<br>
>>OpenStack-dev mailing list<br>
>><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><font color="#999999">Best wishes!<br>Baohua<br></font>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>