On Thu, Dec 11, 2014 at 6:25 PM, joehuang <joehu...@huawei.com> wrote:
> Hello, Joe > > > > Thank you for your good question. > > > > Question: > > How would something like flavors work across multiple vendors. The > OpenStack API doesn't have any hard coded names and sizes for flavors. So a > flavor such as m1.tiny may actually be very different vendor to vendor. > > > > Answer: > > The flavor is defined by Cloud Operator from the cascading OpenStack. And > Nova-proxy ( which is the driver for “Nova as hypervisor” ) will sync the > flavor to the cascaded OpenStack when it was first used in the cascaded > OpenStack. If flavor was changed before a new VM is booted, the changed > flavor will also be updated to the cascaded OpenStack just before the new > VM booted request. Through this synchronization mechanism, all flavor used > in multi-vendor’s cascaded OpenStack will be kept the same as what used in > the cascading level, provide a consistent view for flavor. > I don't think this is sufficient. If the underlying hardware the between multiple vendors is different setting the same values for a flavor will result in different performance characteristics. For example, nova allows for setting VCPUs, but nova doesn't provide an easy way to define how powerful a VCPU is. Also flavors are commonly hardware dependent, take what rackspace offers: http://www.rackspace.com/cloud/public-pricing#cloud-servers Rackspace has "I/O Optimized" flavors * High-performance, RAID 10-protected SSD storage * Option of booting from Cloud Block Storage (additional charges apply for Cloud Block Storage) * Redundant 10-Gigabit networking * Disk I/O scales with the number of data disks up to ~80,000 4K random read IOPS and ~70,000 4K random write IOPS.* How would cascading support something like this? > > > Best Regards > > > > Chaoyi Huang ( joehuang ) > > > > *From:* Joe Gordon [mailto:joe.gord...@gmail.com] > *Sent:* Friday, December 12, 2014 8:17 AM > *To:* OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells - > summit recap and move forward > > > > > > > > On Thu, Dec 11, 2014 at 1:02 AM, joehuang <joehu...@huawei.com> 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. > > 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. > . > > >>> 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. > > > > How would something like flavors work across multiple vendors. The > OpenStack API doesn't have any hard coded names and sizes for flavors. So a > flavor such as m1.tiny may actually be very different vendor to vendor. > > > > > >> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev