Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requirements for Carvel configuration #3752

Closed
wants to merge 3 commits into from
Closed

Requirements for Carvel configuration #3752

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d597b23
Requirements for Carvel configuration
carlisia Apr 30, 2021
3a5b56d
Fix typo
carlisia Apr 30, 2021
ab27407
Second iteration of requirements
carlisia May 11, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions design/carvel-install-design.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# Design proposal for Velero Installation with Carvel

Currently, the Velero CLI tool has a `install` command that configures numerous major and minor aspects of Velero. This document outlines how we can also have Velero be installed and upgraded using the Carvel tooling.


## Goals
- Have one source of truth for all Velero configuration
- Have compatibility with gitop practices (i.e. ability to generate a full set of yaml for install that can be stored in source control)
dsu-igeek marked this conversation as resolved.
Show resolved Hide resolved
- Have a clear path for deprecating of the `install` command

## Requirements
- Ability for the Carvel deployment to consume/inject configuration data as needed for a normal Velero deployment with default resources. For example: it should configure a default BSL alongside the deployment.
- The Carvel toolset must be able to, in addition to install, upgrade Velero as well as update its configuration settings.
- "Ask once" approach to configuring the Velero deployment defaults. In other words: reuse given parameters for putting together the needed overlays and packaging configuration.
- Ideally, setup the Carvel tooling so that it discovers and uses configuration data from known distros.
- The toolset and artifacts must be setup in a way that it will access and consume the CRDs that match the intended Velero version. Users should have uncomplicated access to the proper versions of the CRDs to be able to upgrade and downgrade Velero.
- The toolset and artifacts must be laid out in a directory structure in a way that it can be discovered and used by other projects.
- Migrate deployment configuration from using Go code to using Carvel manifests, and wrap the `install` command around the toolset.
- Deprecate the `install` command once the Carvel tooling is fully setup and well tested.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we'll actually be able to deprecate "install", since Carvel also relies on installing KAPP which seems like a lot to ask the non-Tanzu user to do to install Velero. I think it would be possible, though, to call the Karvel libraries from the CLI and have the CLI use Carvel as a library to generate the installation yamls

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm removing this line because now that I think about it, that's what the line above says (wrap aroun a Carvel library).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how kapp factors into this effort. Our current install commands drives the installation of resources and updates to the configuration. It does nothing beyond that. Our controllers do the work of keeping track of changes in the cluster. From this perspective, the Carvel tooling cli can do everything our install and Go code does (in which case we could deprecate the install barring another reason to keep it), once we have the templates in place, which we will need for Tanzu and any other configuration consumer. Am I missing anything?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh lord. Please ignore my ramblings above, my mind was elsewhere. Apologies!

@dsu-igeek I was very much assuming that we could require the installation and use of any of the Carvel tooling for the non Tanzu Velero user. As far as I am understanding, this would mean ytt for configuration and kapp for deployment for the requirements we have. Is this not correct? We can require ytt but not kapp? Something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explanation: I read your KAPP in all caps and my brain had translated it into kapp-controller, but my comment doesn't make sense even so. Ha.

- Envirornments that need to be supported: AWS, VSphere, Azure.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind as well


## Non Goals
- Introduce new configuration
- Propose changes to the configuration that go beyond the ability to install and update as currently exists.