Juju Digest, Vol 77, Issue 21

[Giuseppe Attardi]

On 26/6/2017 14:00, juju-request at lists.ubuntu.com wrote:
> Date: Mon, 26 Jun 2017 12:13:10 +0300
> From: Dmitrii Shcherbakov<dmitrii.shcherbakov at canonical.com>
> To: Merlijn Sebrechts<merlijn.sebrechts at gmail.com>
> Cc: juju<juju at lists.ubuntu.com>
> Subject: Re: Italian federated cloud runs Juju
> Message-ID:
> 	<CAE1qvGQOuqO_WYBw28TtTeenrBUrGp-kksfWZb1kkX1hsuiYaA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Merlijn,
>
> As far as I know, this is only authentication federation. It might fit into
> a single use-case but you will have independent clouds where projects don't
> have anything in common on different installations (e.g. quotas, security
> groups, resource limits etc. will not be synchronized in any way). VXLAN
> connectivity between sites will not be possible in this case as clouds
> don't know anything about each other.
>
> It is a good project and I am definitely glad that they use our tools for
> that!
>
> If you think about the ETSI Architecture, Juju is a VNF Manager and there
> should be a VNFM per site with an orchestrator on top in that model.
>
> https://insights.ubuntu.com/wp-content/uploads/058f/Screen-Shot-2015-07-09-at-11.02.33.png
>
> In general, there are multiple approaches to handling multi-site
> deployments (each with its trade-offs) which are mentioned in a great blog
> post written after the OpenStack Summit this year:
>
> http://serverascode.com/2017/05/09/openstack-multisite-multicloud.html
>
> https://www.youtube.com/watch?v=3YCogWHREHA
>
> https://beyondtheclouds.github.io/dcc.html
> https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds
>
> Just wanted to share that in case you are interested in multi-site
> deployments and how does Juju fit in these.
>
> No approach is preferable in my view as there are different requirements
> and use-cases.
>
> Best Regards,
> Dmitrii Shcherbakov
>
> Field Software Engineer
> IRC (freenode): Dmitrii-Sh
Yes, it is the same guy, it is me.

This is not just an authencication federation, as Shcherbakov says.
This is a true federation made of multiple regions, with a single 
coordinating master region.
This makes the federation into a *single* cloud, where any resource is 
available to any user of the federation.
We use federated authentication, just for authenticating users, using 
three types of authentication: SAML, OIDC and Keystone.
But the federation consists of several distinct OpenStack clouds, which 
share common O~S infrastructure services.
It took us a considerable amount of work to achieve this solution, that 
delegates administration of individual regions to specific domain 
administrators.
In particular the solution allows us to deal with resource segregation, 
so that only each O~S project is entitled to use just the resources that 
have been assigned to it, by clever use of the quota mechanism.

We are also working on a sophisticated accounting/billing scheme that 
allows each user/organization to visualize the amount of resources they 
use and to be billed accordingly.
That is were I have developed a charm for Gnocchi.

The link mentioned by Shcherbakov presents a nice discussion about the 
options for building a federation, that we all considered before 
building ours. Tricircla was not ready for production.
Ours is a deployed and working federation with over 500 current users.

We just run a two day workshop in Rome with 10 people from eastern 
Europe in the EaPConnect European project, where we gave them a full 
hands-one experience on how to build a region and then to integrate it 
into the federation.
Each participant was given it own set of resources so that they could 
practically build a new OpenStack region in a few hours!
They were all enthusiastic.
You can see a picture of the participants here:

https://www.facebook.com/photo.php?fbid=10155052806563855&set=a.10151237649608855.434137.518308854

The slides will be made available soon, including a tutorial on building 
charms (in particular the Jupyter Notebook charm will be a use case).

The technology for O~S multiclouds, still needs improvements, but for now, this is our practical solution.

Please read the paper and provide feedback.
If there are better solutions, we would be glad to explore them.

-- Giuseppe Attardi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170626/ab698789/attachment.html>