-
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
Managing hosts adding network interfaces #3431
base: master
Are you sure you want to change the base?
Managing hosts adding network interfaces #3431
Conversation
guides/common/modules/proc_adding-a-bonded-interface-using-cli.adoc
Outdated
Show resolved
Hide resolved
guides/common/modules/proc_adding-a-bonded-interface-using-cli.adoc
Outdated
Show resolved
Hide resolved
. Navigate to the *Add Interface* form: | ||
+ | ||
-- | ||
* Navigate to *Hosts* > *All Hosts*. |
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.
AFAIK, we use numbering, not bullets, for substeps.
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'll default to complying with the rest of the docs for consistency, but I'll present my logic just in case:
- The usual option results into the
a. b. c.
numbering, which is counterintuitive (looks like answer options in a test) - It's possible to do the better
i. ii. iii.
numbering, but the markup is illogical (.
for level one items,...
for level two items) - I chose bullet points, because the markup is clean enough, and the result is clear. Plus, most of the grouped steps can be done in any order, it's a form in the UI.
I'll wait for a 👍 from another reviewer to change these to a. b. c.
.
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 point of view is based on "separating content from presentation": you want to add substeps, so let's use the markup for substeps. The way that markup is rendered is a separate issue.
c151bac
to
95568b4
Compare
987bae4
to
630b523
Compare
630b523
to
8280430
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.
A couple of suggestions.
|
||
include::modules/proc_adding-a-physical-interface.adoc[leveloffset=+1] | ||
include::modules/con_network-interface-configuration-options.adoc[leveloffset=+1] |
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 see this as a reference file ref_
at the end of the assembly.
When adding a network interface, you need to specify several configuration options. The following lists provide information on the relevant options for the different types of interfaces. | ||
|
||
[id="Physical_interface_settings_{context}"] | ||
== Physical interface settings |
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.
== Physical interface settings | |
.Physical interface settings |
I'd prefer informal headings to separate the options.
[id="Virtual_interface_settings_{context}"] | ||
== Virtual interface settings | ||
|
||
* *Tag*. You can set a VLAN tag to trunk a network segment from the physical network through to the virtual interface. |
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.
* *Tag*. You can set a VLAN tag to trunk a network segment from the physical network through to the virtual interface. | |
*Tag*:: You can set a VLAN tag to trunk a network segment from the physical network through to the virtual interface. |
Is there a reason for a different markup than the options above?
[id="Bonded_interface_settings_{context}"] | ||
== Bonded interface settings | ||
|
||
* *Mode*. The bonding mode defines a policy for fault tolerance and load balancing. |
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.
* *Mode*. The bonding mode defines a policy for fault tolerance and load balancing. | |
*Mode*:: The bonding mode defines a policy for fault tolerance and load balancing. |
Same here.
What changes are you introducing?
Improvements to the "Adding network interfaces" section of the Managing hosts guide.
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
https://issues.redhat.com/browse/SAT-26429
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
Checklists
Please cherry-pick my commits into: