- 
                Notifications
    You must be signed in to change notification settings 
- Fork 222
Uyuni development in no time
While we generally advise developers to use sumaform to create development infrastructure (Server, clients, etc), it is not a must and can be a bit difficult to understand at the beginning.
Here is how to get started developing without sumaform, just by manually creating your infrastructure. It's written in an informal tone because it was originally written in answer to a user in Gitter.
What we are going to do is the following:
- Install Uyuni Stable to make sure all the dependencies, database, etc are set up correctly
- Deploy a development version of Uyuni on top of Uyuni Stable
The reason to "prepare" the system first with Uyuni Stable is some of the pattern packages are not built by default for Uyuni development versions. Instead of trying to get those packages built, it's just easier to do this in two setps.
Whenever you make changes in the code and want to try them, you can go directly to step 2 (deploy Uyuni development version), you only need step 1 (deploy Uyuni Stable) once.
- 
Install Uyuni Server Stable (2021.02 as of now) 
- 
Fork all of the packages of Uyuni master into your own OBS project: 
for I in `osc ls systemsmanagement:Uyuni:Master`; do osc branch --nodevelproject systemsmanagement:Uyuni:Master $I home:pagarcia:hackweek20; done
OBS typically updates the forks when there are changes in the original project (systemsmanagement:Uyuni:Master). We do not want that because it would smash the precious code we are going to write. We can avoid OBS smashing our code by using --nodevelproject parameter.
E. g. in my case that results in: https://build.opensuse.org/project/show/home:pagarcia:hackweek20).
- 
Copy the projectconfig and meta from https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master to your fork's to make sure everything builds. 
- 
When the packages in your fork are built, ssh into the Uyuni Server and zypper ar --enable --refreshthe repo of your fork.
- 
Stop Uyuni: spacewalk-service stopon the Uyuni Server
- 
Run zypper dup --allow-vendor-change --allow-arch-change --allow-name-change --allow-downgradeon the Uyuni Server. Your Uyuni Server is now updated to your fork.
- 
Run rpm -qi susemanager-schemaand note the version. As of today, it says 4.2.9.
- 
Run ls -lah /etc/sysconfig/rhn/schema-upgrade. Notice thesusemanager-schema-4.2.X-to-susemanager-schema-4.2.Ydirectories. If 4.2.X > 4.2.9 (or whatever version ofsusemanager-schemais installed on your system), then you need to manually execute those migration scripts:psql -U uyunidatabaseuser -d uyunidatabase < /etc/sysconfig/rhn/schema-upgrade/susemanager-schema-4.2.9-to-susemanager-schema-4.2.10/*. You may need to run this for more than one directory. You only need to do this if you modified some SQL, or (in the future) if you are rebasing your code and someone else modified the database.
- 
If operating system packages were also upgraded, reboot. If not, just start Uyuni Server: spacewalk-service start. It might take a while to the database migrations.
If you will be modifying the client tools (either traditional stack or Salt stack), then do the same for the whatever client tools OBS project you will be modifying. E. g. for CentOS 7:
- Create fork of Uyuni Master CentOS 7 client tools in a new subproject of your project (e. g. home:pagarcia:hackweek20:CentOS7-Client-Tools):
for I in ``osc ls systemsmanagement:Uyuni:Master:CentOS7-Uyuni-Client-Tools``; do osc branch --nodevelproject systemsmanagement:Uyuni:Master:CentOS7-Uyuni-Client-Tools home:pagarcia:hackweek20:CentOS7-Client-Tools; done
- 
To avoid submitting Salt to two places (home:pagarcia:hackwek20 -for the Server- and home:pagarcia:hackweek20:CentOS7-Client-Tools -for the client tools-), delete the salt package in home:pagarcia:hackweek20:CentOS7-Client-Tools and branch it from the Server OBS repo: osc branch home:pagarcia:hackwek20 salt home:pagarcia:hackweek20:CentOS7-Client-Tools
- 
Modify /etc/rhn/spacewalk-common-channels.inito take the client tools from your OBS repository. Otherwise, you will noticed very weird interactions because Salt on the Uyuni Server side will contain the changes you made, but Salt on the client side will not.
- Fork the Uyuni source code (https://github.com/uyuni-project/uyuni/) into your own repo (e. .g in my case https://github.com/paususe/uyuni).
- Clone the Uyuni upstream repository: git clone git@github.com:uyuni-project/uyuni.git
- Add your own fork as a remote: git remote add paususe git@github.com:paususe/uyuni.git
- Follow the instructions in http://bosdonnat.fr/slides/openSUSEAsiaSummit19/ to develop.
What I typically do is I always develop locally, submit code to OBS for packages to be created, and then zypper dup --allow-vendor-change --allow-arch-change --allow-name-change --allow-downgrade on the Uyuni Server. It's a bit slower (I need to wait for OBS to finish) than deploying code directly to the Uyuni Server via SSH but that way I am sure I am always updating all the packages that might have been affected by my changes.