-
Notifications
You must be signed in to change notification settings - Fork 200
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
Use REX for bats testing in Katello 4.10+ #1695
Conversation
We have an installer switch to deploy the keys ;)
|
Katello 4.9 client bats tests passed:
|
8ce7f44
to
ecb2b98
Compare
bats/fb-katello-client.bats
Outdated
} | ||
|
||
@test "enable remote execution (or katello-agent for Katello 4.9 and below)" { | ||
if tIsVersionNewer "${KATELLO_VERSION}" 4.10; then |
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 could put something like:
tIsKatelloAgentRemoted() {
KATELLO_VERSION=$(tKatelloVersion)
tIsVersionNewer "${KATELLO_VERSION}" 4.10
}
into the shared files and use that instead of if newer than 4.10
all the time, but up to you :)
bats/fb-katello-client.bats
Outdated
timeout 300 hammer job-invocation create --feature katello_package_install --inputs 'package=gorilla' --search-query "name = ${HOSTNAME}" | ||
else | ||
timeout 300 hammer host package install --host "${HOSTNAME}" --packages gorilla |
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 must admit I always found it weird that the REX-based package install is not something like
hammer host package install --host "${HOSTNAME}" --packages gorilla --provider rex
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.
Why does a user need to care about provider?
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 think the question is why it needs a job-invocation
in one case and a hammer host package
install in the other. The user shouldn't have to care: they just want to install a package. It can be nice to have the option to enforce a certain provider for testing though.
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 see it as creating a common invocation method no matter the operation. We can have a special invocation method just for package operations, where do we draw the line between special commands and general use of the REX hammer interface?
I am not saying I necessarily like the current REX invocation as it's a bit... wordy. And likely based off the structure of the API more than thinking about the users point of view.
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.
Why does a user need to care about provider?
Exactly.
In the UI, there is a default one and the user can select an alternative one if they want to with a single click.
With hammer, it's totally different depending on the provider.
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 definitely agree that it's a bit less convenient than the old katello agent commands. With katello agent gone, we could consider cleaning up the hammer commands to make them more convenient.
@jeremylenz think it's worth an addition to the tasks relating to post katello-agent removal cleanup?
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.
cleaning up the hammer commands to make them more convenient.
What specifically do you have in mind? Keeping the old hammer host package
commands and redirecting them to REX? Or improving the hammer job invocation create
commands?
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.
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.
My approach is to just warn the user and ask them to use the job-invocations
I do not want to be in the business of redirecting because it would require us to keep hammer commands consistent with the job template changes.
bats/fb-katello-client.bats
Outdated
KATELLO_VERSION=$(tKatelloVersion) | ||
} | ||
|
||
@test "enable remote execution (or katello-agent for Katello 4.9 and below)" { |
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.
Another approach to make it clear is to have 2 "tests". One for enable katello-agent that's skipped on >= 4.10 and one for enabling REX that's skipped on < 4.10.
Or given how much of this file is conditional: write fb-katello-client-rex.bats
and fb-katello-client-katello-agent.bats
and handle it at a higher level. Simply don't execute it at all on >= 4.10.
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.
+1 from me to split file approach
ecb2b98
to
4502398
Compare
36bfd0d
to
d9c3db0
Compare
Updated to have two files. Tested on Nightly and Katello 4.9 again. |
summarizing for my own sanity, this:
based on that: ACK side quest:
|
Sums it up well!
I can separate it out, sure. We should do container push in the future so those tests can go in there. |
d9c3db0
to
682ff8f
Compare
@evgeni the container test has been split out. |
682ff8f
to
acfa739
Compare
Switches content actions to use remote execution via ssh instead of Katello agent for Katello 4.10+.
On my local pipeline, ssh keys weren't set up for REX so I added a bit in the setup section to do that.
I haven't yet tested on a pipeline lower than 4.10, but I figured I could get some eyes on this first.
I tested this on my local nightly pipeline from forklift.