removed unnecessary comments

docs_user/assemblies/assembly_adopting-the-image-service.adoc

@@ -1,7 +1,6 @@
 [id="adopting-the-image-service_{context}"]
 
 :context: image-service
-//Check xref context."Reviewing the OpenStack configuration" xref does not work.
 
 = Adopting the {image_service}
 

docs_user/modules/openstack-troubleshooting.adoc

@@ -1,7 +1,6 @@
 [id="troubleshooting-adoption_{context}"]
 
 //:context: troubleshooting-adoption
-//kgilliga: This module might be converted to an assembly.
 
 = Troubleshooting adoption
 

docs_user/modules/proc_adopting-autoscaling.adoc

@@ -1,7 +1,5 @@
 [id="adopting-autoscaling_{context}"]
 
-//Check xref contexts.
-
 = Adopting autoscaling
 
 Adopting autoscaling means that an existing `OpenStackControlPlane` custom resource (CR), where Aodh services are supposed to be disabled, should be patched to start the service with the configuration parameters provided by the source environment.

docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc

@@ -122,7 +122,7 @@ done
 ----
 ifeval::["{build}" != "downstream"]
 . Create a https://kubernetes.io/docs/concepts/configuration/secret/#ssh-authentication-secrets[ssh authentication secret] for the data plane nodes: 
-//kgilliga: We probably shouldn't link to an external site. I need to check if we will document this in Red Hat docs.
+//kgilliga:I need to check if we will document this in Red Hat docs.
 endif::[]
 ifeval::["{build}" != "upstream"]
 . Create a ssh authentication secret for the data plane nodes: 

docs_user/modules/proc_adopting-the-object-storage-service.adoc

@@ -1,5 +1,5 @@
 [id="adopting-the-object-storage-service_{context}"]
-//check xref
+
 = Adopting the Object Storage service
 
 This section only applies if you are using OpenStack Swift as {object_storage_first_ref}. If you are using the Object Storage API of Ceph RGW this section can be skipped.

docs_user/modules/proc_adopting-the-orchestration-service.adoc

@@ -25,7 +25,6 @@ such as {networking_first_ref}, {compute_service_first_ref}, {object_storage_fir
 trying to adopt {orchestration}.
 
 .Procedure
-//kgilliga: I get an error when I click this link. Do we need it in the downstream docs?
 ifeval::["{build}" != "downstream"] 
 As already done for https://github.com/openstack-k8s-operators/data-plane-adoption/blob/main/keystone_adoption.md[Keystone], the Heat Adoption follows a similar pattern.
 endif::[]

docs_user/modules/proc_adopting-the-placement-service.adoc

@@ -1,7 +1,5 @@
 [id="adopting-the-placement-service_{context}"]
 
-//Check xref contexts.
-
 = Adopting the Placement service
 
 .Prerequisites

docs_user/modules/proc_deploying-file-systems-service-control-plane.adoc

@@ -104,7 +104,6 @@ backend driver needs to use its own instance of the `manila-share`
 service.
 * If a storage backend driver needs a custom container image, find it on the
 https://catalog.redhat.com/software/containers/search?gs&q=manila[RHOSP Ecosystem Catalog] 
-//kgilliga: Should this link to the RH Ecosystem Catalog appear downstream only?
 and set `manila: template: manilaShares: <custom name> : containerImage`
 value. The following example illustrates multiple storage backend drivers,
 using custom container images.

docs_user/modules/proc_migrating-ceph-mds.adoc

@@ -207,7 +207,6 @@ ifeval::["{build}" != "downstream"]
 [NOTE]
 It is possible to elect as "active" a dedicated MDS for a particular file system. To configure this preference, `CephFS` provides a configuration option for MDS called `mds_join_fs` which enforces this affinity.
 When failing over MDS daemons, a cluster’s monitors will prefer standby daemons with `mds_join_fs` equal to the file system name with the failed rank. If no standby exists with `mds_join_fs` equal to the file system name, it will choose an unqualified standby as a replacement.
-//kgilliga: We might want to discuss what info is really necessary downstream.
 endif::[]
 +
 ----

docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc

@@ -278,4 +278,4 @@ oc delete pod mariadb-copy-data
 oc delete pvc mariadb-data
 ----
 For more information, see https://learn.redhat.com/t5/DO280-Red-Hat-OpenShift/About-pod-security-standards-and-warnings/m-p/32502[About pod security standards and warnings].
-//kgilliga: Should this link to "About pod security standards and warnings" appear downstream only?
+

docs_user/modules/proc_migrating-tls-everywhere.adoc

@@ -78,7 +78,6 @@ The item you need to consider is the first one: `caSigningCert cert-pki-ca`.
 
 
 . Export the certificate and key from the `/etc/pki/pki-tomcat/alias` directory:
-//kgilliga: SMEs, Please confirm that this step is accurate. ^
 +
 ----
 $IPA_SSH pk12util -o /tmp/freeipa.p12 -n 'caSigningCert\ cert-pki-ca' -d /etc/pki/pki-tomcat/alias -k /etc/pki/pki-tomcat/alias/pwdfile.txt -w /etc/pki/pki-tomcat/alias/pwdfile.txt

docs_user/modules/proc_preparing-block-storage-service-by-customizing-configuration.adoc

@@ -33,7 +33,6 @@ image. If they do, find the location of the image in the vendor's instruction
 available in the https://catalog.redhat.com/software/search?target_platforms=Red%20Hat%20OpenStack%20Platform&p=1&functionalCategories=Data%20storage[{rhos_prev_long} {block_storage} ecosystem
 page]
 //kgilliga: Shouldn't this link be this instead? https://catalog.redhat.com/software/search?target_platforms=Red%20Hat%20OpenStack%20Platform&p=1&functionalCategories=Data%20storage&certified_plugin_types=Block%20Storage%20(Cinder)
-//Also, should we link to the Red Hat catalog downstream only?
 and add it under the specific's driver section using the `containerImage` key.
 The following example shows a CRD for a Pure Storage array with a certified driver:
 +

docs_user/modules/proc_relocating-one-instance-of-a-monitoring-stack-to-migrate-daemons-to-target-nodes.adoc

@@ -104,6 +104,7 @@ With the procedure described above we lose High Availability: the monitoring
 stack daemons have no VIP and haproxy anymore; Node exporters are still
 running on all the nodes: instead of using labels we keep the current approach
 as we want to not reduce the monitoring space covered.
+
 //kgilliga: What does "the procedure described above" refer to?
 
 . Update the Ceph Dashboard Manager configuration. An important aspect that should be considered at this point is to replace and

docs_user/modules/proc_stopping-openstack-services.adoc

@@ -1,7 +1,5 @@
 [id="stopping-openstack-services_{context}"]
 
-//Check xref context.
-
 = Stopping {rhos_prev_long} services
 
 Before you start the adoption, you must stop the {rhos_prev_long} ({OpenStackShort}) services.