Note: Doc team updates the current version of the documentation and the
two previous versions (n-2), but we address *only high-priority, or
customer-reported issues* for -2 releases in support.
Describe the changes in the doc and link to your dev story:

1. - [ ] Mandatory: Add the required version to the Fix version/s field.

• All versions (At least 2.11 and 2.10)

2. - [ ] Mandatory: Choose the type of documentation change or review.

• We need to update to an existing topic

3. - [ ] *Mandatory: *Use the following link to open the doc and find where the
documentation update should go. Note: As the feature and doc is
understood and developed, this placement decision may change:

• Published doc: https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html-single/clusters/index#auto-add-host-steps-cli

4. - [ ] Mandatory for GA content:

5. - [ ] Mandatory for bugs: What is the diff? Clearly define what the
problem is, what the change is, and link to the current documentation. Only
use this for a documentation bug.

We should state that we can specify the role ("master" or "worker") of the BareMetalHost resource by setting bmac.agent-install.openshift.io/role annotation.
And we can specify the hostname using bmac.agent-install.openshift.io/hostname annotation.
Ref : https://github.com/openshift/assisted-service/blob/master/internal/controller/controllers/bmh_agent_controller.go#L79

However, current ACM document doesn't mention these annotations.
So, users cannot know how to specify hostname and role (master or worker) when using BMH resources.
This is a problem especially when we replace a master node.

I think our document should mention some optional annotations, bmac.agent-install.openshift.io/role and bmac.agent-install.openshift.io/hostname, in the document like the following example BMH resource definition :

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: <bmh-name>
  namespace: <your_infraenv_namespace>
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: <hostname>
    bmac.agent-install.openshift.io/role: <master-or-worker>
  labels:
    infraenvs.agent-install.openshift.io: <your-infraenv>
spec:
  online: true
  automatedCleaningMode: disabled
  bootMACAddress: <your-mac-address>
  bmc:
    address: <machine-address>
    credentialsName: <bmc-secret-name>
  rootDeviceHints:
    deviceName: /dev/sda 


- bmac.agent-install.openshift.io/hostname: (Optional) specify the hostname of this node
- bmac.agent-install.openshift.io/role: (Optional) specify the role of this node

And, the following document describes how to specify the role of an agent resource.
This method works well when we use Discovery ISO method instead of the BareMetalHost method.
However, in some scenario, we need to use the BareMetalHost method instead of using a Discovery ISO and need to specify its role, due to https://issues.redhat.com/browse/ACM-15278.
I think the following document should mention how to specify the role on the a BareMetalHost resource scenario, not only the Discovery ISO scenario.

https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html-single/clusters/index#adding-ctrl-nodes-managed-healthy