From 5a43829263480e1a908f057d646c467c144ce1cf Mon Sep 17 00:00:00 2001 From: Willy Kloucek Date: Thu, 2 May 2024 16:57:32 +0200 Subject: [PATCH] remove unmaintained configuration about the oCIS Helm chart, see also https://github.com/owncloud/ocis-charts/pull/547 --- antora.yml | 46 +- .../orchestration/orchestration.adoc | 819 +----------------- .../tab-pages/_kube-versions-tab-1.adoc | 40 - .../tab-pages/_kube-versions-tab-2.adoc | 40 - .../tab-pages/_kube-versions-tab-3.adoc | 17 - .../tab-pages/breaking-changes.adoc | 151 ---- .../builtin-user-mgmt-secrets-tab-1.adoc | 11 - .../builtin-user-mgmt-secrets-tab-2.adoc | 11 - .../builtin-user-mgmt-secrets-tab-3.adoc | 11 - .../external-user-mgmt-secrets-tab-1.adoc | 11 - .../external-user-mgmt-secrets-tab-2.adoc | 11 - .../external-user-mgmt-secrets-tab-3.adoc | 11 - .../tab-pages/val-desc-tab-1.adoc | 18 - .../tab-pages/val-desc-tab-2.adoc | 18 - .../tab-pages/val-desc-tab-3.adoc | 19 - .../orchestration/tab-pages/values-tab-1.adoc | 23 - .../orchestration/tab-pages/values-tab-2.adoc | 23 - .../orchestration/tab-pages/values-tab-3.adoc | 23 - 18 files changed, 16 insertions(+), 1287 deletions(-) delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-1.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-2.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-3.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/breaking-changes.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-1.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-2.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-3.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-1.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-2.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-3.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-1.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-2.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-3.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-1.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-2.adoc delete mode 100644 modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-3.adoc diff --git a/antora.yml b/antora.yml index 98e15663..2fce6b1a 100644 --- a/antora.yml +++ b/antora.yml @@ -1,58 +1,42 @@ name: ocis title: Infinite Scale Documentation -version: 'next' +version: "next" start_page: ROOT:index.adoc nav: -- modules/ROOT/partials/nav.adoc + - modules/ROOT/partials/nav.adoc asciidoc: attributes: - latest-ocis-version: {page-component-version} # do not change, this is the value of the version key - previous-ocis-version: {page-component-version} # do not change, this is the value of the version key + latest-ocis-version: { page-component-version } # do not change, this is the value of the version key + previous-ocis-version: { page-component-version } # do not change, this is the value of the version key # used to define the include path for services without trailing / # note that any changes of this path also need adjustment in # https://github.com/owncloud/ocis-charts/tree/master/charts/ocis/docs - s-path: 'deployment/services/s-list' + s-path: "deployment/services/s-list" # service_tab_x will be used to assemble the url accessing the link for the services - service_tab_1: 'docs' # latest stable like docs-stable-5.0 + service_tab_1: "docs" # latest stable like docs-stable-5.0 # service_tab_x_tab_text will be used as tab text shown for service_tab_x - service_tab_1_tab_text: 'master' # latest stable including patch releases like 5.0.0 + service_tab_1_tab_text: "master" # latest stable including patch releases like 5.0.0 # compose_tab_x will be used to assemble the url (tag) accessing the link for the services (tag) - compose_tab_1: 'master' # latest stable including patch releases like v5.0.0 (note the v !) + compose_tab_1: "master" # latest stable including patch releases like v5.0.0 (note the v !) # compose_tab_x_tab_text will be used as tab text shown for tab_x - compose_tab_1_tab_text: 'master' # latest stable including patch releases like 5.0.0 (must be without v !) + compose_tab_1_tab_text: "master" # latest stable including patch releases like 5.0.0 (must be without v !) # this is the first part of the name for envvars between major versions that will be added or removed # example for full name: 4.0.0-5.0.0-added.adoc or 4.0.0-5.0.0-removed.adoc - env_var_delta_name: '4.0.0-5.0.0' - - # helm_tab_x will be used to assemble the url (tag) accessing the raw content for helm charts (tag) - # note that tab 2 always contains the actual release and tab 3 the former - helm_tab_1: 'master' - helm_tab_2: 'v0.5.0' - helm_tab_3: 'v0.4.0' - - # helm_tab_x_tab_text will be used as tab text shown for tab_x - # note that tab 2 always contains the actual release and tab 3 the former - helm_tab_1_tab_text: 'latest' - helm_tab_2_tab_text: '0.5.0' - helm_tab_3_tab_text: '0.4.0' + env_var_delta_name: "4.0.0-5.0.0" # set attributes defining path components which will be assembled in the document - secrets: 'deployment/container/orchestration/orchestration.adoc#define-secrets' - ocis-charts-raw-url: 'https://raw.githubusercontent.com/owncloud/ocis-charts/' - values-versions-url: '/charts/ocis/docs/values.adoc.yaml' - values-desc-versions-url: '/charts/ocis/docs/values-desc-table.adoc' - composer-url: 'https://github.com/owncloud/ocis/tree/' - composer-raw-url: 'https://raw.githubusercontent.com/owncloud/ocis/' - composer-final-path: '/deployments/examples' + composer-url: "https://github.com/owncloud/ocis/tree/" + composer-raw-url: "https://raw.githubusercontent.com/owncloud/ocis/" + composer-final-path: "/deployments/examples" docker-ocis-url: https://hub.docker.com/r/owncloud/ocis # used in deployment/services via partials/env-and-yaml.adoc - ocis-services-raw-url: 'https://raw.githubusercontent.com/owncloud/ocis/' - ocis-services-final-path: '/services/_includes/' + ocis-services-raw-url: "https://raw.githubusercontent.com/owncloud/ocis/" + ocis-services-final-path: "/services/_includes/" diff --git a/modules/ROOT/pages/deployment/container/orchestration/orchestration.adoc b/modules/ROOT/pages/deployment/container/orchestration/orchestration.adoc index a8b9af87..88bc68d8 100644 --- a/modules/ROOT/pages/deployment/container/orchestration/orchestration.adoc +++ b/modules/ROOT/pages/deployment/container/orchestration/orchestration.adoc @@ -4,7 +4,7 @@ :description: This document provides guidelines for container orchestration tools suitable for Infinite Scale. //// -on new helmchart releases, check for attributes `no_second_tab` and `no_third_tab` to enable tab rendering. +on new helmchart releases, check for attributes `no_second_tab` and `no_third_tab` to enable tab rendering. if all blocks are allowed to be rendered, you can safely remove the attributes and the queries from the block. //// @@ -127,820 +127,3 @@ git clone --depth 1 https://github.com/owncloud/ocis.git -b {compose_tab_1_tab_t {download-gh-directory-url}?url={composer-url}{compose_tab_1}{composer-final-path} ---- -- - -== Kubernetes and Helm - -The commands and examples are based on software from Kubernetes and Helm. For other software products or environments without claim to completeness like: - -* OpenShift -* Rancher -* K3s -* AWS EKS -* GCP GKE -* Azure AKS - -you may need to adapt the commands and possibly the provided yaml files. As an example, OpenShift requires, if not otherwise defined, the container user and password ID to be a very high number. Check your software or environment for details and requirements. - -Note that this does not affect the supported Kubernetes versions. Any software or environment must match the version standards. - -=== Kubernetes - -{kubernetes-url}[Kubernetes] (abbreviated as K8s) is an open-source platform for governing clusters of containerized application services. Kubernetes automates the vital aspects of container lifecycle management, including scaling, replication, monitoring, and scheduling. It offers a framework for distributed systems. Infinite Scale was designed with Kubernetes in mind. Therefore ownCloud provides Helm charts for a convenient deployment of Infinite Scale on a Kubernetes cluster. - -//// -For more information on Kubernetes (K8s) features, check out {why-K8s-url}[Why you need Kubernetes and what it can do]. If that is too abstract, there is an {eli5-K8s-url}[ELI5 writeup]. - -We also recommend Marcel Wunderlich's {wunderlich-K8s-url}[4 series articles] on Kubernetes, clarifying its declarative nature, deep-diving into ingress networking, storage and monitoring. -//// - -See the xref:availability_scaling/availability_scaling.adoc#deployment-evolution [Deployment Evolution] description in the _Availability and Scalability_ section for reasons to use Kubernetes. - -Infinite Scale follows the {12factor-url}[Twelve-Factor App] principles regarding configuration, which means almost every aspect of Infinite Scale is modifiable via environment variables. - -When designing your Kubernetes cluster, you have two major approaches available which are `minikube` and `kubeadm`. - -minikube:: -{minikube-url}[minikube] lets you run a _single-node Kubernetes cluster locally_. It is a good way to test a deployment. It requires no extra configuration on any cloud platform as everything runs on your local machine. - -kubeadm:: -{kubeadm-url}[kubeadm] _requires at least two nodes_ and builds a minimum viable, production-ready Kubernetes cluster, using best practices. It also allows the container runtime to be chosen, though it has Docker by default. - -A tool to note: kubectl:: -{kubectl-url}[kubectl] is the command-line tool for Kubernetes. It allows users to run commands against a K8s cluster. It supports multiple contexts for as many clusters as you have access to. _minikube_ also provides kubectl wrapped as `minikube kubectcl`. - -Pods:: -A {kubernetes-pod-url}[Pod] is a Kubernetes abstraction that represents a group of one or more application containers such as Docker and some shared resources for those containers. - -=== Helm - -{helm-url}[Helm] is a Kubernetes deployment tool for automating creation, packaging, configuration and deployment of applications and services to Kubernetes clusters. Comparing Kubernetes to the operating system, Helm would be the package manager. Helm automates the maintenance of YAML manifests for Kubernetes objects. This is done by packaging information into charts -- therefore Helm Charts -- and advertising them to a Kubernetes cluster. The image below shows the interaction of Helm v3 with Kubernetes. - -image::deployment/container/what-is-helm.drawio.svg[Interaction of Helm v3 with Kubernetes, width=400] - -=== Prerequisites - -Installing Kubernetes:: -Depending on whether you want to go for a single or multi-node Kubernetes environment, follow the {K8s-setup-url}[Kubernetes Installation Documentation] to do so. This documentation will use minikube in the examples. Verify your installation by typing: -+ --- -[source,bash] ----- -minikube version ----- --- - -Installing Helm:: -Follow the {helm-install-url}[Helm Installation Documentation] post installation and setup of Kubernetes. Verify your installation by typing: -+ --- -[source,bash] ----- -helm version ----- --- - -== Using Our Helm Charts with Infinite Scale - -NOTE: The Helm chart is still in an experimental phase and has not yet been published on a Helm chart repository. For your convenience, ownCloud provides an {ocis-helm-charts-url}[ocis-charts] git repository. - -NOTE: ownCloud will publish updated data when new Helm chart releases become available. This information will be available in additional tabs in corresponding sections. Note that two Helm chart stable versions will be documented beside the development version. - -NOTE: When defining your own Helm charts, consider that, if you're using config overrides in your yaml definitions, a service does not get redefined in the override again. Multiple definitions can cause chart issues that are hard to identify. - -The `values.yaml` file provided by ownCloud uses generic configuration. You can customize this configuration with your own values, for example for different setups or sizings. This should be done by using your own `values.yaml` file at a different location which will _overwrite_ or _add_ content to the provided one. While not mandatory, the identical file name of `values.yaml` follows the convention of Helm. When it comes to security sensitive data like secrets, such data is usually _not_ added in the overwrite-values file for security reasons. In such a case, you apply secrets via command from a secrets file. - -=== Supported Infinite Scale Versions - -See the following table to match the Helm chart versions with Infinite Scale releases. Note that the chart version matches the tag in the {ocis-helm-charts-url}[ocis-charts] git repository. - -{empty} - -// this table needs manual update on the "works" rows when a new Helm chart release is published - -[width="60%",cols="~,~",options="header"] -|=== -| Helm Chart Version -| Works with Infinite Scale Versions - -| {helm_tab_1_tab_text} -| 4.0.1 - -| {helm_tab_2_tab_text} -| 4.0.1 - -| {helm_tab_3_tab_text} -| 3.0.0 -|=== - -* If a chart has been superseded by another for the same Infinite Scale release, only the latest one is listed. -* Note that Helm Chart Version `0.2.0` was a necessary intermediate for Infinite Scale `3.0.0-alpha.1` only and is therefore not listed with a working Infinite Scale version. - -=== Breaking Changes - -//// -* On each Helm Chart release, only the breaking-changes.adoc file MUST be maintained. -* We can of course also state that one tab has no breaking change but in this case, this needs manual maintenance on each new version in this document too. -//// - -Select possible breaking changes of a Helm chart version from the tabs. A new document with all details will be opened, directly referring to the selected version, although the document contains information about all published versions. - -[tabs] -==== -{helm_tab_2_tab_text}:: -+ --- -xref:deployment/container/orchestration/tab-pages/breaking-changes.adoc#{helm_tab_2_tab_text}[Breaking Changes,window=_blank] --- - -{helm_tab_3_tab_text}:: -+ --- -xref:deployment/container/orchestration/tab-pages/breaking-changes.adoc#{helm_tab_3_tab_text}[Breaking Changes,window=_blank] --- -==== - -=== Supported Kubernetes Versions - -//// -note to adapt the _kube-versions-tab-x files -1. when a new kubernetes version is added to the list or -2. when a new ocis release gets published and the tab names change !! - -for (1), just add the version to the relevant tab-x file -for (2), you need to "rotate" the content of the files. - -tab-2 -> tab-3 -tab-1 -> tab-2 -tab-1 gets new or adapted content based on former tab-1 content -//// - -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -include::./tab-pages/_kube-versions-tab-1.adoc[] --- -{helm_tab_2_tab_text}:: -+ --- -include::./tab-pages/_kube-versions-tab-2.adoc[] --- -{helm_tab_3_tab_text}:: -+ --- -include::./tab-pages/_kube-versions-tab-3.adoc[] --- -==== - -=== Get the Chart - -As the Helm chart has currently not been published to a Helm repository, you need to clone ownCloud's Helm chart git repository named {ocis-helm-charts-url}[ocis-charts]. - -=== Start minikube - -. Start your minikube cluster with the latest supported K8s version: -+ -[source,bash] ----- -minikube start --kubernetes-version=v1.28.1 ----- - -. Enable the `minikube ingress` plugin, which acts like a reverse proxy for your cluster: -+ -[source,bash] ----- -minikube addons enable ingress ----- - -. Linux only: enable the `ingress-dns` plugin and configure it: -+ -[source,bash] ----- -minikube addons enable ingress-dns ----- - -. Configure the `in-cluster DNS server` to resolve local DNS names inside the cluster`: -+ -Note that this step is not optional but mandatory for an Infinite Scale installation. For details see https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/#installation[Step 4, (optional) Configure in-cluster DNS server to resolve local DNS names inside cluster]. - -. macOS only: run `minikube tunnel` to be expose `80,443` ports: -+ -[source,bash] ----- -minikube tunnel ----- - -. Configure hosts: -.. On Linux you need to add additional configurations to use ingress by adding the domain names to `/etc/hosts`. Those entries need to point to the Minikube interface IP which you can get by running `minikube ip`. -+ -[source,bash] ----- -192.168.49.2 ocis.kube.owncloud.test ----- - -.. On macOS you need to add additional configurations to use ingress by adding the domain names to `/etc/hosts`. Since you are using `minikube tunnel`, those entries need to point to `127.0.0.1` because it's listening on the localhost interface. -+ -[source,bash] ----- -127.0.0.1 ocis.kube.owncloud.test ----- - -=== Deploy the Chart - -// note the sources for values and description are on GitHub at ocis-charts. - -:t1_text: Helm chart with default configurations. -:t2_text: Description of the values.yaml file. - -* When installing Infinite Scale in Minikube on MacOS, you need to set the `hostAliases` option: -+ -[source,yaml] ----- -hostAliases: - - ip: "192.168.49.2" # <- needs to be the IP of `minikube ip` - hostnames: - - "ocis.kube.owncloud.test" ----- - -* Based on the Kubernetes version, you will find comments in `values.yaml` where content depends on the Kubernetes version. Search for comments with `Kubernetes` for details. - -* Deploy the chart with the deployment name `ocis`, use any name as desired. To do so, run the following command from the root of the cloned repository: -+ -[source,bash] ----- -helm install ocis ./charts/ocis ----- -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/values-tab-1.adoc[values.yaml,window=_blank] -| {t1_text} - -| xref:deployment/container/orchestration/tab-pages/val-desc-tab-1.adoc[Values Description,window=_blank] -| {t2_text} -|=== --- -{helm_tab_2_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/values-tab-2.adoc[values.yaml,window=_blank] -| {t1_text} - -| xref:deployment/container/orchestration/tab-pages/val-desc-tab-2.adoc[Values Description,window=_blank] -| {t2_text} -|=== --- -{helm_tab_3_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/values-tab-3.adoc[values.yaml,window=_blank] -| {t1_text} - -| xref:deployment/container/orchestration/tab-pages/val-desc-tab-3.adoc[Values Description,window=_blank] -| {t2_text} -|=== --- -==== - -=== Customize the Generic Setup - -In all examples, adapt the settings according your needs. - -==== Set Your Own Default Values - -// edit the yaml data shown at example$deployment/container/orchestration/ - -* Create your _own local_ `values.yaml` file which will overwrite parts of the provided one with the following content: -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/values-overwrite-tab-1.yaml[] ----- --- -{helm_tab_2_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/values-overwrite-tab-2.yaml[] ----- --- -{helm_tab_3_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/values-overwrite-tab-3.yaml[] ----- --- -==== - -==== Enable Metrics with Prometheus - -// edit the yaml data shown at example$deployment/container/orchestration/ - -* In order to scrape oCIS' metrics with Prometheus, you need to set up a `ServiceMonitor`. In order to apply the ServiceMonitor, you need to have Prometheus' CustomResourceDefinitions available, e.g. by installing the {prometheus-operator-url}[Prometheus Operator]. -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/service-monitor-tab-1.yaml[] ----- --- -{helm_tab_2_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/service-monitor-tab-2.yaml[] ----- --- -{helm_tab_3_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/service-monitor-tab-3.yaml[] ----- --- -==== - -==== Configure Email Notification - -// edit the yaml data shown at example$deployment/container/orchestration/ - -* If the key `features.emailNotifications.enable` is set to `true`, the SMTP email server Secret referenced in `secretRefs.notificationsSmtpSecretRef` needs to be configured: -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/email-notification-tab-1.yaml[] ----- --- -{helm_tab_2_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/email-notification-tab-2.yaml[] ----- --- -{helm_tab_3_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/email-notification-tab-3.yaml[] ----- --- -==== - -==== Configure S3ng Storage - -// edit the yaml data shown at example$deployment/container/orchestration/ - -* If the key `services.storageusers.storageBackend.driver` is set to `s3ng`, the S3 access key ID / secret Secret referenced in `secretRefs.s3CredentialsSecretRef` needs to be configured: -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/s3ng-s3-access-key-id-secret-tab-1.yaml[] ----- --- -{helm_tab_2_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/s3ng-s3-access-key-id-secret-tab-2.yaml[] ----- --- -{helm_tab_3_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/s3ng-s3-access-key-id-secret-tab-3.yaml[] ----- --- -==== - -==== Configure Userlog Global Notifications Secret - -// edit the yaml data shown at example$deployment/container/orchestration/ - -// comment/uncomment when HC releases are published that allow showing stuff -// when all tabs are allowed, we can safely remove the variables and queries -// did not exist in 0.5.0 -:no_second_tab: true -//:no_third_tab: true - -* Configure _Global Notifications Secrets_ referenced in `secretRefs.globalNotificationsSecretRef` if required: -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/userlog-global-notifications-secret-tab-1.yaml[] ----- --- -ifndef::no_second_tab[] -{helm_tab_2_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/userlog-global-notifications-secret-tab-2.yaml[] ----- --- -ifndef::no_third_tab[] -{helm_tab_3_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/userlog-global-notifications-secret-tab-3.yaml[] ----- --- -endif::no_third_tab[] -endif::no_second_tab[] -==== - -// unset the attributes for any use on a different location. -:!no_second_tab: -:!no_third_tab: - -// this is an additional anchor for yaml files that get _included_ and reference to this section which was renamed. -[#define-secrets] - -==== Define Mandatory Secrets and ConfigMaps - -Infinite Scale requires some mandatory Secrets and ConfigMaps to work. They are created _one-off_ if you don't explicitly provide them. If you're using the builtin user management, which is not recommended, among the auto generated Secrets, there are also some certificates which expire and need to be renewed manually. - -IMPORTANT: These Secrets and ConfigMaps need to be part of your backup since you need to provide them manually during a disaster recovery procedure. - -// edit the yaml data shown at example$deployment/container/orchestration/ - -===== Mandatory Secrets - -:t_text: List of all mandatory Secrets. - -* If you want to manage Secrets on your own, you can look at the following example which shows what mandatory Secrets look like and how they can be generated. The example assumes that the `secretRefs` are not changed. Each Secret data entry holds a description of how to generate it or find the right value. -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/generic-secrets-tab-1.adoc[generic-secrets.yaml,window=_blank] -| {t_text} -|=== --- -{helm_tab_2_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/generic-secrets-tab-2.adoc[generic-secrets.yaml,window=_blank] -| {t_text} -|=== --- -{helm_tab_3_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/generic-secrets-tab-3.adoc[generic-secrets.yaml,window=_blank] -| {t_text} -|=== --- -==== - -===== Apply Mandatory Secrets - -Secrets can be applied by command or included in `extraResources` of your own `values.yaml` file. Adapt the data content according to your environment: - -. To apply secrets by command, save the content as `mandatory-secrets.yaml` and use the following command with a path to the secrets file added if necessary: -+ -[source,bash] ----- -kubectl apply -f mandatory-secrets.yaml ----- - -. To apply secrets via your own `values.yaml`, add the content at `extraResources`. Proper yaml formatting is necessary. - -===== Mandatory ConfigMaps - -* If you want to manage ConfigMaps on your own, you can look at the following example which shows how mandatory ConfigMaps look like and how they can be generated. The example assumes that the `configRefs` are not changed. Each ConfigMaps data entry holds a description of how to generate it or find the right value. - -// edit the yaml data shown at example$deployment/container/orchestration/ - -:t_text: List of all mandatory ConfigMaps. - -* The following example shows what generic configuration need to look like and how they can be generated. The example assumes that the `configRefs` are not changed . Each config data entry holds a description of how to generate it or find the right value. -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/generic-configs-tab-1.adoc[generic-configs.yaml,window=_blank] -| {t_text} -|=== --- -{helm_tab_2_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/generic-configs-tab-2.adoc[generic-configs.yaml,window=_blank] -| {t_text} -|=== --- -{helm_tab_3_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/generic-configs-tab-3.adoc[generic-configs.yaml,window=_blank] -| {t_text} -|=== --- -==== - -===== Apply Mandatory ConfigMaps - -ConfigMaps can be applied by command or included in `extraResources` of your own `values.yaml` file. Adapt the data content according to your environment: - -. To apply configs by command, save the content as `generic-configs.yaml` and use the following command with a path to the secrets file added if necessary: -+ -[source,bash] ----- -kubectl apply -f generic-configs.yaml ----- - -. To apply configs via your own `values.yaml`, add the content at `extraResources`. Proper yaml formatting is necessary. - -==== Built-in User Management Secrets - -If you're using the built-in user management by setting `features.externalUserManagement.enabled` to `false`, which is the default, you'll need additional Secrets. These are also autogenerated for you if you don't provide them manually. - -IMPORTANT: These Secrets are certificates that expire after 365 days and therefore need a certificate rotation from time to time. Rotation can be achieved by deleting the Secrets _ldap-ca_ and _ldap-cert_ and restarting all Infinite Scale deployments like with `kubectl rollout restart deploy`. - -// edit the yaml data shown at example$deployment/container/orchestration/ - -:t_text: Secrets file for the builtin user management. - -* The following example shows what the Secrets for the built-in user management need to look like and how they can be generated. The example assumes that the `secretRefs` are not changed . Each Secret data entry holds a description of how to generate it or find the right value. -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-1.adoc[builtin-user-mgmt-secrets.yaml,window=_blank] -| {t_text} -|=== --- -{helm_tab_2_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-2.adoc[builtin-user-mgmt-secrets.yaml,window=_blank] -| {t_text} -|=== --- -{helm_tab_3_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-3.adoc[builtin-user-mgmt-secrets.yaml,window=_blank] -| {t_text} -|=== --- -==== - -===== Apply Built-in User Management Secrets - -Secrets can be applied by command or included in `extraResources` of your own `values.yaml` file. Adapt the data content according to your environment: - -. To apply secrets by command, save the content as `builtin-user-mgmt-secrets.yaml` and use the following command (adding the path to the secrets file if necessary): -+ -[source,bash] ----- -kubectl apply -f builtin-user-mgmt-secrets.yaml ----- - -. To apply secrets via your own `values.yaml`, add the content at `extraResources`. Proper yaml formatting is necessary. - -==== External User Management Secrets - -If you're using external user management by setting `features.externalUserManagement.enabled` to `true`, you need to set these Secrets. Certificates are also required which should expire and therefore need a certificate rotation from time to time, for which we didn't document appropiate tooling yet. - -If you're using Helm Charts, you are responsible for these user management secrets and their lifecycle. Any information necessary to use this security-relevant data is provided by ownCloud via examples. - -// edit the yaml data shown at example$deployment/container/orchestration/ - -:t_text: Secrets file for the external user management. - -* The following example shows what external user management secrets need to look like and how they can be generated. The example assumes that the `secretRefs` are not changed . Each secret data entry holds a description of how to generate it or find the right value. -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-1.adoc[external-user-mgmt-secrets.yaml,window=_blank] -| {t_text} -|=== --- -{helm_tab_2_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-2.adoc[external-user-mgmt-secrets.yaml,window=_blank] -| {t_text} -|=== --- -{helm_tab_3_tab_text}:: -+ --- -[width="100%",cols="~,~",options="header"] -|=== -| File -| Description - -| xref:deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-3.adoc[external-user-mgmt-secrets.yaml,window=_blank] -| {t_text} -|=== --- -==== - -===== Apply External User Management Secrets - -Secrets can be applied by command or included in `extraResources` of your own `values.yaml` file. Adapt the data content according to your environment: - -. To apply secrets by command, save the content as `external-user-mgmt-secrets.yaml` and use the following command (adding a path to the secrets file if necessary): -+ -[source,bash] ----- -kubectl apply -f external-user-mgmt-secrets.yaml ----- - -. To apply secrets via your own `values.yaml`, add the content at `extraResources`. Proper yaml formatting is necessary. - -==== NGINX Ingress Example - -This is an example with NGINX ingress and certificates issued by cert-manager. To make this work, you need to have NGINX ingress and {cert-manager-url}[cert-manager] installed in your cluster. - -// edit the yaml data shown at example$deployment/container/orchestration/ - -* Defining NGINX ingress and cert-manager. -+ -[tabs] -==== -{helm_tab_1_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/nginx-ingress-tab-1.yaml[] ----- --- -{helm_tab_2_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/nginx-ingress-tab-2.yaml[] ----- --- -{helm_tab_3_tab_text}:: -+ --- -[source,yaml] ----- -include::example$deployment/container/orchestration/nginx-ingress-tab-3.yaml[] ----- --- -==== - -==== Apply Chart Changes - -* Apply all changes defined in your _own_ `values.yaml` file: -+ -[source,bash] ----- -helm upgrade --install --reset-values \ - ocis ./charts/ocis --values values.yaml ----- - -* Ensure that all the pods are running: -+ -[source,bash] ----- -kubectl get pods ----- - -=== Access Infinite Scale in Your Browser - -After you have customized your setup, use the following URL to access Infinite Scale with your browser: - -[source,plaintext] ----- -https://ocis.kube.owncloud.test ----- - -=== Uninstalling the Chart - -To uninstall/delete the `ocis` deployment, use the following command: - -[source,bash] ----- -helm delete ocis ----- - -This command removes all the Kubernetes components associated with the chart and deletes the deployment. diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-1.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-1.adoc deleted file mode 100644 index d0702539..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-1.adoc +++ /dev/null @@ -1,40 +0,0 @@ -We only list non EOL versions as of the chart release date from here: https://kubernetes.io/releases/[window=_blank] - -Note that some EOL versions still might be API compatible. - -{empty} - -[width="100%",cols="~,^~,^~",options="header"] -|=== -| Version -| Covered by tests -| Tested by developers - -a| [subs=-attributes] -+1.28+ -a| [subs=-attributes] -+yes+ -a| [subs=-attributes] -+yes+ - -a| [subs=-attributes] -+1.27+ -a| [subs=-attributes] -+yes+ -a| [subs=-attributes] -+yes+ - -a| [subs=-attributes] -+1.26+ -a| [subs=-attributes] -+yes+ -a| [subs=-attributes] -+no+ - -a| [subs=-attributes] -+1.25+ -a| [subs=-attributes] -+yes+ -a| [subs=-attributes] -+no+ -|=== diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-2.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-2.adoc deleted file mode 100644 index 5eed46d2..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-2.adoc +++ /dev/null @@ -1,40 +0,0 @@ -We only list non EOL versions as of the chart release date from here: https://kubernetes.io/releases/[window=_blank] - -Note that some EOL versions still might be API compatible. - -{empty} - -[width="100%",cols="~,^~,^~",options="header"] -|=== -| Version -| Covered by tests -| Tested by developers - -a| [subs=-attributes] -+1.27+ -a| [subs=-attributes] -+yes+ -a| [subs=-attributes] -+yes+ - -a| [subs=-attributes] -+1.26+ -a| [subs=-attributes] -+yes+ -a| [subs=-attributes] -+yes+ - -a| [subs=-attributes] -+1.25+ -a| [subs=-attributes] -+yes+ -a| [subs=-attributes] -+no+ - -a| [subs=-attributes] -+1.24+ -a| [subs=-attributes] -+yes+ -a| [subs=-attributes] -+no+ -|=== diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-3.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-3.adoc deleted file mode 100644 index 66d13540..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/_kube-versions-tab-3.adoc +++ /dev/null @@ -1,17 +0,0 @@ -* Check the supported Kubernetes versions before you download the chart. -** The `~` represents all patch releases for that particular version. -** The `-0` represents subversions of that particular version. - -+ -[width="100%",cols="~",options="header"] -|=== -| Version -a| [subs=-attributes] -+~1.27.0-0+ -a| [subs=-attributes] -+~1.26.0-0+ -a| [subs=-attributes] -+~1.25.0-0+ -a| [subs=-attributes] -+~1.24.0-0+ -|=== diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/breaking-changes.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/breaking-changes.adoc deleted file mode 100644 index 2cb8885d..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/breaking-changes.adoc +++ /dev/null @@ -1,151 +0,0 @@ -= Helm Chart Breaking Changes -:toc: right -:description: Here you will find all breaking changes that come along with different Helm Chart releases that have been published. Note that all changes apply when going from one release to another. - -//// -Note that there is only this one master file for all breaking changes. -For each breaking changes block you need: -* a new section on top of the lastest one. (actual first, former second) -* directly above the section an ID (see below how it is done) with the corresponding version equal to the version name so it can be accessed via an anchor. This cannot be automated and must be maintained manually. -* Even if there are no breaking changes, add a section telling that there are no breaking changes. -* You cannot substitute the version with an attribute like {helm_tab_2_tab_text} as the attribute changes and the content here needs to be static. -* If there are more than two sections, you can delete some or all except the last two which are mandatory to be present because of referencing. -** Double check the orchestration.adoc file if things need to be adapted (in section breaking changes) -//// - -== Introduction - -{description} - -[id=0.5.0] -== Helm Chart Version: 0.5.0 - -When upgrading from Helm Chart 0.4.0 to 0.5.0, you will be performing a upgrade from Infinite Scale 3.0.0 to 4.0.1. This upgrade will perform some migrations, please also see xref:migration/upgrading_3.0.0_4.0.0.adoc[Upgrading from 3.0.0 to 4.0.0] for more details. - -* Back up Infinite Scale as described in the xref:maintenance/b-r/backup.adoc[backup documentation]. - -* For the Helm Chart, we recommend to: -** delete the Ingress object -+ --- -[source,bash] ----- -kubectl -n ocis delete ingress/proxy ----- - -IMPORTANT: This command will make the Infinite Scale installation unavailable for users. Depending on your Kubernetes Ingress Controller, users will see different error pages. Deleting the Ingress object just ensures that none of your users can access Infinite Scale during the migration processes. --- - -* Install Infinite Scale chart version 0.5.0 with the `ingress.enabled` setting set to `false`, see xref:deployment/container/orchestration/orchestration.adoc#deploy-the-chart[Deploy the Chart] and xref:deployment/container/orchestration/orchestration.adoc#apply-chart-changes[Apply Chart Changes]. -* With Infinite Scale started using the new Helm chart version, monitor the migration status for the storage-users and storage-system service by running these commands: -+ --- -[source,bash] ----- -kubectl -n exec svc/storageusers -- ocis migrate decomposedfs -r /var/lib/ocis/storage/users list ----- - -[source,bash] ----- -kubectl -n exec svc/storagesystem -- ocis migrate decomposedfs -r /var/lib/ocis/storage/metadata list ----- --- -* If all migration steps of both services show the state `succeeded`, migrations have finished. -* You can now set the `ingress.enabled` setting to `true` and deploy the Helm chart as usual. The formerly deleted Ingress object will be recreated automatically. - -Users should now be able to access Infinite Scale again. - -[id=0.4.0] -== Helm Chart Version: 0.4.0 - -The Infinite Scale Helm Chart version 0.4.0 has received various improvements. - -Among them are the following notable improvements: - -* Supports the *update from the Helm Chart 0.1.0* by setting: + -`services.storagesystem.persistence.claimName` to `storage-system-data` and + - `services.storageusers.persistence.claimName` to `storage-users-data` + -in order to mitigate the breaking changes from Helm Chart 0.2.0. - -* Support for *Secret Auto Generation*. + -You no longer need to generate secrets manually. + -** If you already have secrets generated and configured via `extraResources`, you can just remove them from `extraResources`. -** If you applied the secrets manually to the Kubernetes cluster, they are not yet managed by Helm. Therefore you need to add the + -`app.kubernetes.io/managed-by`, + -`meta.helm.sh/release-name` and + -`meta.helm.sh/release-namespace` + -annotations manually to each secret. The values of the annotations can be found on any other resource that was deployed by the Infinite Scale chart. + -** If you don't want Secrets / ConfigMaps to be autogenerated or be managed by Helm, you can disable it by setting the particular `configRefs` / `secretRefs` option to a nonempty string (referencing the Secret / ConfigMap managed by you). - -Please also check the changes for the Helm Chart versions 0.3.0 and 0.2.0 if you're planning to update from Helm Chart version 0.1.0. - -[id=0.3.0] -== Helm Chart Version: 0.3.0 - -Note that Helm Chart version `0.3.0` was the first release compatible with Infinite Scale 3.0.0 but contains no upgrade path from version `0.1.0` to `0.3.0`. Upgrading will be implemented in a subsequent release. - -* The following keys have been deprecated: + -`services.storageusers.storageBackend.driverConfig.s3ng.secretKey` and + - `services.storageusers.storageBackend.driverConfig.s3ng.accessKey` + -Please set them via the `secretRefs.s3CredentialsSecretRef` secret instead. - -* If you had set `services.web.config.disableFeedbackLink` = `true`, + -you need to replace it by: + -`services.web.config.feedbackLink.enabled` = `false`. - -* In order to persist the instance logo that can be changed via the Web UI, + -`services.web.persistence.enabled` must be set to `true`. + -In prior releases, the web frontend did not have any persistence. - -[id=0.2.0] -== Helm Chart Version: 0.2.0 - -Note that Helm Chart version `0.2.0` was a necessary intermediate for Infinite Scale `3.0.0-alpha.1` only and is listed for completeness of breaking changes. - -* Version `0.2.0` of the Helm Chart introduces some changes compared to version `0.1.0` with respect to the naming of Persistent Volume Claim names of the storageusers and storagesystem services. Updating from version `0.1.0` without manual update interventions will result in data loss. - -* Service/app names were aligned at various places (values file, YAML files, directories). - -[width=100%,cols="~,~",options=header] -|=== -| Old Value Name (0.1.0) -| New Value Name (0.2.0) - -| `configRefs.storageUsersConfigRef` -| `configRefs.storageusersConfigRef` - -| `secretRefs.storageSystemJwtSecretRef` -| `secretRefs.storagesystemJwtSecretRef` - -| `secretRefs.storageSystemSecretRef` -| `secretRefs.storagesystemSecretRef` - -| `services.appProvider` -| `services.appprovider` - -| `services.appRegistry` -| `services.appregistry` - -| `services.authBasic` -| `services.authbasic` - -| `services.authMachine` -| `services.authmachine` - -| `services.storagePublicLink` -| `services.storagepubliclink` - -| `services.storageShares` -| `services.storageshares` - -| `services.storageSystem` -| `services.storagesystem` - -| `services.storageUsers` -| `services.storageusers` -|=== - -[id=0.1.0] -== Helm Chart Version: 0.1.0 - -There are no breaking changes for this release. diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-1.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-1.adoc deleted file mode 100644 index ab88795b..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-1.adoc +++ /dev/null @@ -1,11 +0,0 @@ -= builtin-user-mgmt-secrets.yaml -:noindex: - -== Chart Version: {helm_tab_1_tab_text} - -// Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -[source,yaml] ----- -include::example$deployment/container/orchestration/builtin-user-mgmt-secrets-tab-1.yaml[] ----- diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-2.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-2.adoc deleted file mode 100644 index f9470f31..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-2.adoc +++ /dev/null @@ -1,11 +0,0 @@ -= builtin-user-mgmt-secrets.yaml -:noindex: - -== Chart Version: {helm_tab_2_tab_text} - -// Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -[source,yaml] ----- -include::example$deployment/container/orchestration/builtin-user-mgmt-secrets-tab-2.yaml[] ----- diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-3.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-3.adoc deleted file mode 100644 index 91901b97..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/builtin-user-mgmt-secrets-tab-3.adoc +++ /dev/null @@ -1,11 +0,0 @@ -= builtin-user-mgmt-secrets.yaml -:noindex: - -== Chart Version: {helm_tab_3_tab_text} - -// Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -[source,yaml] ----- -include::example$deployment/container/orchestration/builtin-user-mgmt-secrets-tab-3.yaml[] ----- diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-1.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-1.adoc deleted file mode 100644 index 48c886a1..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-1.adoc +++ /dev/null @@ -1,11 +0,0 @@ -= external-user-mgmt-secrets.yaml -:noindex: - -== Chart Version: {helm_tab_1_tab_text} - -// Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -[source,yaml] ----- -include::example$deployment/container/orchestration/external-user-mgmt-secrets-tab-1.yaml[] ----- diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-2.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-2.adoc deleted file mode 100644 index 5a207be4..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-2.adoc +++ /dev/null @@ -1,11 +0,0 @@ -= external-user-mgmt-secrets.yaml -:noindex: - -== Chart Version: {helm_tab_2_tab_text} - -// Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -[source,yaml] ----- -include::example$deployment/container/orchestration/external-user-mgmt-secrets-tab-2.yaml[] ----- diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-3.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-3.adoc deleted file mode 100644 index c99e6391..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/external-user-mgmt-secrets-tab-3.adoc +++ /dev/null @@ -1,11 +0,0 @@ -= external-user-mgmt-secrets.yaml -:noindex: - -== Chart Version: {helm_tab_3_tab_text} - -// Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -[source,yaml] ----- -include::example$deployment/container/orchestration/external-user-mgmt-secrets-tab-3.yaml[] ----- diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-1.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-1.adoc deleted file mode 100644 index 4a73804f..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-1.adoc +++ /dev/null @@ -1,18 +0,0 @@ -= values.yaml Description -:noindex: - -== Chart Version: {helm_tab_1_tab_text} - -//// -Note that this page is created because when the contents of the included table is big, the tab size would be too high and not comfortable to read. - -The source content comes from github. - -If there are xref's, these are resolved via an attribute defined in antora.yml - -This is an adoc table that gets included, not a yaml file. - -{ocis-charts-raw-url}{helm_tab_1}{values-desc-versions-url} -//// - -include::{ocis-charts-raw-url}{helm_tab_1}{values-desc-versions-url}[] diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-2.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-2.adoc deleted file mode 100644 index 430d7304..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-2.adoc +++ /dev/null @@ -1,18 +0,0 @@ -= values.yaml Description -:noindex: - -== Chart Version: {helm_tab_2_tab_text} - -//// -Note that this page is created because when the contents of the included table is big, the tab size would be too high and not comfortable to read. - -The source content comes from github. - -If there are xref's, these are resolved via an attribute defined in antora.yml - -This is an adoc table that gets included, not a yaml file. - -{ocis-charts-raw-url}{helm_tab_2}{values-desc-versions-url} -//// - -include::{ocis-charts-raw-url}{helm_tab_2}{values-desc-versions-url}[] diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-3.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-3.adoc deleted file mode 100644 index 74b16a33..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/val-desc-tab-3.adoc +++ /dev/null @@ -1,19 +0,0 @@ -= values.yaml Description -:noindex: - -== Chart Version: {helm_tab_3_tab_text} - -//// -Note that this page is created because when the contents of the included table is big, the tab size would be too high and not comfortable to read. - -The source content comes from github. - -If there are xref's, these are resolved via an attribute defined in antora.yml - -This is an adoc table that gets included, not a yaml file. - -{ocis-charts-raw-url}{helm_tab_3}{values-desc-versions-url} -//// - - -include::{ocis-charts-raw-url}{helm_tab_3}{values-desc-versions-url}[] diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-1.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-1.adoc deleted file mode 100644 index 3839ce10..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-1.adoc +++ /dev/null @@ -1,23 +0,0 @@ -= values.yaml -:noindex: - -== Chart Version: {helm_tab_1_tab_text} - -//// -Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -The source content comes from github. - -If there are xref's, these are resolved via an attribute defined in antora.yml - -{ocis-charts-raw-url}{helm_tab_1}{values-versions-url} - -We need to allow substitution of attributes first, then macros -//// - -Note, to improve readbility, syntax highlighting is used. A drawback is that links in comments are not clickable. See the xref:deployment/container/orchestration/tab-pages/val-desc-tab-1.adoc[Values Description] page where the links can be clicked. - -[source,yaml,subs="attributes+,+macros"] ----- -include::{ocis-charts-raw-url}{helm_tab_1}{values-versions-url}[] ----- diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-2.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-2.adoc deleted file mode 100644 index 6dfe7da6..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-2.adoc +++ /dev/null @@ -1,23 +0,0 @@ -= values.yaml -:noindex: - -== Chart Version: {helm_tab_2_tab_text} - -//// -Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -The source content comes from github. - -If there are xref's, these are resolved via an attribute defined in antora.yml - -{ocis-charts-raw-url}{helm_tab_2}{values-versions-url - -We need to allow substitution of attributes first, then macros -//// - -Note, to improve readbility, syntax highlighting is used. A drawback is that links in comments are not clickable. See the xref:deployment/container/orchestration/tab-pages/val-desc-tab-2.adoc[Values Description] page where the links can be clicked. - -[source,yaml,subs="attributes+,+macros"] ----- -include::{ocis-charts-raw-url}{helm_tab_2}{values-versions-url}[] ----- diff --git a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-3.adoc b/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-3.adoc deleted file mode 100644 index 97a8a843..00000000 --- a/modules/ROOT/pages/deployment/container/orchestration/tab-pages/values-tab-3.adoc +++ /dev/null @@ -1,23 +0,0 @@ -= values.yaml -:noindex: - -== Chart Version: {helm_tab_3_tab_text} - -//// -Note that this page is created because when the contents of the included yaml is big, the tab size would be too high and not comfortable to read. - -The source content comes from github. - -If there are xref's, these are resolved via an attribute defined in antora.yml - -{ocis-charts-raw-url}{helm_tab_3}{values-versions-url} - -We need to allow substitution of attributes first, then macros -//// - -Note, to improve readbility, syntax highlighting is used. A drawback is that, links in comments are not clickable. See the xref:deployment/container/orchestration/tab-pages/val-desc-tab-3.adoc[Values Description] page where the links can be clicked. - -[source,yaml,subs="attributes+,+macros"] ----- -include::{ocis-charts-raw-url}{helm_tab_3}{values-versions-url}[] -----