<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 2:23 PM Luigi Toscano <<a href="mailto:ltoscano@redhat.com">ltoscano@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, 28 November 2018 18:43:04 CET Alfredo Moralejo Alonso wrote:<br>
> On Tue, Nov 27, 2018 at 4:02 PM Luigi Toscano <<a href="mailto:ltoscano@redhat.com" target="_blank">ltoscano@redhat.com</a>> wrote:<br>
<br>
> > The source package openstack-sahara generates the following packages:<br>
> > - python{2,3}-sahara contains the shared python libraries (with tests<br>
> > ending<br>
> > up in python2-sahara-tests). Almost all the other subpackages depends on<br>
> > it.<br>
> > - openstack-sahara-image-pack is not a service, but a standalone command<br>
> > used<br>
> > to build images. It only depends on python{2,3}-sahara.<br>
> > - openstack-sahara-common contains few shared components and programs<br>
> > shared<br>
> > by all services.<br>
> > - openstack-sahara-api and openstack-sahara-engine depend on<br>
> > openstack-sahara-<br>
> > common and contain only the unit file and the entry point for the services<br>
> > of<br>
> > the same name.<br>
> > - openstack-sahara depends on -api,-engine,-common,-image-pack, and<br>
> > despite<br>
> > the name, contains the long-deprecated openstack-sahara-all unit file and<br>
> > entry point. Historical reasons (it was originally the package holding the<br>
> > sahara service).<br>
> > - there is also openstack-sahara-doc for documentation.<br>
> > <br>
> > == The main disruptive change is the spliting of plugins from the Sahara<br>
> > codebase. They are being moved in their own repositories:<br>
> > <br>
> > <a href="http://specs.openstack.org/openstack/sahara-specs/specs/rocky/plugins-outs" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/sahara-specs/specs/rocky/plugins-outs</a><br>
> > ide-sahara-core.html<br>
> > <br>
> > Each plugin will get its own package, with subpackages for the main code,<br>
> > for<br>
> > the tests and the documentation. Please note that each plugin package<br>
> > depends<br>
> > on python{2,3}-sahara, while the core does not depend on plugins.<br>
> > <br>
> > Sahara services can still start even if no additional plugins, thanks to<br>
> > the<br>
> > fake plugin still living inside sahara.git.<br>
> > <br>
> > Now, I was wondering if there is a way to automatically installing the<br>
> > known<br>
> > plugin subpackages when installing or upgrading (with dnf/yum) "sahara",<br>
> > without introducing circular dependencies. Does it make sense to do it?<br>
> > Maybe<br>
> > introducing a new source package which only depends on all sahara<br>
> > packages,<br>
> > services and plugins? Would it make sense to do it?<br>
> > If it makes sense, would it make sense to rename openstack-sahara.noarch<br>
> > as<br>
> > openstack-sahara-core.noarch, and move the openstack-sahara "catch-all"<br>
> > subpackage to this new source package?<br>
> <br>
> In that case, the new package would only depend on plugins or also in<br>
> services and common?<br>
On all of them. The idea would be to keep binary openstack-sahara package as <br>
the package which installs everything, as it is the case right now.<br>
<br>
> <br>
> I think this is similar to what we have with tempest and separated plugins.<br>
> For this case we have a subpackage tempest-all that depends in the plugins.<br>
> To allow bootstraping the repo avoiding circular dependencies we use a<br>
> parameter repo_bootstrap that we set to 1 when boostraping a repo [1]. I<br>
> think you could do something similar and add all plugins as requires for<br>
> the desired packages, i.e. openstack-sahara-plugins if you want to have a<br>
> subpackages only installing plugins or even as requirements of -common if<br>
> what you want is to always get plugins installed for each service<br>
> installation.<br>
<br>
Thanks for the hint. So here we could use this trick (toggle the value of the <br>
parameter after the plugins packages are available) to make the binary <br>
openstack-sahara package depend on all plugin packages. I don't think that <br>
there is a need for a binary openstack-sahara-plugins package.<br>
<br>
The drawback of this approach is that packagers need to remember to do it at <br>
each cycle! :)<br>
<br></blockquote><div><br></div><div>Yes, maintainers need to toggle the parameter to off and on in bootstraping new releases.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On the other side, the only alternative (new source package) may have a higher <br>
initial cost - or maybe not. Is there any specific reason why you didn't <br>
follow this path with openstack-tempest-all?<br>
<br></blockquote><div><br></div><div>So IIUC, what you propose is to move openstack-tempest-all to a new package (srpm) which would only have a subpackage with requires to all Sahara ones, right?.<br></div><div><br></div><div>I guess It should work but we would probably hit problems with tooling for the new package because it wouldn't have an associate source repo. We probably only need to create some fake repo. I like more the idea of using the repo_bootstrap for consistency (it's something we use in different packages with similar issues).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <br>
> [1]<br>
> <a href="https://github.com/rdo-packages/tempest-distgit/blob/rpm-master/openstack-te" rel="noreferrer" target="_blank">https://github.com/rdo-packages/tempest-distgit/blob/rpm-master/openstack-te</a><br>
> mpest.spec#L131-L171<br>
> > == Smaller change: the openstack-sahara-all service is going away, maybe<br>
> > in<br>
> > stein, but for sure in train. Would it make sense to keep openstack-sahara<br>
> > (or<br>
> > openstack-sahara-core, see the previous point) as empty package just for<br>
> > dependency reasons?<br>
> <br>
> Yes, I think it makes sense to have a metapackage to install all supported<br>
> plugins.<br>
<br>
Ack, thanks.<br>
<br>
Ciao<br>
-- <br>
Luigi<br>
<br>
<br>
</blockquote></div></div>