Kubernetes refactoring #450
Draft
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
cbosdo
force-pushed
the
k8s-refactoring
branch
7 times, most recently
from
997fe46
to
8f9ea9e
Compare
cbosdo
force-pushed
the
k8s-refactoring
branch
3 times, most recently
from
e95556e
to
837af3c
Compare
cbosdo
force-pushed
the
k8s-refactoring
branch
7 times, most recently
from
e5c4acd
to
d0bcbeb
Compare
cbosdo
force-pushed
the
k8s-refactoring
branch
from
d0bcbeb
to
c54d24e
Compare
3 tasks
cbosdo
force-pushed
the
k8s-refactoring
branch
2 times, most recently
from
a570a6e
to
dcbc987
Compare
stylecheck reports that modules should not have underscore in their names: rename test_utils to fix this. Rule ST1003. Note that mixed caps are not allowed in module names either.
stylecheck reports that modules should not have underscore in their names: rename flags_tests to fix this. Rule ST1003. Note that mixed caps are not allowed in module names either.
Since the testing module provides a TempDir function, use it in our tests. This also removes a number of errcheck errors about unchecked error in defer.
Returning the function cleaning the temporary folder from its creation function factorizes the removal and removes the missing checks for the os.RemoveAll() error.
During a migration to kubernetes the server is deployed after the rsync to prepare the SSL secrets and PVC. This has the nasty effect to corrupt the synchronized data with a too recent catalog version ID. This would let the DB migration to fail starting the old postgresql server. To workaround this, move the data to the the backup place after the rsync instead of the begining of the db upgrade.
After the k8s migration the pod has been started again since the initial connection creation. We need to reset the connection to not search for the old pod name.
Some pods require a long time to run. This is the case for the DB upgrade finalization that runs a potentially long reindex.
Migration deploys the helm chart multiple times. Identifying which revision corresponds to which step in helm history is hard without a description.
During the development process the susemanager-release file appends a string like `Alpha1` to the version. The inspection sed command chokes on this.
Of of the issuers creation function had two distinct behaviors and this was only generating confusion when reading the whole code. This function has been split and some useless intermediary functions have been merged. This with better function naming should make the SSL setup code more understandable.
In the kubernetes world we need to link the ports to services. For now we only have a TCP and an UDP service for server and the same for proxy, but in the short term, we will need more services to allow splitting into multiple pods. This refactoring is preparing this split.
Running commands in a running container only works if there is a running container and is harder to unit test. In order to help sharing code for Kubernetes, the SanityCheck now gets the existing deployment version with inspecting its image. This also helps adding unit tests for those checks.
In order to later share code between those 3 very similar commands, we need to share the parameters data structure.
Migration to kubernetes is rather fragile, with:
1. tasks running in `kubectl exec` or as `pod`.
2. the uyuni helm chart being deployed multiple times
3. `hostPath` mounts are used everywhere for the scripts to run and
data to read and force the script to run on the cluster node.
Here are the solutions to those problems:
1. Each step will run as a Job and those won't be deleted automatically
for the user to access their logs after.
2. Stop using the helm chart and deploy the resources when we need them.
This will allow more control of what runs when and reduces the number
of useless starts of the giant container.
Postgresql DB upgrade will disable SSL temporarily in the
postgresql.conf in order to not rely on the SSL certificates to be
migrated.
3. The scripts to run for each step will be passed directly as `sh -c`
parameter to the generated Jobs.
The migration data are be stored in a special volume and not on the
host.
As a collateral, SSH agent can no longer be used as that would require
running on a cluster node again. At the moment the user is required to
create a ConfigMap to stored the SSH config and known_hosts and a Secret
for a passwordless SSH key.
The PersistentVolumes are not destroyed after the end of the first job
and are then reused by the next ones and the final deployment.
Using Kubernetes API modules also helps for code reuse with a future
operator. However for this `kubectl` should be dropped completely in
favor of the official go client, but that could come in a future PR.
As a side effect kubernetes interactions would be easier to mock for
unit tests.
Note that the old postgresql database cannot be moved to a separate
PersistentVolumes. As we run a `db_upgrade --link`, the old database is
linked by the new one and cannot be disposed of.
Remove all server resources without relying on the helm chart.
In order to share the same code for installation, migration and upgrade the RunSetup() function needs to move to the shared utils module.
cbosdo
force-pushed
the
k8s-refactoring
branch
from
dcbc987
to
ffc6888
Compare
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?
Migration to kubernetes is rather fragile, with:
1. tasks running in
kubectl execor aspod.2. the uyuni helm chart being deployed multiple times
3.
hostPathmounts are used everywhere for the scripts to run anddata to read and force the script to run on the cluster node.
Here are the solutions to those problems:
Each step will run as a Job and those won't be deleted automatically
for the user to access their logs after.
Stop using the helm chart and deploy the resources when we need them.
This will allow more control of what runs when and reduces the number
of useless starts of the giant container.
Postgresql DB upgrade will disable SSL temporarily in the
postgresql.conf in order to not rely on the SSL certificates to be
migrated.
The scripts to run for each step will be passed directly as
sh -cparameter to the generated Jobs.
The migration data are be stored in a special volume and not on the
host.
As a collateral, SSH agent can no longer be used as that would require
running on a cluster node again. At the moment the user is required to
create a ConfigMap to stored the SSH config and known_hosts and a Secret
for a passwordless SSH key.
The PersistentVolumes are not destroyed after the end of the first job
and are then reused by the next ones and the final deployment.
Using Kubernetes API modules also helps for code reuse with a future
operator. However for this
kubectlshould be dropped completely infavor of the official go client, but that could come in a future PR.
As a side effect kubernetes interactions would be easier to mock for
unit tests.
Note that the old postgresql database cannot be moved to a separate
PersistentVolumes. As we run a
db_upgrade --link, the old database islinked by the new one and cannot be disposed of.
Test coverage
No tests: add explanation
No tests: already covered
Unit tests were added
DONE
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!