-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replace ant tasks kubectl usage by uyunictl #7505
replace ant tasks kubectl usage by uyunictl #7505
Conversation
In the container world the hostname is private to the cluster and could even contain random parts. This change avoids confusion between the FQDN and HOST variables and offers a clean code path for containers.
When running the setup in a container running on kubernetes we don't have control on the hostname the user knows about. Rather that relying on getting it from the system, allow reading it from the setup input file.
When running the setup in a container we want to avoid the setup_env.sh script and read the values from variables.
Running mgr-bootstrap in a containerized server cannot assume the hostname is the user-facing FQDN.
Provide a helm chart to ease installation of the server container on kubernetes cluster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I probably provided different instructions in the beginning, the PR looks good, but I would remove the podman
specific parts as mentioned in the comments
java/manager-build.xml
Outdated
@@ -17,6 +17,10 @@ | |||
<property file="conf/rhn_java.conf"/> | |||
|
|||
<!-- Other properties --> | |||
<property name="container.name" value="uyuni-server" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can remove the container.name
property: this is automatically discovered by uyunictl
java/manager-build.xml
Outdated
@@ -17,6 +17,10 @@ | |||
<property file="conf/rhn_java.conf"/> | |||
|
|||
<!-- Other properties --> | |||
<property name="container.name" value="uyuni-server" /> | |||
<property name="ssh.key" value="/home/user/.ssh/id_rsa" /> | |||
<property name="podman.connection.name" value="srv" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would let the user configure their connections at the podman
level and only pass the connection name to the ant target. What do you guys think about it? In any case for kubernetes users they would need to setup they kubeconfig file to connect to the cluster.
java/manager-build.xml
Outdated
</fail> | ||
</target> | ||
|
||
<target name="is-podman-installed" description="Cheks if podman is installed"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't care if podman
or kubectl
is installed: uyunictl
checks for us, and even checks for podman-remote
.
java/manager-build.xml
Outdated
<target name="remove-podman-connection" depends="warn-if-podman-not-installed" description="Removes podman system connection"> | ||
<echo message="Removing podman system connection..."/> | ||
<exec executable="podman"> | ||
<arg line="system connection rm ${podman.connection.name}"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I probably mislead you here, but the more I think about it, the more I'm convinced we don't want any podman
or kubectl
specific code here. We can just document how to setup the connections. Setting up a remote connection on podman
doesn't prevent from using the local podman
instance if the user doesn't set the CONTAINER_CONNECTION
variable or the --connection
parameter.
java/manager-build.xml
Outdated
<exec failonerror="true" executable="sh"> | ||
<arg line="-c 'tar c -p -C ${frontend.dist.dir} -f - . | kubectl exec -i ${kubectl.args} -- tar xf - -C /srv/www/htdocs'"/> | ||
<arg line="-c 'tar c -C ${build.dir}/webapp -f - --exclude=log4j2.xml . | uyunictl exec -i -- tar xf - -C ${deploy.dir}'"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember why I had to use tar
here, but it seems that kubectl
can copy folders too. In any case this should be handled at the uyunictl
level, not the ant file to make uyunictl
user's life easier. Is there any reason not to use your fancy copy-to-container
macro?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we agreed, on this specific case we're sticking to the tar solution. The reason is that kubectl doesn't support excluding specific files/folder during the copy operation.
java/manager-build.xml
Outdated
<exec executable="kubectl"> | ||
<arg line="exec ${kubectl.args} -- sed 's/JAVA_OPTS="\([^"]*\)"/JAVA_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,address=\$HOSTNAME:8000,server=y,suspend=n \1"/' -i /etc/sysconfig/tomcat"/> | ||
<!-- wraps uyunictl command, executing the given argline and setting the CONTAINER_CONNECTION env var --> | ||
<macrodef name="wrap-uyunictl"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love the way you implemented this with a macro 😍 . May be you can name it simply uyunictl
java/manager-build.xml
Outdated
<sequential> | ||
<exec failonerror="@{failonerror}" executable="uyunictl"> | ||
<arg line="@{argline}"/> | ||
<env key="CONTAINER_CONNECTION" value="${podman.connection.name}"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This variable is not useful in the case of kubectl
but can't harm if it's added unconditionnaly
java/manager-build.xml
Outdated
<attribute name="failonerror" default="false"/> | ||
<sequential> | ||
<exec failonerror="@{failonerror}" executable="sh"> | ||
<arg line="-c 'tar c -p -C @{source} -f - . | uyunictl exec -i -- tar xf - -C @{target}'"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably we can get rid of the tar
part here.
yes, i forced this to use podman remote connection every where. Pretty much all tasks were updated and podman references should be gone |
a07128c
to
a1bdad9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now you just need to rebase and merge! Thanks for the PR
fb89dc8
into
uyuni-project:server-container
What does this PR change?
replace ant tasks kubectl usage by uyunictl
GUI diff
No difference.
Documentation
No documentation needed: only internal and user invisible changes
DONE
Test coverage
No tests
DONE
Links
Fixes #
None
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)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run: