Fixes #13571 - Remote execution integration

[iNecas]

Add ability to use the Remote Execution tooling for the content actions
on hosts.

First, we need to use the developer API to define the remote execution features
and templates.

Then, there is ability in UI to jump into the remote execution UI
from the appropriate places.

Depends on theforeman/foreman_remote_execution#149.

• - detect if Remote Execution plugin is installed and make the option available only when presented
• - errata support

[jlsherrill]

I'm okay if we assume remote execution is installed (and start requiring it by default)

we're going to do that eventually to support things like errata application so might as well do that now?

[jlsherrill]

Also, curious if you think it makes sense to be able to specify a default value for whether you want to use remote execution or not. If someone really likes remote execution they may want to do that.

[jlsherrill]

[test]

[ehelms]

When viewing the gif, what I missed was how a user does a package install as we do them today with gofer/katello-agent. I saw the ability to choose how to perform but both looked via remote execution only.

[ehelms]

I would prefer we not assume remote execution is installed and either make it a hard dependency or not. I can see value in both cases:

1. Hard dependency on remote execution for Katello to work
2. Optional dependency that unlocks features when present

Option 2 provides more composibility and lighter-weightness to Katello as it can manage your content but can be enhanced by adding remote execution to unlock functionality.

[ehelms]

Which screen in the diff is this being used at?

[ehelms]

Looking further down the diff, it appears this is providing a controller to hit remotely but not any UI components itself?

[iNecas]

It mostly uses the present UI in JobInvocationsController (from remote execution). This provides the mapping between the Katello UI and the remote execution

[iNecas]

@ehelms @jlsherrill I have both:
- detect if Remote Execution plugin is installed and make the option available only when presented
- errata support
as a todo in this PR, just wanted to get the initial code into review earlier. So the plan is optional dependency and unlocking the new features when rex is available. The errata support should arrive today.

The original use for katello-agent is still triggered by the original buttons itselfs. I can make that as another option in the poppup, and make the default configurable in settings: seems like something people, that prefer remote execution would prefer anyway.

[iNecas]

I've made the remote execution optiona + a setting option to make it the default action. The popup now contains "run via Katello agent" option as well

[ehelms]

@jlsherrill currently this defaults to and shows Katello Agent as the top choice no matter if katello agent is installed - I lean towards not showing that as an option or simply not defaulting to it if not present. What do you think?

@iNecas consider me a REX noob here, I selected install via ssh and was taken to a job invocation screen where it failed, but I can't tell why it failed.

Question -- does the SSH option require the content host is registered against a particular proxy or the main proxy with the SSH feature enabled on it? If yes, should that option be displayed if the content host is or the main proxy doesn't have that feature?

[iNecas]

@ehelms the failure is due to host coming from Katello does not have a operating system assigned. I would like to see that fixed in the Katelo (I can do that) if you think it's a good idea? We could fallback in our template to handle this case though, @stbenjam ideas?

[iNecas]

@ehelms ad. the proxy selection, see http://theforeman.org/plugins/foreman_remote_execution/0.2/#4.1Determiningthesmartproxyforhost : there are multiple strategies for selecting one

[stbenjam]

@ehelms the failure is due to host coming from Katello does not have a operating system assigned. I would like to see that fixed in the Katelo (I can do that) if you think it's a good idea? We could fallback in our template to handle this case though, @stbenjam ideas?

In a real world situation Katello hosts created through subscription-manager will have an Operating System since #5719. I think it'd be better if the test objects reflected that.

It raises an issue though that the template doesn't support anything other than Red Hat and Debian, so we should handle that case - by like as you suggested setting a default (e.g. yum), or failing better. I think I'd prefer the latter, because someone running Package Action on FreeBSD should get some helpful message.

[stbenjam]

Oh I see, not a test object but that was @ehelms's real host - how come it doesn't have an OS assigned? Both puppet reported hosts and subscription-manager reported hosts should have one.

[ehelms]

Is this rebased to include #5719? I am not seeing in the git logs and I registered this host against this PR.

[stbenjam]

Yea, it's not, it was a recent merge. Rebasing should solve the problem.

The error message should be more helpful anyway, I filed http://projects.theforeman.org/issues/13632.

[iNecas]

I've rebased the stuff and converted the content_host_ids

[iNecas]

Ad. not showing the stuff when the rex/agent is not available for the host: it's a bit tricky, especially for the bulk action, where we would need to check if at least on from the group has the feature. Also, in case you want to plan the execution in the future, in theory, you would not need the host to have the proxy available right now. I would rather see this handled in remote execution by enhancing the error messages, when no proxy is available for the execution

[iNecas]

I've taken @waldenraines suggestion and improved the JS code, it looks a bit more as Angular code now. The CI should get green now.

[iNecas]

Tests are green now

[ehelms]

I will take a look at this again today - thanks for indulging us with getting the UI code up to speed!

[iNecas]

I've done some updates to the developer api on rex side. If you rebase theforeman/foreman_remote_execution#149 on already migrated system, you should follow theforeman/foreman_remote_execution#149 to get up to date with the schema (or just resetting the databases form scratch).

[ehelms]

I see the above error when templates aren't associated which is kind of ugly from a user perspective. Further, after a complete reset with migrate and seed I do not see the templates auto-associated to the various features. Is that intentional? I thought when I previously reviewed it they were automatically associated.

[iNecas]

It gets associated only at a time of first seeding the templates: the reason for this is we don't know, if no template is assigned to the template on purpose or accidentally.

We could say though that we don't allow no template to be assigned to the feature, in which case we would assign it to the seeded one when seeding.

[ares]

after short discussion with Ivan, I lean to that we should re-associate the template as the on purpose disassociation is quite edge case and I'd recommend using permissions for this use case

[ehelms]

1. So don't allow it to be unset? or default to the base if not otherwise specified? I just want to clarify what we are landing on so I can properly review the behavior.

2. Are the test failures due to needing a new release of foreman_tasks?

[iNecas]

1. the desired behaviour will be, if unset, re-attach the original template when seeding, /me waiting for fixes #13579 - sync templates during seed theforeman/foreman_remote_execution#150 to finish tests so that I can push my changes in
2. the issues were fixed by fixes #13723 - use git ls for gemspec theforeman/foreman-tasks#173 (comment), once I update this PR with latest changes, it should get green

[ehelms]

Ok - can a template be complete unset from a feature? In other words, can the template for a feature be set to blank by the user?

[iNecas]

yes

[iNecas]

I've updated from latest PR in remote execution theforeman/foreman_remote_execution#149: now the unassigned feature should get assigned to the default template when re-seeding. Still I would consider this as a corner case. The tests should get green as well now.

[iNecas]

The tests are green :) http://ci.theforeman.org/job/test_katello_pull_request/8431/

[ehelms]

ACK - thanks @iNecas !