[rdo-dev] Packaging issues about upcoming changes in Sahara

[Luigi Toscano]

Hi,

there are two upcoming changes in Sahara which will impact the packaging. A 
more detailed email will land soon on openstack-discuss, but as RDO 
contributor I'd like to start the packaging discussion here first.

The source package openstack-sahara generates the following packages:
- python{2,3}-sahara contains the shared python libraries (with tests ending 
up in python2-sahara-tests). Almost all the other subpackages depends on it.
- openstack-sahara-image-pack is not a service, but a standalone command used 
to build images. It only depends on python{2,3}-sahara.
- openstack-sahara-common contains few shared components and programs shared 
by all services.
- openstack-sahara-api and openstack-sahara-engine depend on openstack-sahara-
common and contain only the unit file and the entry point for the services of 
the same name.
- openstack-sahara depends on -api,-engine,-common,-image-pack, and despite 
the name, contains the long-deprecated openstack-sahara-all unit file and 
entry point. Historical reasons (it was originally the package holding the 
sahara service).
- there is also openstack-sahara-doc for documentation.

== The main disruptive change is the spliting of plugins from the Sahara 
codebase. They are being moved in their own repositories:
http://specs.openstack.org/openstack/sahara-specs/specs/rocky/plugins-outside-sahara-core.html

Each plugin will get its own package, with subpackages for the main code, for 
the tests and the documentation. Please note that each plugin package depends 
on python{2,3}-sahara, while the core does not depend on plugins.

Sahara services can still start even if no additional plugins, thanks to the 
fake plugin still living inside sahara.git.

Now, I was wondering if there is a way to automatically installing the known 
plugin subpackages when installing or upgrading (with dnf/yum) "sahara", 
without introducing circular dependencies. Does it make sense to do it? Maybe 
introducing a new source package which only depends on all sahara packages, 
services and plugins? Would it make sense to do it?
If it makes sense, would it make sense to rename openstack-sahara.noarch as 
openstack-sahara-core.noarch, and move the openstack-sahara "catch-all" 
subpackage to this new source package?

== Smaller change: the openstack-sahara-all service is going away, maybe in 
stein, but for sure in train. Would it make sense to keep openstack-sahara (or 
openstack-sahara-core, see the previous point) as empty package just for 
dependency reasons?

Ciao
-- 
Luigi