Skip to content
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

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

rh-max
Copy link
Contributor

@rh-max rh-max commented Nov 6, 2024

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

  • I am okay with my commits getting squashed when you merge this PR.
  • I am familiar with the contributing guidelines.

Please cherry-pick my commits into:

  • Foreman 3.12/Katello 4.14 (Satellite 6.16)
  • Foreman 3.11/Katello 4.13 (orcharhino 6.11 on EL8 only)
  • Foreman 3.10/Katello 4.12
  • Foreman 3.9/Katello 4.11 (Satellite 6.15; orcharhino 6.8/6.9/6.10)
  • Foreman 3.8/Katello 4.10
  • Foreman 3.7/Katello 4.9 (Satellite 6.14)
  • Foreman 3.6/Katello 4.8
  • Foreman 3.5/Katello 4.7 (Satellite 6.13; orcharhino 6.6/6.7)
  • We do not accept PRs for Foreman older than 3.5.

. Navigate to the *Add Interface* form:
+
--
* Navigate to *Hosts* > *All Hosts*.
Copy link
Contributor

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.

Copy link
Contributor Author

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..

Copy link
Member

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.

@rh-max rh-max added Needs tech review Requires a review from the technical perspective Needs style review Requires a review from docs style/grammar perspective labels Nov 7, 2024
@rh-max rh-max force-pushed the managing-hosts-adding-network-interfaces branch from c151bac to 95568b4 Compare November 7, 2024 10:01
@rh-max rh-max force-pushed the managing-hosts-adding-network-interfaces branch from 987bae4 to 630b523 Compare November 7, 2024 11:10
@rh-max rh-max force-pushed the managing-hosts-adding-network-interfaces branch from 630b523 to 8280430 Compare November 7, 2024 12:19
Copy link
Contributor

@Lennonka Lennonka left a 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]
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
== 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* *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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* *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.

@pr-processor pr-processor bot added the Waiting on contributor Requires an action from the author label Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs style review Requires a review from docs style/grammar perspective Needs tech review Requires a review from the technical perspective Waiting on contributor Requires an action from the author
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants