mgrpxy: add migrate command from RPM to containerized version

[rjmateus]

Consider if we should have a mgrpxy migrate command from RPM base proxy to a containerized version.
The base product for the rpm base proxy is SUSE Manager proxy with sles15sp4 and we want to migrate to sle-micro 5.5. For this reason we should not have an in-place migration.

The migrate command could be interesting to migrate some pre-defined configuration and branch server data that could be needed (@nadvornik or @aaannz could you confirm? )

Research

We would need to be careful with the migration, especially regarding the certificates and FQDN.
The old machine can still be registered on SUMA server as a regular minion. We would not be able to re-use the same FQDN, since containerized proxy would be deployed in a new machine.

[aaannz]

Retail part

DHCP and DNS configuration is the same, just in case of containerized RBS, managing it is left on customer. Formulas are still provided, but customer need to have salt minion for them. This was done as majority of customers I know use their own DHCP and DNS and does not use our formulas for them.

How normal RBS works

Before any deployment, image-sync state needs to be applied on the RBS to sync and if needed unpack images. What images to download is in the images and boot_images pillars.

Stock SLE tftp server serves saltboot kernel and initrd based on the salt manager pxelinux/grub configuration. Saltboot state send a pxe_update event after image is successfully deployed and this reactor handling this event applies state on the RBS to update pxelinux/grub configuration.

How containerized RBS works

Once a retail image is build, when images and boot_images pillars are being created, this image is also registered as a cobbler distro. This happens only if the image is not build as an image bundle (tar ball of boot image and system image), which is the default (system image, kernel and initrd in separate files).

Once saltboot group is applied to the branch group, cobbler profile for given branch is prepared.

On the containerized RBS our tftp server is translating tftp queries to http queries for cobbler pxe/grub configurations to get correct kernel and initrd and kernel options.

Saltboot state issues pxe_update event as in normal case, however this time our java based reactor registers/updates cobbler system entry and updates pxe/grub data for next boots.

Notes

• Both reactors works at the same time.
• If saltboot group is not set for a group, this branch profile does not exists, cobbler system is not created.
• If image is bundle build, cobbler distro is not created for the image.

Migration ToDo

• First I need to point out that migration of normal RBS to containerized RBS is made primarily on SUMA server.
• We'll need to deprecate and remove non-bundle builds and with it start using compressed images. Reason why some users continue using bundle builds is the size of the archive. Bundle build is automatically compressed, whereas non bundle build is compressed only if instructed in the kiwi file.
• Migration tool will need to extract existing bundle builds and register them as cobbler distros on the server if needed.
• Migration tool will need to add saltboot group to the branch group
• Migration tool will need to get pxelinux/grub configs from the branch server and create appropriate cobbler system entries
• Now we can stop normal RBS services and start containerized RBS

Seamless migration path

• Advice users to use default non-bundle builds
• Advice users to use Saltboot group with branch group
• Continue using normal RBS for some time to allow all terminals to reboot once
• Switch over from normal RBS to containerized RBS