<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 26/6/2017 14:00,
      <a class="moz-txt-link-abbreviated" href="mailto:juju-request@lists.ubuntu.com">juju-request@lists.ubuntu.com</a> wrote:<br>
    </div>
    <blockquote
      cite="mid:mailman.51.1498478405.27118.juju@lists.ubuntu.com"
      type="cite">
      <pre wrap="">Date: Mon, 26 Jun 2017 12:13:10 +0300
From: Dmitrii Shcherbakov <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:dmitrii.shcherbakov@canonical.com"><dmitrii.shcherbakov@canonical.com></a>
To: Merlijn Sebrechts <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:merlijn.sebrechts@gmail.com"><merlijn.sebrechts@gmail.com></a>
Cc: juju <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:juju@lists.ubuntu.com"><juju@lists.ubuntu.com></a>
Subject: Re: Italian federated cloud runs Juju
Message-ID:
        <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:CAE1qvGQOuqO_WYBw28TtTeenrBUrGp-kksfWZb1kkX1hsuiYaA@mail.gmail.com"><CAE1qvGQOuqO_WYBw28TtTeenrBUrGp-kksfWZb1kkX1hsuiYaA@mail.gmail.com></a>
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.

<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://insights.ubuntu.com/wp-content/uploads/058f/Screen-Shot-2015-07-09-at-11.02.33.png">https://insights.ubuntu.com/wp-content/uploads/058f/Screen-Shot-2015-07-09-at-11.02.33.png</a>

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:

<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://serverascode.com/2017/05/09/openstack-multisite-multicloud.html">http://serverascode.com/2017/05/09/openstack-multisite-multicloud.html</a>

<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=3YCogWHREHA">https://www.youtube.com/watch?v=3YCogWHREHA</a>

<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://beyondtheclouds.github.io/dcc.html">https://beyondtheclouds.github.io/dcc.html</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds">https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds</a>

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</pre>
    </blockquote>
    Yes, it is the same guy, it is me.<br>
    <br>
    This is not just an authencication federation, as Shcherbakov says.<br>
    This is a true federation made of multiple regions, with a single
    coordinating master region.<br>
    This makes the federation into a *single* cloud, where any resource
    is available to any user of the federation.<br>
    We use federated authentication, just for authenticating users,
    using three types of authentication: SAML, OIDC and Keystone.<br>
    But the federation consists of several distinct OpenStack clouds,
    which share common O~S infrastructure services.<br>
    It took us a considerable amount of work to achieve this solution,
    that delegates administration of individual regions to specific
    domain administrators.<br>
    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.<br>
    <br>
    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.<br>
    That is were I have developed a charm for Gnocchi.<br>
    <br>
    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.<br>
    Ours is a deployed and working federation with over 500 current
    users.<br>
    <br>
    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.<br>
    Each participant was given it own set of resources so that they
    could practically build a new OpenStack region in a few hours!<br>
    They were all enthusiastic.<br>
    You can see a picture of the participants here:<br>
        <br>
       
<a class="moz-txt-link-freetext" href="https://www.facebook.com/photo.php?fbid=10155052806563855&set=a.10151237649608855.434137.518308854">https://www.facebook.com/photo.php?fbid=10155052806563855&set=a.10151237649608855.434137.518308854</a><br>
    <br>
    The slides will be made available soon, including a tutorial on
    building charms (in particular the Jupyter Notebook charm will be a
    use case).<br>
    <pre wrap="">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

</pre>
  </body>
</html>