Split remote execution into multiple assemblies#4753
Split remote execution into multiple assemblies#4753aneta-petrova merged 8 commits intotheforeman:masterfrom
Conversation
Reorganize remote execution assembly into logical sections
Split the remote execution assembly into three focused assemblies to improve navigation and maintainability:
- Overview: what REX is, architecture, transport mode comparison
- Configuration: setting up hosts, permissions, SSH/Kerberos, templates, running jobs
- Reference: advanced settings, cron lines, rate limits
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Restructure remote execution into five focused assemblies
Replace the previous three-section structure with five assemblies following a progressive learning path:
- Discovering remote execution: overview, architecture, transport modes
- Getting started with remote execution: installation, permissions, first jobs
- Configuring remote execution: SmartProxy settings, authentication, SSH/Kerberos
- Extending remote execution: job templates, Ansible playbooks, scheduling
- Remote execution reference: advanced settings, cron syntax, performance
Use gerund-based naming (discovering, getting started, configuring, extending) for better consistency with documentation conventions. Drop _{context} suffix from assembly IDs for cleaner cross-references.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fix up assembly introductions
Rework remote execution reference
guides/common/modules/con_getting-started-with-remote-execution.adoc
Outdated
Show resolved
Hide resolved
Lennonka
left a comment
There was a problem hiding this comment.
Love it!
I've taken a look at the new TOC and the following things jumped out at me.
The rest looks good architecture wise.
guides/common/assembly_getting-started-with-remote-execution.adoc
Outdated
Show resolved
Hide resolved
|
Btw, I've been thinking about moving Ansible playbook import (example) into the Ansible guide solely because it fits better with the Ansible content journey rather than the REX content journey IMO. But we can do that in another PR ofc if we agree on it. |
|
|
||
| include::modules/con_remote-execution-in-project.adoc[leveloffset=+1] | ||
|
|
||
| include::modules/con_remote-execution-workflow.adoc[leveloffset=+1] |
There was a problem hiding this comment.
Can we reserve the term "workflow" for user workflows and call this a "process"?
There was a problem hiding this comment.
I like this question. I do not have an answer/+1/-1.
There was a problem hiding this comment.
I think I know what you mean with 'workflow' but also don't think 'process' would be right here. Is it okay if I leave this as is? This is not something I'm changing in this PR, the heading already exists.
|
Feel free to leave changes in headings/titles for another PR. :) |
Co-authored-by: Brian Angelica <91690569+bangelic@users.noreply.github.com>
Co-authored-by: Lena Ansorgová <zuansorg@redhat.com>
maximiliankolb
left a comment
There was a problem hiding this comment.
One suggestion about deeply nested assemblies. Overall, I like this PR.
|
|
||
| include::modules/con_remote-execution-in-project.adoc[leveloffset=+1] | ||
|
|
||
| include::modules/con_remote-execution-workflow.adoc[leveloffset=+1] |
There was a problem hiding this comment.
I like this question. I do not have an answer/+1/-1.
Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de>
Separate authentication and advanced config assemblies Create reference assembly for remote execution Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Why not try it if it makes sense, but a separate PR would be better for that with its own round of reviews and all that :) |
|
Thanks for all the brilliant suggestions, this was a very productive peer review. Can I please get a re-review? |
There was a problem hiding this comment.
LGTM!
Just a few notes, mostly non-blocking.
A second ack by @maximiliankolb would be appreciated.
maximiliankolb
left a comment
There was a problem hiding this comment.
Thanks Anet, LGTM.
RE Lena's comment: I lean towards applying it.
Co-authored-by: Lena Ansorgová <zuansorg@redhat.com>
--------- Co-authored-by: Brian Angelica <91690569+bangelic@users.noreply.github.com> Co-authored-by: Lena Ansorgová <zuansorg@redhat.com> Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> (cherry picked from commit 593c49d) (cherry picked from commit 331257a)
--------- Co-authored-by: Brian Angelica <91690569+bangelic@users.noreply.github.com> Co-authored-by: Lena Ansorgová <zuansorg@redhat.com> Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> (cherry picked from commit 593c49d)
--------- Co-authored-by: Brian Angelica <91690569+bangelic@users.noreply.github.com> Co-authored-by: Lena Ansorgová <zuansorg@redhat.com> Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> (cherry picked from commit 593c49d)
What changes are you introducing?
Creating sub-assemblies in the existing remote execution assembly. The new assemblies are based on 'feature lifecycle phases': overview/learning, getting started, configuring, customizing, reference.
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
The existing assembly is very large (about 30 sections). Splitting it into multiple assemblies helps with navigation.
Part of the CQA (Content Quality Assessment) checklist: One user story per assembly
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
Contributor checklists
Please cherry-pick my commits into: