|
| 1 | +This repository hosts the containment-rpm-pxe resources used to wrap the PXE images built by KIWI on OBS into RPMs. |
| 2 | + |
| 3 | +The work is based on the original [containment-rpm](https://github.com/openSUSE/containment-rpm) tool created by SUSE Studio and [container-rpm-docker](https://github.com/SUSE/containment-rpm-docker). |
| 4 | + |
| 5 | +# Explaining the magic |
| 6 | + |
| 7 | +Everything starts with the user creating a package (in the build service |
| 8 | +terminology, we are not talking about `.rpm` files) that contains all the KIWI |
| 9 | +sources required to build a PXE image. |
| 10 | + |
| 11 | +The build service will look at these files, figure out the operating system |
| 12 | +of the target and provision a build a PXE image of the same type. To make it clear, if |
| 13 | +the user uploaded the sources of a SLE11 SP3 appliance then the build service |
| 14 | +is going to build a SLE11 SP3 PXE image. |
| 15 | + |
| 16 | +The build service will install all the packages required to run KIWI. It will |
| 17 | +also download all the packages required by the appliance inside of the build |
| 18 | +system. Then it will start the KIWI process like a normal KIWI user would do. |
| 19 | +However once KIWI successfully completes the creation of the appliance the build |
| 20 | +service is going to trigger a post build hook. |
| 21 | + |
| 22 | +The post build hook will look for a file named `kiwi_post_run` located inside |
| 23 | +of the `/usr/lib/build` directory. If the file exists and is executable then |
| 24 | +the build service will invoke it. The `kiwi_post_run` script is where we |
| 25 | +trigger the build of a new rpm containing the output of the kiwi process. |
| 26 | + |
| 27 | +Obviously we must make the `kiwi_post_run` file available on the build host. The |
| 28 | +solution is simple: create a package containing our script plus other resources |
| 29 | +and ask the build service to install this package inside of the build environment. |
| 30 | +The package containing the post build hook is usually called `containment-rpm`. |
| 31 | + |
| 32 | +The package contains basically two files: |
| 33 | + |
| 34 | + * The post build script (`kiwi_post_run`): it can be written in any language |
| 35 | + you want. If you use an interpreted language make sure to add it as a |
| 36 | + runtime dependency inside of the pakage spec file (`containment-rpm-pxe` in |
| 37 | + our case. |
| 38 | + * The `.spec` file used to build the package containing the output of the kiwi |
| 39 | + build. This file is usually a template which is later customized by the |
| 40 | + `kiwi_post_run` script to hold the right values (e.g.: the build version). |
| 41 | + |
| 42 | +In our case `kiwi_post_run` will decompress the PXE image (it supports cpio |
| 43 | +images as well), will look for the kernel and initrd, will fill image.spec.in |
| 44 | +template, and will build the RPM. |
| 45 | + |
| 46 | +# How to prepare a project on the build service |
| 47 | + |
| 48 | + |
| 49 | +It is recommended to have a build service project dedicated to building |
| 50 | +the images. |
| 51 | + |
| 52 | +The project must have at least two repositories: |
| 53 | + |
| 54 | + * A KIWI repository, this is called 'images' by default by the build service. |
| 55 | + * A repository to build the containment-rpm-docker binary. |
| 56 | + |
| 57 | +If you plan to build PXE images for different version of SLE then you have to |
| 58 | +make sure you build the containment rpm also for these targets. You have to do |
| 59 | +that because the build host will have the same OS of the target (see previous |
| 60 | +section). |
| 61 | + |
| 62 | + |
| 63 | +First, you need to create a package called containment-rpm-doker at the |
| 64 | +repository where you plan to build it. |
| 65 | + |
| 66 | +Then, run the script ```prepare-for-obs```, and a folder ```for_obs``` will |
| 67 | +be created with the spec file, changelog file and sources. |
| 68 | + |
| 69 | +Upload them to your package at OBS (use osc CLI, or web interface, or API) |
| 70 | + |
| 71 | +When the package is built, you need to edit the project config: |
| 72 | +`osc meta -e prjconf` and make sure you have something like this: |
| 73 | + |
| 74 | +``` |
| 75 | +%if "%_repository" == "images" |
| 76 | +Type: kiwi |
| 77 | +Repotype: rpm-md |
| 78 | +Patterntype: none |
| 79 | +Required: containment-rpm-docker |
| 80 | +%endif |
| 81 | +``` |
| 82 | + |
| 83 | +We changed `Repotype` because the repository is going to have also the rpm |
| 84 | +containing the output produced by KIWI. |
| 85 | + |
| 86 | +We added the `Required` statement to have the `containment-rpm-docker` and all |
| 87 | +its dependencies installed inside of the build environment used by the build |
| 88 | +service. |
| 89 | + |
| 90 | +Next we need to edit the project metadata: `osc meta -e prj`. We have to add |
| 91 | +the repository containing the `containment-rpm-pxe` to the list of repositories |
| 92 | +available by the `images` target at build time. |
| 93 | + |
| 94 | +```xml |
| 95 | + <repository name="images"> |
| 96 | + <path project="Devel:Myproject:Where:containment-rpm-exe:is" repository="SLE_12"/> |
| 97 | + <arch>x86_64</arch> |
| 98 | + </repository> |
| 99 | +``` |
| 100 | + |
| 101 | +So in the end the project will have just two packages (again, build service |
| 102 | +terminology not `.rpm` files): |
| 103 | + |
| 104 | + * `my-appliance`: this is where the KIWI sources are placed. |
| 105 | + * `containment-rpm`: this is the package containing the script called by the |
| 106 | + post build hook. |
| 107 | + |
| 108 | +As you can notice there is no definition of the package containing the output |
| 109 | +of the KIWI process. Whenever the `my-appliance` package is built the rpm |
| 110 | +containing its output is going to be created. Note well: this rpm is going |
| 111 | +to be published by the build service inside of the `images` repository. |
| 112 | + |
| 113 | +## Using a special kiwi version |
| 114 | + |
| 115 | +If you want to use a special version of KIWI to build your images you can either |
| 116 | +have a `kiwi` package inside of your project or you can reference the `kiwi` |
| 117 | +package from another repository. |
| 118 | + |
| 119 | +### Custom kiwi package inside of the project |
| 120 | + |
| 121 | +This requires you to copy/link the `kiwi` package from somewhere to your project. |
| 122 | + |
| 123 | +Then you have to add your repository to the list of repositories available for the |
| 124 | +`images` one. This is what we have already done previously to make it possible to |
| 125 | +install the `containment-rpm` inside of the build environment: |
| 126 | + |
| 127 | +```xml |
| 128 | + <repository name="images"> |
| 129 | + <path project="Devel:Myproject:Images" repository="SLE_12"/> |
| 130 | + <arch>x86_64</arch> |
| 131 | + </repository> |
| 132 | +``` |
| 133 | + |
| 134 | +### kiwi package from an external project |
| 135 | + |
| 136 | +This is the only sane way to have a recent version of KIWI on an old system like |
| 137 | +SLE11 SP3. |
| 138 | + |
| 139 | +First of all we have to make edit the project metadata: `osc meta -e prj`. |
| 140 | + |
| 141 | +Add the path to the project containing the `kiwi` package to the `images` repository: |
| 142 | + |
| 143 | +```xml |
| 144 | + <repository name="images"> |
| 145 | + <path project="openSUSE.org:Myexternalproject" repository="SLE_12"/> |
| 146 | + <path project="Devel:Myproject:Images" repository="SLE_12"/> |
| 147 | + <arch>x86_64</arch> |
| 148 | + </repository> |
| 149 | +``` |
| 150 | + |
| 151 | +Then add the same repository to your KIWI source file (the `.kiwi` file). |
0 commit comments