summaryrefslogtreecommitdiffstats
path: root/docs/oom_user_guide.rst
diff options
context:
space:
mode:
authorSylvain Desbureaux <sylvain.desbureaux@orange.com>2021-09-30 12:27:20 +0000
committerGerrit Code Review <gerrit@onap.org>2021-09-30 12:27:20 +0000
commita001a61bdd6430027b39281f9d79366e837c7494 (patch)
tree62a6d95b84d11e0c94ad79f26645bd159eb1a3fc /docs/oom_user_guide.rst
parent7fe88978fd7e65e140b7f763845c15157157dc58 (diff)
parentc08270e3213309dac5d6dada14c1d09410921be7 (diff)
Merge changes If3c9758c,I704fc2ee
* changes: [DOC] Fix docs requirements and Sphinx profiles [DOC] Fix some doc8 issues
Diffstat (limited to 'docs/oom_user_guide.rst')
-rw-r--r--docs/oom_user_guide.rst23
1 files changed, 12 insertions, 11 deletions
diff --git a/docs/oom_user_guide.rst b/docs/oom_user_guide.rst
index 3a707e25ea..5f63c7d1a2 100644
--- a/docs/oom_user_guide.rst
+++ b/docs/oom_user_guide.rst
@@ -444,23 +444,24 @@ the portal and then simply access now the new ssl-encrypted URL:
| Alternatives Considered:
- - Kubernetes port forwarding was considered but discarded as it would require
- the end user to run a script that opens up port forwarding tunnels to each of
- the pods that provides a portal application widget.
+ - Kubernetes port forwarding was considered but discarded as it would
+ require the end user to run a script that opens up port forwarding tunnels
+ to each of the pods that provides a portal application widget.
- Reverting to a VNC server similar to what was deployed in the Amsterdam
- release was also considered but there were many issues with resolution, lack
- of volume mount, /etc/hosts dynamic update, file upload that were a tall order
- to solve in time for the Beijing release.
+ release was also considered but there were many issues with resolution,
+ lack of volume mount, /etc/hosts dynamic update, file upload that were
+ a tall order to solve in time for the Beijing release.
Observations:
- - If you are not using floating IPs in your Kubernetes deployment and directly attaching
- a public IP address (i.e. by using your public provider network) to your K8S Node
- VMs' network interface, then the output of 'kubectl -n onap get services | grep "portal-app"'
+ - If you are not using floating IPs in your Kubernetes deployment and
+ directly attaching a public IP address (i.e. by using your public provider
+ network) to your K8S Node VMs' network interface, then the output of
+ 'kubectl -n onap get services | grep "portal-app"'
will show your public IP instead of the private network's IP. Therefore,
- you can grab this public IP directly (as compared to trying to find the floating
- IP first) and map this IP in /etc/hosts.
+ you can grab this public IP directly (as compared to trying to find the
+ floating IP first) and map this IP in /etc/hosts.
.. figure:: oomLogoV2-Monitor.png
:align: right