Open Stack

> 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 [harlowja at fastmail.com]
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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev