v1.5.0-rc.1 release (#2921)
* v1.5.0-rc.1 release Signed-off-by: Carlisia <carlisia@vmware.com> * Reviews Signed-off-by: Carlisia <carlisia@vmware.com> * Re-generate docs Signed-off-by: Carlisia <carlisia@vmware.com>pull/2896/head v1.5.0-rc.1
parent
543678140b
commit
b60e6ff21e
|
@ -1,11 +1,11 @@
|
|||
## v1.5.0-beta.1
|
||||
### 2020-08-21
|
||||
## v1.5.0-rc.1
|
||||
### 2020-09-09
|
||||
|
||||
### Download
|
||||
https://github.com/vmware-tanzu/velero/releases/tag/v1.5.0-beta.1
|
||||
https://github.com/vmware-tanzu/velero/releases/tag/v1.5.0-rc.1
|
||||
|
||||
### Container Image
|
||||
`velero/velero:v1.5.0-beta.1`
|
||||
`velero/velero:v1.5.0-rc.1`
|
||||
|
||||
### Documentation
|
||||
https://velero.io/docs/v1.5-pre/
|
||||
|
@ -18,22 +18,29 @@ https://velero.io/docs/v1.5-pre/upgrade-to-1.5/
|
|||
* Auto Volume Backup Using Restic with `--default-volumes-to-restic` flag
|
||||
* DeleteItemAction plugins
|
||||
* Code modernization
|
||||
* Sneak preview - restore hooks using init containers
|
||||
* Restore Hooks: InitContianer Restore Hooks and Exec Restore Hooks
|
||||
|
||||
### All Changes
|
||||
|
||||
* Use format version instead of version on `velero backup describe` since version has been deprecated (#2901, @jenting)
|
||||
* Implement post-restore exec hooks in pod containers (#2804, @areed)
|
||||
* rename the PV if VolumeSnapshotter has modified the PV name (#2835, @pawanpraka1)
|
||||
* fix EnableAPIGroupersions output log format (#2882, @jenting)
|
||||
* Convert ServerStatusRequest controller to kubebuilder (#2838, @carlisia)
|
||||
* Check for errors on restic backup command (#2863, @dymurray)
|
||||
* 🐛 fix passing LDFLAGS across build stages (#2853, @ashish-amarnath)
|
||||
* Feature: Invoke DeleteItemAction plugins based on backup contents when a backup is deleted. (#2815, @nrb)
|
||||
* When JSON logging format is enabled, place error message at "error.message" instead of "error" for compatibility with Elasticsearch/ELK and the Elastic Common Schema (#2830, @bgagnon)
|
||||
* discovery Helper support get GroupVersionResource and an APIResource from GroupVersionKind (#2764, @runzexia)
|
||||
* Migrate site from Jekyll to Hugo (#2720, @tbatard)
|
||||
* Add the DeleteItemAction plugin type (#2808, @nrb)
|
||||
* discovery Helper support get GroupVersionResource and an APIResource from GroupVersionKind (#2764, @runzexia)
|
||||
* 🐛 Manually patch the generated yaml for restore CRD as a hacky workaround (#2814, @ashish-amarnath)
|
||||
* Pass default-volumes-to-restic flag from create schedule to backup (#2776, @ashish-amarnath)
|
||||
* Enhance Backup to support backing up resources in specific orders and add --ordered-resources option to support this feature. (#2724, @phuong)
|
||||
* Migrate site from Jekyll to Hugo (#2720, @tbatard)
|
||||
* Setup crd validation github action on k8s versions (#2805, @ashish-amarnath)
|
||||
* 🐛 Supply command to run restic-wait init container (#2802, @ashish-amarnath)
|
||||
* Make init and exec restore hooks as optional in restore hookSpec (#2793, @ashish-amarnath)
|
||||
* Implement restore hooks injecting init containers into pod spec (#2787, @ashish-amarnath)
|
||||
* Pass default-volumes-to-restic flag from create schedule to backup (#2776, @ashish-amarnath)
|
||||
* Enhance Backup to support backing up resources in specific orders and add --ordered-resources option to support this feature. (#2724, @phuong)
|
||||
* Fix inconsistent type for the "resource" structured logging field (#2796, @bgagnon)
|
||||
* Add the ability to set the allowPrivilegeEscalation flag in the securityContext for the Restic restore helper. (#2792, @doughepi)
|
||||
* Add cacert flag for velero backup-location create (#2778, @jenting)
|
||||
|
@ -42,28 +49,34 @@ https://velero.io/docs/v1.5-pre/upgrade-to-1.5/
|
|||
* Add wait group and error channel for restore hooks to restore context. (#2755, @areed)
|
||||
* Refactor image builds to use buildx for multi arch image building (#2754, @robreus)
|
||||
* Add annotation key constants for restore hooks (#2750, @ashish-amarnath)
|
||||
* Adds Start and CompletionTimestamp to RestoreStatus. Displays the Timestamps when issued a print or describe (#2748, @thejasbabu)
|
||||
* Adds Start and CompletionTimestamp to RestoreStatus
|
||||
Displays the Timestamps when issued a print or describe (#2748, @thejasbabu)
|
||||
* Move pkg/backup/item_hook_handlers.go to internal/hook (#2734, @nrb)
|
||||
* add metrics for restic back up operation (#2719, @ashish-amarnath)
|
||||
* StorageGrid compatibility by removing explicit gzip accept header setting (#2712, @fvsqr)
|
||||
* restic: add support for setting SecurityContext (runAsUser, runAsGroup) for restore (#2621, @jaygridley)
|
||||
* Add backupValidationFailureTotal to metrics (#2714, @kathpeony)
|
||||
* Convert manifests + BSL api client to kubebuilder (#2561, @carlisia)
|
||||
* Add linter checks to Makefile (#2615, @tbatard)
|
||||
* improve builder image handling so that we don't rebuild each `make shell`
|
||||
first check if there are pending changed on the build-image dockerfile if so build it.
|
||||
then check if there is an image in the registry if so pull it.
|
||||
then build an image cause we don't have a cached image. (this handles the backward compat case.)
|
||||
fix make clean to clear go mod cache before removing dirs (for containerized builds) (#2620, @mauilion)
|
||||
* bump Kubernetes module dependencies to v0.18.4 to fix https://github.com/vmware-tanzu/velero/issues/2540 by adding code compatibility with kubernetes v1.18 (#2651, @laverya)
|
||||
* Add a BSL controller to handle validation + update BSL status phase (validation removed from the server and no longer blocks when there's any invalid BSL) (#2674, @carlisia)
|
||||
* updated acceptable values on cron schedule from 0-7 to 0-6 (#2676, @dthrasher)
|
||||
* Improve velero download doc (#2660, @carlisia)
|
||||
* Update basic-install and release-instructions documentation for Windows Chocolatey package (#2638, @adamrushuk)
|
||||
* Add backupValidationFailureTotal to metrics (#2714, @kathpeony)
|
||||
* move CSI plugin out of prototype into beta (#2636, @ashish-amarnath)
|
||||
* Add a new supported provider for an object storage plugin for Storj (#2635, @jessicagreben)
|
||||
* Update basic-install.md documentation: Add windows cli installation option via chocolatey (#2629, @adamrushuk)
|
||||
* Documentation: Update Jekyll to 4.1.0. Switch from redcarpet to kramdown for Markdown renderer (#2625, @tbatard)
|
||||
* improve builder image handling so that we don't rebuild each `make shell`. first check if there are pending changed on the build-image dockerfile if so build it. then check if there is an image in the registry if so pull it. then build an image cause we don't have a cached image. (this handles the backward compat case.). fix make clean to clear go mod cache before removing dirs (for containerized builds) (#2620, @mauilion)
|
||||
* Add linter checks to Makefile (#2615, @tbatard)
|
||||
* add a CI check for a changelog file (#2613, @ashish-amarnath)
|
||||
* implement option to back up all volumes by default with restic (#2611, @ashish-amarnath)
|
||||
* When a timeout string can't be parsed, log the error as a warning instead of silently consuming the error. (#2610, @nrb)
|
||||
* Azure: support using `aad-pod-identity` auth when using restic (#2602, @skriss)
|
||||
* Improve velero download doc (#2660, @carlisia)
|
||||
* log a warning instead of erroring if an additional item returned from a plugin can't be found in the Kubernetes API (#2595, @skriss)
|
||||
* when creating new backup from schedule from cli, allow backup name to be automatically generated (#2569, @cblecker)
|
||||
* Convert manifests + BSL api client to kubebuilder (#2561, @carlisia)
|
||||
* Azure: support using `aad-pod-identity` auth when using restic (#2602, @skriss)
|
||||
* When a timeout string can't be parsed, log the error as a warning instead of silently consuming the error. (#2610, @nrb)
|
||||
* implement option to back up all volumes by default with restic (#2611, @ashish-amarnath)
|
||||
* add a CI check for a changelog file (#2613, @ashish-amarnath)
|
||||
* Documentation: Update Jekyll to 4.1.0
|
||||
* Switch from redcarpet to kramdown for Markdown renderer (#2625, @tbatard)
|
||||
* Update basic-install.md documentation: Add windows cli installation option via chocolatey (#2629, @adamrushuk)
|
||||
* Add a new supported provider for an object storage plugin for Storj (#2635, @jessicagreben)
|
||||
* Update basic-install and release-instructions documentation for Windows Chocolatey package (#2638, @adamrushuk)
|
||||
* backup/restore: reinstantiate backup store just before uploading artifacts to ensure credentials are up-to-date (#2550, @skriss)
|
||||
* when creating new backup from schedule from cli, allow backup name to be automatically generated (#2569, @cblecker)
|
||||
|
|
|
@ -15,7 +15,7 @@ params:
|
|||
latest: v1.4
|
||||
versions:
|
||||
- main
|
||||
- v1.5-pre
|
||||
- v1.5.0-rc.1
|
||||
- v1.4
|
||||
- v1.3.2
|
||||
- v1.3.1
|
||||
|
|
|
@ -1,317 +0,0 @@
|
|||
---
|
||||
title: "Documentation Style Guide"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
_This style guide is adapted from the [Kubernetes style guide](https://kubernetes.io/docs/contribute/style/style-guide/)._
|
||||
|
||||
This page outlines writing style guidelines for the Velero documentation and you should use this page as a reference you write or edit content. Note that these are guidelines, not rules. Use your best judgment as you write documentation, and feel free to propose changes to these guidelines. Changes to the style guide are made by the Velero maintainers as a group. To propose a change or addition create an issue/PR, or add a suggestion to the [community meeting agenda](https://hackmd.io/Jq6F5zqZR7S80CeDWUklkA) and attend the meeting to participate in the discussion.
|
||||
|
||||
The Velero documentation uses the [kramdown](https://kramdown.gettalong.org/) Markdown renderer.
|
||||
|
||||
## Content best practices
|
||||
|
||||
|
||||
### Use present tense
|
||||
|
||||
<table caption="Do and Don't - Use present tense">
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>This `command` starts a proxy.</td><td>This command will start a proxy.</td></tr>
|
||||
</table>
|
||||
|
||||
Exception: Use future or past tense if it is required to convey the correct meaning.
|
||||
|
||||
### Use active voice
|
||||
|
||||
<table caption="Do and Don't - Use active voice" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>You can explore the API using a browser.</td><td>The API can be explored using a browser.</td></tr>
|
||||
<tr><td>The YAML file specifies the replica count.</td><td>The replica count is specified in the YAML file.</td></tr>
|
||||
</table>
|
||||
|
||||
Exception: Use passive voice if active voice leads to an awkward sentence construction.
|
||||
|
||||
### Use simple and direct language
|
||||
|
||||
Use simple and direct language. Avoid using unnecessary phrases, such as saying "please."
|
||||
|
||||
<table caption="Do and Don't - Use simple and direct language" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>To create a ReplicaSet, ...</td><td>In order to create a ReplicaSet, ...</td></tr>
|
||||
<tr><td>See the configuration file.</td><td>Please see the configuration file.</td></tr>
|
||||
<tr><td>View the Pods.</td><td>With this next command, we'll view the Pods.</td></tr>
|
||||
</table>
|
||||
|
||||
### Address the reader as "you"
|
||||
|
||||
<table caption="Do and Don't - Addressing the reader" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>You can create a Deployment by ...</td><td>We'll create a Deployment by ...</td></tr>
|
||||
<tr><td>In the preceding output, you can see...</td><td>In the preceding output, we can see ...</td></tr>
|
||||
</table>
|
||||
|
||||
### Avoid Latin phrases
|
||||
|
||||
Prefer English terms over Latin abbreviations.
|
||||
|
||||
<table caption="Do and Don't - Avoid Latin phrases" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>For example, ...</td><td>e.g., ...</td></tr>
|
||||
<tr><td>That is, ...</td><td>i.e., ...</td></tr>
|
||||
</table>
|
||||
|
||||
Exception: Use "etc." for et cetera.
|
||||
|
||||
## Patterns to avoid
|
||||
|
||||
|
||||
### Avoid using "we"
|
||||
|
||||
Using "we" in a sentence can be confusing, because the reader might not know
|
||||
whether they're part of the "we" you're describing.
|
||||
|
||||
<table caption="Do and Don't - Patterns to avoid" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Version 1.4 includes ...</td><td>In version 1.4, we have added ...</td></tr>
|
||||
<tr><td>Kubernetes provides a new feature for ...</td><td>We provide a new feature ...</td></tr>
|
||||
<tr><td>This page teaches you how to use Pods.</td><td>In this page, we are going to learn about Pods.</td></tr>
|
||||
</table>
|
||||
|
||||
### Avoid jargon and idioms
|
||||
|
||||
Many readers speak English as a second language. Avoid jargon and idioms to help them understand better.
|
||||
|
||||
<table caption="Do and Don't - Avoid jargon and idioms" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Internally, ...</td><td>Under the hood, ...</td></tr>
|
||||
<tr><td>Create a new cluster.</td><td>Turn up a new cluster.</td></tr>
|
||||
</table>
|
||||
|
||||
### Avoid statements about the future
|
||||
|
||||
Avoid making promises or giving hints about the future. If you need to talk about
|
||||
a beta feature, put the text under a heading that identifies it as beta
|
||||
information.
|
||||
|
||||
### Avoid statements that will soon be out of date
|
||||
|
||||
Avoid words like “recently”, "currently" and "new." A feature that is new today might not be
|
||||
considered new in a few months.
|
||||
|
||||
<table caption="Do and Don't - Avoid statements that will soon be out of date" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>In version 1.4, ...</td><td>In the current version, ...</td></tr>
|
||||
<tr><td>The Federation feature provides ...</td><td>The new Federation feature provides ...</td></tr>
|
||||
</table>
|
||||
|
||||
### Language
|
||||
|
||||
This documentation uses U.S. English spelling and grammar.
|
||||
|
||||
## Documentation formatting standards
|
||||
|
||||
|
||||
### Use camel case for API objects
|
||||
|
||||
When you refer to an API object, use the same uppercase and lowercase letters
|
||||
that are used in the actual object name. Typically, the names of API
|
||||
objects use
|
||||
[camel case](https://en.wikipedia.org/wiki/Camel_case).
|
||||
|
||||
Don't split the API object name into separate words. For example, use
|
||||
PodTemplateList, not Pod Template List.
|
||||
|
||||
Refer to API objects without saying "object," unless omitting "object"
|
||||
leads to an awkward sentence construction.
|
||||
|
||||
<table caption="Do and Don't - API objects" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>The Pod has two containers.</td><td>The pod has two containers.</td></tr>
|
||||
<tr><td>The Deployment is responsible for ...</td><td>The Deployment object is responsible for ...</td></tr>
|
||||
<tr><td>A PodList is a list of Pods.</td><td>A Pod List is a list of pods.</td></tr>
|
||||
<tr><td>The two ContainerPorts ...</td><td>The two ContainerPort objects ...</td></tr>
|
||||
<tr><td>The two ContainerStateTerminated objects ...</td><td>The two ContainerStateTerminateds ...</td></tr>
|
||||
</table>
|
||||
|
||||
### Use angle brackets for placeholders
|
||||
|
||||
Use angle brackets for placeholders. Tell the reader what a placeholder represents.
|
||||
|
||||
1. Display information about a Pod:
|
||||
|
||||
kubectl describe pod <pod-name> -n <namespace>
|
||||
|
||||
If the pod is in the default namespace, you can omit the '-n' parameter.
|
||||
|
||||
### Use bold for user interface elements
|
||||
|
||||
<table caption="Do and Don't - Bold interface elements" markdown="1">
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td markdown="span">Click **Fork**.</td><td>Click "Fork".</td></tr>
|
||||
<tr><td markdown="span">Select **Other**.</td><td>Select "Other".</td></tr>
|
||||
</table>
|
||||
|
||||
### Use italics to define or introduce new terms
|
||||
|
||||
<table caption="Do and Don't - Use italics for new terms" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td markdown="span">A _cluster_ is a set of nodes ...</td><td>A "cluster" is a set of nodes ...</td></tr>
|
||||
<tr><td markdown="span">These components form the _control plane_.</td><td markdown="span">These components form the **control plane**.</td></tr>
|
||||
</table>
|
||||
|
||||
### Use code style for filenames, directories, paths, object field names and namespaces
|
||||
|
||||
<table caption="Do and Don't - Use code style for filenames, directories, paths, object field names and namespaces" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td markdown="span">Open the `envars.yaml` file.</td><td>Open the envars.yaml file.</td></tr>
|
||||
<tr><td markdown="span">Go to the `/docs/tutorials` directory.</td><td>Go to the /docs/tutorials directory.</td></tr>
|
||||
<tr><td markdown="span">Open the `/_data/concepts.yaml` file.</td><td markdown="span">Open the /\_data/concepts.yaml file.</td></tr>
|
||||
</table>
|
||||
|
||||
### Use punctuation inside quotes
|
||||
|
||||
<table caption="Do and Don't - Use punctuation inside quotes" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>events are recorded with an associated "stage."</td><td>events are recorded with an associated "stage".</td></tr>
|
||||
<tr><td>The copy is called a "fork."</td><td>The copy is called a "fork".</td></tr>
|
||||
</table>
|
||||
|
||||
Exception: When the quoted word is a user input.
|
||||
|
||||
Example:
|
||||
* My user ID is “IM47g”.
|
||||
* Did you try the password “mycatisawesome”?
|
||||
|
||||
## Inline code formatting
|
||||
|
||||
|
||||
### Use code style for inline code and commands
|
||||
|
||||
For inline code in an HTML document, use the `<code>` tag. In a Markdown
|
||||
document, use the backtick (`` ` ``).
|
||||
|
||||
<table caption="Do and Don't - Use code style for inline code and commands" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td markdown="span">The `kubectl run` command creates a Deployment.</td><td>The "kubectl run" command creates a Deployment.</td></tr>
|
||||
<tr><td markdown="span">For declarative management, use `kubectl apply`.</td><td>For declarative management, use "kubectl apply".</td></tr>
|
||||
<tr><td markdown="span">Use single backticks to enclose inline code. For example, `var example = true`.</td><td>Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**.</td></tr>
|
||||
<tr><td>Use triple backticks (\`\`\`) before and after a multi-line block of code for fenced code blocks.</td><td>Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations.</td></tr>
|
||||
<tr><td>Use meaningful variable names that have a context.</td><td>Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context.</td></tr>
|
||||
<tr><td>Remove trailing spaces in the code.</td><td>Add trailing spaces in the code, where these are important, because a screen reader will read out the spaces as well.</td></tr>
|
||||
</table>
|
||||
|
||||
### Starting a sentence with a component tool or component name
|
||||
|
||||
<table caption="Do and Don't - Starting a sentence with a component tool or component name" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td markdown="span">The `kubeadm` tool bootstraps and provisions machines in a cluster.</td><td markdown="span">`kubeadm` tool bootstraps and provisions machines in a cluster.</td></tr>
|
||||
<tr><td>The kube-scheduler is the default scheduler for Kubernetes.</td><td>kube-scheduler is the default scheduler for Kubernetes.</td></tr>
|
||||
</table>
|
||||
|
||||
### Use normal style for string and integer field values
|
||||
|
||||
For field values of type string or integer, use normal style without quotation marks.
|
||||
|
||||
<table caption="Do and Don't - Use normal style for string and integer field values" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td markdown="span">Set the value of `imagePullPolicy` to `Always`.</td><td markdown="span">Set the value of `imagePullPolicy` to "Always".</td></tr>
|
||||
<tr><td markdown="span">Set the value of `image` to `nginx:1.16`.</td><td markdown="span">Set the value of `image` to nginx:1.16.</td></tr>
|
||||
<tr><td markdown="span">Set the value of the `replicas` field to `2`.</td><td markdown="span">Set the value of the `replicas` field to 2.</td></tr>
|
||||
</table>
|
||||
|
||||
## Code snippet formatting
|
||||
|
||||
|
||||
### Don't include the command prompt
|
||||
|
||||
<table caption="Do and Don't - Don't include the command prompt" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>kubectl get pods</td><td>$ kubectl get pods</td></tr>
|
||||
</table>
|
||||
|
||||
### Separate commands from output
|
||||
|
||||
Verify that the Pod is running on your chosen node:
|
||||
|
||||
```
|
||||
kubectl get pods --output=wide
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
nginx 1/1 Running 0 13s 10.200.0.4 worker0
|
||||
```
|
||||
|
||||
## Velero.io word list
|
||||
|
||||
|
||||
A list of Velero-specific terms and words to be used consistently across the site.
|
||||
|
||||
<table caption="Velero.io word list" >
|
||||
<tr><th>Trem</th><th>Useage</th></tr>
|
||||
<tr><td>Kubernetes</td><td>Kubernetes should always be capitalized.</td></tr>
|
||||
<tr><td>Docker</td><td>Docker should always be capitalized.</td></tr>
|
||||
<tr><td>Velero</td><td>Velero should always be capitalized.</td></tr>
|
||||
<tr><td>VMware</td><td>VMware should always be correctly capitalized.</td></tr>
|
||||
<tr><td>On-premises</td><td>On-premises or on-prem rather than on-premise or other variations.</td></tr>
|
||||
<tr><td>Backup</td><td>Backup rather than back up, back-up or other variations.</td></tr>
|
||||
<tr><td>Plugin</td><td>Plugin rather than plug-in or other variations.</td></tr>
|
||||
<tr><td>Allowlist</td><td>Use allowlist instead of whitelist.</td></tr>
|
||||
<tr><td>Denylist</td><td>Use denylist instead of blacklist.</td></tr>
|
||||
</table>
|
||||
|
||||
## Markdown elements
|
||||
|
||||
### Headings
|
||||
People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest.
|
||||
|
||||
<table caption="Do and Don't - Headings" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Include a title on each page or blog post.</td><td>Include more than one title headings (#) in a page.</td></tr>
|
||||
<tr><td>Use ordered headings to provide a meaningful high-level outline of your content.</td><td>Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles.</td></tr>
|
||||
<tr><td markdown="span">Use sentence case for headings. For example, **Extend kubectl with plugins**</td><td markdown="span">Use title case for headings. For example, **Extend Kubectl With Plugins**</td></tr>
|
||||
</table>
|
||||
|
||||
### Paragraphs
|
||||
|
||||
<table caption="Do and Don't - Paragraphs" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td>Try to keep paragraphs under 6 sentences.</td><td>Write long-winded paragraphs.</td></tr>
|
||||
<tr><td markdown="span">Use three hyphens (`---`) to create a horizontal rule for breaks in paragraph content.</td><td>Use horizontal rules for decoration.</td></tr>
|
||||
</table>
|
||||
|
||||
### Links
|
||||
|
||||
<table caption="Do and Don't - Links" >
|
||||
<tr><th>Do</th><th>Don't</th></tr>
|
||||
<tr><td markdown="span">Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See [check required ports](#check-required-ports) for more details.</td><td markdown="span">Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See [here](#check-required-ports) for more details.</td></tr>
|
||||
<tr><td markdown="span">Write Markdown-style links: `[link text](URL)`. For example: `[community meeting agenda](https://hackmd.io/Jq6F5zqZR7S80CeDWUklkA)` and the output is [community meeting agenda](https://hackmd.io/Jq6F5zqZR7S80CeDWUklkA).</td><td markdown="span">Write HTML-style links: `<a href="/media/examples/link-element-example.css" target="_blank">Visit our tutorial!</a>`</td></tr>
|
||||
</table>
|
||||
|
||||
|
||||
### Lists
|
||||
|
||||
Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list.
|
||||
Website navigation links can also be marked up as list items; after all they are nothing but a group of related links.
|
||||
|
||||
- End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences.
|
||||
|
||||
- Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.
|
||||
|
||||
- Use the number one (`1.`) for ordered lists.
|
||||
|
||||
- Use (`+`), (`*`), or (`-`) for unordered lists - be consistent within the same document.
|
||||
|
||||
- Leave a blank line after each list.
|
||||
|
||||
- Indent nested lists with four spaces (for example, ⋅⋅⋅⋅).
|
||||
|
||||
- List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab.
|
||||
|
||||
### Tables
|
||||
|
||||
The semantic purpose of a data table is to present tabular data. Sighted users can quickly scan the table but a screen reader goes through line by line. A table caption is used to create a descriptive title for a data table. Assistive technologies (AT) use the HTML table caption element to identify the table contents to the user within the page structure. For example, `<table caption="Do and Don't - Use present tense">`. To make tables accessible, use HTML formatting to create tables.
|
||||
|
||||
If you need to create a table and style table data with markdown, add `markdown="span"` to all `<td>` where the markdown interpreter should be applied.
|
|
@ -1,95 +0,0 @@
|
|||
---
|
||||
title: "Providers"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
Velero supports a variety of storage providers for different backup and snapshot operations. Velero has a plugin system which allows anyone to add compatibility for additional backup and volume storage platforms without modifying the Velero codebase.
|
||||
|
||||
## Velero supported providers
|
||||
|
||||
| Provider | Object Store | Volume Snapshotter | Plugin Provider Repo | Setup Instructions |
|
||||
|-----------------------------------|---------------------|------------------------------|-----------------------------------------|-------------------------------|
|
||||
| [Amazon Web Services (AWS)][7] | AWS S3 | AWS EBS | [Velero plugin for AWS][8] | [AWS Plugin Setup][35] |
|
||||
| [Google Cloud Platform (GCP)][11] | Google Cloud Storage| Google Compute Engine Disks | [Velero plugin for GCP][12] | [GCP Plugin Setup][36] |
|
||||
| [Microsoft Azure][9] | Azure Blob Storage | Azure Managed Disks | [Velero plugin for Microsoft Azure][10] | [Azure Plugin Setup][37] |
|
||||
| [VMware vSphere][39] | 🚫 | vSphere Volumes | [VMware vSphere][39] | [vSphere Plugin Setup][40] |
|
||||
| [Container Storage Interface (CSI)]| 🚫 | CSI Volumes | [Velero plugin for CSI][44] | [CSI Plugin Setup][45] |
|
||||
|
||||
Contact: [#Velero Slack][28], [GitHub Issues][29]
|
||||
|
||||
## Community supported providers
|
||||
|
||||
| Provider | Object Store | Volume Snapshotter | Plugin Documentation | Contact |
|
||||
|---------------------------|------------------------------|------------------------------------|------------------------|---------------------------------|
|
||||
| [AlibabaCloud][21] | Alibaba Cloud OSS | Alibaba Cloud | [AlibabaCloud][22] | [GitHub Issue][23] |
|
||||
| [DigitalOcean][15] | DigitalOcean Object Storage | DigitalOcean Volumes Block Storage | [StackPointCloud][16] | |
|
||||
| [Hewlett Packard][24] | 🚫 | HPE Storage | [Hewlett Packard][25] | [Slack][26], [GitHub Issue][27] |
|
||||
| [OpenEBS][17] | 🚫 | OpenEBS CStor Volume | [OpenEBS][18] | [Slack][19], [GitHub Issue][20] |
|
||||
| [Portworx][31] | 🚫 | Portworx Volume | [Portworx][32] | [Slack][33], [GitHub Issue][34] |
|
||||
| [Storj][41] | Storj Object Storage | 🚫 | [Storj][42] | [GitHub Issue][43] |
|
||||
|
||||
## S3-Compatible object store providers
|
||||
|
||||
Velero's AWS Object Store plugin uses [Amazon's Go SDK][0] to connect to the AWS S3 API. Some third-party storage providers also support the S3 API, and users have reported the following providers work with Velero:
|
||||
|
||||
_Note that these storage providers are not regularly tested by the Velero team._
|
||||
|
||||
* [IBM Cloud][1]
|
||||
* [Oracle Cloud][2]
|
||||
* [Minio][3]
|
||||
* [DigitalOcean][4]
|
||||
* [NooBaa][5]
|
||||
* Ceph RADOS v12.2.7
|
||||
* Quobyte
|
||||
* [Cloudian HyperStore][38]
|
||||
|
||||
_Some storage providers, like Quobyte, may need a different [signature algorithm version][6]._
|
||||
|
||||
## Non-supported volume snapshots
|
||||
|
||||
In the case you want to take volume snapshots but didn't find a plugin for your provider, Velero has support for snapshotting using restic. Please see the [restic integration][30] documentation.
|
||||
|
||||
[0]: https://github.com/aws/aws-sdk-go/aws
|
||||
[1]: contributions/ibm-config.md
|
||||
[2]: contributions/oracle-config.md
|
||||
[3]: contributions/minio.md
|
||||
[4]: https://github.com/StackPointCloud/ark-plugin-digitalocean
|
||||
[5]: http://www.noobaa.com/
|
||||
[6]: https://github.com/vmware-tanzu/velero-plugin-for-aws/blob/main/backupstoragelocation.md
|
||||
[7]: https://aws.amazon.com
|
||||
[8]: https://github.com/vmware-tanzu/velero-plugin-for-aws
|
||||
[9]: https://azure.com
|
||||
[10]: https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure
|
||||
[11]: https://cloud.google.com
|
||||
[12]: https://github.com/vmware-tanzu/velero-plugin-for-gcp
|
||||
[15]: https://www.digitalocean.com/
|
||||
[16]: https://github.com/StackPointCloud/ark-plugin-digitalocean
|
||||
[17]: https://openebs.io/
|
||||
[18]: https://github.com/openebs/velero-plugin
|
||||
[19]: https://openebs-community.slack.com/
|
||||
[20]: https://github.com/openebs/velero-plugin/issues
|
||||
[21]: https://www.alibabacloud.com/
|
||||
[22]: https://github.com/AliyunContainerService/velero-plugin
|
||||
[23]: https://github.com/AliyunContainerService/velero-plugin/issues
|
||||
[24]: https://www.hpe.com/us/en/storage.html
|
||||
[25]: https://github.com/hpe-storage/velero-plugin
|
||||
[26]: https://slack.hpedev.io/
|
||||
[27]: https://github.com/hpe-storage/velero-plugin/issues
|
||||
[28]: https://kubernetes.slack.com/messages/velero
|
||||
[29]: https://github.com/vmware-tanzu/velero/issues
|
||||
[30]: restic.md
|
||||
[31]: https://portworx.com/
|
||||
[32]: https://docs.portworx.com/scheduler/kubernetes/ark.html
|
||||
[33]: https://portworx.slack.com/messages/px-k8s
|
||||
[34]: https://github.com/portworx/ark-plugin/issues
|
||||
[35]: https://github.com/vmware-tanzu/velero-plugin-for-aws#setup
|
||||
[36]: https://github.com/vmware-tanzu/velero-plugin-for-gcp#setup
|
||||
[37]: https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure#setup
|
||||
[38]: https://www.cloudian.com/
|
||||
[39]: https://github.com/vmware-tanzu/velero-plugin-for-vsphere
|
||||
[40]: https://github.com/vmware-tanzu/velero-plugin-for-vsphere#installing-the-plugin
|
||||
[41]: https://storj.io
|
||||
[42]: https://github.com/storj-thirdparty/velero-plugin
|
||||
[43]: https://github.com/storj-thirdparty/velero-plugin/issues
|
||||
[44]: https://github.com/vmware-tanzu/velero-plugin-for-csi/
|
||||
[45]: https://velero.io/docs/v1.4/csi/
|
|
@ -1,49 +0,0 @@
|
|||
---
|
||||
title: "Website Guidelines"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
## Running the website locally
|
||||
|
||||
When making changes to the website, please run the site locally before submitting a PR and manually verify your changes.
|
||||
|
||||
At the root of the project, run:
|
||||
|
||||
```bash
|
||||
make serve-docs
|
||||
```
|
||||
|
||||
This runs all the Ruby dependencies in a container.
|
||||
|
||||
Alternatively, for quickly loading the website, under the `velero/site/` directory run:
|
||||
|
||||
```bash
|
||||
bundle exec jekyll serve --livereload --future
|
||||
```
|
||||
|
||||
For more information on how to run the website locally, please see our [jekyll documentation](https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/site/README-JEKYLL.md).
|
||||
|
||||
## Adding a blog post
|
||||
|
||||
The `author_name` value must also be included in the tags field so the page that lists the author's posts will work properly (Ex: https://velero.io/tags/carlisia%20campos/).
|
||||
|
||||
Note that the tags field can have multiple values.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
author_name: Carlisia Campos
|
||||
tags: ['Carlisia Campos', "release", "how-to"]
|
||||
```
|
||||
|
||||
### Please add an image
|
||||
|
||||
If there is no image added to the header of the post, the default Velero logo will be used. This is fine, but not ideal.
|
||||
|
||||
If there's an image that can be used as the blog post icon, the image field must be set to:
|
||||
|
||||
```text
|
||||
image: /img/posts/<your_image_name.png>
|
||||
```
|
||||
|
||||
This image file must be added to the `/site/img/posts` folder.
|
|
@ -1,6 +1,8 @@
|
|||
---
|
||||
toc: "false"
|
||||
cascade:
|
||||
version: v1.5-pre
|
||||
version: v1.5.0-rc.1
|
||||
toc: "true"
|
||||
---
|
||||
![100]
|
||||
|
||||
|
@ -31,7 +33,7 @@ If you encounter issues, review the [troubleshooting docs][30], [file an issue][
|
|||
|
||||
## Contributing
|
||||
|
||||
If you are ready to jump in and test, add code, or help with documentation, follow the instructions on our [Start contributing](https://velero.io/docs/v1.5.0-beta.1/start-contributing/) documentation for guidance on how to setup Velero for development.
|
||||
If you are ready to jump in and test, add code, or help with documentation, follow the instructions on our [Start contributing](https://velero.io/docs/v1.5.0-rc.1/start-contributing/) documentation for guidance on how to setup Velero for development.
|
||||
|
||||
## Changelog
|
||||
|
|
@ -3,7 +3,7 @@ layout: docs
|
|||
title: API types
|
||||
---
|
||||
|
||||
Here we list the API types that have some functionality that you can only configure via json/yaml vs the `velero` cli
|
||||
Here's a list the API types that have some functionality that you can only configure via json/yaml vs the `velero` cli
|
||||
(hooks)
|
||||
|
||||
* [Backup][1]
|
|
@ -5,7 +5,7 @@ layout: docs
|
|||
|
||||
## Use
|
||||
|
||||
The `Backup` API type is used as a request for the Velero server to perform a backup. Once created, the
|
||||
Use the `Backup` API type to request the Velero server to perform a backup. Once created, the
|
||||
Velero Server immediately starts the backup process.
|
||||
|
||||
## API GroupVersion
|
||||
|
@ -36,11 +36,11 @@ spec:
|
|||
# Array of namespaces to exclude from the backup. Optional.
|
||||
excludedNamespaces:
|
||||
- some-namespace
|
||||
# Array of resources to include in the backup. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to include in the backup. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. If unspecified, all resources are included. Optional.
|
||||
includedResources:
|
||||
- '*'
|
||||
# Array of resources to exclude from the backup. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to exclude from the backup. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. Optional.
|
||||
excludedResources:
|
||||
- storageclasses.storage.k8s.io
|
||||
|
@ -69,13 +69,13 @@ spec:
|
|||
volumeSnapshotLocations:
|
||||
- aws-primary
|
||||
- gcp-primary
|
||||
# The amount of time before this backup is eligible for garbage collection. If not specified,
|
||||
# The amount of time before this backup is eligible for garbage collection. If not specified,
|
||||
# a default value of 30 days will be used. The default can be configured on the velero server
|
||||
# by passing the flag --default-backup-ttl.
|
||||
# by passing the flag --default-backup-ttl.
|
||||
ttl: 24h0m0s
|
||||
# Whether restic should be used to take a backup of all pod volumes by default.
|
||||
defaultVolumesToRestic: true
|
||||
# Actions to perform at different times during a backup. The only hook currently supported is
|
||||
# Actions to perform at different times during a backup. The only hook supported is
|
||||
# executing a command in a container in a pod using the pod exec API. Optional.
|
||||
hooks:
|
||||
# Array of hooks that are applicable to specific resources. Optional.
|
||||
|
@ -101,9 +101,9 @@ spec:
|
|||
matchLabels:
|
||||
app: velero
|
||||
component: server
|
||||
# An array of hooks to run before executing custom actions. Currently only "exec" hooks are supported.
|
||||
# An array of hooks to run before executing custom actions. Only "exec" hooks are supported.
|
||||
pre:
|
||||
-
|
||||
-
|
||||
# The type of hook. This must be "exec".
|
||||
exec:
|
||||
# The name of the container where the command will be executed. If unspecified, the
|
||||
|
@ -119,12 +119,12 @@ spec:
|
|||
# How long to wait for the command to finish executing. Defaults to 30 seconds. Optional.
|
||||
timeout: 10s
|
||||
# An array of hooks to run after all custom actions and additional items have been
|
||||
# processed. Currently only "exec" hooks are supported.
|
||||
# processed. Only "exec" hooks are supported.
|
||||
post:
|
||||
# Same content as pre above.
|
||||
# Status about the Backup. Users should not set any data here.
|
||||
status:
|
||||
# The version of this Backup. The only version currently supported is 1.
|
||||
# The version of this Backup. The only version supported is 1.
|
||||
version: 1
|
||||
# The date and time when the Backup is eligible for garbage collection.
|
||||
expiration: null
|
||||
|
@ -144,5 +144,5 @@ status:
|
|||
warnings: 2
|
||||
# Number of errors that were logged by the backup.
|
||||
errors: 0
|
||||
|
||||
|
||||
```
|
|
@ -33,6 +33,7 @@ The configurable parameters are as follows:
|
|||
|
||||
#### Main config parameters
|
||||
|
||||
{{< table caption="Main config parameters" >}}
|
||||
| Key | Type | Default | Meaning |
|
||||
| --- | --- | --- | --- |
|
||||
| `provider` | String | Required Field | The name for whichever object storage provider will be used to store the backups. See [your object storage provider's plugin documentation][0] for the appropriate value to use. |
|
||||
|
@ -44,6 +45,6 @@ The configurable parameters are as follows:
|
|||
| `accessMode` | String | `ReadWrite` | How Velero can access the backup storage location. Valid values are `ReadWrite`, `ReadOnly`. |
|
||||
| `backupSyncPeriod` | metav1.Duration | Optional Field | How frequently Velero should synchronize backups in object storage. Default is Velero's server backup sync period. Set this to `0s` to disable sync. |
|
||||
| `validationFrequency` | metav1.Duration | Optional Field | How frequently Velero should validate the object storage . Default is Velero's server validation frequency. Set this to `0s` to disable validation. Default 1 minute. |
|
||||
|
||||
{{ </table> }}
|
||||
|
||||
[0]: ../supported-providers.md
|
|
@ -6,7 +6,7 @@ layout: docs
|
|||
## Use
|
||||
|
||||
The `Schedule` API type is used as a repeatable request for the Velero server to perform a backup for a given cron notation. Once created, the
|
||||
Velero Server will start the backup process. It will then wait for the next valid point of the given cron expression and execute the backup
|
||||
Velero Server will start the backup process. It will then wait for the next valid point of the given cron expression and execute the backup
|
||||
process on a repeating basis.
|
||||
|
||||
## API GroupVersion
|
||||
|
@ -41,11 +41,11 @@ spec:
|
|||
# Array of namespaces to exclude from the scheduled backup. Optional.
|
||||
excludedNamespaces:
|
||||
- some-namespace
|
||||
# Array of resources to include in the scheduled backup. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to include in the scheduled backup. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. If unspecified, all resources are included. Optional.
|
||||
includedResources:
|
||||
- '*'
|
||||
# Array of resources to exclude from the scheduled backup. Resources may be shortcuts (e.g. 'po' for 'pods')
|
||||
# Array of resources to exclude from the scheduled backup. Resources may be shortcuts (for example 'po' for 'pods')
|
||||
# or fully-qualified. Optional.
|
||||
excludedResources:
|
||||
- storageclasses.storage.k8s.io
|
||||
|
@ -74,11 +74,11 @@ spec:
|
|||
volumeSnapshotLocations:
|
||||
- aws-primary
|
||||
- gcp-primary
|
||||
# The amount of time before backups created on this schedule are eligible for garbage collection. If not specified,
|
||||
# The amount of time before backups created on this schedule are eligible for garbage collection. If not specified,
|
||||
# a default value of 30 days will be used. The default can be configured on the velero server
|
||||
# by passing the flag --default-backup-ttl.
|
||||
# by passing the flag --default-backup-ttl.
|
||||
ttl: 24h0m0s
|
||||
# Actions to perform at different times during a backup. The only hook currently supported is
|
||||
# Actions to perform at different times during a backup. The only hook supported is
|
||||
# executing a command in a container in a pod using the pod exec API. Optional.
|
||||
hooks:
|
||||
# Array of hooks that are applicable to specific resources. Optional.
|
||||
|
@ -104,9 +104,9 @@ spec:
|
|||
matchLabels:
|
||||
app: velero
|
||||
component: server
|
||||
# An array of hooks to run before executing custom actions. Currently only "exec" hooks are supported.
|
||||
# An array of hooks to run before executing custom actions. Only "exec" hooks are supported.
|
||||
pre:
|
||||
-
|
||||
-
|
||||
# The type of hook. This must be "exec".
|
||||
exec:
|
||||
# The name of the container where the command will be executed. If unspecified, the
|
||||
|
@ -122,7 +122,7 @@ spec:
|
|||
# How long to wait for the command to finish executing. Defaults to 30 seconds. Optional.
|
||||
timeout: 10s
|
||||
# An array of hooks to run after all custom actions and additional items have been
|
||||
# processed. Currently only "exec" hooks are supported.
|
||||
# processed. Only "exec" hooks are supported.
|
||||
post:
|
||||
# Same content as pre above.
|
||||
status:
|
|
@ -32,10 +32,11 @@ The configurable parameters are as follows:
|
|||
|
||||
#### Main config parameters
|
||||
|
||||
{{< table caption="Main config parameters" >}}
|
||||
| Key | Type | Default | Meaning |
|
||||
| --- | --- | --- | --- |
|
||||
| `provider` | String | Required Field | The name for whichever storage provider will be used to create/store the volume snapshots. See [your volume snapshot provider's plugin documentation][0] for the appropriate value to use. |
|
||||
| `config` | map[string]string | None (Optional) | Provider-specific configuration keys/values to be passed to the volume snapshotter plugin. See [your volume snapshot provider's plugin documentation][0] for details. |
|
||||
|
||||
{{</table>}}
|
||||
|
||||
[0]: ../supported-providers.md
|
|
@ -88,5 +88,5 @@ To use multiple commands, wrap your target command in a shell and separate them
|
|||
|
||||
|
||||
[1]: api-types/backup.md
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/examples/nginx-app/with-pv.yaml
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/examples/nginx-app/with-pv.yaml
|
||||
[3]: cloud-common.md
|
|
@ -3,15 +3,6 @@ title: "Basic Install"
|
|||
layout: docs
|
||||
---
|
||||
|
||||
- [Basic Install](#basic-install)
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Install the CLI](#install-the-cli)
|
||||
- [Option 1: macOS - Homebrew](#option-1-macos---homebrew)
|
||||
- [Option 2: GitHub release](#option-2-github-release)
|
||||
- [Option 3: Windows - Chocolatey](#option-3-windows---chocolatey)
|
||||
- [Install and configure the server components](#install-and-configure-the-server-components)
|
||||
- [Command line Autocompletion](#command-line-autocompletion)
|
||||
|
||||
Use this doc to get a basic installation of Velero.
|
||||
Refer [this document](customize-installation.md) to customize your installation.
|
||||
|
||||
|
@ -22,7 +13,7 @@ Refer [this document](customize-installation.md) to customize your installation.
|
|||
|
||||
Velero uses object storage to store backups and associated artifacts. It also optionally integrates with supported block storage systems to snapshot your persistent volumes. Before beginning the installation process, you should identify the object storage provider and optional block storage provider(s) you'll be using from the list of [compatible providers][0].
|
||||
|
||||
There are supported storage providers for both cloud-provider environments and on-premises environments. For more details on on-premises scenarios, see the [on-premises documentation][2].
|
||||
Velero supports storage providers for both cloud-provider environments and on-premises environments. For more details on on-premises scenarios, see the [on-premises documentation][2].
|
||||
|
||||
### Velero on Windows
|
||||
|
||||
|
@ -49,7 +40,7 @@ brew install velero
|
|||
tar -xvf <RELEASE-TARBALL-NAME>.tar.gz
|
||||
```
|
||||
|
||||
1. Move the extracted `velero` binary to somewhere in your `$PATH` (e.g. `/usr/local/bin` for most users).
|
||||
1. Move the extracted `velero` binary to somewhere in your `$PATH` (`/usr/local/bin` for most users).
|
||||
|
||||
### Option 3: Windows - Chocolatey
|
||||
|
|
@ -34,7 +34,7 @@ Note that the Makefile targets assume building from a git repository. When build
|
|||
|
||||
There are a number of different ways to build `velero` depending on your needs. This section outlines the main possibilities.
|
||||
|
||||
When building by using `make`, it will place the binaries under `_output/bin/$GOOS/$GOARCH`. For example, you will find the binary for darwin here: `_output/bin/darwin/amd64/velero`, and the binary for linux here: `_output/bin/linux/amd64/velero`. `make` will also splice version and git commit information in so that `velero version` displays proper output.
|
||||
When building by using `make`, it will place the binaries under `_output/bin/$GOOS/$GOARCH`. For example, you will find the binary for darwin here: `_output/bin/darwin/amd64/velero`, and the binary for linux here: `_output/bin/linux/amd64/velero`. `make` will also splice version and git commit information in so that `velero version` displays proper output.
|
||||
|
||||
Note: `velero install` will also use the version information to determine which tagged image to deploy. If you would like to overwrite what image gets deployed, use the `image` flag (see below for instructions on how to build images).
|
||||
|
||||
|
@ -164,7 +164,7 @@ $ REGISTRY=myrepo BUILDX_OUTPUT_TYPE=registry make container
|
|||
|
||||
### Cross platform building
|
||||
|
||||
Docker `buildx` platforms currently supported:
|
||||
Docker `buildx` platforms supported:
|
||||
* `linux/amd64`
|
||||
* `linux/arm64`
|
||||
* `linux/arm/v7`
|
|
@ -65,7 +65,7 @@ Example:
|
|||
|
||||
We use a package to generate mocks for our interfaces.
|
||||
|
||||
Example: if you want to change this mock: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/pkg/restic/mocks/restorer.go
|
||||
Example: if you want to change this mock: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/pkg/restic/mocks/restorer.go
|
||||
|
||||
Run:
|
||||
|
|
@ -26,7 +26,7 @@ of the Velero repository is under active development and is not guaranteed to be
|
|||
tar -xvf <RELEASE-TARBALL-NAME>.tar.gz -C /dir/to/extract/to
|
||||
```
|
||||
|
||||
We'll refer to the directory you extracted to as the "Velero directory" in subsequent steps.
|
||||
The directory you extracted is called the "Velero directory" in subsequent steps.
|
||||
|
||||
1. Move the `velero` binary from the Velero directory to somewhere in your PATH.
|
||||
|
||||
|
@ -44,7 +44,7 @@ Several comments:
|
|||
|
||||
2. Velero uses an AWS S3 compatible API. Which means it authenticates using a signature created from a pair of access and secret keys — a set of HMAC credentials. You can create these HMAC credentials by specifying `{“HMAC”:true}` as an optional inline parameter. See step 3 in the [Service credentials][3] guide.
|
||||
|
||||
3. After successfully creating a Service credential, you can view the JSON definition of the credential. Under the `cos_hmac_keys` entry there are `access_key_id` and `secret_access_key`. We will use them in the next step.
|
||||
3. After successfully creating a Service credential, you can view the JSON definition of the credential. Under the `cos_hmac_keys` entry there are `access_key_id` and `secret_access_key`. Use them in the next step.
|
||||
|
||||
4. Create a Velero-specific credentials file (`credentials-velero`) in your local directory:
|
||||
|
||||
|
@ -54,7 +54,7 @@ Several comments:
|
|||
aws_secret_access_key=<SECRET_ACCESS_KEY>
|
||||
```
|
||||
|
||||
where the access key id and secret are the values that we got above.
|
||||
Where the access key id and secret are the values that you got above.
|
||||
|
||||
## Install and start Velero
|
||||
|
||||
|
@ -69,7 +69,7 @@ velero install \
|
|||
--backup-location-config region=<YOUR_REGION>,s3ForcePathStyle="true",s3Url=<YOUR_URL_ACCESS_POINT>
|
||||
```
|
||||
|
||||
Velero does not currently have a volume snapshot plugin for IBM Cloud, so creating volume snapshots is disabled.
|
||||
Velero does not have a volume snapshot plugin for IBM Cloud, so creating volume snapshots is disabled.
|
||||
|
||||
Additionally, you can specify `--use-restic` to enable [restic support][16], and `--wait` to wait for the deployment to be ready.
|
||||
|
|
@ -14,13 +14,13 @@ See [Set up Velero on your platform][3] for how to configure Velero for a produc
|
|||
|
||||
If you encounter issues with installing or configuring, see [Debugging Installation Issues](debugging-install.md).
|
||||
|
||||
### Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
* Access to a Kubernetes cluster, version 1.7 or later. **Note:** restic support requires Kubernetes version 1.10 or later, or an earlier version with the mount propagation feature enabled. Restic support is not required for this example, but may be of interest later. See [Restic Integration][17].
|
||||
* A DNS server on the cluster
|
||||
* `kubectl` installed
|
||||
|
||||
### Download Velero
|
||||
## Download Velero
|
||||
|
||||
1. Download the [latest official release's](https://github.com/vmware-tanzu/velero/releases) tarball for your client platform.
|
||||
|
||||
|
@ -34,11 +34,11 @@ of the Velero repository is under active development and is not guaranteed to be
|
|||
tar -xvf <RELEASE-TARBALL-NAME>.tar.gz -C /dir/to/extract/to
|
||||
```
|
||||
|
||||
We'll refer to the directory you extracted to as the "Velero directory" in subsequent steps.
|
||||
The directory you extracted is called the "Velero directory" in subsequent steps.
|
||||
|
||||
1. Move the `velero` binary from the Velero directory to somewhere in your PATH.
|
||||
|
||||
#### MacOS Installation
|
||||
### MacOS Installation
|
||||
|
||||
On Mac, you can use [HomeBrew](https://brew.sh) to install the `velero` client:
|
||||
|
||||
|
@ -46,7 +46,7 @@ On Mac, you can use [HomeBrew](https://brew.sh) to install the `velero` client:
|
|||
brew install velero
|
||||
```
|
||||
|
||||
### Set up server
|
||||
## Set up server
|
||||
|
||||
These instructions start the Velero server and a Minio instance that is accessible from within the cluster only. See [Expose Minio outside your cluster][31] for information about configuring your cluster for outside access to Minio. Outside access is required to access logs and run `velero describe` commands.
|
||||
|
||||
|
@ -71,7 +71,7 @@ These instructions start the Velero server and a Minio instance that is accessib
|
|||
--secret-file ./credentials-velero \
|
||||
--use-volume-snapshots=false \
|
||||
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.velero.svc:9000 \
|
||||
--snapshot-location-config region="default"
|
||||
--snapshot-location-config region="default"
|
||||
```
|
||||
|
||||
This example assumes that it is running within a local cluster without a volume provider capable of snapshots, so no `VolumeSnapshotLocation` is created (`--use-volume-snapshots=false`).
|
||||
|
@ -92,7 +92,7 @@ These instructions start the Velero server and a Minio instance that is accessib
|
|||
kubectl get deployments --namespace=nginx-example
|
||||
```
|
||||
|
||||
### Back up
|
||||
## Back up
|
||||
|
||||
1. Create a backup for any object that matches the `app=nginx` label selector:
|
||||
|
||||
|
@ -138,7 +138,7 @@ These instructions start the Velero server and a Minio instance that is accessib
|
|||
|
||||
NOTE: You might need to wait for a few minutes for the namespace to be fully cleaned up.
|
||||
|
||||
### Restore
|
||||
## Restore
|
||||
|
||||
1. Run:
|
||||
|
||||
|
@ -171,7 +171,7 @@ velero restore describe <RESTORE_NAME>
|
|||
|
||||
For more information, see [the debugging information][18].
|
||||
|
||||
### Clean up
|
||||
## Clean up
|
||||
|
||||
If you want to delete any backups you created, including data in object storage and persistent
|
||||
volume snapshots, you can run:
|
||||
|
@ -237,7 +237,7 @@ You must also get the Minio URL, which you can then specify as the value of the
|
|||
|
||||
If you're using Minio with HTTPS, you may see unintelligible text in the output of `velero describe`, or `velero logs` commands.
|
||||
|
||||
In order to fix this, you can add a public URL to the `BackupStorageLocation`.
|
||||
To fix this, you can add a public URL to the `BackupStorageLocation`.
|
||||
|
||||
In a terminal, run the following:
|
||||
|
||||
|
@ -249,7 +249,7 @@ If your certificate is self-signed, see the [documentation on self-signed certif
|
|||
|
||||
## Expose Minio outside your cluster with Kubernetes in Docker (KinD):
|
||||
|
||||
Kubernetes in Docker currently does not have support for NodePort services (see [this issue](https://github.com/kubernetes-sigs/kind/issues/99)). In this case, you can use a port forward to access the Minio bucket.
|
||||
Kubernetes in Docker does not have support for NodePort services (see [this issue](https://github.com/kubernetes-sigs/kind/issues/99)). In this case, you can use a port forward to access the Minio bucket.
|
||||
|
||||
In a terminal, run the following:
|
||||
|
|
@ -5,7 +5,7 @@ layout: docs
|
|||
|
||||
## Introduction
|
||||
|
||||
[Velero](https://velero.io/) is a tool used to backup and migrate Kubernetes applications. Here are the steps to use [Oracle Cloud Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Concepts/objectstorageoverview.htm) as a destination for Velero backups.
|
||||
[Velero](https://velero.io/) is a tool used to backup and migrate Kubernetes applications. Here are the steps to use [Oracle Cloud Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Concepts/objectstorageoverview.htm) as a destination for Velero backups.
|
||||
|
||||
1. [Download Velero](#download-velero)
|
||||
2. [Create A Customer Secret Key](#create-a-customer-secret-key)
|
||||
|
@ -17,17 +17,17 @@ layout: docs
|
|||
|
||||
## Download Velero
|
||||
|
||||
1. Download the [latest release](https://github.com/vmware-tanzu/velero/releases/) of Velero to your development environment. This includes the `velero` CLI utility and example Kubernetes manifest files. For example:
|
||||
1. Download the [latest release](https://github.com/vmware-tanzu/velero/releases/) of Velero to your development environment. This includes the `velero` CLI utility and example Kubernetes manifest files. For example:
|
||||
|
||||
```
|
||||
wget https://github.com/vmware-tanzu/velero/releases/download/v1.0.0/velero-v1.0.0-linux-amd64.tar.gz
|
||||
```
|
||||
|
||||
*We strongly recommend that you use an official release of Velero. The tarballs for each release contain the velero command-line client. The code in the main branch of the Velero repository is under active development and is not guaranteed to be stable!*
|
||||
**NOTE:** Its strongly recommend that you use an official release of Velero. The tarballs for each release contain the velero command-line client. The code in the main branch of the Velero repository is under active development and is not guaranteed to be stable!
|
||||
|
||||
2. Untar the release in your `/usr/bin` directory: `tar -xzvf <RELEASE-TARBALL-NAME>.tar.gz`
|
||||
2. Untar the release in your `/usr/bin` directory: `tar -xzvf <RELEASE-TARBALL-NAME>.tar.gz`
|
||||
|
||||
You may choose to rename the directory `velero` for the sake of simplicty: `mv velero-v1.0.0-linux-amd64 velero`
|
||||
You may choose to rename the directory `velero` for the sake of simplicty: `mv velero-v1.0.0-linux-amd64 velero`
|
||||
|
||||
3. Add it to your PATH: `export PATH=/usr/local/bin/velero:$PATH`
|
||||
|
||||
|
@ -49,15 +49,15 @@ Usage:
|
|||
|
||||
|
||||
|
||||
## Create A Customer Secret Key
|
||||
## Create A Customer Secret Key
|
||||
|
||||
1. Oracle Object Storage provides an API to enable interoperability with Amazon S3. To use this Amazon S3 Compatibility API, you need to generate the signing key required to authenticate with Amazon S3. This special signing key is an Access Key/Secret Key pair. Follow these steps to [create a Customer Secret Key](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#To4). Refer to this link for more information about [Working with Customer Secret Keys](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#s3).
|
||||
1. Oracle Object Storage provides an API to enable interoperability with Amazon S3. To use this Amazon S3 Compatibility API, you need to generate the signing key required to authenticate with Amazon S3. This special signing key is an Access Key/Secret Key pair. Follow these steps to [create a Customer Secret Key](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#To4). Refer to this link for more information about [Working with Customer Secret Keys](https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingcredentials.htm#s3).
|
||||
|
||||
2. Create a Velero credentials file with your Customer Secret Key:
|
||||
|
||||
```
|
||||
$ vi credentials-velero
|
||||
|
||||
$ vi credentials-velero
|
||||
|
||||
[default]
|
||||
aws_access_key_id=bae031188893d1eb83719648790ac850b76c9441
|
||||
aws_secret_access_key=MmY9heKrWiNVCSZQ2Mf5XTJ6Ys93Bw2d2D6NMSTXZlk=
|
||||
|
@ -65,15 +65,15 @@ Usage:
|
|||
|
||||
|
||||
|
||||
## Create An Oracle Object Storage Bucket
|
||||
## Create An Oracle Object Storage Bucket
|
||||
|
||||
Create an Oracle Cloud Object Storage bucket called `velero` in the root compartment of your Oracle Cloud tenancy. Refer to this page for [more information about creating a bucket with Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Tasks/managingbuckets.htm#usingconsole).
|
||||
Create an Oracle Cloud Object Storage bucket called `velero` in the root compartment of your Oracle Cloud tenancy. Refer to this page for [more information about creating a bucket with Object Storage](https://docs.cloud.oracle.com/iaas/Content/Object/Tasks/managingbuckets.htm#usingconsole).
|
||||
|
||||
|
||||
|
||||
## Install Velero
|
||||
## Install Velero
|
||||
|
||||
You will need the following information to install Velero into your Kubernetes cluster with Oracle Object Storage as the Backup Storage provider:
|
||||
You will need the following information to install Velero into your Kubernetes cluster with Oracle Object Storage as the Backup Storage provider:
|
||||
|
||||
```
|
||||
velero install \
|
||||
|
@ -85,14 +85,14 @@ velero install \
|
|||
--backup-location-config region=[region],s3ForcePathStyle="true",s3Url=[storage API endpoint]
|
||||
```
|
||||
|
||||
- `--provider` Because we are using the S3-compatible API, we will use `aws` as our provider.
|
||||
- `--provider` This example uses the S3-compatible API, so use `aws` as the provider.
|
||||
- `--bucket` The name of the bucket created in Oracle Object Storage - in our case this is named `velero`.
|
||||
- ` --prefix` The name of your Oracle Cloud tenancy - in our case this is named `oracle-cloudnative`.
|
||||
- `--use-volume-snapshots=false` Velero does not currently have a volume snapshot plugin for Oracle Cloud creating volume snapshots is disabled.
|
||||
- `--use-volume-snapshots=false` Velero does not have a volume snapshot plugin for Oracle Cloud, so creating volume snapshots is disabled.
|
||||
- `--secret-file` The path to your `credentials-velero` file.
|
||||
- `--backup-location-config` The path to your Oracle Object Storage bucket. This consists of your `region` which corresponds to your Oracle Cloud region name ([List of Oracle Cloud Regions](https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm?Highlight=regions)) and the `s3Url`, the S3-compatible API endpoint for Oracle Object Storage based on your region: `https://oracle-cloudnative.compat.objectstorage.[region name].oraclecloud.com`
|
||||
|
||||
For example:
|
||||
For example:
|
||||
|
||||
```
|
||||
velero install \
|
||||
|
@ -104,7 +104,7 @@ velero install \
|
|||
--backup-location-config region=us-phoenix-1,s3ForcePathStyle="true",s3Url=https://oracle-cloudnative.compat.objectstorage.us-phoenix-1.oraclecloud.com
|
||||
```
|
||||
|
||||
This will create a `velero` namespace in your cluster along with a number of CRDs, a ClusterRoleBinding, ServiceAccount, Secret, and Deployment for Velero. If your pod fails to successfully provision, you can troubleshoot your installation by running: `kubectl logs [velero pod name]`.
|
||||
This will create a `velero` namespace in your cluster along with a number of CRDs, a ClusterRoleBinding, ServiceAccount, Secret, and Deployment for Velero. If your pod fails to successfully provision, you can troubleshoot your installation by running: `kubectl logs [velero pod name]`.
|
||||
|
||||
|
||||
|
||||
|
@ -117,19 +117,19 @@ kubectl delete namespace/velero clusterrolebinding/velero
|
|||
kubectl delete crds -l component=velero
|
||||
```
|
||||
|
||||
This will remove all resources created by `velero install`.
|
||||
This will remove all resources created by `velero install`.
|
||||
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
After creating the Velero server in your cluster, try this example:
|
||||
After creating the Velero server in your cluster, try this example:
|
||||
|
||||
### Basic example (without PersistentVolumes)
|
||||
|
||||
1. Start the sample nginx app: `kubectl apply -f examples/nginx-app/base.yaml`
|
||||
|
||||
This will create an `nginx-example` namespace with a `nginx-deployment` deployment, and `my-nginx` service.
|
||||
This will create an `nginx-example` namespace with a `nginx-deployment` deployment, and `my-nginx` service.
|
||||
|
||||
```
|
||||
$ kubectl apply -f examples/nginx-app/base.yaml
|
||||
|
@ -145,13 +145,13 @@ After creating the Velero server in your cluster, try this example:
|
|||
NAME READY STATUS RESTARTS AGE
|
||||
pod/nginx-deployment-67594d6bf6-4296p 1/1 Running 0 20s
|
||||
pod/nginx-deployment-67594d6bf6-f9r5s 1/1 Running 0 20s
|
||||
|
||||
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
service/my-nginx LoadBalancer 10.96.69.166 <pending> 80:31859/TCP 21s
|
||||
|
||||
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
deployment.apps/nginx-deployment 2 2 2 2 21s
|
||||
|
||||
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
replicaset.apps/nginx-deployment-67594d6bf6 2 2 2 21s
|
||||
```
|
||||
|
@ -164,7 +164,7 @@ After creating the Velero server in your cluster, try this example:
|
|||
Run `velero backup describe nginx-backup` or `velero backup logs nginx-backup` for more details.
|
||||
```
|
||||
|
||||
At this point you can navigate to appropriate bucket, which we called `velero`, in the Oracle Cloud Object Storage console to see the resources backed up using Velero.
|
||||
At this point you can navigate to appropriate bucket, called `velero`, in the Oracle Cloud Object Storage console to see the resources backed up using Velero.
|
||||
|
||||
3. Simulate a disaster by deleting the `nginx-example` namespace: `kubectl delete namespaces nginx-example`
|
||||
|
||||
|
@ -191,7 +191,7 @@ After creating the Velero server in your cluster, try this example:
|
|||
Run `velero restore describe nginx-backup-20190604102710` or `velero restore logs nginx-backup-20190604102710` for more details.
|
||||
```
|
||||
|
||||
Running `kubectl get namespaces` will show that the `nginx-example` namespace has been restored along with its contents.
|
||||
Running `kubectl get namespaces` will show that the `nginx-example` namespace has been restored along with its contents.
|
||||
|
||||
5. Run: `velero restore get` to view the list of restored resources. After the restore finishes, the output looks like the following:
|
||||
|
||||
|
@ -201,14 +201,14 @@ After creating the Velero server in your cluster, try this example:
|
|||
nginx-backup-20190604104249 nginx-backup Completed 0 0 2019-06-04 10:42:39 -0700 PDT <none>
|
||||
```
|
||||
|
||||
NOTE: The restore can take a few moments to finish. During this time, the `STATUS` column reads `InProgress`.
|
||||
NOTE: The restore can take a few moments to finish. During this time, the `STATUS` column reads `InProgress`.
|
||||
|
||||
After a successful restore, the `STATUS` column shows `Completed`, and `WARNINGS` and `ERRORS` will show `0`. All objects in the `nginx-example` namespace should be just as they were before you deleted them.
|
||||
|
||||
If there are errors or warnings, for instance if the `STATUS` column displays `FAILED` instead of `InProgress`, you can look at them in detail with `velero restore describe <RESTORE_NAME>`
|
||||
|
||||
|
||||
6. Clean up the environment with `kubectl delete -f examples/nginx-app/base.yaml`
|
||||
6. Clean up the environment with `kubectl delete -f examples/nginx-app/base.yaml`
|
||||
|
||||
```
|
||||
$ kubectl delete -f examples/nginx-app/base.yaml
|
||||
|
@ -229,20 +229,20 @@ After creating the Velero server in your cluster, try this example:
|
|||
This asks the Velero server to delete all backup data associated with `BACKUP_NAME`. You need to do this for each backup you want to permanently delete. A future version of Velero will allow you to delete multiple backups by name or label selector.
|
||||
|
||||
Once fully removed, the backup is no longer visible when you run: `velero backup get BACKUP_NAME` or more generally `velero backup get`:
|
||||
|
||||
|
||||
```
|
||||
$ velero backup get nginx-backup
|
||||
An error occurred: backups.velero.io "nginx-backup" not found
|
||||
```
|
||||
|
||||
```
|
||||
$ velero backup get
|
||||
NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTOR
|
||||
$ velero backup get
|
||||
NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTOR
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Additional Reading
|
||||
## Additional Reading
|
||||
|
||||
* [Official Velero Documentation](https://velero.io/docs/v1.5.0-beta.1/)
|
||||
* [Official Velero Documentation](https://velero.io/docs/v1.5.0-rc.1/)
|
||||
* [Oracle Cloud Infrastructure Documentation](https://docs.cloud.oracle.com/)
|
|
@ -9,7 +9,7 @@ Integrating Container Storage Interface (CSI) snapshot support into Velero enabl
|
|||
|
||||
By supporting CSI snapshot APIs, Velero can support any volume provider that has a CSI driver, without requiring a Velero-specific plugin to be available.
|
||||
|
||||
# Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
The following are the prerequisites for using Velero to take Container Storage Interface (CSI) snapshots:
|
||||
|
||||
|
@ -17,7 +17,7 @@ The following are the prerequisites for using Velero to take Container Storage I
|
|||
1. The cluster is running a CSI driver capable of support volume snapshots at the [v1beta1 API level](https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-feature-cis-volume-snapshot-beta/).
|
||||
1. When restoring CSI volumesnapshots across clusters, the name of the CSI driver in the destination cluster is the same as that on the source cluster to ensure cross cluster portability of CSI volumesnapshots
|
||||
|
||||
# Installing Velero with CSI support
|
||||
## Installing Velero with CSI support
|
||||
|
||||
Ensure that the Velero server is running with the `EnableCSI` feature flag. See [Enabling Features][1] for more information.
|
||||
Also, the Velero [CSI plugin][2] ([Docker Hub][3]) is necessary to integrate with the CSI volume snapshot APIs.
|
||||
|
@ -34,7 +34,7 @@ velero install \
|
|||
To include the status of CSI objects associated with a Velero backup in `velero backup describe` output, run `velero client config set features=EnableCSI`.
|
||||
See [Enabling Features][1] for more information about managing client-side feature flags.
|
||||
|
||||
# Implementation Choices
|
||||
## Implementation Choices
|
||||
|
||||
This section documents some of the choices made during implementation of the Velero [CSI plugin][2]:
|
||||
|
||||
|
@ -45,12 +45,12 @@ This section documents some of the choices made during implementation of the Vel
|
|||
velero.io/csi-volumesnapshot-class: "true"
|
||||
```
|
||||
|
||||
# Roadmap
|
||||
## Roadmap
|
||||
|
||||
Velero's support level for CSI volume snapshotting will follow upstream Kubernetes support for the feature, and will reach general availability sometime
|
||||
after volume snapshotting is GA in upstream Kubernetes. Beta support is expected to launch in Velero v1.4.
|
||||
|
||||
# How it Works - Overview
|
||||
## How it Works - Overview
|
||||
|
||||
Velero's CSI support does not rely on the Velero VolumeSnapshotter plugin interface.
|
||||
|
||||
|
@ -68,7 +68,7 @@ When Velero synchronizes backups into a new cluster, VolumeSnapshotContent objec
|
|||
|
||||
The `DeletionPolicy` on the VolumeSnapshotContent will be the same as the `DeletionPolicy` on the VolumeSnapshotClass that was used to create the VolumeSnapshot. Setting a `DeletionPolicy` of `Retain` on the VolumeSnapshotClass will preserve the volume snapshot in the storage system for the lifetime of the Velero backup and will prevent the deletion of the volume snapshot, in the storage system, in the event of a disaster where the namespace with the VolumeSnapshot object may be lost.
|
||||
|
||||
When the Velero backup expires, the VolumeSnapshot objects will be deleted and the VolumeSnapshotContent objects will be updated to have a `DeletionPolicy` of `Delete`, in order to free space on the storage system.
|
||||
When the Velero backup expires, the VolumeSnapshot objects will be deleted and the VolumeSnapshotContent objects will be updated to have a `DeletionPolicy` of `Delete`, to free space on the storage system.
|
||||
|
||||
For more details on how each plugin works, see the [CSI plugin repo][2]'s documentation.
|
||||
|
|
@ -29,7 +29,7 @@ You will need to give your plugin(s) a name when registering them by calling the
|
|||
|
||||
## Plugin Kinds
|
||||
|
||||
Velero currently supports the following kinds of plugins:
|
||||
Velero supports the following kinds of plugins:
|
||||
|
||||
- **Object Store** - persists and retrieves backups, backup logs and restore logs
|
||||
- **Volume Snapshotter** - creates volume snapshots (during backup) and restores volumes from snapshots (during restore)
|
||||
|
@ -46,7 +46,7 @@ plugins will also emit debug-level logs. See the [sample repository][1] for an e
|
|||
|
||||
## Plugin Configuration
|
||||
|
||||
Velero uses a ConfigMap-based convention for providing configuration to plugins. If your plugin needs to be configured at runtime,
|
||||
Velero uses a ConfigMap-based convention for providing configuration to plugins. If your plugin needs to be configured at runtime,
|
||||
define a ConfigMap like the following:
|
||||
|
||||
```yaml
|
||||
|
@ -56,19 +56,19 @@ metadata:
|
|||
# any name can be used; Velero uses the labels (below)
|
||||
# to identify it rather than the name
|
||||
name: my-plugin-config
|
||||
|
||||
|
||||
# must be in the namespace where the velero deployment
|
||||
# is running
|
||||
namespace: velero
|
||||
|
||||
|
||||
labels:
|
||||
# this value-less label identifies the ConfigMap as
|
||||
# config for a plugin (i.e. the built-in change storageclass
|
||||
# config for a plugin (the built-in change storageclass
|
||||
# restore item action plugin)
|
||||
velero.io/plugin-config: ""
|
||||
|
||||
|
||||
# add a label whose key corresponds to the fully-qualified
|
||||
# plugin name (e.g. mydomain.io/my-plugin-name), and whose
|
||||
# plugin name (for example mydomain.io/my-plugin-name), and whose
|
||||
# value is the plugin type (BackupItemAction, RestoreItemAction,
|
||||
# ObjectStore, or VolumeSnapshotter)
|
||||
<fully-qualified-plugin-name>: <plugin-type>
|
||||
|
@ -91,5 +91,5 @@ Once parsed into a `[]string`, the features can then be registered using the `Ne
|
|||
Velero adds the `LD_LIBRARY_PATH` into the list of environment variables to provide the convenience for plugins that requires C libraries/extensions in the runtime.
|
||||
|
||||
[1]: https://github.com/vmware-tanzu/velero-plugin-example
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/pkg/plugin/logger.go
|
||||
[3]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/pkg/restore/restic_restore_action.go
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/pkg/plugin/logger.go
|
||||
[3]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/pkg/restore/restic_restore_action.go
|
|
@ -3,34 +3,6 @@ title: "Customize Velero Install"
|
|||
layout: docs
|
||||
---
|
||||
|
||||
- [Customize Velero Install](#customize-velero-install)
|
||||
- [Plugins](#plugins)
|
||||
- [Install in any namespace](#install-in-any-namespace)
|
||||
- [Use non-file-based identity mechanisms](#use-non-file-based-identity-mechanisms)
|
||||
- [Enable restic integration](#enable-restic-integration)
|
||||
- [Enable default use of restic to backup pod volumes](#default-pod-volume-backup-to-restic)
|
||||
- [Enable features](#enable-features)
|
||||
- [Enable server side features](#enable-server-side-features)
|
||||
- [Enable client side features](#enable-client-side-features)
|
||||
- [Customize resource requests and limits](#customize-resource-requests-and-limits)
|
||||
- [Install with custom resource requests and limits](#install-with-custom-resource-requests-and-limits)
|
||||
- [Update resource requests and limits after install](#update-resource-requests-and-limits-after-install)
|
||||
- [Configure more than one storage location for backups or volume snapshots](#configure-more-than-one-storage-location-for-backups-or-volume-snapshots)
|
||||
- [Do not configure a backup storage location during install](#do-not-configure-a-backup-storage-location-during-install)
|
||||
- [Install an additional volume snapshot provider](#install-an-additional-volume-snapshot-provider)
|
||||
- [Generate YAML only](#generate-yaml-only)
|
||||
- [Use a storage provider secured by a self-signed certificate](#use-a-storage-provider-secured-by-a-self-signed-certificate)
|
||||
- [Additional options](#additional-options)
|
||||
- [Optional Velero CLI configurations](#optional-velero-cli-configurations)
|
||||
- [Enabling shell autocompletion](#enabling-shell-autocompletion)
|
||||
- [Bash on Linux](#bash-on-linux)
|
||||
- [Install bash-completion](#install-bash-completion)
|
||||
- [Enable Velero CLI autocompletion for Bash on Linux](#enable-velero-cli-autocompletion-for-bash-on-linux)
|
||||
- [Bash on macOS](#bash-on-macos)
|
||||
- [Install bash-completion](#install-bash-completion-1)
|
||||
- [Enable Velero CLI autocompletion for Bash on macOS](#enable-velero-cli-autocompletion-for-bash-on-macos)
|
||||
- [Autocompletion on Zsh](#autocompletion-on-zsh)
|
||||
|
||||
## Plugins
|
||||
|
||||
During install, Velero requires that at least one plugin is added (with the `--plugins` flag). Please see the documentation under [Plugins](overview-plugins.md)
|
||||
|
@ -102,13 +74,14 @@ velero client config set features=
|
|||
|
||||
At installation, Velero sets default resource requests and limits for the Velero pod and the restic pod, if you using the [restic integration](/docs/main/restic/).
|
||||
|
||||
<table caption="Velero Customize resource requests and limits defaults" >
|
||||
<tr><th>Setting</th><th>Velero pod defaults</th><th>restic pod defaults</th></tr>
|
||||
<tr><td>CPU request</td><td>500m</td><td>500m</td></tr>
|
||||
<tr><td>Memory requests</td><td>128Mi</td><td>512Mi</td></tr>
|
||||
<tr><td>CPU limit</td><td>1000m (1 CPU)</td><td>1000m (1 CPU)</td></tr>
|
||||
<tr><td>Memory limit</td><td>256Mi</td><td>1024Mi</td></tr>
|
||||
</table>
|
||||
{{< table caption="Velero Customize resource requests and limits defaults" >}}
|
||||
|Setting|Velero pod defaults|restic pod defaults|
|
||||
|--- |--- |--- |
|
||||
|CPU request|500m|500m|
|
||||
|Memory requests|128Mi|512Mi|
|
||||
|CPU limit|1000m (1 CPU)|1000m (1 CPU)|
|
||||
|Memory limit|256Mi|1024Mi|
|
||||
{{< /table >}}
|
||||
|
||||
### Install with custom resource requests and limits
|
||||
|
||||
|
@ -375,4 +348,4 @@ If you get an error like `complete:13: command not found: compdef`, then add the
|
|||
[8]: https://github.com/vmware-tanzu/velero/issues/2311
|
||||
[9]: self-signed-certificates.md
|
||||
[10]: csi.md
|
||||
[11]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/pkg/apis/velero/v1/constants.go
|
||||
[11]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/pkg/apis/velero/v1/constants.go
|
|
@ -44,7 +44,7 @@ into the Velero server pod. Ensure the following:
|
|||
#### Using kube2iam
|
||||
This means that Velero can't read the content of the S3 bucket. Ensure the following:
|
||||
|
||||
* There is a Trust Policy document allowing the role used by kube2iam to assume Velero's role, as stated in the AWS config documentation.
|
||||
* A Trust Policy document exists that allows the role used by kube2iam to assume Velero's role, as stated in the AWS config documentation.
|
||||
* The new Velero role has all the permissions listed in the documentation regarding S3.
|
||||
|
||||
|
|
@ -3,9 +3,6 @@ title: "Debugging Restores"
|
|||
layout: docs
|
||||
---
|
||||
|
||||
* [Example][0]
|
||||
* [Structure][1]
|
||||
|
||||
## Example
|
||||
|
||||
When Velero finishes a Restore, its status changes to "Completed" regardless of whether or not there are issues during the process. The number of warnings and errors are indicated in the output columns from `velero restore get`:
|
||||
|
@ -93,17 +90,14 @@ Errors:
|
|||
|
||||
## Structure
|
||||
|
||||
Errors appear for incomplete or partial restores. Warnings appear for non-blocking issues (e.g. the
|
||||
Errors appear for incomplete or partial restores. Warnings appear for non-blocking issues, for example, the
|
||||
restore looks "normal" and all resources referenced in the backup exist in some form, although some
|
||||
of them may have been pre-existing).
|
||||
of them may have been pre-existing.
|
||||
|
||||
Both errors and warnings are structured in the same way:
|
||||
|
||||
* `Velero`: A list of system-related issues encountered by the Velero server (e.g. couldn't read directory).
|
||||
* `Velero`: A list of system-related issues encountered by the Velero server. For example, Velero couldn't read a directory.
|
||||
|
||||
* `Cluster`: A list of issues related to the restore of cluster-scoped resources.
|
||||
|
||||
* `Namespaces`: A map of namespaces to the list of issues related to the restore of their respective resources.
|
||||
|
||||
[0]: #example
|
||||
[1]: #structure
|
|
@ -5,7 +5,7 @@ layout: docs
|
|||
|
||||
After you set up the Velero server, try these examples:
|
||||
|
||||
### Basic example (without PersistentVolumes)
|
||||
## Basic example (without PersistentVolumes)
|
||||
|
||||
1. Start the sample nginx app:
|
||||
|
||||
|
@ -33,7 +33,7 @@ After you set up the Velero server, try these examples:
|
|||
velero restore create --from-backup nginx-backup
|
||||
```
|
||||
|
||||
### Snapshot example (with PersistentVolumes)
|
||||
## Snapshot example (with PersistentVolumes)
|
||||
|
||||
> NOTE: For Azure, you must run Kubernetes version 1.7.2 or later to support PV snapshotting of managed disks.
|
||||
|
|
@ -9,7 +9,7 @@ This document describes Velero's image tagging policy.
|
|||
|
||||
`velero/velero:<SemVer>`
|
||||
|
||||
Velero follows the [Semantic Versioning](http://semver.org/) standard for releases. Each tag in the `github.com/vmware-tanzu/velero` repository has a matching image, e.g. `velero/velero:v1.0.0`.
|
||||
Velero follows the [Semantic Versioning](http://semver.org/) standard for releases. Each tag in the `github.com/vmware-tanzu/velero` repository has a matching image, `velero/velero:v1.0.0`.
|
||||
|
||||
### Latest
|
||||
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
|
@ -7,17 +7,17 @@ layout: docs
|
|||
|
||||
Velero has two custom resources, `BackupStorageLocation` and `VolumeSnapshotLocation`, that are used to configure where Velero backups and their associated persistent volume snapshots are stored.
|
||||
|
||||
A `BackupStorageLocation` is defined as a bucket, a prefix within that bucket under which all Velero data should be stored, and a set of additional provider-specific fields (e.g. AWS region, Azure storage account, etc.) The [API documentation][1] captures the configurable parameters for each in-tree provider.
|
||||
A `BackupStorageLocation` is defined as a bucket, a prefix within that bucket under which all Velero data is stored, and a set of additional provider-specific fields (AWS region, Azure storage account, etc.) The [API documentation][1] captures the configurable parameters for each in-tree provider.
|
||||
|
||||
A `VolumeSnapshotLocation` is defined entirely by provider-specific fields (e.g. AWS region, Azure resource group, Portworx snapshot type, etc.) The [API documentation][2] captures the configurable parameters for each in-tree provider.
|
||||
A `VolumeSnapshotLocation` is defined entirely by provider-specific fields (AWS region, Azure resource group, Portworx snapshot type, etc.) The [API documentation][2] captures the configurable parameters for each in-tree provider.
|
||||
|
||||
The user can pre-configure one or more possible `BackupStorageLocations` and one or more `VolumeSnapshotLocations`, and can select *at backup creation time* the location in which the backup and associated snapshots should be stored.
|
||||
|
||||
This configuration design enables a number of different use cases, including:
|
||||
|
||||
- Take snapshots of more than one kind of persistent volume in a single Velero backup (e.g. in a cluster with both EBS volumes and Portworx volumes)
|
||||
- Take snapshots of more than one kind of persistent volume in a single Velero backup. For example, in a cluster with both EBS volumes and Portworx volumes
|
||||
- Have some Velero backups go to a bucket in an eastern USA region, and others go to a bucket in a western USA region
|
||||
- For volume providers that support it (e.g. Portworx), have some snapshots be stored locally on the cluster and have others be stored in the cloud
|
||||
- For volume providers that support it, like Portworx, you can have some snapshots stored locally on the cluster and have others stored in the cloud
|
||||
|
||||
## Limitations / Caveats
|
||||
|
||||
|
@ -27,15 +27,15 @@ This configuration design enables a number of different use cases, including:
|
|||
|
||||
- Each Velero backup has one `BackupStorageLocation`, and one `VolumeSnapshotLocation` per volume provider. It is not possible (yet) to send a single Velero backup to multiple backup storage locations simultaneously, or a single volume snapshot to multiple locations simultaneously. However, you can always set up multiple scheduled backups that differ only in the storage locations used if redundancy of backups across locations is important.
|
||||
|
||||
- Cross-provider snapshots are not supported. If you have a cluster with more than one type of volume (e.g. EBS and Portworx), but you only have a `VolumeSnapshotLocation` configured for EBS, then Velero will **only** snapshot the EBS volumes.
|
||||
- Cross-provider snapshots are not supported. If you have a cluster with more than one type of volume, like EBS and Portworx, but you only have a `VolumeSnapshotLocation` configured for EBS, then Velero will **only** snapshot the EBS volumes.
|
||||
|
||||
- Restic data is stored under a prefix/subdirectory of the main Velero bucket, and will go into the bucket corresponding to the `BackupStorageLocation` selected by the user at backup creation time.
|
||||
|
||||
## Examples
|
||||
|
||||
Let's look at some examples of how we can use this configuration mechanism to address some common use cases:
|
||||
Let's look at some examples of how you can use this configuration mechanism to address some common use cases:
|
||||
|
||||
#### Take snapshots of more than one kind of persistent volume in a single Velero backup (e.g. in a cluster with both EBS volumes and Portworx volumes)
|
||||
### Take snapshots of more than one kind of persistent volume in a single Velero backup
|
||||
|
||||
During server configuration:
|
||||
|
||||
|
@ -62,7 +62,7 @@ Alternately, since in this example there's only one possible volume snapshot loc
|
|||
velero backup create full-cluster-backup
|
||||
```
|
||||
|
||||
#### Have some Velero backups go to a bucket in an eastern USA region, and others go to a bucket in a western USA region
|
||||
### Have some Velero backups go to a bucket in an eastern USA region, and others go to a bucket in a western USA region
|
||||
|
||||
During server configuration:
|
||||
|
||||
|
@ -95,7 +95,7 @@ velero backup create full-cluster-alternate-location-backup \
|
|||
--storage-location s3-alt-region
|
||||
```
|
||||
|
||||
#### For volume providers that support it (e.g. Portworx), have some snapshots be stored locally on the cluster and have others be stored in the cloud
|
||||
### For volume providers that support it (like Portworx), have some snapshots be stored locally on the cluster and have others be stored in the cloud
|
||||
|
||||
During server configuration:
|
||||
|
||||
|
@ -112,8 +112,8 @@ velero snapshot-location create portworx-cloud \
|
|||
During backup creation:
|
||||
|
||||
```shell
|
||||
# Note that since in this example we have two possible volume snapshot locations for the Portworx
|
||||
# provider, we need to explicitly specify which one to use when creating a backup. Alternately,
|
||||
# Note that since in this example you have two possible volume snapshot locations for the Portworx
|
||||
# provider, you need to explicitly specify which one to use when creating a backup. Alternately,
|
||||
# you can set the --default-volume-snapshot-locations flag on the `velero server` command (run by
|
||||
# the Velero deployment) to specify which location should be used for each provider by default, in
|
||||
# which case you don't need to specify it when creating a backup.
|
||||
|
@ -128,7 +128,7 @@ velero backup create cloud-snapshot-backup \
|
|||
--volume-snapshot-locations portworx-cloud
|
||||
```
|
||||
|
||||
#### Use a single location
|
||||
### Use a single location
|
||||
|
||||
If you don't have a use case for more than one location, it's still easy to use Velero. Let's assume you're running on AWS, in the `us-west-1` region:
|
||||
|
|
@ -5,7 +5,7 @@ layout: docs
|
|||
|
||||
*Using Backups and Restores*
|
||||
|
||||
Velero can help you port your resources from one cluster to another, as long as you point each Velero instance to the same cloud object storage location. In this scenario, we are also assuming that your clusters are hosted by the same cloud provider. **Note that Velero does not natively support the migration of persistent volumes snapshots across cloud providers.** If you would like to migrate volume data between cloud platforms, please enable [restic][2], which will backup volume contents at the filesystem level.
|
||||
Velero can help you port your resources from one cluster to another, as long as you point each Velero instance to the same cloud object storage location. This scenario assumes that your clusters are hosted by the same cloud provider. **Note that Velero does not natively support the migration of persistent volumes snapshots across cloud providers.** If you would like to migrate volume data between cloud platforms, please enable [restic][2], which will backup volume contents at the filesystem level.
|
||||
|
||||
1. *(Cluster 1)* Assuming you haven't already been checkpointing your data with the Velero `schedule` operation, you need to first back up your entire cluster (replacing `<BACKUP-NAME>` as desired):
|
||||
|
||||
|
@ -13,7 +13,7 @@ Velero can help you port your resources from one cluster to another, as long as
|
|||
velero backup create <BACKUP-NAME>
|
||||
```
|
||||
|
||||
The default backup retention period, expressed as TTL (time to live), is 30 days (720 hours); you can use the `--ttl <DURATION>` flag to change this as necessary. See [how velero works][1] for more information about backup expiry.
|
||||
The default backup retention period, expressed as TTL (time to live), is 30 days (720 hours); you can use the `--ttl <DURATION>` flag to change this as necessary. See [how velero works][1] for more information about backup expiry.
|
||||
|
||||
1. *(Cluster 2)* Configure `BackupStorageLocations` and `VolumeSnapshotLocations`, pointing to the locations used by *Cluster 1*, using `velero backup-location create` and `velero snapshot-location create`. Make sure to configure the `BackupStorageLocations` as read-only
|
||||
by using the `--access-mode=ReadOnly` flag for `velero backup-location create`.
|
|
@ -5,11 +5,11 @@ layout: docs
|
|||
|
||||
The Velero installation and backups by default are run in the `velero` namespace. However, it is possible to use a different namespace.
|
||||
|
||||
### 1) Customize the namespace during install
|
||||
## Customize the namespace during install
|
||||
|
||||
Use the `--namespace` flag, in conjunction with the other flags in the `velero install` command (as shown in the [the Velero install instructions][0]). This will inform Velero where to install.
|
||||
|
||||
### 2) Customize the namespace for operational commands
|
||||
## Customize the namespace for operational commands
|
||||
|
||||
To have namespace consistency, specify the namespace for all Velero operational commands to be the same as the namespace used to install Velero:
|
||||
|
|
@ -14,9 +14,9 @@ If you do not already have an object storage system, [MinIO][2] is an open-sourc
|
|||
|
||||
### (Optional) Selecting volume snapshot providers
|
||||
|
||||
If you need to back up persistent volume data, you must select a volume backup solution. [Supported providers][0] contains information on the supported options.
|
||||
If you need to back up persistent volume data, you must select a volume backup solution. [Supported providers][0] contains information on the supported options.
|
||||
|
||||
For example, if you use [Portworx][4] for persistent storage, you can install their Velero plugin to get native Portworx snapshots as part of your Velero backups.
|
||||
For example, if you use [Portworx][4] for persistent storage, you can install their Velero plugin to get native Portworx snapshots as part of your Velero backups.
|
||||
|
||||
If there is no native snapshot plugin available for your storage platform, you can use Velero's [restic integration][1], which provides a platform-agnostic file-level backup solution for volume data.
|
||||
|
||||
|
@ -34,7 +34,7 @@ First, download the Velero image, tag it for the your private registry, then upl
|
|||
|
||||
```bash
|
||||
PRIVATE_REG=<your private registry>
|
||||
VELERO_VERSION=<version of Velero you're targetting, e.g. v1.4.0>
|
||||
VELERO_VERSION=<version of Velero you're targeting, for example v1.4.0>
|
||||
|
||||
docker pull velero/velero:$VELERO_VERSION
|
||||
docker tag velero/velero:$VELERO_VERSION $PRIVATE_REG/velero:$VELERO_VERSION
|
||||
|
@ -47,7 +47,7 @@ Next, repeat these steps for any plugins you may need. This example will use the
|
|||
|
||||
```bash
|
||||
PRIVATE_REG=<your private registry>
|
||||
PLUGIN_VERSION=<version of plugin you're targetting, e.g. v1.0.2>
|
||||
PLUGIN_VERSION=<version of plugin you're targeting, for example v1.0.2>
|
||||
|
||||
docker pull velero/velero-plugin-for-aws:$PLUGIN_VERSION
|
||||
docker tag velero/velero-plugin-for-aws:$PLUGIN_VERSION $PRIVATE_REG/velero-plugin-for-aws:$PLUGIN_VERSION
|
||||
|
@ -60,7 +60,7 @@ If you are using restic, you will also need to upload the restic helper image.
|
|||
|
||||
```bash
|
||||
PRIVATE_REG=<your private registry>
|
||||
VELERO_VERSION=<version of Velero you're targetting, e.g. v1.4.0>
|
||||
VELERO_VERSION=<version of Velero you're targeting, for example v1.4.0>
|
||||
|
||||
docker pull velero/velero-restic-restore-helper:$VELERO_VERSION
|
||||
docker tag velero/velero-restic-restore-helper:$VELERO_VERSION $PRIVATE_REG/velero-restic-restore-helper:$VELERO_VERSION
|
|
@ -63,9 +63,9 @@ Note that this file includes detailed info about your volume snapshots in the `s
|
|||
|
||||
## Output File Format Versioning
|
||||
|
||||
The Velero output file format is intended to be relatively stable, but may change over time in order to support new features.
|
||||
The Velero output file format is intended to be relatively stable, but may change over time to support new features.
|
||||
|
||||
In order to accommodate this, Velero follows [Semantic Versioning](http://semver.org/) for the file format version.
|
||||
To accommodate this, Velero follows [Semantic Versioning](http://semver.org/) for the file format version.
|
||||
|
||||
Minor and patch versions will indicate backwards-compatible changes that previous versions of Velero can restore, including new directories or files.
|
||||
|
||||
|
@ -78,12 +78,12 @@ However, a major version release of Velero does not necessarily mean that the ba
|
|||
|
||||
### File Format Version: 1.1 (Current)
|
||||
|
||||
In version 1.1, we have added the support of API groups versions as part of the backup (previously, only the preferred version of each API Groups was backed up). Each resource has one or more sub-directories, one sub-directory for each supported version of the API group. The preferred version API Group of each resource has the suffix "-preferredversion" as part of the sub-directory name. For backward compatibility, we kept the classic directory structure without the API Group version, which sits on the same level as the API Group sub-directory versions.
|
||||
By default, only the preferred API group of each resource is backed up.
|
||||
In order to take a backup of all API group versions, you need to run the Velero server with `--features=EnableAPIGroupVersions` feature flag. This is an experimental flag and the restore logic to handle multiple API Group Versions will be added in the future.
|
||||
Version 1.1 added support of API groups versions as part of the backup (previously, only the preferred version of each API Groups was backed up). Each resource has one or more sub-directories, one sub-directory for each supported version of the API group. The preferred version API Group of each resource has the suffix "-preferredversion" as part of the sub-directory name. For backward compatibility, we kept the classic directory structure without the API Group version, which sits on the same level as the API Group sub-directory versions.
|
||||
By default, only the preferred API group of each resource is backed up.
|
||||
To take a backup of all API group versions, you need to run the Velero server with `--features=EnableAPIGroupVersions` feature flag. This is an experimental flag and the restore logic to handle multiple API Group Versions will be added in the future.
|
||||
|
||||
|
||||
When unzipped, a typical backup directory (e.g. `backup1234.tar.gz`) taken with this file format version looks like the following (with the feature flag):
|
||||
When unzipped, a typical backup directory (`backup1234.tar.gz`) taken with this file format version looks like the following (with the feature flag):
|
||||
|
||||
```
|
||||
resources/
|
||||
|
@ -185,7 +185,7 @@ resources/
|
|||
|
||||
### File Format Version: 1
|
||||
|
||||
When unzipped, a typical backup directory (e.g. `backup1234.tar.gz`) looks like the following:
|
||||
When unzipped, a typical backup directory (`backup1234.tar.gz`) looks like the following:
|
||||
|
||||
```
|
||||
resources/
|
|
@ -3,13 +3,26 @@ title: "Release Instructions"
|
|||
layout: docs
|
||||
---
|
||||
|
||||
## Ahead of Time
|
||||
This page covers the steps to perform when releasing a new version of Velero.
|
||||
|
||||
### (GA Only) Release Blog Post PR
|
||||
## Preparing for a release
|
||||
|
||||
Prepare a PR containing the release blog post. It's usually easiest to make a copy of the most recent existing post, then replace the content as appropriate.
|
||||
### (GA Only) Create release blog post
|
||||
|
||||
You also need to update `site/index.html` to have "Latest Release Information" contain a link to the new post.
|
||||
For each major or minor release, create and publish a blog post to let folks know what's new.
|
||||
|
||||
What to include in a release blog:
|
||||
* Thank all contributors for their involvement in the release.
|
||||
* Where possible shoutout folks by name or consider spotlighting new maintainers.
|
||||
* Highlight the themes, or areas of focus, for the release. Some examples of themes are security, bug fixes, feature improvements. See past Velero [release blog posts][1] for more examples.
|
||||
* Include summaries of new features or workflows introduced in a release.
|
||||
* This can also include new project initiatives, like a code-of-conduct update.
|
||||
* Consider creating additional blog posts that go through new features in more detail. Plan to publish additional blogs after the release blog (all blogs don’t have to be publish all at once).
|
||||
|
||||
Release blog post PR:
|
||||
* Prepare a PR containing the release blog post. Read the [website guidelines][2] for more information on creating a blog post. It's usually easiest to make a copy of the most recent existing post, then replace the content as appropriate.
|
||||
* You also need to update `site/index.html` to have "Latest Release Information" contain a link to the new post.
|
||||
* Plan to publish this blog the same day as the release.
|
||||
|
||||
### (Pre-Release and GA) Changelog and Docs PR
|
||||
|
||||
|
@ -36,7 +49,7 @@ You also need to update `site/index.html` to have "Latest Release Information" c
|
|||
|
||||
### (Pre-Release and GA) GitHub Token
|
||||
|
||||
To run the `goreleaser` process to generate a GitHub release, you'll need to have a GitHub token. See https://goreleaser.com/environment/ for more details.
|
||||
To run the `goreleaser` process to generate a GitHub release, you'll need to have a GitHub token. See https://goreleaser.com/environment/ for more details.
|
||||
|
||||
You may regenerate the token for every release if you prefer.
|
||||
|
||||
|
@ -52,39 +65,57 @@ You may regenerate the token for every release if you prefer.
|
|||
1. Click "Regenerate token".
|
||||
1. Save the token value somewhere - you'll need it during the release, in the `GITHUB_TOKEN` environment variable.
|
||||
|
||||
## During Release
|
||||
## Release steps
|
||||
|
||||
This process is the same for both pre-release and GA, except for the fact that there will not be a blog post PR to merge for pre-release versions.
|
||||
Once you have done the prep steps, use the steps below to perform a release. This process is the same for both pre-release and GA, except for the fact that there will not be a blog post PR to merge for pre-release versions.
|
||||
|
||||
1. Merge the changelog + docs PR, so that it's included in the release tag.
|
||||
|
||||
1. Set your GitHub token as an environment variable. `export GITHUB_TOKEN=<your token value>`
|
||||
1. Run `/hack/release-tools/tag-release.sh` and follow the instructions.
|
||||
1. Run `/hack/release-tools/tag-release.sh` and follow the instructions for a dry-run, without pushing to GitHub.
|
||||
1. Run `/hack/release-tools/tag-release.sh publish` and follow the instructions when everything looks good to publish to GitHub and create the release.
|
||||
|
||||
1. Navigate to the draft GitHub release, at https://github.com/vmware-tanzu/velero/releases.
|
||||
|
||||
1. If this is a patch release (e.g. `v1.2.1`), note that the full `CHANGELOG-1.2.md` contents will be included in the body of the GitHub release. You need to delete the previous releases' content (e.g. `v1.2.0`'s changelog) so that only the latest patch release's changelog shows.
|
||||
|
||||
1. Do a quick review for formatting. **Note:** the `goreleaser` process should detect if it's a pre-release version, and check that box in the GitHub release appropriately, but it's always worth double-checking.
|
||||
|
||||
1. Publish the release.
|
||||
|
||||
1. By now, the Docker images should have been published. Perform a smoke-test - for example:
|
||||
|
||||
- Download the CLI from the GitHub release
|
||||
- Use it to install Velero into a cluster (or manually update an existing deployment to use the new images)
|
||||
- Verify that `velero version` shows the expected output
|
||||
|
||||
- Run a backup/restore and ensure it works
|
||||
|
||||
1. (GA Only) Merge the blog post PR.
|
||||
1. Announce the release:
|
||||
- Twitter (mention a few highlights, link to the blog post)
|
||||
- Slack channel
|
||||
- Google group (this doesn't get a lot of traffic, and recent releases may not have been posted here)
|
||||
|
||||
### Post-release - Homebrew version update
|
||||
1. Update Homebrew version. From a Mac, you can run `brew bump-formula-pr` to create a new PR with the updated release's information. To make sure it's the most up-to-date:
|
||||
|
||||
From a Mac, you can run `brew bump-formula-pr` to create a new PR with the updated release's information.
|
||||
1. If you don't already have one, create a [GitHub access token for Homebrew](https://github.com/settings/tokens/new?scopes=gist,public_repo&description=Homebrew)
|
||||
|
||||
To make sure it's the most up-to-date:
|
||||
1. Run `export HOMEBREW_GITHUB_API_TOKEN=your_token_here` on your command line to make sure that `brew` can work on GitHub on your behalf.
|
||||
|
||||
1. If you don't already have one, create a [GitHub access token for Homebrew](https://github.com/settings/tokens/new?scopes=gist,public_repo&description=Homebrew)
|
||||
1. Run `export HOMEBREW_GITHUB_API_TOKEN=your_token_here` on your command line to make sure that `brew` can work on GitHub on your behalf.
|
||||
1. Run `hack/brew-update.sh`. This script will download the necessary files, do the checks, and invoke the brew helper to submit the PR, which will open in your browser.
|
||||
1. Run `hack/brew-update.sh`. This script will download the necessary files, do the checks, and invoke the brew helper to submit the PR, which will open in your browser.
|
||||
|
||||
### Post-release - Windows Chocolatey version update
|
||||
1. Update Windows Chocolatey version. From a Windows computer, follow the step-by-step instructions to [create the Windows Chocolatey package for Velero CLI](https://github.com/adamrushuk/velero-choco/blob/main/README.md)
|
||||
|
||||
From a Windows computer, follow the step-by-step instructions to [create the Windows Chocolatey package for Velero CLI](https://github.com/adamrushuk/velero-choco/blob/main/README.md)
|
||||
## Announce a release
|
||||
|
||||
Once you are finished doing the release, let the rest of the world know its available by posting messages in the following places.
|
||||
|
||||
1. Velero's Twitter account. Maintainers are encouraged to help spread the word by posting or reposting on social media.
|
||||
1. Community Slack channel.
|
||||
1. Google group message.
|
||||
|
||||
What to include:
|
||||
|
||||
* Thank all contributors
|
||||
* A brief list of highlights in the release
|
||||
* Link to the release blog post, release notes, and/or github release page
|
||||
|
||||
[1]: https://velero.io/blog
|
||||
[2]: website-guidelines.md
|
|
@ -3,7 +3,7 @@ title: "Restic Integration"
|
|||
layout: docs
|
||||
---
|
||||
|
||||
Velero supports backing up and restoring Kubernetes volumes using a free open-source backup tool called [restic][1]. This support is considered beta quality. Please see the list of [limitations](#limitations) to understand if it currently fits your use case.
|
||||
Velero supports backing up and restoring Kubernetes volumes using a free open-source backup tool called [restic][1]. This support is considered beta quality. Please see the list of [limitations](#limitations) to understand if it fits your use case.
|
||||
|
||||
Velero allows you to take snapshots of persistent volumes as part of your backups if you’re using one of
|
||||
the supported cloud providers’ block storage offerings (Amazon EBS Volumes, Azure Managed Disks, Google Persistent Disks).
|
||||
|
@ -34,7 +34,7 @@ To install restic, use the `--use-restic` flag in the `velero install` command.
|
|||
velero install --use-restic
|
||||
```
|
||||
|
||||
When using restic on a storage provider that doesn't currently have Velero support for snapshots, the `--use-volume-snapshots=false` flag prevents an unused `VolumeSnapshotLocation` from being created on installation.
|
||||
When using restic on a storage provider that doesn't have Velero support for snapshots, the `--use-volume-snapshots=false` flag prevents an unused `VolumeSnapshotLocation` from being created on installation.
|
||||
|
||||
### Configure restic DaemonSet spec
|
||||
|
||||
|
@ -125,7 +125,7 @@ To mount the correct hostpath to pods volumes, run the restic pod in `privileged
|
|||
```
|
||||
|
||||
|
||||
If restic is not running in a privileged mode, it will not be able to access pods volumes within the mounted hostpath directory because of the default enforced SELinux mode configured in the host system level. You can [create a custom SCC](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html) in order to relax the security in your cluster so that restic pods are allowed to use the hostPath volume plug-in without granting them access to the `privileged` SCC.
|
||||
If restic is not running in a privileged mode, it will not be able to access pods volumes within the mounted hostpath directory because of the default enforced SELinux mode configured in the host system level. You can [create a custom SCC](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html) to relax the security in your cluster so that restic pods are allowed to use the hostPath volume plug-in without granting them access to the `privileged` SCC.
|
||||
|
||||
By default a userland openshift namespace will not schedule pods on all nodes in the cluster.
|
||||
|
||||
|
@ -330,13 +330,12 @@ Regardless of how volumes are discovered for backup using restic, the process of
|
|||
## Limitations
|
||||
|
||||
- `hostPath` volumes are not supported. [Local persistent volumes][4] are supported.
|
||||
- Those of you familiar with [restic][1] may know that it encrypts all of its data. We've decided to use a static,
|
||||
common encryption key for all restic repositories created by Velero. **This means that anyone who has access to your
|
||||
- Those of you familiar with [restic][1] may know that it encrypts all of its data. Velero uses a static,
|
||||
common encryption key for all restic repositories it creates. **This means that anyone who has access to your
|
||||
bucket can decrypt your restic backup data**. Make sure that you limit access to the restic bucket
|
||||
appropriately. We plan to implement full Velero backup encryption, including securing the restic encryption keys, in
|
||||
a future release.
|
||||
appropriately.
|
||||
- An incremental backup chain will be maintained across pod reschedules for PVCs. However, for pod volumes that are *not*
|
||||
PVCs, such as `emptyDir` volumes, when a pod is deleted/recreated (e.g. by a ReplicaSet/Deployment), the next backup of those
|
||||
PVCs, such as `emptyDir` volumes, when a pod is deleted/recreated (for example, by a ReplicaSet/Deployment), the next backup of those
|
||||
volumes will be full rather than incremental, because the pod volume's lifecycle is assumed to be defined by its pod.
|
||||
- Restic scans each file in a single thread. This means that large files (such as ones storing a database) will take a long time to scan for data deduplication, even if the actual
|
||||
difference is small.
|
||||
|
@ -448,7 +447,7 @@ to the container command in the deployment/daemonset pod template spec.
|
|||
|
||||
## How backup and restore work with restic
|
||||
|
||||
We introduced three custom resource definitions and associated controllers:
|
||||
Velero has three custom resource definitions and associated controllers:
|
||||
|
||||
- `ResticRepository` - represents/manages the lifecycle of Velero's [restic repositories][5]. Velero creates
|
||||
a restic repository per namespace when the first restic backup for a namespace is requested. The controller
|
||||
|
@ -512,7 +511,7 @@ on to running other init containers/the main containers.
|
|||
|
||||
### Monitor backup annotation
|
||||
|
||||
Velero does not currently provide a mechanism to detect persistent volume claims that are missing the restic backup annotation.
|
||||
Velero does not provide a mechanism to detect persistent volume claims that are missing the restic backup annotation.
|
||||
|
||||
To solve this, a controller was written by Thomann Bits&Beats: [velero-pvc-watcher][7]
|
||||
|
|
@ -14,16 +14,16 @@ velero restore create RESTORE_NAME \
|
|||
```
|
||||
## What happens when user removes restore objects
|
||||
A **restore** object represents the restore operation. There are two types of deletion for restore objects:
|
||||
### 1. Deleting with **`velero restore delete`**
|
||||
1. Deleting with **`velero restore delete`**.
|
||||
This command will delete the custom resource representing it, along with its individual log and results files. But, it will not delete any objects that were created by it from your cluster.
|
||||
### 2. Deleting with **`kubectl -n velero delete restore`**
|
||||
2. Deleting with **`kubectl -n velero delete restore`**.
|
||||
This command will delete the custom resource representing the restore, but will not delete log/results files from object storage, or any objects that were created during the restore in your cluster.
|
||||
|
||||
## Restore command-line options
|
||||
To see all commands for restores, run : `velero restore --help`
|
||||
To see all options associated with a specific command, provide the --help flag to that command. For example, **`velero restore create --help`** shows all options associated with the **create** command.
|
||||
|
||||
### To List all options of restore use : **`velero restore --help`**
|
||||
To list all options of restore, use **`velero restore --help`**
|
||||
|
||||
```Usage:
|
||||
velero restore [command]
|
|
@ -4,7 +4,7 @@ layout: docs
|
|||
---
|
||||
|
||||
If you are using an S3-Compatible storage provider that is secured with a self-signed certificate, connections to the object store may fail with a `certificate signed by unknown authority` message.
|
||||
In order to proceed, a certificate bundle may be provided when adding the storage provider.
|
||||
To proceed, provide a certificate bundle when adding the storage provider.
|
||||
|
||||
## Trusting a self-signed certificate during installation
|
||||
|
|
@ -3,14 +3,14 @@ title: "Start contributing"
|
|||
layout: docs
|
||||
---
|
||||
|
||||
### Before you start
|
||||
## Before you start
|
||||
|
||||
* Please familiarize yourself with the [Code of Conduct][1] before contributing.
|
||||
* Also, see [CONTRIBUTING.md][2] for instructions on the developer certificate of origin that we require.
|
||||
|
||||
### Finding your way around
|
||||
## Finding your way around
|
||||
|
||||
You may join the Velero community and contribute in many different ways, including helping us design or test new features. For any significant feature we consider adding, we start with a design document. You may find a list of currently in progress new designs here: https://github.com/vmware-tanzu/velero/pulls?q=is%3Aopen+is%3Apr+label%3ADesign. Feel free to review and help us with your input.
|
||||
You may join the Velero community and contribute in many different ways, including helping us design or test new features. For any significant feature we consider adding, we start with a design document. You may find a list of in progress new designs here: https://github.com/vmware-tanzu/velero/pulls?q=is%3Aopen+is%3Apr+label%3ADesign. Feel free to review and help us with your input.
|
||||
|
||||
You can also vote on issues using :+1: and :-1:, as explained in our [Feature enhancement request][3] and [Bug issue][4] templates. This will help us quantify importance and prioritize issues.
|
||||
|
||||
|
@ -18,11 +18,11 @@ For information on how to connect with our maintainers and community, join our o
|
|||
|
||||
Please browse our list of resources, including a playlist of past online community meetings, blog posts, and other resources to help you get familiar with our project: [Velero resources](https://velero.io/resources/).
|
||||
|
||||
### Contributing
|
||||
## Contributing
|
||||
|
||||
If you are ready to jump in and test, add code, or help with documentation, please use the navigation on the left under `Contribute`.
|
||||
|
||||
[1]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/CODE_OF_CONDUCT.md
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/CONTRIBUTING.md
|
||||
[3]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/.github/ISSUE_TEMPLATE/feature-enhancement-request.md
|
||||
[4]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-beta.1/.github/ISSUE_TEMPLATE/bug_report.md
|
||||
[1]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/CODE_OF_CONDUCT.md
|
||||
[2]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/CONTRIBUTING.md
|
||||
[3]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/.github/ISSUE_TEMPLATE/feature-enhancement-request.md
|
||||
[4]: https://github.com/vmware-tanzu/velero/blob/v1.5.0-rc.1/.github/ISSUE_TEMPLATE/bug_report.md
|
|
@ -0,0 +1,344 @@
|
|||
---
|
||||
title: "Documentation Style Guide"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
_This style guide is adapted from the [Kubernetes style guide](https://kubernetes.io/docs/contribute/style/style-guide/)._
|
||||
|
||||
This page outlines writing style guidelines for the Velero documentation and you should use this page as a reference you write or edit content. Note that these are guidelines, not rules. Use your best judgment as you write documentation, and feel free to propose changes to these guidelines. Changes to the style guide are made by the Velero maintainers as a group. To propose a change or addition create an issue/PR, or add a suggestion to the [community meeting agenda](https://hackmd.io/Jq6F5zqZR7S80CeDWUklkA) and attend the meeting to participate in the discussion.
|
||||
|
||||
The Velero documentation uses the [kramdown](https://kramdown.gettalong.org/) Markdown renderer.
|
||||
|
||||
## Content best practices
|
||||
### Use present tense
|
||||
|
||||
{{< table caption="Do and Don't - Use present tense" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|This `command` starts a proxy.|This command will start a proxy.|
|
||||
{{< /table >}}
|
||||
|
||||
Exception: Use future or past tense if it is required to convey the correct meaning.
|
||||
|
||||
### Use active voice
|
||||
|
||||
{{< table caption="Do and Don't - Use active voice" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|You can explore the API using a browser.|The API can be explored using a browser.|
|
||||
|The YAML file specifies the replica count.|The replica count is specified in the YAML file.|
|
||||
{{< /table >}}
|
||||
|
||||
Exception: Use passive voice if active voice leads to an awkward sentence construction.
|
||||
|
||||
### Use simple and direct language
|
||||
|
||||
Use simple and direct language. Avoid using unnecessary phrases, such as saying "please."
|
||||
|
||||
{{< table caption="Do and Don't - Use simple and direct language" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|To create a ReplicaSet, ...|In order to create a ReplicaSet, ...|
|
||||
|See the configuration file.|Please see the configuration file.|
|
||||
|View the Pods.|With this next command, we'll view the Pods.|
|
||||
{{< /table >}}
|
||||
|
||||
### Address the reader as "you"
|
||||
|
||||
{{< table caption="Do and Don't - Addressing the reader" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|You can create a Deployment by ...|We'll create a Deployment by ...|
|
||||
|In the preceding output, you can see...|In the preceding output, we can see ...|
|
||||
{{< /table >}}
|
||||
|
||||
### Avoid Latin phrases
|
||||
|
||||
Prefer English terms over Latin abbreviations.
|
||||
|
||||
{{< table caption="Do and Don't - Avoid Latin phrases" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|For example, ...|e.g., ...|
|
||||
|That is, ...|i.e., ...|
|
||||
{{< /table >}}
|
||||
|
||||
Exception: Use "etc." for et cetera.
|
||||
|
||||
## Patterns to avoid
|
||||
|
||||
|
||||
### Avoid using "we"
|
||||
|
||||
Using "we" in a sentence can be confusing, because the reader might not know
|
||||
whether they're part of the "we" you're describing.
|
||||
|
||||
{{< table caption="Do and Don't - Avoid using we" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|Version 1.4 includes ...|In version 1.4, we have added ...|
|
||||
|Kubernetes provides a new feature for ...|We provide a new feature ...|
|
||||
|This page teaches you how to use Pods.|In this page, we are going to learn about Pods.|
|
||||
{{< /table >}}
|
||||
|
||||
### Avoid jargon and idioms
|
||||
|
||||
Many readers speak English as a second language. Avoid jargon and idioms to help them understand better.
|
||||
|
||||
{{< table caption="Do and Don't - Avoid jargon and idioms" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|Internally, ...|Under the hood, ...|
|
||||
|Create a new cluster.|Turn up a new cluster.|
|
||||
{{< /table >}}
|
||||
|
||||
### Avoid statements about the future or that will soon be out of date
|
||||
|
||||
Avoid making promises or giving hints about the future. If you need to talk about
|
||||
a beta feature, put the text under a heading that identifies it as beta
|
||||
information.
|
||||
|
||||
Also avoid words like “recently”, "currently" and "new." A feature that is new today might not be
|
||||
considered new in a few months.
|
||||
|
||||
{{< table caption="Do and Don't - Avoid statements that will soon be out of date" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|In version 1.4, ...|In the current version, ...|
|
||||
|The Federation feature provides ...|The new Federation feature provides ...|
|
||||
{{< /table >}}
|
||||
|
||||
### Language
|
||||
|
||||
This documentation uses U.S. English spelling and grammar.
|
||||
|
||||
## Documentation formatting standards
|
||||
|
||||
### Use camel case for API objects
|
||||
|
||||
When you refer to an API object, use the same uppercase and lowercase letters
|
||||
that are used in the actual object name. Typically, the names of API
|
||||
objects use
|
||||
[camel case](https://en.wikipedia.org/wiki/Camel_case).
|
||||
|
||||
Don't split the API object name into separate words. For example, use
|
||||
PodTemplateList, not Pod Template List.
|
||||
|
||||
Refer to API objects without saying "object," unless omitting "object"
|
||||
leads to an awkward sentence construction.
|
||||
|
||||
{{< table caption="Do and Don't - Do and Don't - API objects" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|The Pod has two containers.|The pod has two containers.|
|
||||
|The Deployment is responsible for ...|The Deployment object is responsible for ...|
|
||||
|A PodList is a list of Pods.|A Pod List is a list of pods.|
|
||||
|The two ContainerPorts ...|The two ContainerPort objects ...|
|
||||
|The two ContainerStateTerminated objects ...|The two ContainerStateTerminateds ...|
|
||||
{{< /table >}}
|
||||
|
||||
### Use angle brackets for placeholders
|
||||
|
||||
Use angle brackets for placeholders. Tell the reader what a placeholder represents.
|
||||
|
||||
1. Display information about a Pod:
|
||||
|
||||
kubectl describe pod <pod-name> -n <namespace>
|
||||
|
||||
If the pod is in the default namespace, you can omit the '-n' parameter.
|
||||
|
||||
### Use bold for user interface elements
|
||||
|
||||
{{< table caption="Do and Don't - Bold interface elements" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|Click **Fork**.|Click "Fork".|
|
||||
|Select **Other**.|Select "Other".|
|
||||
{{< /table >}}
|
||||
|
||||
### Use italics to define or introduce new terms
|
||||
|
||||
{{< table caption="Do and Don't - Use italics for new terms" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|A _cluster_ is a set of nodes ...|A "cluster" is a set of nodes ...|
|
||||
|These components form the _control plane_.|These components form the **control plane**.|
|
||||
{{< /table >}}
|
||||
|
||||
### Use code style for filenames, directories, paths, object field names and namespaces
|
||||
{{< table caption="Do and Don't - Use code style for filenames, directories, paths, object field names and namespaces" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|Open the `envars.yaml` file.|Open the envars.yaml file.|
|
||||
|Go to the `/docs/tutorials` directory.|Go to the /docs/tutorials directory.|
|
||||
|Open the `/_data/concepts.yaml` file.|Open the /\_data/concepts.yaml file.|
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
### Use punctuation inside quotes
|
||||
{{< table caption="Do and Don't - Use code style for filenames, directories, paths, object field names and namespaces" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|events are recorded with an associated "stage."|events are recorded with an associated "stage".|
|
||||
|The copy is called a "fork."|The copy is called a "fork".|
|
||||
{{< /table >}}
|
||||
|
||||
Exception: When the quoted word is a user input.
|
||||
|
||||
Example:
|
||||
* My user ID is “IM47g”.
|
||||
* Did you try the password “mycatisawesome”?
|
||||
|
||||
## Inline code formatting
|
||||
|
||||
|
||||
### Use code style for inline code and commands
|
||||
|
||||
For inline code in an HTML document, use the `<code>` tag. In a Markdown
|
||||
document, use the backtick (`` ` ``).
|
||||
|
||||
{{< table caption="Do and Don't - Use code style for filenames, directories, paths, object field names and namespaces" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|The `kubectl run` command creates a Deployment.|The "kubectl run" command creates a Deployment.|
|
||||
|For declarative management, use `kubectl apply`.|For declarative management, use "kubectl apply".|
|
||||
|Use single backticks to enclose inline code. For example, `var example = true`.|Use two asterisks (`**`) or an underscore (`_`) to enclose inline code. For example, **var example = true**.|
|
||||
|Use triple backticks (\`\`\`) before and after a multi-line block of code for fenced code blocks.|Use multi-line blocks of code to create diagrams, flowcharts, or other illustrations.|
|
||||
|Use meaningful variable names that have a context.|Use variable names such as 'foo','bar', and 'baz' that are not meaningful and lack context.|
|
||||
|Remove trailing spaces in the code.|Add trailing spaces in the code, where these are important, because a screen reader will read out the spaces as well.|
|
||||
{{< /table >}}
|
||||
|
||||
### Starting a sentence with a component tool or component name
|
||||
|
||||
{{< table caption="Do and Don't - Starting a sentence with a component tool or component name" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|The `kubeadm` tool bootstraps and provisions machines in a cluster.|`kubeadm` tool bootstraps and provisions machines in a cluster.|
|
||||
|The kube-scheduler is the default scheduler for Kubernetes.|kube-scheduler is the default scheduler for Kubernetes.|
|
||||
{{< /table >}}
|
||||
|
||||
### Use normal style for string and integer field values
|
||||
|
||||
For field values of type string or integer, use normal style without quotation marks.
|
||||
|
||||
{{< table caption="Do and Don't - Use normal style for string and integer field values" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|Set the value of `imagePullPolicy` to `Always`.|Set the value of `imagePullPolicy` to "Always".|
|
||||
|Set the value of `image` to `nginx:1.16`.|Set the value of `image` to nginx:1.16.|
|
||||
|Set the value of the `replicas` field to `2`.|Set the value of the `replicas` field to 2.|
|
||||
{{< /table >}}
|
||||
|
||||
## Code snippet formatting
|
||||
|
||||
|
||||
### Don't include the command prompt
|
||||
|
||||
{{< table caption="Do and Don't - Don't include the command prompt" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|kubectl get pods|$ kubectl get pods|
|
||||
{{< /table >}}
|
||||
|
||||
### Separate commands from output
|
||||
|
||||
Verify that the Pod is running on your chosen node:
|
||||
|
||||
```
|
||||
kubectl get pods --output=wide
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE IP NODE
|
||||
nginx 1/1 Running 0 13s 10.200.0.4 worker0
|
||||
```
|
||||
|
||||
## Velero.io word list
|
||||
|
||||
|
||||
A list of Velero-specific terms and words to be used consistently across the site.
|
||||
|
||||
{{< table caption="Velero.io word list" >}}
|
||||
|Trem|Useage|
|
||||
|--- |--- |
|
||||
|Kubernetes|Kubernetes should always be capitalized.|
|
||||
|Docker|Docker should always be capitalized.|
|
||||
|Velero|Velero should always be capitalized.|
|
||||
|VMware|VMware should always be correctly capitalized.|
|
||||
|On-premises|On-premises or on-prem rather than on-premise or other variations.|
|
||||
|Backup|Backup rather than back up, back-up or other variations.|
|
||||
|Plugin|Plugin rather than plug-in or other variations.|
|
||||
|Allowlist|Use allowlist instead of whitelist.|
|
||||
|Denylist|Use denylist instead of blacklist.|
|
||||
{{< /table >}}
|
||||
|
||||
## Markdown elements
|
||||
|
||||
### Headings
|
||||
People accessing this documentation may use a screen reader or other assistive technology (AT). [Screen readers](https://en.wikipedia.org/wiki/Screen_reader) are linear output devices, they output items on a page one at a time. If there is a lot of content on a page, you can use headings to give the page an internal structure. A good page structure helps all readers to easily navigate the page or filter topics of interest.
|
||||
|
||||
{{< table caption="Do and Don't - Headings" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|Include a title on each page or blog post.|Include more than one title headings (#) in a page.|
|
||||
|Use ordered headings to provide a meaningful high-level outline of your content.|Use headings level 4 through 6, unless it is absolutely necessary. If your content is that detailed, it may need to be broken into separate articles.|
|
||||
|Use sentence case for headings. For example, **Extend kubectl with plugins**|Use title case for headings. For example, **Extend Kubectl With Plugins**|
|
||||
{{< /table >}}
|
||||
|
||||
### Paragraphs
|
||||
|
||||
{{< table caption="Do and Don't - Paragraphs" >}}
|
||||
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|Try to keep paragraphs under 6 sentences.|Write long-winded paragraphs.|
|
||||
|Use three hyphens (`---`) to create a horizontal rule for breaks in paragraph content.|Use horizontal rules for decoration.|
|
||||
{{< /table >}}
|
||||
|
||||
### Links
|
||||
|
||||
{{< table caption="Do and Don't - Links" >}}
|
||||
|Do|Don't|
|
||||
|--- |--- |
|
||||
|Write hyperlinks that give you context for the content they link to. For example: Certain ports are open on your machines. See [check required ports](#check-required-ports) for more details.|Use ambiguous terms such as “click here”. For example: Certain ports are open on your machines. See [here](#check-required-ports) for more details.|
|
||||
|Write Markdown-style links: `[link text](URL)`. For example: `[community meeting agenda](https://hackmd.io/Jq6F5zqZR7S80CeDWUklkA)` and the output is [community meeting agenda](https://hackmd.io/Jq6F5zqZR7S80CeDWUklkA).|Write HTML-style links: `Visit our tutorial!`|
|
||||
{{< /table >}}
|
||||
|
||||
|
||||
### Lists
|
||||
|
||||
Group items in a list that are related to each other and need to appear in a specific order or to indicate a correlation between multiple items. When a screen reader comes across a list—whether it is an ordered or unordered list—it will be announced to the user that there is a group of list items. The user can then use the arrow keys to move up and down between the various items in the list.
|
||||
Website navigation links can also be marked up as list items; after all they are nothing but a group of related links.
|
||||
|
||||
- End each item in a list with a period if one or more items in the list are complete sentences. For the sake of consistency, normally either all items or none should be complete sentences.
|
||||
|
||||
- Ordered lists that are part of an incomplete introductory sentence can be in lowercase and punctuated as if each item was a part of the introductory sentence.
|
||||
|
||||
- Use the number one (`1.`) for ordered lists.
|
||||
|
||||
- Use (`+`), (`*`), or (`-`) for unordered lists - be consistent within the same document.
|
||||
|
||||
- Leave a blank line after each list.
|
||||
|
||||
- Indent nested lists with four spaces (for example, ⋅⋅⋅⋅).
|
||||
|
||||
- List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either four spaces or one tab.
|
||||
|
||||
### Tables
|
||||
|
||||
The semantic purpose of a data table is to present tabular data. Sighted users can quickly scan the table but a screen reader goes through line by line. A table [caption](https://www.w3schools.com/tags/tag_caption.asp) is used to create a descriptive title for a data table. Assistive technologies (AT) use the HTML table caption element to identify the table contents to the user within the page structure.
|
||||
|
||||
If you need to create a table, create the table in markdown and use the table [Hugo shortcode](https://gohugo.io/content-management/shortcodes/) to include a caption.
|
||||
|
||||
```
|
||||
{{</* table caption="Configuration parameters" >}}
|
||||
Parameter | Description | Default
|
||||
:---------|:------------|:-------
|
||||
`timeout` | The timeout for requests | `30s`
|
||||
`logLevel` | The log level for log output | `INFO`
|
||||
{{< /table */>}}
|
||||
|
||||
```
|
||||
**Note:** This shortcode does not support markdown reference-style links. Use inline-style links in tables. See more information about [markdown link styles](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links).
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
title: "Providers"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
Velero supports a variety of storage providers for different backup and snapshot operations. Velero has a plugin system which allows anyone to add compatibility for additional backup and volume storage platforms without modifying the Velero codebase.
|
||||
|
||||
## Velero supported providers
|
||||
|
||||
{{< table caption="Velero supported providers" >}}
|
||||
|
||||
| Provider | Object Store | Volume Snapshotter | Plugin Provider Repo | Setup Instructions |
|
||||
|-----------------------------------|---------------------|------------------------------|-----------------------------------------|-------------------------------|
|
||||
| [Amazon Web Services (AWS)](https://aws.amazon.com) | AWS S3 | AWS EBS | [Velero plugin for AWS](https://github.com/vmware-tanzu/velero-plugin-for-aws) | [AWS Plugin Setup](https://github.com/vmware-tanzu/velero-plugin-for-aws#setup) |
|
||||
| [Google Cloud Platform (GCP)](https://cloud.google.com) | Google Cloud Storage| Google Compute Engine Disks | [Velero plugin for GCP](https://github.com/vmware-tanzu/velero-plugin-for-gcp) | [GCP Plugin Setup](https://github.com/vmware-tanzu/velero-plugin-for-gcp#setup) |
|
||||
| [Microsoft Azure](https://azure.com) | Azure Blob Storage | Azure Managed Disks | [Velero plugin for Microsoft Azure](https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure) | [Azure Plugin Setup](https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure#setup) |
|
||||
| [VMware vSphere](https://github.com/vmware-tanzu/velero-plugin-for-vsphere) | 🚫 | vSphere Volumes | [VMware vSphere](https://github.com/vmware-tanzu/velero-plugin-for-vsphere) | [vSphere Plugin Setup](https://github.com/vmware-tanzu/velero-plugin-for-vsphere#installing-the-plugin) |
|
||||
| [Container Storage Interface (CSI)](https://github.com/vmware-tanzu/velero-plugin-for-csi/)| 🚫 | CSI Volumes | [Velero plugin for CSI](https://github.com/vmware-tanzu/velero-plugin-for-csi/) | [CSI Plugin Setup](website-guidelines.md) |
|
||||
{{< /table >}}
|
||||
|
||||
Contact: [#Velero Slack](https://kubernetes.slack.com/messages/velero), [GitHub Issues](https://github.com/vmware-tanzu/velero/issues)
|
||||
|
||||
## Community supported providers
|
||||
{{< table caption="Community supported providers" >}}
|
||||
|
||||
| Provider | Object Store | Volume Snapshotter | Plugin Documentation | Contact |
|
||||
|---------------------------|------------------------------|------------------------------------|------------------------|---------------------------------|
|
||||
| [AlibabaCloud](https://www.alibabacloud.com/) | Alibaba Cloud OSS | Alibaba Cloud | [AlibabaCloud](https://github.com/AliyunContainerService/velero-plugin) | [GitHub Issue](https://github.com/AliyunContainerService/velero-plugin/issues) |
|
||||
| [DigitalOcean](https://www.digitalocean.com/) | DigitalOcean Object Storage | DigitalOcean Volumes Block Storage | [StackPointCloud](https://github.com/StackPointCloud/ark-plugin-digitalocean) | |
|
||||
| [Hewlett Packard](https://www.hpe.com/us/en/storage.html) | 🚫 | HPE Storage | [Hewlett Packard](https://github.com/hpe-storage/velero-plugin) | [Slack](https://slack.hpedev.io/), [GitHub Issue](https://github.com/hpe-storage/velero-plugin/issues) |
|
||||
| [OpenEBS](https://openebs.io/) | 🚫 | OpenEBS CStor Volume | [OpenEBS](https://github.com/openebs/velero-plugin) | [Slack](https://openebs-community.slack.com/), [GitHub Issue](https://github.com/openebs/velero-plugin/issues) |
|
||||
| [Portworx](https://portworx.com/) | 🚫 | Portworx Volume | [Portworx](https://docs.portworx.com/scheduler/kubernetes/ark.html) | [Slack](https://portworx.slack.com/messages/px-k8s), [GitHub Issue](https://github.com/portworx/ark-plugin/issues) |
|
||||
| [Storj](https://storj.io) | Storj Object Storage | 🚫 | [Storj](https://github.com/storj-thirdparty/velero-plugin) | [GitHub Issue](https://github.com/storj-thirdparty/velero-plugin/issues) |
|
||||
{{< /table >}}
|
||||
|
||||
## S3-Compatible object store providers
|
||||
|
||||
Velero's AWS Object Store plugin uses [Amazon's Go SDK][0] to connect to the AWS S3 API. Some third-party storage providers also support the S3 API, and users have reported the following providers work with Velero:
|
||||
|
||||
_Note that these storage providers are not regularly tested by the Velero team._
|
||||
|
||||
* [IBM Cloud][1]
|
||||
* [Oracle Cloud][2]
|
||||
* [Minio][3]
|
||||
* [DigitalOcean][4]
|
||||
* [NooBaa][5]
|
||||
* Ceph RADOS v12.2.7
|
||||
* Quobyte
|
||||
* [Cloudian HyperStore][38]
|
||||
|
||||
_Some storage providers, like Quobyte, may need a different [signature algorithm version][6]._
|
||||
|
||||
## Non-supported volume snapshots
|
||||
|
||||
In the case you want to take volume snapshots but didn't find a plugin for your provider, Velero has support for snapshotting using restic. Please see the [restic integration][30] documentation.
|
||||
|
||||
[0]: https://github.com/aws/aws-sdk-go/aws
|
||||
[1]: contributions/ibm-config.md
|
||||
[2]: contributions/oracle-config.md
|
||||
[3]: contributions/minio.md
|
||||
[4]: https://github.com/StackPointCloud/ark-plugin-digitalocean
|
||||
[5]: http://www.noobaa.com/
|
||||
[6]: https://github.com/vmware-tanzu/velero-plugin-for-aws/blob/main/backupstoragelocation.md
|
||||
[25]: https://github.com/hpe-storage/velero-plugin
|
||||
[30]: restic.md
|
||||
[36]: https://github.com/vmware-tanzu/velero-plugin-for-gcp#setup
|
||||
[38]: https://www.cloudian.com/
|
|
@ -5,18 +5,6 @@ layout: docs
|
|||
|
||||
These tips can help you troubleshoot known issues. If they don't help, you can [file an issue][4], or talk to us on the [#velero channel][25] on the Kubernetes Slack server.
|
||||
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
- [Debug installation/ setup issues](#debug-installation-setup-issues)
|
||||
- [Debug restores](#debug-restores)
|
||||
- [General troubleshooting information](#general-troubleshooting-information)
|
||||
- [Getting velero debug logs](#getting-velero-debug-logs)
|
||||
- [Known issue with restoring LoadBalancer Service](#known-issue-with-restoring-loadbalancer-service)
|
||||
- [Miscellaneous issues](#miscellaneous-issues)
|
||||
- [Velero reports `custom resource not found` errors when starting up.](#velero-reports-custom-resource-not-found-errors-when-starting-up)
|
||||
- [`velero backup logs` returns a `SignatureDoesNotMatch` error](#velero-backup-logs-returns-a-signaturedoesnotmatch-error)
|
||||
- [Velero (or a pod it was backing up) restarted during a backup and the backup is stuck InProgress](#velero-or-a-pod-it-was-backing-up-restarted-during-a-backup-and-the-backup-is-stuck-inprogress)
|
||||
- [Velero is not publishing prometheus metrics](#velero-is-not-publishing-prometheus-metrics)
|
||||
|
||||
## Debug installation/ setup issues
|
||||
|
||||
- [Debug installation/setup issues][2]
|
||||
|
@ -82,7 +70,7 @@ Here are some things to verify if you receive `SignatureDoesNotMatch` errors:
|
|||
|
||||
## Velero (or a pod it was backing up) restarted during a backup and the backup is stuck InProgress
|
||||
|
||||
Velero cannot currently resume backups that were interrupted. Backups stuck in the `InProgress` phase can be deleted with `kubectl delete backup <name> -n <velero-namespace>`.
|
||||
Velero cannot resume backups that were interrupted. Backups stuck in the `InProgress` phase can be deleted with `kubectl delete backup <name> -n <velero-namespace>`.
|
||||
Backups in the `InProgress` phase have not uploaded any files to object storage.
|
||||
|
||||
## Velero is not publishing prometheus metrics
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "Upgrading to Velero 1.5"
|
||||
title: "Upgrading to Velero 1.4"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
|
@ -65,7 +65,7 @@ If you're not yet running at least Velero v1.4, see the following:
|
|||
Git commit: <git SHA>
|
||||
|
||||
Server:
|
||||
Version: v1.5.0-beta.1
|
||||
Version: v1.4.0-beta.1
|
||||
```
|
||||
|
||||
[0]: basic-install.md#install-the-cli
|
|
@ -0,0 +1,45 @@
|
|||
---
|
||||
title: "Website Guidelines"
|
||||
layout: docs
|
||||
---
|
||||
|
||||
## Running the website locally
|
||||
|
||||
When making changes to the website, please run the site locally before submitting a PR and manually verify your changes.
|
||||
|
||||
At the root of the project, run:
|
||||
|
||||
```bash
|
||||
make serve-docs
|
||||
```
|
||||
|
||||
This runs all the Hugo dependencies in a container.
|
||||
|
||||
Alternatively, for quickly loading the website, under the `velero/site/` directory run:
|
||||
|
||||
```bash
|
||||
hugo serve
|
||||
```
|
||||
|
||||
For more information on how to run the website locally, please see our [Hugo documentation](https://gohugo.io/getting-started/).
|
||||
|
||||
## Adding a blog post
|
||||
|
||||
To add a blog post, create a new markdown (.MD) file in the `/site/content/posts/` folder. A blog post requires the following front matter.
|
||||
|
||||
```yaml
|
||||
title: "Title of the blog"
|
||||
excerpt: Brief summary of thee blog post that appears as a preview on velero.io/blogs
|
||||
author_name: Jane Smith
|
||||
slug: URL-For-Blog
|
||||
# Use different categories that apply to your blog. This is used to connect related blogs on the site
|
||||
categories: ['velero','release']
|
||||
# Image to use for blog. The path is relative to the site/static/ folder
|
||||
image: /img/posts/example-image.jpg
|
||||
# Tag should match author to drive author pages. Tags can have multiple values.
|
||||
tags: ['Velero Team', 'Nolan Brubaker']
|
||||
```
|
||||
|
||||
Include the `author_name` value in tags field so the page that lists the author's posts will work properly, for example https://velero.io/tags/carlisia-campos/.
|
||||
|
||||
Ideally each blog will have a unique image to use on the blog home page, but if you do not include an image, the default Velero logo will be used instead. Use an image that is less than 70KB and add it to the `/site/static/img/posts` folder.
|
|
@ -11,7 +11,7 @@ While GitHub issues, milestones, and labels generally work pretty well, the Vele
|
|||
In our effort to minimize tooling while enabling product management insights, we have decided to use [ZenHub Open-Source](https://www.zenhub.com/blog/open-source/) to overlay product and project tracking on top of GitHub.
|
||||
ZenHub is a GitHub application that provides Kanban visualization, Epic tracking, fine-grained prioritization, and more. It's primary backing storage system is existing GitHub issues along with additional metadata stored in ZenHub's database.
|
||||
|
||||
If you are a Velero user or Velero Developer, you do not _need_ to use ZenHub for your regular workflow (e.g to see open bug reports or feature requests, work on pull requests). However, if you'd like to be able to visualize the high-level project goals and roadmap, you will need to use the free version of ZenHub.
|
||||
If you are a Velero user or Velero Developer, you do not _need_ to use ZenHub for your regular workflow (to see open bug reports or feature requests, work on pull requests). However, if you'd like to be able to visualize the high-level project goals and roadmap, you will need to use the free version of ZenHub.
|
||||
|
||||
## Using ZenHub
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
# that the navigation for older versions still work.
|
||||
|
||||
main: main-toc
|
||||
v1.5-pre: v1-5-pre-toc
|
||||
v1.5.0-rc.1: v1-5-0-rc-1-toc
|
||||
v1.4: v1-4-toc
|
||||
v1.3.2: v1-3-2-toc
|
||||
v1.3.1: v1-3-1-toc
|
||||
|
|
Loading…
Reference in New Issue