11:43 a.m.
On Tue, Nov 27, 2018 at 4:02 PM Luigi Toscano <ltoscano(a)redhat.com> wrote:
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.
Nice, thanks for it.
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-out...
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?
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.
[1]
https://github.com/rdo-packages/tempest-distgit/blob/rpm-master/openstack...
== 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.
Ciao
--
Luigi
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org