-
Notifications
You must be signed in to change notification settings - Fork 95
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
Modularize Foreman API guide #3353
Conversation
3c1af6c
to
305f215
Compare
guides/common/modules/proc_creating-and-modifying-resources.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_creating-and-modifying-resources.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_creating-and-modifying-resources.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_passing-json-data-to-the-api-request.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_uploading-content-to-projectserver.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_using-apipie-bindings-with-ruby.adoc
Outdated
Show resolved
Hide resolved
305f215
to
a358a3a
Compare
a358a3a
to
3cafdbe
Compare
I'd suggest to keep it for clarity because some endpoints can be accessed by using multiple methods and it's more descriptive to be explicit about the method in use even if it's the default one. |
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.
My few cents.
guides/common/modules/proc_creating-and-modifying-resources.adoc
Outdated
Show resolved
Hide resolved
I'm assuming you mean inside the Python and Ruby code. Assuming they won't change the functionality (if they are semantically same), we might go with " (double quotes) because it looks like they are used more frequently in the code and are better for readability. However, this requires a more in-depth research as to the semantics of the code IMHO. Perhaps even developer review. |
f16f584
to
6b74008
Compare
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.
Rebased to "master" and started working on applying feedback. Draft for now!
guides/common/modules/proc_creating-and-modifying-resources.adoc
Outdated
Show resolved
Hide resolved
6b74008
to
13dc9d2
Compare
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.
Implemented the suggestion to use ".API request" and ".API repsonse" in all applicable files.
As a follow-up task, we should look at all procedures relating to applying errata to hosts: there are quite a few! For now, I consider this out of scope.
13dc9d2
to
548bd26
Compare
548bd26
to
3ad3153
Compare
guides/common/modules/con_working-with-lifecycle-environments.adoc
Outdated
Show resolved
Hide resolved
3ad3153
to
fd84b61
Compare
Rebased to "master", resolved a merge conflict, and reverted a change "MB -> MiB". |
guides/common/modules/proc_uploading-content-to-projectserver.adoc
Outdated
Show resolved
Hide resolved
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.
One last suggestion. The rest looks good!
guides/common/modules/proc_creating-linked-lifecycle-environments.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_creating-linked-lifecycle-environments.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_deleting-a-lifecycle-environment.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_deleting-a-lifecycle-environment.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_updating-a-lifecycle-environment.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_uploading-content-larger-than-2-mb.adoc
Outdated
Show resolved
Hide resolved
6da393f
to
dcdf8e6
Compare
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.
guides/common/modules/proc_uploading-content-to-projectserver.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_creating-linked-lifecycle-environments.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_deleting-a-lifecycle-environment.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_deleting-a-lifecycle-environment.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_updating-a-lifecycle-environment.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_uploading-content-larger-than-2-mb.adoc
Outdated
Show resolved
Hide resolved
. In the {ProjectWebUI}, navigate to *Hosts* > *Host Collections*. | ||
. Select a host collection. | ||
. On the *Actions* tab, click *Errata Installation*. | ||
. Follow the {ProjectWebUI} to install errata. |
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.
"Follow the UI to install errata" is pretty vague for a procedure step.
If your PR covers only modularization, then my comment is probably outside the scope of this task. Do you think this justifies a bug?
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 believe that we've started to remove doc bloat if the WebUI is good and the user is guided by a wizard. This is one of these instances.
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.
This is a slippery slope. I want to discuss this with you offline.
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.
Can you please continue the conversation here (rather than offline)? I'm actually following this thread and am interested in the topic. (I agree with Max that if the steps are explained in the wizard/UI, duplicating them in the docs is not the best idea.)
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.
@maximiliankolb I checked the wizard in the web UI and yes, it works just fine on its own. Perhaps you could add its name, to help users check they landed on the right page in case of any confusion? How about something like this:
. Follow the {ProjectWebUI} to install errata. | |
. Follow the *Content Host Errata Management* wizard in the {ProjectWebUI} to install errata. |
Looking into the IBM style guide, it does include this in one of its examples:
- [Step 1]
- In the wizard, follow the instructions on each page.
- [Step 3]
So it doesn't look like we're breaking any official convention with this approach.
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.
If the "installing errata" wizard is extremely brief, that might be a consideration.
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.
Re: my own reservations. This is something that I would prefer to discuss with our team.
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'd rather not share a direct link to a closed resource. A full-text search of the pdf should get you where you need to be but just in case it doesn't: the example is in Punctuation > Colons > Introductory text. While I realize that this section is not centered around describing UI elements, I don't think it matters because the example is still there 🤷 Also, I didn't see anything that would discourage from this approach in Technical elements > UI elements > Usage and highlighting for interface elements (where wizards are actually described).
I'm not totally opposed to deviating from a style guide in cases when there is a reason. I didn't mean my comments to be a conversation stopper. As I mentioned, I looked at the wizard itself and reached the conclusion that no additional documentation support was necessary + I checked the style guide to make sure it supports this approach. If you disagree, I'd be happy to hear why :)
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.
Oh well, I took too long to write up my comment :) That's what happens when I try too hard.
To quote your example:
In the “Printer setup” wizard, specify details about the printer that you want to use.
vs this PR's
Follow the Content Host Errata Management wizard in the {ProjectWebUI} to install errata.
is basically the same thing: Printer setup wizard/Content Host Errata Management wizard > specify printer details/install errata. In my opinion, it all comes down to actually trying the wizard and seeing what it looks like.
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.
It's interesting that this wizard is not documented anywhere. I was only able to find the CLI procedure for applying errata to a host collection. I checked the host management guide as well.
|
||
.Procedure | ||
. In the {ProjectWebUI}, navigate to *Hosts* > *Host Collections*. | ||
. Select a host collection. |
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.
. Select a host collection. | |
. Click a host collection to view the *Details* tab. |
If the docs say "Select" whenever the user clicks to view details, you can ignore this comment for the sake of consistency.
. In the {ProjectWebUI}, navigate to *Hosts* > *Host Collections*. | ||
. Select a host collection. | ||
. On the *Actions* tab, click *Errata Installation*. | ||
. Follow the {ProjectWebUI} to install errata. |
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.
. Follow the {ProjectWebUI} to install errata. | |
. On the *Content Host Errata Management* page, select the hosts and click *Done*. |
I think a wizard has to have one or more pages.
* Modularize content in "guides/common/modules" related to the Foreman API guide * Unifying anchors Is a original effort by Lena to bring the Foreman API guide upstream, we briefly discussed to way to set anchors. If I remember correctly, we though about using the api- prefix similar to the cli- prefix for CLI procedures. I consider this to have value on its own; and allow for a smoother transition in case we ever decide that we want to also show the API procedure as part of "normal aka. WebUI-based" workflows. * Using long options for commands (mostly curl) to provide better readability * Using one argument per line to also simplify readability
dcdf8e6
to
40397d6
Compare
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.
Rebased to "master" and reworded one procedure. This PR is only about modularizing existing content. Kindly asking for re-review @apinnick and @asteflova
I would be happy to do a quick follow-up PR to reword the Web UI wizard.
Merged to "master" and cherry-picked to "3.13": Thanks to everyone for their input. @apinnick @Lennonka @asteflova If you want to propose any follow-up changes, esp. to procedures about "applying errata" (we have a lot of these!), ping me. I could also open an upstream issue and look into this myself soon. |
What changes are you introducing?
guides/common/modules
related to the Foreman API guideapi-
prefix similar to thecli-
prefix for CLI procedures. I consider this to have value on its own; and allow for a smoother transition in case we ever decide that we want to also show the API procedure as part of "normal aka. WebUI-based" workflows.Why are you introducing these changes? (Explanation, links to references, issues, etc.)
mostly to improve maintainability by splitting content into smaller modules. to align with existing content; help downstream integration; to prepare for the eventual merge with WebUI related procedures.
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
--request GET
for curl commands? It's the default HTTP method and the command would also work without.Checklists
Please cherry-pick my commits into: