<div dir="ltr">Nice job! That's awesome.<div><br></div><div>Thanks,</div><div>Édouard.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 8:02 AM, Miguel Angel Ajo Pelayo <span dir="ltr"><<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you shihanzhang!,<br>
<br>
I can't believe I didn't realize the ipset part spec was accepted I live<br>
on my own bubble... I will be reviewing and testing/helping on that part<br>
too during the next few days,  I was too concentrated in the RPC part.<br>
<br>
<br>
Best regards,<br>
<div class=""><br>
----- Original Message -----<br>
> hi neutroner!<br>
> my patch about BP:<br>
> <a href="https://blueprints.launchpad.net/openstack/?searchtext=add-ipset-to-security" target="_blank">https://blueprints.launchpad.net/openstack/?searchtext=add-ipset-to-security</a><br>
> need install ipset in devstack, I have commit the patch:<br>
> <a href="https://review.openstack.org/#/c/113453/" target="_blank">https://review.openstack.org/#/c/113453/</a>, who can help me review it, thanks<br>
> very much!<br>
><br>
> Best regards,<br>
> shihanzhang<br>
><br>
><br>
><br>
><br>
> At 2014-08-21 10:47:59, "Martinx - ジェームズ" <<a href="mailto:thiagocmartinsc@gmail.com">thiagocmartinsc@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> +1 "NFTablesDriver"!<br>
><br>
> Also, NFTables, AFAIK, improves IDS systems, like Suricata, for example:<br>
> <a href="https://home.regit.org/2014/02/suricata-and-nftables/" target="_blank">https://home.regit.org/2014/02/suricata-and-nftables/</a><br>
><br>
> Then, I'm wondering here... What benefits might come for OpenStack Nova /<br>
> Neutron, if it comes with a NFTables driver, instead of the current<br>
> IPTables?!<br>
><br>
</div>> * E fficient Security Group design?<br>
<div class="">> * Better FWaaS, maybe with NAT(44/66) support?<br>
> * Native support for IPv6, with the defamed NAT66 built-in, simpler "Floating<br>
> IP" implementation, for both v4 and v6 networks under a single<br>
</div>> implementation ( I don't like NAT66, I prefer a `routed Floating IPv6`<br>
> version ) ?<br>
> * Metadata over IPv6 still using NAT(66) ( I don't like NAT66 ), single<br>
<div class="HOEnZb"><div class="h5">> implementation?<br>
> * Suricata-as-a-Service?!<br>
><br>
> It sounds pretty cool! :-)<br>
><br>
><br>
> On 20 August 2014 23:16, Baohua Yang < <a href="mailto:yangbaohua@gmail.com">yangbaohua@gmail.com</a> > wrote:<br>
><br>
><br>
><br>
> Great！<br>
> We met similar problems.<br>
> The current mechanisms produce too many iptables rules, and it's hard to<br>
> debug.<br>
> Really look forward to seeing a more efficient security group design.<br>
><br>
><br>
> On Thu, Jul 10, 2014 at 11:44 PM, Kyle Mestery < <a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> On Thu, Jul 10, 2014 at 4:30 AM, shihanzhang < <a href="mailto:ayshihanzhang@126.com">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>
> 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>
> Kyle<br>
><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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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">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>
> Best wishes!<br>
> Baohua<br>
><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>
><br>
><br>
><br>
><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>
<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>
</div></div></blockquote></div><br></div>