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? - 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 -- Giulio Fidente GPG KEY: 08D733BA __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev