> What is the REST API for tricircle? > When looking at the github I see: > ''Documentation: TBD'' > Getting a feel for its REST API would really be helpful in determine how > much of a proxy/request router it is vs being an actual API. I don't > really want/like a proxy/request router (if that wasn't obvious, ha).
For Nova API-GW/Cinder API-GW, Nova API/Cinder API will be accepted and forwarded. For Neutron with Tricircle Neutron plugin in Tricircle, it's Neutron API, just like any other Neutron plugin, doesn't change Neutron API. Tricircle reuse tempest test cases to ensure the API accepted kept consistent with Nova/Cinder/Neutron. So no special documentation for these APIs(if we provide, documentation inconsistency will be introduced) Except that, Tricircle Admin API provides its own API to manage bottom OpenStack instance, the documentation is in review: https://review.openstack.org/#/c/356291/ > Looking at say: > https://github.com/openstack/tricircle/blob/master/tricircle/nova_apigw/controllers/server.py > That doesn't inspire me so much, since that appears to be more of a > fork/join across many different clients, and creating a nova like API > out of the joined results of those clients (which feels sort of ummm, > wrong). This is where I start to wonder about what the right API is > here, and trying to map 1 `create_server` top-level API onto M child > calls feels a little off (because that mapping will likely never be > correct due to the nature of the child clouds, ie u have to assume a > very strict homogenous nature to even get close to this working). > Where there other alternative ways of doing this that were discussed? > Perhaps even a new API that doesn't try to 1:1 map onto child calls, > something along the line of make an API that more directly suits what > this project is trying to do (vs trying to completely hide that there M > child calls being made underneath). > I get the idea of becoming a uber-openstack-API and trying to unify X > other other openstacks under that API with this uber-API but it just > feels like the wrong way to tackle this. > -Josh This is an interesting phenomenon here: cloud operators and end users often asked for single endpoint for the multi-site cloud. But for technology guys often think multi-region mode(each region with separate endpoint) is not an issue for end user. During the Tricircle big-tent application https://review.openstack.org/#/c/338796/ , Anne Gentle commented "Rackspace public cloud has had multiple endpoints for regions for years now. I know from supporting end users for years we had to document it, and explain it often, but end-users worked with it." In another comment, "I want to be sure I'm clear that I want many of the problems solved that you mention in your application. In my view, Tricircle has so far been a bit of an isolated effort that I hadn't heard of until now. Hence the amount of discussion and further work we may need to get to the end goal, which isn't accepting another project but making sure we clearly write down what an acceptable solution means for many, many clouds and teams. I can't say who is correct or not, the requirement is true or false(or fake?). But single end point for multi-site cloud provides another choice for the end user and cloud operators. Except that, Tricircle tries to provide quota management over multi-region and global resource management like flavor/volume-type, the end user and cloud operators not see each seperate/disjoint flavor/volume-type. And moreover, Tricircle wants to support large scale cloud too. In AWS, one AZ(Avaialbility Zone) includes 1 or more DC, and 1 DC typically with more than 50 thousands of physical servers, and one region have 2 or more AZs. The size of one region >= 50k physical servers http://www.slideshare.net/AmazonWebServices/spot301-aws-innovation-at-scale-aws-reinvent-2014 So in Tricircle, provides a model that one AZ can includes multiple bottom OpenStack instances(one OpenStack instances scalability is limited by many factors). Through this model, Tricircle can support one region with many AZs, and many OpenStack instances to support large scale cloud. Here is the spec for dynamic pod binding(one bottom OpenStack instance is called a pod in Tricircle) https://github.com/openstack/tricircle/blob/master/specs/dynamic-pod-binding.rst Nova/Cinder API routing itself is no value to OpenStack community, no value to end user or cloud operators. But through the Nova/Cinder API routing, we can add additional value for quota management/gloabl objects like flavor/volume type/utra-large AZ, to extend current Nova/Cinder/Neutron API with the capability to reach Amazon level scalability, and don't ruin already built OpenStack API eco-system. That means single model to deal with multi-site and large scale cloud need: multi-site often means large-scale too. We proposed to add plugin mechanism in Nova/Cinder API layer to remove the in-consistency worry, but it'll take long time to get consensus in community wide. So Tricircle will be divided into two independent and decoupled projects, only one of the projects which deal with networking automation will try to become an big-tent project, And Nova/Cinder API-GW will be removed from the scope of big-tent project application, and put them into another project: https://docs.google.com/presentation/d/1kpVo5rsL6p_rq9TvkuczjommJSsisDiKJiurbhaQg7E TricircleNetworking: Dedicated for cross Neutron networking automation in multi-region OpenStack deployment, run without or with TricircleGateway. Try to become big-tent project in the current application of https://review.openstack.org/#/c/338796/. TricircleGateway: Dedicated to provide API gateway for those who need single Nova/Cinder API endpoint in multi-region OpenStack deployment, run without or with TricircleNetworking. Live as non-big-tent, non-offical-openstack project, just like Tricircle toady’s status. And not pursue big-tent only if the consensus can be achieved in OpenStack community, including Arch WG and TCs, then decide how to get it on board in OpenStack. A new repository is needed to be applied for this project. If you want to use other APIs to manage edge clouds, at last we have to support all operations and attributes which provided in OpenStack, and it will grow to a collection of API sets which includes all in OpenStack APIs. Can we simplify and ignore some features which are already supported in Nova/Cinder/Neutron? This is a question. Best Regards Chaoyi Huang (joehuang) ________________________________________ From: Joshua Harlow [[email protected]] Sent: 01 September 2016 12:17 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs joehuang wrote: > I just pointed out the issues for RPC which is used between API cell and > child cell if we deploy child cells in edge clouds. For this thread is > about massively distributed cloud, so the RPC issues inside current > Nova/Cinder/Neutron are not the main focus(it could be another important > and interesting topic), for example, how to guarantee the reliability > for rpc message: +1 although I'd like to also discuss this, but so be it, perhaps a different topic :) > > > Cells is a good enhancement for Nova scalability, but there are > some issues > > in deployment Cells for massively distributed edge clouds: > > > > 1) using RPC for inter-data center communication will bring the > difficulty > > in inter-dc troubleshooting and maintenance, and some critical > issue in > > operation. No CLI or restful API or other tools to manage a child > cell > > directly. If the link between the API cell and child cells is > broken, then > > the child cell in the remote edge cloud is unmanageable, no > matter locally > > or remotely. > > > > 2). The challenge in security management for inter-site RPC > communication. > > Please refer to the slides[1] for the challenge 3: Securing > OpenStack over > > the Internet, Over 500 pin holes had to be opened in the firewall > to allow > > this to work – Includes ports for VNC and SSH for CLIs. Using RPC > in cells > > for edge cloud will face same security challenges. > > > > 3)only nova supports cells. But not only Nova needs to support > edge clouds, > > Neutron, Cinder should be taken into account too. How about > Neutron to > > support service function chaining in edge clouds? Using RPC? how > to address > > challenges mentioned above? And Cinder? > > > > 4). Using RPC to do the production integration for hundreds of > edge cloud is > > quite challenge idea, it's basic requirements that these edge > clouds may > > be bought from multi-vendor, hardware/software or both. > > That means using cells in production for massively distributed > edge clouds > > is quite bad idea. If Cells provide RESTful interface between API > cell and > > child cell, it's much more acceptable, but it's still not enough, > similar > > in Cinder, Neutron. Or just deploy lightweight OpenStack instance > in each > > edge cloud, for example, one rack. The question is how to manage > the large > > number of OpenStack instance and provision service. > > > > > > [1]https://www.openstack.org/assets/presentation-media/OpenStack-2016-Austin-D-NFV-vM.pdf > > > That's also my suggestion to collect all candidate proposals, and > discuss these proposals and compare their cons. and pros. in the > Barcelona summit. > > I propose to use Nova/Cinder/Neutron restful API for inter-site > communication for edge clouds, and provide Nova/Cinder/Neutron API as > the umbrella for all edge clouds. This is the pattern of Tricircle: > https://github.com/openstack/tricircle/ > What is the REST API for tricircle? When looking at the github I see: ''Documentation: TBD'' Getting a feel for its REST API would really be helpful in determine how much of a proxy/request router it is vs being an actual API. I don't really want/like a proxy/request router (if that wasn't obvious, ha). Looking at say: https://github.com/openstack/tricircle/blob/master/tricircle/nova_apigw/controllers/server.py That doesn't inspire me so much, since that appears to be more of a fork/join across many different clients, and creating a nova like API out of the joined results of those clients (which feels sort of ummm, wrong). This is where I start to wonder about what the right API is here, and trying to map 1 `create_server` top-level API onto M child calls feels a little off (because that mapping will likely never be correct due to the nature of the child clouds, ie u have to assume a very strict homogenous nature to even get close to this working). Where there other alternative ways of doing this that were discussed? Perhaps even a new API that doesn't try to 1:1 map onto child calls, something along the line of make an API that more directly suits what this project is trying to do (vs trying to completely hide that there M child calls being made underneath). I get the idea of becoming a uber-openstack-API and trying to unify X other other openstacks under that API with this uber-API but it just feels like the wrong way to tackle this. -Josh __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
