Split Administering hosts into multiple assemblies#4758
Split Administering hosts into multiple assemblies#4758aneta-petrova merged 10 commits intotheforeman:masterfrom
Conversation
|
The PR preview for 9ce5abc is available at theforeman-foreman-documentation-preview-pr-4758.surge.sh The following output files are affected by this PR:
|
b70be75 to
61922e5
Compare
Each assembly should describe a single user story only Assisted-by: Cursor
61922e5 to
6a01de6
Compare
maximiliankolb
left a comment
There was a problem hiding this comment.
Great PR overall. I made some suggestions.
| = Managing host placement and associations | ||
|
|
||
| [role="_abstract"] | ||
| Use {Project} to link each host to a compute resource, organization, location, and content view environment. |
There was a problem hiding this comment.
This feels very vague to me.
What does "link" mean? You cannot just say "move host A from Azure to GCE". Instead, you'd have to redeploy it and delete the old one. That only works well if you have its configuration as code.
There was a problem hiding this comment.
Would "associate" work better? That's what I tried to address your comment.
|
|
||
| [role="_abstract"] | ||
| Use {Project} to link each host to a compute resource, organization, location, and content view environment. | ||
| Detach host records when hosts move or retire so your host list stays current. |
There was a problem hiding this comment.
| Detach host records when hosts move or retire so your host list stays current. | |
| Detach host records when hosts move or retire so your host list stays current and {Project} no longer tries to manage it. |
Unsure about this too. Does detach mean unregister on the Client or mark as unassociated in Foreman/delete in Foreman?
There was a problem hiding this comment.
This was an attempt to describe the use case. I struggled to come up with a better one. If the new use case description is off too, then perhaps we don't have to add a use case and the first line of the abstract could also be enough?
|
This might be out of scope for this PR, but it would be great if we could move 20. Host status in Foreman under the first chapter Reviewing hosts... Just for your consideration :) |
Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de>
Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de>
Still within the scope of creating a new assembly and a good idea, thanks! Implemented. |
ed8453e to
370478e
Compare
|
I addressed all comments, and would appreciate @maximiliankolb's re-review to see if I interpreted his hints correctly. |
370478e to
7e96489
Compare
|
@aneta-petrova I can have a look at it on Monday. Please ping me if there's no comment by Monday 3pm. |
| = Managing host placement and associations | ||
|
|
||
| [role="_abstract"] | ||
| Use {Project} to associate each host with a compute resource, organization, location, and content view environment. |
There was a problem hiding this comment.
this is unclear to me. What do you mean by "associate"?
I would split this: You can assign an org/loc to a host; a host may run on a compute resource (unless bare metal); a host may have a CV env (if katello; even then it is optional IMHO).
There was a problem hiding this comment.
It's proving difficult to meet the requirements for abstracts when the assembly is somewhat generic :/ The guidelines I'm working with are written down in https://github.com/theforeman/foreman-documentation/pull/4778/changes. And I'm trying to avoid just listing the features in the included procedures because that's not what an abstract should be about.
I gave this another try. This time, I'm carefully avoiding the verb 'associate' and also the term 'infrastructure resources'. I thought that perhaps 'context-defining resources' could work? I'm just trying to find one term that describes the stuff you use to manage the hosts in the procedures included in the assembly :) What do you think now @maximiliankolb? Am I getting closer to something acceptable?
|
|
||
| [role="_abstract"] | ||
| Use {Project} to associate each host with a compute resource, organization, location, and content view environment. | ||
| This helps you keep your hosts aligned with appropriate infrastructure resources. |
There was a problem hiding this comment.
This is also unclear to me.
Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de>
Assisted-by: Cursor
maximiliankolb
left a comment
There was a problem hiding this comment.
One last suggestion.
Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de>
3d1b111 to
9ce5abc
Compare
maximiliankolb
left a comment
There was a problem hiding this comment.
Thanks Anet, LGTM.
* Split Administering hosts into multiple assemblies Each assembly should describe a single user story only Assisted-by: Cursor --------- Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de> (cherry picked from commit 9f4cabf)
* Split Administering hosts into multiple assemblies Each assembly should describe a single user story only Assisted-by: Cursor --------- Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de> (cherry picked from commit 9f4cabf)
* Split Administering hosts into multiple assemblies Each assembly should describe a single user story only Assisted-by: Cursor --------- Co-authored-by: Maximilian Kolb <mail@maximilian-kolb.de>
What changes are you introducing?
Introducing several smaller, focused assemblies in place of the existing catch-all "Administering hosts" assembly.
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
Each assembly should cover a single user story (this is part of the downstream Content Quality Assessment (CQA) initiative.)
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
I'm not changing anything about the modules themselves, I'm just moving them around.
I used the skill from #4723 for a first draft and I'd say it got about half of the changes right on the first try, so it did a lot of heavy lifting for me, which was very useful.
Contributor checklists
Please cherry-pick my commits into: