update

README.md

@@ -6,62 +6,74 @@ SAAP docs are built using [MkDocs](https://github.com/mkdocs/mkdocs) which is ba
 
 This repository has Github action workflow which checks the quality of the documentation and builds the Dockerfile image on Pull Requests. On a push to the main branch, it will create a GitHub release and push the built Dockerfile image to an image repository.
 
-## Build Dockerfile image and run container
+## Build locally
+
+There are at least three options to get fast continuous feedback during local development:
+
+1. Build and run the docs using the Dockerfile image
+1. Run the commands locally
+1. Use Tilt
 
-Build Dockerfile image:
+### Build Dockerfile image and run container
 
-```shell
+Build Dockerfile test image:
+
+```bash
 $ docker build . -t test
 ```
 
-Run container:
+Run test container:
 
-```shell
+```bash
 $ docker run -p 8080:8080 test
 ```
 
 Then access the docs on [`localhost:8080`](localhost:8080).
 
-## Build locally
-
-It is preferred to build and run the docs using the Dockerfile image, however an alternative is to run the commands locally.
+### Run commands locally
 
 Use [virtualenvwrapper](https://virtualenvwrapper.readthedocs.io/en/latest/install.html) to set up Python virtual environments.
 
 Install [Python 3](https://www.python.org/downloads/).
 
 Install mkdocs-material and mermaid plugin:
 
-```sh
+```bash
 $ pip3 install mkdocs-material mkdocs-mermaid2-plugin
 ```
 
 Finally serve the docs using the built-in web server which is based on Python http server - note that the production build will use Nginx instead:
 
-```
+```bash
 $ mkdocs serve
 ```
 
 or 
 
-```
+```bash
 $ python3 -m mkdocs serve 
 ```
 
-## Run QA checks locally
+### QA Checks
 
-QA checks can be run locally for faster development feedback.
-
-### Markdown linting:
+Markdown linting:
 
 ```bash
 $ brew install markdownlint-cli
 $ markdownlint -c .markdownlint.yaml content
 ```
 
-### Spell checking
+Spell checking:
 
 ```bash
 $ brew install vale
 $ vale content
 ```
+
+## Use Tilt
+
+Install [Tilt](https://docs.tilt.dev/index.html), then run:
+
+```bash
+$ tilt up
+```

Tiltfile

@@ -0,0 +1,22 @@
+local_resource('install vale',
+                cmd='which vale > /dev/null || brew install vale')
+local_resource('spell check with vale',
+                cmd='vale content',
+                deps='./content/',
+                resource_deps=['install vale'])
+
+local_resource('install markdownlint',
+                cmd='which markdownlint > /dev/null || brew install markdownlint-cli')
+local_resource('markdownlint',
+                cmd='markdownlint -c .markdownlint.yaml content',
+                deps='./content/',
+                resource_deps=['install markdownlint'])
+
+local_resource('build test image',
+               cmd='docker build -t test .',
+               deps='./content/',
+               resource_deps=['spell check with vale', 'markdownlint'])
+
+local_resource('run test container',
+               cmd='docker run -d -p 8080:8080 test',
+               resource_deps=['build test image'])

content/about/service-definition/networking.md

@@ -14,7 +14,15 @@ SAAP includes TLS security certificates needed for both internal and external se
 
 ## Load-balancers
 
+SAAP is normally created via the installer provisioned infrastructure (IPI) installation method which installs operators that manage load-balancers in the customer cloud, and API load-balancers to the master nodes. Application load-balancers are created as part of creating routers and ingresses. The operators use cloud identities to interact with the cloud providers API to create the load-balancers.
 
+User-provisioned installation (UPI) method is also possible if extra security is needed and then you must create the API and application ingress load balancing infrastructure separately and before SAAP is installed.
+
+SAAP has a default router/ingress load-balancer that is the default application load-balancer, denoted by `apps` in the URL. The default load-balancer can be configured in SAAP to be either publicly accessible over the internet, or only privately accessible over a pre-existing private connection. All application routes on the cluster are exposed on this default router load-balancer, including cluster services such as the logging UI, metrics API, and registry.
+
+SAAP has an optional router/ingress load-balancer that is a secondary application load-balancer, denoted by `apps2` in the URL. The secondary load-balancer can be configured in SAAP to be either publicly accessible over the internet, or only privately accessible over a pre-existing private connection. If a 'Label match' is configured for this router load-balancer, then only application routes matching this label will be exposed on this router load-balancer, otherwise all application routes are also exposed on this router load-balancer.
+
+SAAP has optional load-balancers for services that can be mapped to a service running on SAAP to enable advanced ingress features, such as non-HTTP/SNI traffic or the use of non-standard ports. Cloud providers may have a quota that limits the number of load-balancers that can be used within each cluster.
 
 ## Network use
 
@@ -26,7 +34,7 @@ Project administrators can add route annotations for ingress control through IP
 
 Ingress policies can also be changed by using `NetworkPolicy` objects.
 
-All cluster ingress traffic goes through the defined load balancers. Direct access to all nodes is blocked by cloud configuration.
+All cluster ingress traffic goes through the defined load-balancers. Direct access to all nodes is blocked by cloud configuration.
 
 ## Cluster egress