On Wednesday, 28 November 2018 18:43:04 CET Alfredo Moralejo Alonso wrote: > On Tue, Nov 27, 2018 at 4:02 PM Luigi Toscano <ltosc...@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 _______________________________________________ dev mailing list dev@lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org