<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 4:02 PM Luigi Toscano <<a href="mailto:ltoscano@redhat.com">ltoscano@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
there are two upcoming changes in Sahara which will impact the packaging. A <br>
more detailed email will land soon on openstack-discuss, but as RDO <br>
contributor I'd like to start the packaging discussion here first.<br>
<br></blockquote><div><br></div><div>Nice, thanks for it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The source package openstack-sahara generates the following packages:<br>
- python{2,3}-sahara contains the shared python libraries (with tests ending <br>
up in python2-sahara-tests). Almost all the other subpackages depends on it.<br>
- openstack-sahara-image-pack is not a service, but a standalone command used <br>
to build images. It only depends on python{2,3}-sahara.<br>
- openstack-sahara-common contains few shared components and programs shared <br>
by all services.<br>
- openstack-sahara-api and openstack-sahara-engine depend on openstack-sahara-<br>
common and contain only the unit file and the entry point for the services of <br>
the same name.<br>
- openstack-sahara depends on -api,-engine,-common,-image-pack, and 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>
<a href="http://specs.openstack.org/openstack/sahara-specs/specs/rocky/plugins-outside-sahara-core.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/sahara-specs/specs/rocky/plugins-outside-sahara-core.html</a><br>
<br>
Each plugin will get its own package, with subpackages for the main code, for <br>
the tests and the documentation. Please note that each plugin package 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 the <br>
fake plugin still living inside sahara.git.<br>
<br>
Now, I was wondering if there is a way to automatically installing the known <br>
plugin subpackages when installing or upgrading (with dnf/yum) "sahara", <br>
without introducing circular dependencies. Does it make sense to do it? Maybe <br>
introducing a new source package which only depends on all sahara 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 as <br>
openstack-sahara-core.noarch, and move the openstack-sahara "catch-all" <br>
subpackage to this new source package?<br>
<br></blockquote><div><br></div><div>In that case, the new package would only depend on plugins or also in services and common?<br></div><div><br></div><div>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.</div><div><br></div><div>[1] <a href="https://github.com/rdo-packages/tempest-distgit/blob/rpm-master/openstack-tempest.spec#L131-L171">https://github.com/rdo-packages/tempest-distgit/blob/rpm-master/openstack-tempest.spec#L131-L171</a></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
== Smaller change: the openstack-sahara-all service is going away, maybe in <br>
stein, but for sure in train. Would it make sense to keep openstack-sahara (or <br>
openstack-sahara-core, see the previous point) as empty package just for <br>
dependency reasons?<br>
<br></blockquote><div><br></div><div>Yes, I think it makes sense to have a metapackage to install all supported plugins.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ciao<br>
-- <br>
Luigi<br>
<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.rdoproject.org" target="_blank">dev@lists.rdoproject.org</a><br>
<a href="http://lists.rdoproject.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.rdoproject.org/mailman/listinfo/dev</a><br>
<br>
To unsubscribe: <a href="mailto:dev-unsubscribe@lists.rdoproject.org" target="_blank">dev-unsubscribe@lists.rdoproject.org</a><br>
</blockquote></div></div></div>