On Tue, Nov 27, 2018 at 4:02 PM Luigi Toscano <ltosc...@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-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?
>
>
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-tempest.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.
> Ciao
> --
> Luigi
>
>
> _______________________________________________
> dev mailing list
> dev@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
>
_______________________________________________
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscr...@lists.rdoproject.org
