first initial commit with skeleton

.dockerignore

@@ -0,0 +1 @@
+.git*

.github/md_config.json

@@ -0,0 +1,7 @@
+{
+  "ignorePatterns": [
+    {
+      "pattern": "^(?!http).+"
+    }
+  ]
+}

.github/workflows/pull_request.yaml

@@ -0,0 +1,23 @@
+name: Pull Request
+
+on:
+  pull_request:
+    branches:
+      - 'main'
+
+jobs:
+  qa:
+    uses: stakater/.github/.github/workflows/[email protected]
+    with:
+      MD_CONFIG: .github/md_config.json
+      DOC_SRC: content
+      MD_LINT_CONFIG: markdownlint.yaml
+  build:
+    uses: stakater/.github/.github/workflows/[email protected]
+    with:
+      DOCKER_FILE_PATH: Dockerfile
+    secrets:
+      CONTAINER_REGISTRY_URL: ${{ secrets.STAKATER_NEXUS_PREPROD_REGISTRY }}
+      CONTAINER_REGISTRY_USERNAME: ${{ secrets.STAKATER_NEXUS_PREPROD_USERNAME }}
+      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.STAKATER_NEXUS_PREPROD_PASSWORD }}
+      SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}

.github/workflows/push.yaml

@@ -0,0 +1,19 @@
+name: Push
+
+on:
+  push:
+    branches:
+      - 'main'
+
+jobs:
+  push:
+    uses: stakater/.github/.github/workflows/[email protected]
+    with:
+      DOCKER_FILE_PATH: Dockerfile
+      RELEASE_BRANCH: main
+    secrets:
+      CONTAINER_REGISTRY_URL: ${{ secrets.STAKATER_NEXUS_PREPROD_REGISTRY }}
+      CONTAINER_REGISTRY_USERNAME: ${{ secrets.STAKATER_NEXUS_PREPROD_USERNAME }}
+      CONTAINER_REGISTRY_PASSWORD: ${{ secrets.STAKATER_NEXUS_PREPROD_PASSWORD }}
+      SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}
+      GH_TOKEN: ${{ secrets.STAKATER_GITHUB_TOKEN }}

.github/workflows/release.yaml

@@ -0,0 +1,12 @@
+name: Release
+
+on:
+  push:
+    tags:
+      - "v*"
+
+jobs:
+  release:
+    uses: stakater/.github/.github/workflows/[email protected]
+    secrets:
+      SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}

.gitignore

@@ -0,0 +1,22 @@
+# Dist files
+dist/
+lib/
+
+# Test temp files
+**/__fixtures__/.temp/
+
+# Test coverage files
+coverage/
+
+# MacOS Desktop Services Store
+.DS_Store
+
+# Log files
+*.log
+
+# Typescript build info
+*.tsbuildinfo
+node_modules
+
+# Build files
+site/

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "vocabulary"]
+	path = vocabulary
+	url = [email protected]:stakater/vocabulary.git

.vale.ini

@@ -0,0 +1,9 @@
+StylesPath = "vocabulary/styles"
+MinAlertLevel = warning
+
+Vocab = "Stakater"
+
+# Only check MarkDown files
+[*.md]
+
+BasedOnStyles = Vale

Dockerfile

@@ -0,0 +1,30 @@
+FROM python:3.11-alpine as builder
+
+RUN pip3 install mkdocs-material mkdocs-mermaid2-plugin
+
+# set workdir
+RUN mkdir -p $HOME/application
+WORKDIR $HOME/application
+
+# copy the entire application
+COPY --chown=1001:root . .
+
+# build the docs
+RUN mkdocs build
+
+FROM nginxinc/nginx-unprivileged:1.23-alpine as deploy
+COPY --from=builder $HOME/application/site/ /usr/share/nginx/html/
+COPY default.conf /etc/nginx/conf.d/
+
+# set non-root user
+USER 1001
+
+LABEL name="Multi Tenant Operator Documentation" \
+      maintainer="Stakater <[email protected]>" \
+      vendor="Stakater" \
+      release="1" \
+      summary="Documentation for Multi Tenant Operator"
+
+EXPOSE 8080:8080/tcp
+
+CMD ["nginx", "-g", "daemon off;"]

content/about/cloud-providers/aws.md

@@ -0,0 +1,30 @@
+# AWS
+
+## Instance Types
+
+SAAP offers the following worker node types and sizes on AWS:
+
+### General Purpose
+
+- m5.xlarge (4 vCPU, 16 GiB)
+- m5.2xlarge (8 vCPU, 32 GiB)
+- m5.4xlarge (16 vCPU, 64 GiB)
+
+### Memory Optimized
+
+- r5.xlarge (4 vCPU, 32 GiB)
+- r5.2xlarge (8 vCPU, 64 GiB)
+- r5.4xlarge (16 vCPU, 128 GiB)
+
+### Compute Optimized
+
+- c5.2xlarge (8 vCPU, 16 GiB)
+- c5.4xlarge (16 vCPU, 32 GiB)
+
+## Network usage
+
+TODO
+
+## Cloud network configuration
+
+TODO

content/about/cloud-providers/overview.md

@@ -0,0 +1 @@
+# Overview

content/about/high-availability.md

@@ -0,0 +1,65 @@
+# High availability
+
+## About high availability 
+
+High availability (HA) is a core discipline in an IT infrastructure to keep your apps up and running, even after a partial or full site failure. The main purpose of high availability is to eliminate potential points of failures in an IT infrastructure. For example, you can prepare for the failure of one system by adding redundancy and setting up failover mechanisms.
+
+Availability and disaster avoidance are extremely important aspects of any application platform. SAAP provides many protections against failures at several levels, but customer-deployed applications must be appropriately configured for high availability. In addition, to account for cloud provider outages that might occur, other options are available, such as deploying a cluster across multiple availability zones or maintaining multiple clusters with failover mechanisms.
+
+### What level of availability is best?
+
+You can achieve high availability on different levels in your IT infrastructure and within different components of your cluster. The level of availability that is correct for you depends on several factors, such as your business requirements, the Service Level Agreements that you have with your customers, and the resources that you want to expend.
+
+## Potential points of failure
+
+SAAP provides many features and options for protecting your workloads against downtime, but applications must be architected appropriately to take advantage of these features.
+
+SAAP can help further protect you against many common Kubernetes issues by adding Stakater Site Reliability Engineer (SRE) support and the option to deploy a multi-zone cluster, but there are a number of ways in which a container or infrastructure can still fail. By understanding potential points of failure, you can understand risks and appropriately architect both your applications and your clusters to be as resilient as necessary at each specific level.
+
+!!! note "NOTE"
+
+	An outage can occur at several different levels of infrastructure and cluster components.
+
+SAAP provides several approaches to add more availability to your cluster by adding redundancy and anti-affinity. Review the following image to learn about potential points of failure and how to eliminate them.
+
+TODO - add image
+
+### Potential failure point 1: Container or pod availability
+
+Containers and pods are, by design, short-lived and can fail unexpectedly. Appropriately scaling services so that multiple instances of your application pods are running protects against issues with any individual pod or container. The node scheduler can also ensure that these workloads are distributed across different worker nodes to further improve resiliency.
+
+When accounting for possible pod failures, it is also important to understand how storage is attached to your applications. Single persistent volumes attached to single pods cannot leverage the full benefits of pod scaling, whereas replicated databases, database services, or shared storage can.
+
+To avoid disruption to your applications during planned maintenance, such as upgrades, it is important to define a pod disruption budget. These are part of the Kubernetes API and can be managed with the OpenShift CLI (oc) like other object types. They allow the specification of safety constraints on pods during operations, such as draining a node for maintenance.
+
+### Potential failure point 2: Worker node availability
+
+A worker node is a VM that runs on physical hardware. Worker node failures include hardware outages, such as power, cooling, or networking, and issues on the VM itself. You can account for a worker node failure by setting up multiple worker nodes in your cluster.
+
+Worker nodes are the virtual machines that contain your application pods. By default, SAAP cluster has a minimum of three worker nodes for a single availability-zone cluster. In the event of a worker node failure, pods are relocated to functioning worker nodes, as long as there is enough capacity, until any issue with an existing node is resolved or the node is replaced. More worker nodes means more protection against single node outages, and ensures proper cluster capacity for rescheduled pods in the event of a node failure.
+
+!!! note "NOTE"
+
+	When accounting for possible node failures, it is also important to understand how storage is affected.
+
+### Potential failure point 3: Cluster availability
+
+SAAP clusters have at least three control plane nodes and three infrastructure nodes that are preconfigured for high availability, either in a single zone or across multiple zones depending on the type of cluster you have selected. This means that control plane and infrastructure nodes have the same resiliency of worker nodes, with the added benefit of being managed completely by Stakater.
+
+In the event of a complete control plane node outage, the OpenShift APIs will not function, and existing worker node pods will be unaffected. However, if there is also a pod or node outage at the same time, the control plane nodes will have to recover before new pods or nodes can be added or scheduled.
+
+All services running on infrastructure nodes are configured by Stakater to be highly available and distributed across infrastructure nodes. In the event of a complete infrastructure outage, these services will be unavailable until these nodes have been recovered.
+
+The Kubernetes master is the main component that keeps your cluster up and running. The master stores cluster resources and their configurations in the etcd database that serves as the single point of truth for your cluster. The Kubernetes API server is the main entry point for all cluster management requests from the worker nodes to the master, or when you want to interact with your cluster resources. To protect your cluster master from a zone failure: create a cluster in a multizone location, which spreads the master across zones or consider setting up a second cluster in another zone.
+
+### Potential failure point 4: Zone availability
+
+A zone failure from a public cloud provider affects all virtual components, such as worker nodes, block or shared storage, and load balancers that are specific to a single availability zone. Failures include power, cooling, networking, or storage outages, and natural disasters, like flooding, earthquakes, and hurricanes. To protect against a zone failure, SAAP provides the option for clusters that are distributed across three availability zones, called multi-availability zone clusters. Existing stateless workloads are redistributed to unaffected zones in the event of an outage, as long as there is enough capacity.
+
+### Potential failure point 5: Region availability
+
+Every region is set up with a highly available load balancer that is accessible from the region-specific API endpoint. The load balancer routes incoming and outgoing requests to clusters in the regional zones. The likelihood of a full regional failure is low. However, to account for this failure, you can set up multiple clusters in different regions and connect them by using an external load balancer. If an entire region fails, the cluster in the other region can take over the workload.
+
+### Potential failure point 6: Storage availability
+
+If you have deployed a stateful application, then storage is a critical component and must be accounted for when thinking about high availability. A single block storage PV is unable to withstand outages even at the pod level. The best ways to maintain availability of storage are to use replicated storage solutions, shared storage that is unaffected by outages, or a database service that is independent of the cluster.

content/about/overview.md

@@ -0,0 +1 @@
+# Overview

content/about/responsibility-matrix/application-data.md

@@ -0,0 +1,8 @@
+# Applications and data
+
+You are completely responsible for the applications, workloads, and data that you deploy to SAAP. However, SAAP provides various tools to help you set up, manage, secure, integrate and optimize your apps as described in the following table.
+
+| Resource                    | Stakater responsibilities            | Your responsibilities                |
+| :-------------------------- | :----------------------------------- | :----------------------------------- |
+| Customer data               | - Maintain platform-level standards for data encryption. \n - Provide OpenShift components to help manage application data, such as secrets. \n - Enable integration with third-party data services (such as AWS RDS or Google Cloud SQL) to store and manage data outside of the cluster and/or cloud provider.  | Maintain responsibility for all customer data stored on the platform and how customer applications consume and expose this data.  |
+| Customer applications       | :material-check-all: Update resource | :material-check:     Fetch resource  |

content/about/service-definition/account-management.md

@@ -0,0 +1,17 @@
+# Account Management
+
+## Billing
+
+
+## Cloud Providers
+
+SAAP is available as a managed service on the following cloud providers:
+
+- Amazon Web Services (AWS)
+- Google Cloud Platform (GCP)
+- Azure
+- Binero
+- UpCloud
+
+## Cluster Provisioning
+

content/about/service-definition/artifacts-management.md

@@ -0,0 +1 @@
+# Artifacts Management

content/about/service-definition/logging.md

@@ -0,0 +1 @@
+# Logging

content/about/service-definition/monitoring.md

@@ -0,0 +1 @@
+# Monitoring

content/about/service-definition/networking.md

@@ -0,0 +1,26 @@
+# Networking
+
+## Custom domains for applications
+
+To use a custom hostname for a route, you must update your DNS provider by creating a canonical name (CNAME) record. Your CNAME record should map the OpenShift canonical router hostname to your custom domain. The OpenShift canonical router hostname is shown on the Route Details page after a Route is created. Alternatively, a wildcard CNAME record can be created once to route all subdomains for a given hostname to the cluster’s router.
+
+## Custom domains for cluster services
+
+Custom domains and subdomains are not available for the platform service routes, for example, the API or web console routes, or for the default application routes.
+
+## Domain validated certificates
+
+SAAP includes TLS security certificates needed for both internal and external services on the cluster. For external routes, there are two, separate TLS wildcard certificates that are provided and installed on each cluster, one for the web console and route default hostnames and the second for the API endpoint. Let’s Encrypt is the certificate authority used for certificates. Routes within the cluster, for example, the internal API endpoint, use TLS certificates signed by the cluster’s built-in certificate authority and require the CA bundle available in every pod for trusting the TLS certificate.
+
+## Loadbalancers
+
+
+## Network usage
+
+
+## Cluster ingress
+
+
+## Cluster egress
+
+

content/about/service-definition/overview.md

@@ -0,0 +1 @@
+# Overview

content/about/service-definition/platform.md

@@ -0,0 +1 @@
+# Platform

content/about/service-definition/secrets-management.md

@@ -0,0 +1 @@
+# Secrets Management

content/about/service-definition/security.md

@@ -0,0 +1,23 @@
+# Security
+
+## Authentication provider
+
+Authentication for the cluster is configured as part of cluster creation process. SAAP is not an identity provider, and all access to the cluster must be managed by the customer as part of their integrated solution. Provisioning multiple identity providers provisioned at the same time is supported. The following identity providers are supported:
+
+- GitHub or GitHub Enterprise OAuth
+- GitLab OAuth
+- Google OAuth
+- LDAP
+- OpenID connect
+
+## Privileged containers
+
+Privileged containers are not available by default on SAAP. The anyuid and nonroot Security Context Constraints (SCC) are available for members of the sca group, and should address many use cases. Privileged containers are only available for cluster-admin users.
+
+## Customer administrator user
+
+In addition to normal users
+
+## Cluster administration role
+
+As an administrator

content/about/service-definition/storage.md

@@ -0,0 +1 @@
+# Storage

content/about/sla.md

@@ -0,0 +1 @@
+# SLAs