Open Stack

On 14.8.2018 15:19, Bogdan Dobrelya 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.

Indeed this would complicate things much, but IIUC the spec [1] that 
Giulio referenced doesn't talk about local management at all.

Within the context of what the spec covers, i.e. 1 stack for Controller 
role and other stack(s) for Compute or *Storage roles, i hope we could 
address updates/upgrades workflow similarly as the deployment workflow 
would be addressed -- working with the stacks one by one.

That would probably mean:

1. `update/upgrade prepare` on Controller stack

2. `update/upgrade prepare` on other stacks (perhaps reusing some 
outputs from Controller stack here)

3. `update/upgrade run` on Controller stack

4. `update/upgrade run` on other stacks

5. (`external-update/external-upgrade run` on other stacks where 
appropriate)

6. `update/upgrade converge` on Controller stack

7. `update/upgrade converge` on other stacks (again maybe reusing 
outputs from Controller stack)

I'm not *sure* such approach would work, but at the moment i don't see a 
reason why it wouldn't :)

Jirka

> 
>>
>> - how do we scale the controlplane parameters to accomodate for N
>> backends of the same type?
>>
>> 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
>>
> 
>