Hub XML-RPC upgrade support #408
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Ricardo Mateus <[email protected]>
In order to avoid adding return variables for each value we want to extract at migration time we are now collecting them in a result object. This object could later be extended and reused for the inspect scripts instead of using a map.
When migrating from a non-containerized server, the user may want to setup confidential computing attestation.
The computation of image URLs suffered several problems.
* The registry had to be manually set in the image flags: this is too
error prone, and already some assignements were missing.
* The way the images URL were computed was different between proxy and
server
The dash in the salt-broker parameters name make Viper try to marshall the parameters into a nested structure that we don't have. Changing the parameters from --salt-broker-[image|tag] to --saltbroker-[image|tag] solves the issue.
Creating the service and leaving it disabled allows to call the scale command later to enable it.
Migrate also needs to setup the Hub XML-RPC API container. Reshuffling the code a bit to share what install is doing.
Using podman creds is not secure as those will show up in the the ps output. Instead we generate a temporary podman authentication file and pass it to podman pull.
It doesn't make sense to try to extract all the values for both containers and hosts. This commit introduces Inspector objects that are responsible for generating the inspection script and parsing it into a structure. While at it, the extracted values that were not used have been removed. This gains quite some time at each execution since extracting the SCC registration status was quite long. While doing this we could also drop the InspectData proxyHost flag as SCC credentials are extracted for both server and proxy hosts.
Calling Fatal().Err() is not enough without .Msg(), but instead just return error. This also enables term and exec logging with trace log level.
Co-authored-by: Cedric Bosdonnat <[email protected]>
The Helm chart path on the registry may be different from the one of the container images. Create two separate variables to set those paths.
To make sure there is no slash in the path of the SQL file in the container use the basename to compute the temporary filename.
The command outputs usually have a trailing new line, which fails value != "true" in all cases. This is forcing the update of the podman network even if it's not needed.
The scripts executed at installation, migration and upgrade time were logging their output only in the console. Using the pre-configured logger logs them to both the file and the console.
Properly check for write access to /var/log/uyuni-tools.log. If this can't be used, print the log file path as first thing.
Co-authored-by: Ondřej Holeček <[email protected]>
Cobra inherits the UsageFunc from the parent classes, and the implementation for the grouped flags was recursing: using the function of a blank command object rather than setting to default breaks the loop.
Most of the code is now shared between mgradm and mgrpxy. mgradm support config tarball content: - tarball created by supportconfig command inside the container - tarball created by supportconfig command in the host - content of all the systemd files and configuration related to the server (systemctl cat uyuni-*) - content of all the bound files (it should be empty by now) - podman inspect - podman logs (it should be empty by now) mgrpxy support config tarball content on podman: - tarball created by supportconfig command in the host - content of all the systemd files and configuration related to the proxy (systemctl cat uyuni-*) - content of all the bound files (e.g. apache tuning, squid tuning, other conf files) - podman inspect - podman logs mgrpxy support config tarball content on kubernetes: - content of all configmap (all the configuration such as apache and squid are embedded there) - content of kubectl get pod -o yaml command
A command to help cleaning the squid cache on the proxy would be quite appreciated as this is the best way to fix some issues.
In order to allow updating the image at each upgrade and keep the user configuration, move the image in generated.conf and the rest in custom.conf
If the volumes are already populated, try to reuse the existing user/org if it is possible.
If we stop the coco instances how can we determine how many we have to spin up again? The best thing to do is to just restart them all.
During migration, detect if the Hub XML-RPC API is enabled on the the migrated server and enable it automatically in such a case without the need to provide the number of replicas.
|
closed: autosquashed and pushed to the big PR #405. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR change?
Cherry-pick and massage bits from #357 to add hub xml-rpc support to the
mgradm upgrade podmancommand. Also fix the coco upgrade too.Test coverage
Links
Issue(s): #
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test(see below)Before you merge
Check How to branch and merge properly!