Open Stack

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