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

[Luigi Toscano]

On Wednesday, 28 November 2018 18:43:04 CET Alfredo Moralejo Alonso wrote:
> On Tue, Nov 27, 2018 at 4:02 PM Luigi Toscano <ltoscano at redhat.com> wrote:

> > 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-outs
> > ide-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?
> 
> In that case, the new package would only depend on plugins or also in
> services and common?
On all of them. The idea would be to keep binary openstack-sahara package as 
the package which installs everything, as it is the case right now.

> 
> I think this is similar to what we have with tempest and separated plugins.
> For this case we have a subpackage tempest-all that depends in the plugins.
> To allow bootstraping the repo avoiding circular dependencies we use a
> parameter repo_bootstrap that we set to 1 when boostraping a repo [1]. I
> think you could do something similar and add all plugins as requires for
> the desired packages, i.e. openstack-sahara-plugins if you want to have a
> subpackages only installing plugins or even as requirements of -common if
> what you want is to always get plugins installed for each service
> installation.

Thanks for the hint. So here we could use this trick (toggle the value of the 
parameter after the plugins packages are available) to make the binary 
openstack-sahara package depend on all plugin packages. I don't think that 
there is a need for a binary openstack-sahara-plugins package.

The drawback of this approach is that packagers need to remember to do it at 
each cycle! :)

On the other side, the only alternative (new source package) may have a higher 
initial cost - or maybe not. Is there any specific reason why you didn't 
follow this path with openstack-tempest-all?

> 
> [1]
> https://github.com/rdo-packages/tempest-distgit/blob/rpm-master/openstack-te
> mpest.spec#L131-L171
> > == 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?
> 
> Yes, I think it makes sense to have a metapackage to install all supported
> plugins.

Ack, thanks.

Ciao
-- 
Luigi