-
Notifications
You must be signed in to change notification settings - Fork 96
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
fixes #10756, #13500 - developer api and PXE-less reprovisioning #144
Conversation
Any plugin (or core) and define a feature at initialization: ``` RemoteExecutionFeature.register(:reprovision, N_("Reprovision"), :description => "Reprovision the host via script", :provided_inputs => ["script"]) ``` The mapping between the feature and templates can be made via 'Administer -> Remote Execution Features'. ``` composer = JobInvocationComposer.for_feature(:reprovision, host, :script => "grubby...") composer.save! composer.trigger ``` When seeding a template, there is a new meta `feature`, which allows to assign some template as default to the specified feature. The template mapping is now limited to just one template, but in future, we can extend that to allow different mappings through organizations, but lets keep it simple first.
This commit adds ability to run the script provision template via remote execution and reboot the host, which effectively brings PXEless provisioning into Foreman.
For the reprovisioning to work on centos7, I had to update the script template slightly (ommiting the --copy-default):
|
It gives the best results in combination with theforeman/smart_proxy_remote_execution_ssh#20, that fixes rebooting |
@@ -50,7 +50,7 @@ def remote_execution_proxies(provider) | |||
proxy_scope = ::SmartProxy | |||
end | |||
|
|||
proxies[:global] = proxy_scope.authorized.with_features(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 had to do this in order to ssh keys snippet to work with global proxy, I will probably open a separate PR and issue for this.
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 like the approach in general, do we have a way to get the results back to the caller when it completes? This is also a separate problem by being able to show some structured results (e.g. package install case -> return the version installed), but we should at least support the ability to send a success/fail message back now, perhaps by letting the caller register itself as an observer of the invocation? |
Even in katello today, we're using the task object to get the output. So we might just get the task data simpler to get after triggering, so that the plugin can consume that. |
If a Katello user kicks off a package install, the UI will probably stay the same as it is today, so that I was thinking of a case where you have a plugin that kicks off a remote execution task, and wants to get the results of that sent somewhere else (eventually). For example, foreman_salt has a 'Run Salt' button on the Hosts page. I'd like to notify a ReportImporter service when it completes, because then the service could look at the remote execution task output, and parse that output as a Report. Maybe there's other ways to accomplish this already - like call Remote Execution from within a task itself and just block on the REX task to complete, instead of doing something like the observer pattern. Hopefully I'm explaining what I mean 😕 ❓ |
I see. In your case, I would probably rather go into triggering the task from within the orchestration action in salt: so you would get the composer from the developer API and the calling |
FYI: I've opened separate PR with just developer API #148, in order to move other features forward (such as Katello integration), and getting some time to get the pxe-less reprovision finished (API/CLI and UI updates) |
I've opened the power action templates in separate PR #155 |
closing in favor of #159, I will try also to extend the build button with the toggle there |
Fixes #12040 - make erb options optional
This PR adds ability to run the script provision template via remote
execution and reboot the host, which effectively brings PXEless
provisioning into Foreman.
This feature uses a new developer API of the remote execution plugin.
Any plugin (or core) and define a feature at initialization:
The mapping between the feature and templates can be made via
'Administer -> Remote Execution Features'.
When seeding a template, there is a new meta
feature
, which allows toassign some template as default to the specified feature.
The template mapping is now limited to just one template, but in future, we
can extend that to allow different mappings through organizations, but lets
keep it simple first.
TODO: