Hello, Andrew, Thanks for your confirmation. See inline comments, pls.
-----Original Message----- From: Andrew Laski [mailto:andrew.la...@rackspace.com] Sent: Friday, December 12, 2014 3:56 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward On 12/11/2014 04:02 AM, joehuang wrote: > Hello, Russell, > > Many thanks for your reply. See inline comments. > > -----Original Message----- > From: Russell Bryant [mailto:rbry...@redhat.com] > Sent: Thursday, December 11, 2014 5:22 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – > summit recap and move forward > >>> On Fri, Dec 5, 2014 at 8:23 AM, joehuang <joehu...@huawei.com> wrote: >>>> Dear all & TC & PTL, >>>> >>>> In the 40 minutes cross-project summit session “Approaches for >>>> scaling out”[1], almost 100 peoples attended the meeting, and the >>>> conclusion is that cells can not cover the use cases and >>>> requirements which the OpenStack cascading solution[2] aim to >>>> address, the background including use cases and requirements is >>>> also described in the mail. >> I must admit that this was not the reaction I came away with the discussion >> with. >> There was a lot of confusion, and as we started looking closer, many >> (or perhaps most) people speaking up in the room did not agree that >> the requirements being stated are things we want to try to satisfy. >> [joehuang] Could you pls. confirm your opinion: 1) cells can not cover the >> use cases and requirements which the OpenStack cascading solution aim to >> address. 2) Need further discussion whether to satisfy the use cases and >> requirements. >Correct, cells does not cover all of the use cases that cascading aims to >address. But it was expressed that the use cases that are not covered may not >be cases that we want addressed. [joehuang] Ok, Need further discussion to address the cases or not. > On 12/05/2014 06:47 PM, joehuang wrote: >>>> Hello, Davanum, >>>> >>>> Thanks for your reply. >>>> >>>> Cells can't meet the demand for the use cases and requirements described >>>> in the mail. >> You're right that cells doesn't solve all of the requirements you're >> discussing. >> Cells addresses scale in a region. My impression from the summit >> session and other discussions is that the scale issues addressed by >> cells are considered a priority, while the "global API" bits are not. > [joehuang] Agree cells is in the first class priority. > >>>> 1. Use cases >>>> a). Vodafone use case[4](OpenStack summit speech video from 9'02" >>>> to 12'30" ), establishing globally addressable tenants which result >>>> in efficient services deployment. >> Keystone has been working on federated identity. >> That part makes sense, and is already well under way. > [joehuang] The major challenge for VDF use case is cross OpenStack networking > for tenants. The tenant's VM/Volume may be allocated in different data > centers geographically, but virtual network (L2/L3/FW/VPN/LB) should be built > for each tenant automatically and isolated between tenants. Keystone > federation can help authorization automation, but the cross OpenStack network > automation challenge is still there. > Using prosperity orchestration layer can solve the automation issue, but VDF > don't like prosperity API in the north-bound, because no ecosystem is > available. And other issues, for example, how to distribute image, also > cannot be solved by Keystone federation. > >>>> b). Telefonica use case[5], create virtual DC( data center) cross >>>> multiple physical DCs with seamless experience. >> If we're talking about multiple DCs that are effectively local to >> each other with high bandwidth and low latency, that's one conversation. >> My impression is that you want to provide a single OpenStack API on >> top of globally distributed DCs. I honestly don't see that as a >> problem we should be trying to tackle. I'd rather continue to focus >> on making OpenStack work >> *really* well split into regions. >> I think some people are trying to use cells in a geographically >> distributed way, as well. I'm not sure that's a well understood or >> supported thing, though. >> Perhaps the folks working on the new version of cells can comment further. >> [joehuang] 1) Splited region way cannot provide cross OpenStack networking >> automation for tenant. 2) exactly, the motivation for cascading is "single >> OpenStack API on top of globally distributed DCs". Of course, cascading can >> also be used for DCs close to each other with high bandwidth and low >> latency. 3) Folks comment from cells are welcome. >> . >Cells can handle a single API on top of globally distributed DCs. I have >spoken with a group that is doing exactly that. But it requires that the API >is a trusted part of the OpenStack deployments in those distributed DCs. [joehuang] Could you pls. make it more clear for the deployment mode of cells when used for globally distributed DCs with single API. Do you mean cinder/neutron/glance/ceilometer will be shared by all cells, and use RPC for inter-dc communication, and only support one vendor's OpenStack distribution? How to do the cross data center integration and troubleshooting with RPC if the driver/agent/backend(storage/network/sever) from different vendor. > >>>> c). ETSI NFV use cases[6], especially use case #1, #2, #3, #5, #6, >>>> 8#. For NFV cloud, it’s in nature the cloud will be distributed but >>>> inter-connected in many data centers. >> I'm afraid I don't understand this one. In many conversations about NFV, I >> haven't heard this before. > [joehuang] This is the ETSI requirement and use cases specification for NFV. > ETSI is the home of the Industry Specification Group for NFV. In Figure 14 > (virtualization of EPC) of this document, you can see that the operator's > cloud including many data centers to provide connection service to end user > by inter-connected VNFs. The requirements listed in > (https://wiki.openstack.org/wiki/TelcoWorkingGroup) is mainly about the > requirements from specific VNF(like IMS, SBC, MME, HSS, S/P GW etc) to run > over cloud, eg. migrate the traditional telco. APP from prosperity hardware > to cloud. Not all NFV requirements have been covered yet. Forgive me there > are so many telco terms here. > >>>> 2.requirements >>>> a). The operator has multiple sites cloud; each site can use one or >>>> multiple vendor’s OpenStack distributions. >> Is this a technical problem, or is a business problem of vendors not >> wanting to support a mixed environment that you're trying to work >> around with a technical solution? > [joehuang] Pls. refer to VDF use case, the multi-vendor policy has been > stated very clearly: 1) Local relationships: Operating Companies also have > long standing relationships to their own choice of vendors; 2) Multi-Vendor > :Each site can use one or multiple vendors which leads to better use of local > resources and capabilities. Technical solution must be provided for > multi-vendor integration and verification, It's usually ETSI standard in the > past for mobile network. But how to do that in multi-vendor's cloud > infrastructure? Cascading provide a way to use OpenStack API as the > integration interface. > >>> b). Each site with its own requirements and upgrade schedule while >>> maintaining standard OpenStack API c). The multi-site cloud must >>> provide unified resource management with global Open API exposed, >>> for example create virtual DC cross multiple physical DCs with >>> seamless experience. >>> Although a prosperity orchestration layer could be developed for the >>> multi-site cloud, but it's prosperity API in the north bound >>> interface. The cloud operators want the ecosystem friendly global >>> open API for the mutli-site cloud for global access. >> I guess the question is, do we see a "global API" as something we >> want to accomplish. What you're talking about is huge, and I'm not >> even sure how you would expect it to work in some cases (like networking). > [joehuang] Yes, the most challenge part is networking. In the PoC, L2 > networking cross OpenStack is to leverage the L2 population > mechanism.The L2proxy for DC1 in the cascading layer will detect the > new VM1(in DC1)'s port is up, and then ML2 L2 population will be > activated, the VM1's tunneling endpoint- host IP or L2GW IP in DC1, > will be populated to L2proxy for DC2, and L2proxy for DC2 will create > a external port in the DC2 Neutron with the VM1's tunneling endpoint- > host IP or L2GW IP in DC1. The external port will be attached to the > L2GW or only external port created, L2 population(if not L2GW used) > inside DC2 can be activated to notify all VMs located in DC2 for the > same L2 network. For L3 networking finished in the PoC is to use extra > route over GRE to serve local VLAN/VxLAN networks located in different > DCs. Of course, other L3 networking method can be developed, for > example, through VPN service. There are 4 or 5 BPs talking about edge > network gateway to connect OpenStack tenant network to outside > network, all these technologies can be leveraged to do cross OpenStack > networking for different scenario. To experience the cross OpenStack > networking, please try PoC source code: > https://github.com/stackforge/tricircle > >> In any case, to be as clear as possible, I'm not convinced this is >> something we should be working on. I'm going to need to see much >> more overwhelming support for the idea before helping to figure out any >> further steps. > [joehuang] If you or any other have any doubts, please feel free to ignite a > discussion thread. For time difference reason, we (working in China) are not > able to join most of IRC meeting, so mail-list is a good way for discussion. > > Russell Bryant > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > Best Regards > > Chaoyi Huang ( joehuang ) > > _______________________________________________ > 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 Regards Chaoyi Huang ( joehuang ) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
