<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="HU" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi, <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Some comments inline.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Alan Bishop <abishop@redhat.com>
<br>
<b>Sent:</b> Thursday, August 16, 2018 7:09 PM<br>
<br>
<o:p></o:p></span></p>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Aug 14, 2018 at 9:20 AM Bogdan Dobrelya <<a href="mailto:bdobreli@redhat.com">bdobreli@redhat.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">On 8/13/18 9:47 PM, Giulio Fidente wrote:<br>
> Hello,<br>
> <br>
> I'd like to get some feedback regarding the remaining<br>
> work for the split controlplane spec implementation [1]<br>
> <br>
> Specifically, while for some services like nova-compute it is not<br>
> necessary to update the controlplane nodes after an edge cloud is<br>
> deployed, for other services, like cinder (or glance, probably<br>
> others), it is necessary to do an update of the config files on the<br>
> controlplane when a new edge cloud is deployed.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">[G0]: What is the reason to run a shared cinder in an edge cloud infrastructure? Maybe it is a better approach to run an individual Cinder in every edge cloud instance.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> In fact for services like cinder or glance, which are hosted in the<br>
> controlplane, we need to pull data from the edge clouds (for example<br>
> the newly deployed ceph cluster keyrings and fsid) to configure cinder<br>
> (or glance) with a new backend.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">[G0]: Solution ideas for Glance are listed in [<a href="https://wiki.openstack.org/wiki/Image_handling_in_edge_environment">3</a>].<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> It looks like this demands for some architectural changes to solve the > following two:<br>
> <br>
> - how do we trigger/drive updates of the controlplane nodes after the<br>
> edge cloud is deployed?<br>
<br>
Note, there is also a strict(?) requirement of local management <br>
capabilities for edge clouds temporary disconnected off the central <br>
controlplane. That complicates the updates triggering even more. We'll <br>
need at least a notification-and-triggering system to perform required <br>
state synchronizations, including conflicts resolving. If that's the <br>
case, the architecture changes for TripleO deployment framework are <br>
inevitable AFAICT.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">This is another interesting point. I don't mean to disregard it, but want to<br>
highlight the issue that Giulio and I (and others, I'm sure) are focused on.<br>
<br>
As a cinder guy, I'll use cinder as an example. Cinder services running in the<br>
control plane need to be aware of the storage "backends" deployed at the<br>
Edge. So if a split-stack deployment includes edge nodes running a ceph<br>
cluster, the cinder services need to be updated to add the ceph cluster as a<br>
new cinder backend. So, not only is control plane data needed in order to<br>
deploy an additional stack at the edge, data from the edge deployment needs to<br>
be fed back into a subsequent stack update in the controlplane. Otherwise,<br>
cinder (and other storage services) will have no way of utilizing ceph<br>
clusters at the edge.<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">> <br>
> - how do we scale the controlplane parameters to accomodate for N<br>
> backends of the same type?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, this is also a big problem for me. Currently, TripleO can deploy cinder<br>
with multiple heterogeneous backends (e.g. one each of ceph, NFS, Vendor X,<br>
Vendor Y, etc.). However, the current THT do not let you deploy multiple<br>
instances of the same backend (e.g. more than one ceph). If the goal is to<br>
deploy multiple edge nodes consisting of Compute+Ceph, then TripleO will need<br>
the ability to deploy multiple homogeneous cinder backends. This requirement<br>
will likely apply to glance and manila as well.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">> A very rough approach to the latter could be to use jinja to scale up<br>
> the CephClient service so that we can have multiple copies of it in the<br>
> controlplane.<br>
> <br>
> Each instance of CephClient should provide the ceph config file and<br>
> keyring necessary for each cinder (or glance) backend.<br>
> <br>
> Also note that Ceph is only a particular example but we'd need a similar<br>
> workflow for any backend type.<br>
> <br>
> The etherpad for the PTG session [2] touches this, but it'd be good to<br>
> start this conversation before then.<br>
> <br>
> 1.<br>
> <a href="https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html" target="_blank">
https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html</a><br>
> <br>
> 2. <a href="https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane" target="_blank">
https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane</a><br>
> <br>
<br>
[3]: <a href="https://wiki.openstack.org/wiki/Image_handling_in_edge_environment">
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Br, <o:p></o:p></p>
<p class="MsoNormal">Gerg0<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><br>
-- <br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>