Open Stack

On Tue, Aug 14, 2018 at 9:20 AM Bogdan Dobrelya <bdobreli at redhat.com> wrote:

> On 8/13/18 9:47 PM, Giulio Fidente wrote:
> > Hello,
> >
> > I'd like to get some feedback regarding the remaining
> > work for the split controlplane spec implementation [1]
> >
> > Specifically, while for some services like nova-compute it is not
> > necessary to update the controlplane nodes after an edge cloud is
> > deployed, for other services, like cinder (or glance, probably
> > others), it is necessary to do an update of the config files on the
> > controlplane when a new edge cloud is deployed.
> >
> > In fact for services like cinder or glance, which are hosted in the
> > controlplane, we need to pull data from the edge clouds (for example
> > the newly deployed ceph cluster keyrings and fsid) to configure cinder
> > (or glance) with a new backend.
> >
> > It looks like this demands for some architectural changes to solve the >
> following two:
> >
> > - how do we trigger/drive updates of the controlplane nodes after the
> > edge cloud is deployed?
>
> Note, there is also a strict(?) requirement of local management
> capabilities for edge clouds temporary disconnected off the central
> controlplane. That complicates the updates triggering even more. We'll
> need at least a notification-and-triggering system to perform required
> state synchronizations, including conflicts resolving. If that's the
> case, the architecture changes for TripleO deployment framework are
> inevitable AFAICT.
>

This is another interesting point. I don't mean to disregard it, but want to
highlight the issue that Giulio and I (and others, I'm sure) are focused on.

As a cinder guy, I'll use cinder as an example. Cinder services running in
the
control plane need to be aware of the storage "backends" deployed at the
Edge. So if a split-stack deployment includes edge nodes running a ceph
cluster, the cinder services need to be updated to add the ceph cluster as a
new cinder backend. So, not only is control plane data needed in order to
deploy an additional stack at the edge, data from the edge deployment needs
to
be fed back into a subsequent stack update in the controlplane. Otherwise,
cinder (and other storage services) will have no way of utilizing ceph
clusters at the edge.

>
> > - how do we scale the controlplane parameters to accomodate for N
> > backends of the same type?
>

Yes, this is also a big problem for me. Currently, TripleO can deploy cinder
with multiple heterogeneous backends (e.g. one each of ceph, NFS, Vendor X,
Vendor Y, etc.). However, the current THT do not let you deploy multiple
instances of the same backend (e.g. more than one ceph). If the goal is to
deploy multiple edge nodes consisting of Compute+Ceph, then TripleO will
need
the ability to deploy multiple homogeneous cinder backends. This requirement
will likely apply to glance and manila as well.


> > A very rough approach to the latter could be to use jinja to scale up
> > the CephClient service so that we can have multiple copies of it in the
> > controlplane.
> >
> > Each instance of CephClient should provide the ceph config file and
> > keyring necessary for each cinder (or glance) backend.
> >
> > Also note that Ceph is only a particular example but we'd need a similar
> > workflow for any backend type.
> >
> > The etherpad for the PTG session [2] touches this, but it'd be good to
> > start this conversation before then.
> >
> > 1.
> >
> https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html
> >
> > 2.
> https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180816/dca82213/attachment.html>