add p/z section and nodeport

Author: SNiemann15

modules/ossm-federation-across-cluster.adoc

@@ -15,6 +15,11 @@ If the cluster runs on bare metal and fully supports `LoadBalancer` services, th
 
 If the cluster does not support `LoadBalancer` services, using a `NodePort` service could be an option if the nodes are accessible from the cluster running the other mesh. In the `ServiceMeshPeer` object, specify the IP addresses of the nodes in the `.spec.remote.addresses` field and the service's node ports in the `.spec.remote.discoveryPort` and `.spec.remote.servicePort` fields.
 
+== Exposing the federation ingress on clusters running on IBM Power and IBM Z
+If the cluster runs on IBM Power or IBM Z infrastructure and fully supports `LoadBalancer` services, the IP address found in the `.status.loadBalancer.ingress.ip` field of the ingress gateway `Service` object should be specified as one of the entries in the `.spec.remote.addresses` field of the `ServiceMeshPeer` object.
+
+If the cluster does not support `LoadBalancer` services, using a `NodePort` service could be an option if the nodes are accessible from the cluster running the other mesh. In the `ServiceMeshPeer` object, specify the IP addresses of the nodes in the `.spec.remote.addresses` field and the service's node ports in the `.spec.remote.discoveryPort` and `.spec.remote.servicePort` fields.
+
 == Exposing the federation ingress on Amazon Web Services (AWS)
 By default, LoadBalancer services in clusters running on AWS do not support L4 load balancing. In order for {SMProductName} federation to operate correctly, the following annotation must be added to the ingress gateway service:
 

modules/ossm-federation-config-smcp.adoc

@@ -114,7 +114,7 @@ You use a *gateway* to manage inbound and outbound traffic for your mesh, lettin
 
 You use ingress and egress gateways to manage traffic entering and leaving the service mesh (North-South traffic). When you create a federated mesh, you create additional ingress/egress gateways, to facilitate service discovery between federated meshes, communication between federated meshes, and to manage traffic flow between service meshes (East-West traffic).
 
-To avoid naming conflicts between meshes, you must create separate egress and ingress gateways for each mesh. For example, 'red-mesh' would have separate egress gateways for traffic going to 'green-mesh' and `blue-mesh`.
+To avoid naming conflicts between meshes, you must create separate egress and ingress gateways for each mesh. For example, `red-mesh` would have separate egress gateways for traffic going to `green-mesh` and `blue-mesh`.
 
 .Federation gateway parameters
 [options="header"]
@@ -213,6 +213,16 @@ To avoid naming conflicts between meshes, you must create separate egress and in
 |`LoadBalancer`
 |
 
+|spec:
+  gateways:
+    additionalIngress:
+      <ingressName>:
+        service:
+          type:
+|If the cluster does not support `LoadBalancer` services, the ingress gateway service can be exposed through a `NodePort` service.
+|`NodePort`
+|
+
 |spec:
   gateways:
     additionalIngress:
@@ -234,8 +244,43 @@ To avoid naming conflicts between meshes, you must create separate egress and in
 |Used to specify the `port:` and `name:` used for TLS and service discovery. Federation traffic consists of raw encrypted TCP for service traffic. Federation traffic consists of HTTPS for discovery.
 |Port `15443` is required for receiving TLS service requests to other meshes in the federation. Port `8188` is required for receiving service discovery requests to other meshes in the federation.
 |
+
+|spec:
+  gateways:
+    additionalIngress:
+      <ingressName>:
+        service:
+          ports:
+            nodePort:
+|Used to specify the `nodePort:` if the cluster does not support `LoadBalancer` services.
+|If specified, is required in addition to `port:` and `name:` for both TLS and service discovery. `nodePort:` must be in the range  `30000`-`32767`.
+|
 |===
 
+In the following example, the administrator is configuring the SMCP for federation with  the `green-mesh` using a `NodePort` service.
+
+.Sample SMCP for NodePort
+[source,yaml]
+----
+  gateways:
+     additionalIngress:
+      ingress-green-mesh:
+        enabled: true
+        routerMode: sni-dnat
+        service:
+          type: NodePort
+          metadata:
+            labels:
+              federation.maistra.io/ingress-for: ingress-green-mesh
+          ports:
+          - port: 15443
+            nodePort: 30510
+            name: tls
+          - port: 8188
+            nodePort: 32359
+            name: https-discovery
+----
+
 == Understanding federation trust domain parameters
 
 Each mesh in the federation must have its own unique trust domain. This value is used when configuring mesh federation in the `ServiceMeshPeer` resource.