Merge pull request #1001 from EnterpriseDB/release/2021-02-26

Production Deploy: 2021-02-26 Former-commit-id: 581fd02
EnterpriseDB · Feb 26, 2021 · 32bec81 · 32bec81
2 parents a75206b + 64f6add
commit 32bec81
Show file tree

Hide file tree

Showing 292 changed files with 1,223 additions and 2,354 deletions.
diff --git a/.github/workflows/deploy-develop.yml b/.github/workflows/deploy-develop.yml
@@ -37,8 +37,6 @@ jobs:
         restore-keys: |
           ${{ runner.os }}-gatsby-build-develop-
 
-    - name: Pull sources
-      run: yarn pull-sources --force-build
     - name: Fix mtimes
       run: yarn fix-mtimes --force
     - name: Gatsby build

diff --git a/.github/workflows/deploy-main.yml b/.github/workflows/deploy-main.yml
@@ -37,8 +37,6 @@ jobs:
         restore-keys: |
           ${{ runner.os }}-gatsby-build-main-
 
-    - name: Pull sources
-      run: yarn pull-sources --force-build
     - name: Fix mtimes
       run: yarn fix-mtimes --force
     - name: Gatsby build

diff --git a/.gitignore b/.gitignore
@@ -75,7 +75,6 @@ __pycache__
 
 # Project specific
 dev-sources.json
-external_sources
 product_docs/content/*
 !product_docs/content/.keep
 product_docs/content_build/*

diff --git a/.gitmodules b/.gitmodules
@@ -1,3 +1,3 @@
 [submodule "static/edb-icons"]
 	path = static/edb-icons
-	url = https://edb-submodule-user:nMGifi48LiyofYrYkpjx78Bj7hQUWQXER494dyfHTDEx9UiMnK7WpovFVMpBJBxG@github.com/rocketinsights/edb-icons
+	url = https://edb-submodule-user:nMGifi48LiyofYrYkpjx78Bj7hQUWQXER494dyfHTDEx9UiMnK7WpovFVMpBJBxG@github.com/rocketinsights/edb-icons
diff --git a/README.md b/README.md
@@ -52,36 +52,22 @@ If you are a Windows user, you can work with Docs without installing it locally
 
   - For a list of these sources, see [product_docs/docs](https://github.com/EnterpriseDB/docs/tree/develop/product_docs/docs)
 
-- GitHub-Sourced Docs (entirety of `/external_sources` at present)
-
-  - [Kubernetes Docs](https://github.com/EnterpriseDB/edb-k8s-doc)
-  - [Barman](https://github.com/2ndquadrant-it/barman)
-  - [pgBackRest](https://github.com/EnterpriseDB/pgbackrest-docs)
-
 ### Configuring Which Sources are Loaded
 
 When doing local development of the site or advocacy content, you may want to load other sources to experience the full site. The more sources you load, the slower the site will build, so it's recommended to typically only load the content you'll be working with the most.
 
 #### `yarn config-sources`
 
-Run `yarn config-sources` to setup your `dev-sources.json` file. This file tells Gatsby which sources to load, and also provides the next script `yarn pull-sources` with the data it needs. The script is interactive!
+Run `yarn config-sources` to setup your `dev-sources.json` file. This file tells Gatsby which sources to load. The script is interactive!
 
 Alternatively, you can setup your `dev-sources.json` file manually by copying `dev-sources.sample` to `dev-sources.json`, and editing as desired. The sample file will source everything by default.
 
-If you select an "external" source, you will be prompted to run the next command, `yarn pull-sources`, to download and load this content from the internet.
-
-#### `yarn pull-sources`
-
-Use this command to pull down all the sources you have specified in your `dev-sources.json` file. **This will wipe all external sources**, so make sure you do not have any local changes to these files (in the `external_sources` subdirectory) that you want to save! The `/advocacy_docs` and `/product_docs` folders will not be affected.
-
 ### Types of Sources
 
 **Advocacy Docs** are tutorial content, getting-started material, and anything that is about a subject matter area, but not explicitly tied to a product version.
 
 **Product Docs** are versioned documentation for products. They follow a slightly stricter file structure to allow for version switching and other features.
 
-**GitHub Docs** are a low-touch way to display markdown content from GitHub. These docs will link back to the relavent GitHub url on each page, in order to provide any missing context.
-
 More details can be found on the [Adding New Sources](README_ADDING_NEW_SOURCES.md) page.
 
 ### Adding New Sources

diff --git a/README_ADDING_NEW_SOURCES.md b/README_ADDING_NEW_SOURCES.md
@@ -10,23 +10,15 @@ Advocacy Docs are tutorial content, getting-started material, and anything that
 ### Product Docs
 Product Docs are versioned documentation for products. They follow a slightly stricter file structure to allow for version switching and other features.
 
-### GitHub Docs
-GitHub Docs are a relatively low-touch way to display markdown content from GitHub. These docs are intended to link back to the relevant GitHub url on each page, in order to provide any missing context.
-
 ### Summary Table
 
-| Source Type   | Sourcing        | Versioned | External ** | Location
-|---------------|-----------------|-----------|-------------|-------------
-| Advocacy Docs | always loaded * | no        | no          | `advocacy_docs`
-| Product Docs  | configurable    | yes       | no          | `product_docs/docs`
-| GitHub Docs   | configurable    | no        | yes         | `external_sources` ***
+| Source Type   | Sourcing        | Versioned | Location
+|---------------|-----------------|-----------|-------------
+| Advocacy Docs | always loaded * | no        | `advocacy_docs`
+| Product Docs  | configurable    | yes       | `product_docs/docs`
 
 \* While Advocacy Docs are currently always loaded, this could be changed in the future as needed
 
-\** While currently only GitHub Docs are external, this is because no external docs currently conform to a structure that could be easily used as a Product Doc. As needed, we will add support for external Product Docs.
-
-\*** This will likely change, as it is intended that Product Docs could be optionally external in the future as well.
-
 ## 2. Structure the Markdown Files
 
 In general, the best way to get a sense of the required file/folder structure will be to look at existing examples. However, here is a brief overview of what is required for each source type.
@@ -53,21 +45,15 @@ Product Docs must confirm to a specific folder structing to enable version switc
 
 Once you're within the versioned directory, things should be structured like other source types.
 
-### External Sources
-
-If a doc is being sourced externally, it may not necessarilly be in the correct format that Gatsby expects. If you're adding an external source, see ***External Sources*** in the next section.
-
 ## 3. Update Sourcing Process
 
-If your new doc is a Product Doc or a GitHub Doc, you will need to update the sourcing process, as these source types are configurable. You can skip this section if you're adding a standard internal Advocacy Doc.
+If your new doc is a Product Doc, you will need to update the sourcing process, as this source type is configurable. You can skip this section if you're adding a standard Advocacy Doc.
 
 ### `config_sources.py`
 
 This is the script that is run when a user runs `yarn config-sources`. It will need to be edited to present your new option to the user, and to write the source name to `dev-sources.json`. **This source name should match the top level folder name for your doc!**
 
-If you're adding a Product Doc, you'll want to add your source name to `PRODUCT_DOCS`. If you're adding a GitHub Doc, you'll add your source name to `BASE_OUTPUT` directly.
-
-Next, you'll need to add your source to `OPTIONS`. New Product Docs should be inserted at the end of the current product doc listings, and new GitHub Docs should be added at the end of `OPTIONS`. If your doc is sourced externally, be sure to set the `external: True` option.
+If you're adding a Product Doc, you'll want to add your source name to `PRODUCT_DOCS`. Next, you'll need to add your source to `OPTIONS`. New Product Docs should be inserted at the end of the current product doc listings.
 
 Once you've made your changes, run `yarn config-sources` and confirm that the output in `dev-sources.json` is as expected.
 
@@ -89,15 +75,7 @@ This sample file should also be updated with your new source key, for those who
 
 If the source requires something different than previous sources have, or if there is something different about your source that we have not previously supported, it is likely some changes will need to be made in `gatsby-node.js`.
 
-### External Sources
-
-If you are bringing in an external source, you will need to write scripts that download your source, and convert it to the necessary format for your chosen source type. This will require creating `source_[SOURCE_NAME].py` script in `scripts/source`, and connecting it to `pull_sources.py`. Your sourcing script needs to accomplish everything necessary for Gatsby to load the files successfully, including format translation and any other necessary changes.
-
-## 4. Update the Index Navigation
-
-The navigation links on the side of the index page will need to be updated to link to your new source. Within `src/constants/index-navigation.js`, you'll need to edit the `rawIndexNavigation` json to add your source. The structure should be fairly apparent. If your source is configurable (IE it's not an Advocacy Doc), you should set the `source` key equal to whatever your source name is. This will tell Gatsby to only should this link if your source is loaded.
-
-## 5. You're Hopefully Done!
+### 4. You're Hopefully Done!
 
 At this point, you should have your new source integrated in the site!
 
diff --git a/advocacy_docs/kubernetes/cloud_native_operator/api_reference.mdx b/advocacy_docs/kubernetes/cloud_native_operator/api_reference.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'API Reference'
 originalFilePath: 'src/api_reference.md'
+product: 'Cloud Native Operator'
 ---
 
-
 Cloud Native PostgreSQL extends the Kubernetes API defining the following
 custom resources:
 

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/architecture.mdx b/advocacy_docs/kubernetes/cloud_native_operator/architecture.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Architecture'
 originalFilePath: 'src/architecture.md'
+product: 'Cloud Native Operator'
 ---
 
-
 For High Availability goals, the PostgreSQL database management system provides administrators with built-in **physical replication** capabilities based on **Write Ahead Log (WAL) shipping**.
 
 PostgreSQL supports both asynchronous and synchronous streaming replication, as well as asynchronous file-based log shipping (normally used as a fallback option, for example, to store WAL files in an object store). Replicas are usually called *standby servers* and can also be used for read-only workloads, thanks to the *Hot Standby* feature.

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/backup_recovery.mdx b/advocacy_docs/kubernetes/cloud_native_operator/backup_recovery.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Backup and Recovery'
 originalFilePath: 'src/backup_recovery.md'
+product: 'Cloud Native Operator'
 ---
 
-
 The operator can orchestrate a continuous backup infrastructure
 that is based on the [Barman](https://pgbarman.org) tool. Instead
 of using the classical architecture with a Barman server, which

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/before_you_start.mdx b/advocacy_docs/kubernetes/cloud_native_operator/before_you_start.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Before You Start'
 originalFilePath: 'src/before_you_start.md'
+product: 'Cloud Native Operator'
 ---
 
-
 Before we get started, it is essential to go over some terminology that is
 specific to Kubernetes and PostgreSQL.
 

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/bootstrap.mdx b/advocacy_docs/kubernetes/cloud_native_operator/bootstrap.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Bootstrap'
 originalFilePath: 'src/bootstrap.md'
+product: 'Cloud Native Operator'
 ---
 
-
 This section describes the options you have to create a new
 PostgreSQL cluster and the design rationale behind them.
 

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/cloud_setup.mdx b/advocacy_docs/kubernetes/cloud_native_operator/cloud_setup.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Cloud Setup'
 originalFilePath: 'src/cloud_setup.md'
+product: 'Cloud Native Operator'
 ---
 
-
 This section describes how to orchestrate the deployment and management
 of a PostgreSQL High Availability cluster in a [Kubernetes](https://www.kubernetes.io/) cluster in the public cloud using
 [CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/container_images.mdx b/advocacy_docs/kubernetes/cloud_native_operator/container_images.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Container Image Requirements'
 originalFilePath: 'src/container_images.md'
+product: 'Cloud Native Operator'
 ---
 
-
 The Cloud Native PostgreSQL operator for Kubernetes is designed to
 work with any compatible container image of PostgreSQL that complies
 with the following requirements:

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/credits.mdx b/advocacy_docs/kubernetes/cloud_native_operator/credits.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Credits'
 originalFilePath: 'src/credits.md'
+product: 'Cloud Native Operator'
 ---
 
-
 Cloud Native PostgreSQL (Operator for Kubernetes/OpenShift) has been designed,
 developed, and tested by the EnterpriseDB Cloud Native team:
 

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/e2e.mdx b/advocacy_docs/kubernetes/cloud_native_operator/e2e.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'End-to-End Tests'
 originalFilePath: 'src/e2e.md'
+product: 'Cloud Native Operator'
 ---
 
-
 Cloud Native PostgreSQL operator is automatically tested after each
 commit via a suite of **End-to-end (E2E) tests**. It ensures that
 the operator correctly deploys and manages the PostgreSQL clusters.

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/evaluation.mdx b/advocacy_docs/kubernetes/cloud_native_operator/evaluation.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Free evaluation'
 originalFilePath: 'src/evaluation.md'
+product: 'Cloud Native Operator'
 ---
 
-
 Cloud Native PostgreSQL is available for a free evaluation.
 The process is different between Vanilla/Community PostgreSQL
 and EDB Postgres Advanced.

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/expose_pg_services.mdx b/advocacy_docs/kubernetes/cloud_native_operator/expose_pg_services.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Exposing Postgres Services'
 originalFilePath: 'src/expose_pg_services.md'
+product: 'Cloud Native Operator'
 ---
 
-
 This section explains how to expose a PostgreSQL service externally, allowing access
 to your PostgreSQL database **from outside your Kubernetes cluster** using
 NGINX Ingress Controller.

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/failure_modes.mdx b/advocacy_docs/kubernetes/cloud_native_operator/failure_modes.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Failure Modes'
 originalFilePath: 'src/failure_modes.md'
+product: 'Cloud Native Operator'
 ---
 
-
 This section provides an overview of the major failure scenarios that
 PostgreSQL can face on a Kubernetes cluster during its lifetime.
 

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/index.mdx b/advocacy_docs/kubernetes/cloud_native_operator/index.mdx
@@ -1,9 +1,11 @@
 ---
 title: 'Cloud Native PostgreSQL'
 originalFilePath: 'src/index.md'
+product: 'Cloud Native Operator'
 indexCards: none
 directoryDefaults:
   prevNext: true
+  iconName: kubernetes
 
 navigation:
   - index
@@ -34,7 +36,6 @@ navigation:
 
 ---
 
-
 **Cloud Native PostgreSQL** is an [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/)
 designed by [EnterpriseDB](https://www.enterprisedb.com)
 to manage [PostgreSQL](https://www.postgresql.org/) workloads on any supported [Kubernetes](https://kubernetes.io)

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/installation.mdx b/advocacy_docs/kubernetes/cloud_native_operator/installation.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Installation'
 originalFilePath: 'src/installation.md'
+product: 'Cloud Native Operator'
 ---
 
-
 ## Installation on Kubernetes
 
 The operator can be installed like any other resource in Kubernetes,

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/kubernetes_upgrade.mdx b/advocacy_docs/kubernetes/cloud_native_operator/kubernetes_upgrade.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Kubernetes Upgrade'
 originalFilePath: 'src/kubernetes_upgrade.md'
+product: 'Cloud Native Operator'
 ---
 
-
 Kubernetes clusters must be kept updated. This becomes even more
 important if you are self-managing your Kubernetes clusters, especially
 on **bare metal**.

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/license_keys.mdx b/advocacy_docs/kubernetes/cloud_native_operator/license_keys.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'License and License Keys'
 originalFilePath: 'src/license_keys.md'
+product: 'Cloud Native Operator'
 ---
 
-
 Each `Cluster` resource has a `licenseKey` parameter in its definition.
 
 A `licenseKey` is always required for the operator to work.

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/operator_capability_levels.mdx b/advocacy_docs/kubernetes/cloud_native_operator/operator_capability_levels.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Operator Capability Levels'
 originalFilePath: 'src/operator_capability_levels.md'
+product: 'Cloud Native Operator'
 ---
 
-
 This section provides a summary of the capabilities implemented by Cloud Native PostgreSQL,
 classified using the
 ["Operator SDK definition of Capability Levels"](https://sdk.operatorframework.io/docs/advanced-topics/operator-capabilities/operator-capabilities/)

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/postgresql_conf.mdx b/advocacy_docs/kubernetes/cloud_native_operator/postgresql_conf.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'PostgreSQL Configuration'
 originalFilePath: 'src/postgresql_conf.md'
+product: 'Cloud Native Operator'
 ---
 
-
 Users that are familiar with PostgreSQL are aware of the existence of the following two files
 to configure an instance:
 

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/quickstart.mdx b/advocacy_docs/kubernetes/cloud_native_operator/quickstart.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Quickstart'
 originalFilePath: 'src/quickstart.md'
+product: 'Cloud Native Operator'
 ---
 
-
 This section describes how to test a PostgreSQL cluster on your laptop/computer
 using Cloud Native PostgreSQL on a local Kubernetes cluster in
 [Minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/) or

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/rolling_update.mdx b/advocacy_docs/kubernetes/cloud_native_operator/rolling_update.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Rolling Updates'
 originalFilePath: 'src/rolling_update.md'
+product: 'Cloud Native Operator'
 ---
 
-
 The operator allows changing the PostgreSQL version used in a cluster while
 applications are running against it.
 

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/samples.mdx b/advocacy_docs/kubernetes/cloud_native_operator/samples.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Configuration Samples'
 originalFilePath: 'src/samples.md'
+product: 'Cloud Native Operator'
 ---
 
-
 In this section, you can find some examples of configuration files to set up your PostgreSQL `Cluster`.
 
 * [`cluster-example.yaml`](../samples/cluster-example.yaml):

diff --git a/advocacy_docs/kubernetes/cloud_native_operator/security.mdx b/advocacy_docs/kubernetes/cloud_native_operator/security.mdx
@@ -1,9 +1,9 @@
 ---
 title: 'Security'
 originalFilePath: 'src/security.md'
+product: 'Cloud Native Operator'
 ---
 
-
 This section contains information about security for Cloud Native PostgreSQL,
 from a few standpoints: source code, Kubernetes, and PostgreSQL.