Skip to content
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

Merged
merged 1 commit into from
Aug 25, 2023

Conversation

ianballou
Copy link
Contributor

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.

@evgeni
Copy link
Member

evgeni commented Aug 16, 2023

We have an installer switch to deploy the keys ;)

- "--foreman-proxy-plugin-remote-execution-script-install-key=true"

@ianballou
Copy link
Contributor Author

Katello 4.9 client bats tests passed:

    ok 1 centos8-stream install: enable remote execution (or katello-agent for Katello 4.9 and below)
    ok 2 centos8-stream install: disable puppet agent to prevent checkin from registering host to another org # skip Puppet is not active
    ok 3 centos8-stream install: delete host if present
    ok 4 centos8-stream install: register subscription manager with username and password
    ok 5 centos8-stream install: register subscription manager with activation key
    ok 6 centos8-stream install: start puppet again # skip Puppet isn't enabled
    ok 7 centos8-stream install: check content host is registered
    ok 8 centos8-stream install: enable content view repo
    ok 9 centos8-stream install: install katello-host-tools
    ok 10 centos8-stream install: install package locally
    ok 11 centos8-stream install: check available errata
    ok 12 centos8-stream install: try fetching container content
    ok 13 centos8-stream install: install katello-agent
    ok 14 centos8-stream install: 30 sec of sleep for groggy gofers
    ok 15 centos8-stream install: install package remotely
    ok 16 centos8-stream install: install errata remotely
    ok 17 centos8-stream install: package remove (via remote execution or katello-agent)
    ok 18 centos8-stream install: clean up subscription-manager and gofer after content tests

}

@test "enable remote execution (or katello-agent for Katello 4.9 and below)" {
if tIsVersionNewer "${KATELLO_VERSION}" 4.10; then
Copy link
Member

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 :)

Comment on lines 110 to 112
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
Copy link
Member

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

Copy link
Member

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?

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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.

KATELLO_VERSION=$(tKatelloVersion)
}

@test "enable remote execution (or katello-agent for Katello 4.9 and below)" {
Copy link
Member

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.

Copy link
Member

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

@ianballou ianballou force-pushed the remove-katello-agent branch 5 times, most recently from 36bfd0d to d9c3db0 Compare August 21, 2023 19:46
@ianballou
Copy link
Contributor Author

Updated to have two files. Tested on Nightly and Katello 4.9 again.

@evgeni
Copy link
Member

evgeni commented Aug 25, 2023

summarizing for my own sanity, this:

  • marks the existing "katello-client" tests as being requiring katello agent and skips them on 4.10+
  • introduces rex-based katello-client tests, having roughly the same feature coverage as the agent based ones and executes them on all versions (good!)
  • drops the container test (which is not really agent not really rex) from the agent tests

based on that: ACK

side quest:

  • should the container test be really in an own file, as it is not "client" related (it doesn't require any entitlement or anything) and only really needs the certs to be trusted to work?

@ianballou
Copy link
Contributor Author

summarizing for my own sanity, this:

* marks the existing "katello-client" tests as being requiring katello agent and skips them on 4.10+

* introduces rex-based katello-client tests, having roughly the same feature coverage as the agent based ones and executes them on _all_ versions (good!)

* drops the container test (which is not really agent not really rex) from the agent tests

Sums it up well!

side quest:

* should the container test be really in an own file, as it is not "client" related (it doesn't require any entitlement or anything) and only really needs the certs to be trusted to work?

I can separate it out, sure. We should do container push in the future so those tests can go in there.

@ianballou
Copy link
Contributor Author

@evgeni the container test has been split out.

@evgeni evgeni merged commit 1ce6bad into theforeman:master Aug 25, 2023
7 of 8 checks passed
@ianballou ianballou deleted the remove-katello-agent branch August 28, 2023 14:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants