use h1 tags to not render titles in sidebar (#626)

This commit is contained in:
Felix Kunde 2019-07-19 12:50:39 +02:00 committed by GitHub
parent 2c3c7fd244
commit 0aff809958
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
12 changed files with 38 additions and 39 deletions

View File

@ -1,4 +1,4 @@
# Administrator Guide
<h1>Administrator Guide</h1>
Learn how to configure and manage the Postgres Operator in your Kubernetes (K8s)
environment.

View File

@ -1,4 +1,4 @@
# Developer Guide
<h1>Developer Guide</h1>
Read this guide if you want to debug the operator, fix bugs or contribute new
features and tests.

View File

@ -1,18 +1,17 @@
<h1>Google Summer of Code 2019</h1>
# Google Summer of Code 2019
## Applications steps
## Applications steps
1. Please carefully read the official [Google Summer of Code Student Guide](https://google.github.io/gsocguides/student/)
1. Please carefully read the official [Google Summer of Code Student Guide](https://google.github.io/gsocguides/student/)
2. Join the #postgres-operator slack channel under [Postgres Slack](https://postgres-slack.herokuapp.com) to introduce yourself to the community and get quick feedback on your application.
3. Select a project from the list of ideas below or propose your own.
4. Write a proposal draft. Please open an issue with the label `gsoc2019_application` in the [operator repository](https://github.com/zalando/postgres-operator/issues) so that the community members can publicly review it. See proposal instructions below for details.
5. Submit proposal and the proof of enrollment before April 9 2019 18:00 UTC through the web site of the Program.
## Project ideas
## Project ideas
### Place database pods into the "Guaranteed" Quality-of-Service class
### Place database pods into the "Guaranteed" Quality-of-Service class
* **Description**: Kubernetes runtime does not kill pods in this class on condition they stay within their resource limits, which is desirable for the DB pods serving production workloads. To be assigned to that class, pod's resources must equal its limits. The task is to add the `enableGuaranteedQoSClass` or the like option to the Postgres manifest and the operator configmap that forcibly re-write pod resources to match the limits.
* **Recommended skills**: golang, basic Kubernetes abstractions
@ -21,7 +20,7 @@
### Implement the kubectl plugin for the Postgres CustomResourceDefinition
* **Description**: [kubectl plugins](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/) enable extending the Kubernetes command-line client `kubectl` with commands to manage custom resources. The task is to design and implement a plugin for the `kubectl postgres` command,
* **Description**: [kubectl plugins](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/) enable extending the Kubernetes command-line client `kubectl` with commands to manage custom resources. The task is to design and implement a plugin for the `kubectl postgres` command,
that can enable, for example, correct deletion or major version upgrade of Postgres clusters.
* **Recommended skills**: golang, shell scripting, operational experience with Kubernetes
* **Difficulty**: moderate to medium, depending on the plugin design
@ -29,36 +28,36 @@ that can enable, for example, correct deletion or major version upgrade of Postg
### Implement the openAPIV3Schema for the Postgres CRD
* **Description**: at present the operator validates a database manifest on its own.
* **Description**: at present the operator validates a database manifest on its own.
It will be helpful to reject erroneous manifests before they reach the operator using the [native Kubernetes CRD validation](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#validation). It is up to the student to decide whether to write the schema manually or to adopt existing [schema generator developed for the Prometheus project](https://github.com/ant31/crd-validation).
* **Recommended skills**: golang, JSON schema
* **Difficulty**: medium
* **Mentor(s)**: Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Mentor(s)**: Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Issue**: [#388](https://github.com/zalando/postgres-operator/issues/388)
### Design a solution for the local testing of the operator
* **Description**: The current way of testing is to run minikube, either manually or with some tooling around it like `/run-operator_locally.sh` or Vagrant. This has at least three problems:
First, minikube is a single node cluster, so it is unsuitable for testing vital functions such as pod migration between nodes. Second, minikube starts slowly; that prolongs local testing.
First, minikube is a single node cluster, so it is unsuitable for testing vital functions such as pod migration between nodes. Second, minikube starts slowly; that prolongs local testing.
Third, every contributor needs to come up with their own solution for local testing. The task is to come up with a better option which will enable us to conveniently and uniformly run e2e tests locally / potentially in Travis CI.
A promising option is the Kubernetes own [kind](https://github.com/kubernetes-sigs/kind)
* **Recommended skills**: Docker, shell scripting, basic Kubernetes abstractions
* **Difficulty**: medium to hard depending on the selected desing
* **Mentor(s)**: Dmitry Dolgov [@erthalion](https://github.com/erthalion), Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Mentor(s)**: Dmitry Dolgov [@erthalion](https://github.com/erthalion), Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Issue**: [#475](https://github.com/zalando/postgres-operator/issues/475)
### Detach a Postgres cluster from the operator for maintenance
* **Description**: sometimes a Postgres cluster requires manual maintenance. During such maintenance the operator should ignore all the changes manually applied to the cluster.
Currently the only way to achieve this behavior is to shutdown the operator altogether, for instance by scaling down the operator's own deployment to zero pods. That approach evidently affects all Postgres databases under the operator control and thus is highly undesirable in production Kubernetes clusters. It would be much better to be able to detach only the desired Postgres cluster from the operator for the time being and re-attach it again after maintenance.
* **Description**: sometimes a Postgres cluster requires manual maintenance. During such maintenance the operator should ignore all the changes manually applied to the cluster.
Currently the only way to achieve this behavior is to shutdown the operator altogether, for instance by scaling down the operator's own deployment to zero pods. That approach evidently affects all Postgres databases under the operator control and thus is highly undesirable in production Kubernetes clusters. It would be much better to be able to detach only the desired Postgres cluster from the operator for the time being and re-attach it again after maintenance.
* **Recommended skills**: golang, architecture of a Kubernetes operator
* **Difficulty**: hard - requires significant modification of the operator's internals and careful consideration of the corner cases.
* **Mentor(s)**: Dmitry Dolgov [@erthalion](https://github.com/erthalion), Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Mentor(s)**: Dmitry Dolgov [@erthalion](https://github.com/erthalion), Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Issue**: [#421](https://github.com/zalando/postgres-operator/issues/421)
### Propose your own idea
Feel free to come up with your own ideas. For inspiration,
see [our bug tracker](https://github.com/zalando/postgres-operator/issues),
the [official `CustomResouceDefinition` docs](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
and [other operators](https://github.com/operator-framework/awesome-operators).
Feel free to come up with your own ideas. For inspiration,
see [our bug tracker](https://github.com/zalando/postgres-operator/issues),
the [official `CustomResouceDefinition` docs](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
and [other operators](https://github.com/operator-framework/awesome-operators).

View File

@ -1,4 +1,4 @@
# Concepts
<h1>Concepts</h1>
The Postgres [operator](https://coreos.com/blog/introducing-operators.html)
manages PostgreSQL clusters on Kubernetes (K8s):

View File

@ -1,4 +1,4 @@
# Postgres Operator UI
<h1>Postgres Operator UI</h1>
The Postgres Operator UI provides a graphical interface for a convenient
database-as-a-service user experience. Once the operator is set up by database

View File

@ -1,4 +1,4 @@
# Quickstart
<h1>Quickstart</h1>
This guide aims to give you a quick look and feel for using the Postgres
Operator on a local Kubernetes environment.
@ -55,7 +55,7 @@ kubectl create -f manifests/postgres-operator.yaml # deployment
```
There is a [Kustomization](https://github.com/kubernetes-sigs/kustomize)
manifest that [combines the mentioned resources](../manifests/kustomization.yaml) -
manifest that [combines the mentioned resources](../manifests/kustomization.yaml) -
it can be used with kubectl 1.14 or newer as easy as:
```bash

View File

@ -1,4 +1,4 @@
# Cluster manifest reference
<h1>Cluster manifest reference</h1>
Individual Postgres clusters are described by the Kubernetes *cluster manifest*
that has the structure defined by the `postgresql` CRD (custom resource

View File

@ -28,7 +28,7 @@ flags](https://godoc.org/github.com/golang/glog) are also supported. For
instance, one may want to add `-alsologtostderr` and `-v=8` to debug the
operator REST calls.
## Environment variables
# Environment variables
The following environment variables are accepted by the operator:

View File

@ -1,4 +1,4 @@
# Configuration parameters
<h1>Configuration parameters</h1>
There are two mutually-exclusive methods to set the Postgres Operator
configuration.

View File

@ -1,4 +1,4 @@
# User Guide
<h1>User Guide</h1>
Learn how to work with the Postgres Operator in a Kubernetes (K8s) environment.

View File

@ -29,10 +29,9 @@ spec:
runAsNonRoot: true
readOnlyRootFilesystem: true
env:
# provided additional ENV vars can overwrite individual config map entries
# provided additional ENV vars can overwrite individual config map entries
- name: CONFIG_MAP_NAME
value: "postgres-operator"
# In order to use the CRD OperatorConfiguration instead, uncomment these lines and comment out the two lines above
# - name: POSTGRES_OPERATOR_CONFIGURATION_OBJECT
# value: postgresql-operator-default-configuration

View File

@ -3,13 +3,14 @@ repo_url: https://github.com/zalando/postgres-operator
theme: readthedocs
nav:
- index.md
- quickstart.md
- operator-ui.md
- administrator.md
- user.md
- developer.md
- Concepts: 'index.md'
- Quickstart: 'quickstart.md'
- Postgres Operator UI: 'operator-ui.md'
- Admin guide: 'administrator.md'
- User guide: 'user.md'
- Developer guide: 'developer.md'
- Reference:
- reference/operator_parameters.md
- reference/cluster_manifest.md
- reference/command_line_and_environment.md
- Config parameters: 'reference/operator_parameters.md'
- Manifest parameters: 'reference/cluster_manifest.md'
- CLI options and environment: 'reference/command_line_and_environment.md'
- Google Summer of Code 2019: 'gsoc-2019/ideas.md'