Uyuni is made up of code from four major sites:
- Uyuni-specific code
- Repositories shared with openSUSE and SUSE Linux Enterprise
- Open Build Service
- Translations (openSUSE Weblate)
This is the main GitHub project that contains most of the source code.
The following repositories are maintained:
- uyuni: Contains the main Uyuni source code (including, for example the source code for bakend, frontend, database or cucumber testsuite).
- retail: Uyuni Retail salt formulas and related tools and documentation
- hub-xmlrpc-api: The hub-xmlrpc-api package that allows a Server of Serves architecture (Hub).
- uyuni-docs: The Uyuni documentation.
- sumaform: The Terraform code to deploy Uyuni environments, using among other things to run the cucumber testsuite.
- minima: A Simple Linux Repository Manager, used in sumaform.
- evil-minions: A load generator for Salt, useful for performance testing.
- obs-to-maven: Tool creating a maven repository out of RPMs built by OpenBuildService.
- uyuni-rfc: Uyuni feature RFCs.
- uyuni-project.github.io: Uyuni website
There are other repositories containing source code that we package and distribute in Uyuni, but it is used in other projects (so we don't have it at our main GitHub project:
- salt: SUSE and openSUSE patches and backports for SaltStack.
- salt-netapi-client: Java bindings for the Salt API.
- salt-formulas: Salt Formulas for SUSE Enterprise Linux, openSUSE Linux and Uyuni.
- smdba: SUSE Manager database administration tool (replacement for spacewalk-dobby).
- virtual-host-gatherer: Script to gather information about virtual system running on different kind of hypervisors.
- subscription-matcher: Tool to report whether some installed SUSE products match a set of SUSE subscriptions.
- containment-rpm-pxe: Wrap PXE images built by KIWI on OBS into RPMs.
In addition to Git repositories, we maintain some packages directly in the Open Build Service.
There are tree kind of reasons for this:
- Packages that contain only upstream code and (in some infrequent cases) some patches to keep old versions. It is the case for all packages at systemsmanagement:Uyuni:Master:Other.
- Packages where we contribute actively upstream or that we update frequently, but where we still need to keep a separate set of patches, mostly because we apply them in advance:
The package does not really contain code. Some examples of this are:
- 000product (the product definition for the Uyuni Server and the Uyuni Proxy).
- 000CloudImages-Server (the cloud image definition for the Uyuni Server).
- 000CloudImages-Proxy (the cloud image definition for the Uyuni Proxy).
- patterns-uyuniy (the patterns for the Uyuni Server and the Uyuni Proxy).
- release-notes-uyuni (the release notes for the Uyuni Server).
- release-notes-uyuni-proxy (the release notes for the Uyuni Server and the Uyuni Proxy).
- uyuni-build-keys (the Uyuni build keys, used by reposync to trust repositories, to allow clients to trust them)
Translations (openSUSE Weblate)
We have a project at Weblate to manage the Uyuni translations.