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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
