Requirements for Carvel configuration #3752
Conversation
Signed-off-by: Carlisia <[email protected]>
Signed-off-by: Carlisia <[email protected]>
|
Note: I have to add the current Velero scenarios we support, and what we will aim to support with Carvel. Even so, the current list of requirements could use a review. |
design/carvel-install-design.md
Outdated
| - 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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I'm removing this line because now that I think about it, that's what the line above says (wrap aroun a Carvel library).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
design/carvel-install-design.md
Outdated
| - 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. | ||
| - Envirornments that need to be supported: AWS, VSphere, Azure. |
Signed-off-by: Carlisia <[email protected]>
| ## Requirements | ||
| ### Organization | ||
| - The generated Velero configuration templates and artifacts must be kept in the Velero GitHub repository. | ||
| - The confiruation artifacts must be be laid out in a directory structure in a way that conforms with the expected standard so that they can be easily discovered by configuration consumers. |
There was a problem hiding this comment.
confiruation -> configuration
| - For compatibility with devops, Velero must continue to provide a `dry-run` option via the Carvel tooling for outputing configuration artifacts without installing them. | ||
| - Because the Carvel tooling, given proper templates, offers full functionality to do what the current Velero install command does, namelly create deployment and other resources in Kubernetes clusters, as well as update them, a path to deprecating that command could be considered and defined. An intermediate step might be to wrap the `install` command around the Carvel tooling. | ||
| - Documentation and sample templates to be used by the configuration consumers must be provided for each environment supported. | ||
|
|
There was a problem hiding this comment.
How about uninstall? Is this something that can be handled via the Carvel framework?
| | Backup/restore of K8s resources | ✅ | ✅ | ✅ | ✅ | | ||
| | Backup/restore of PVs via plugins | ✅ | ✅ | ✅ | N/A | | ||
| | Backup/restore of PVs with restic | ✅ | ✅ | ✅ | N/A | | ||
|
|
There was a problem hiding this comment.
Please add some specifics for the platforms, for MVP, e.g. for vSphere we need to be able to install the AWS plugin and the vSphere plugin. Add the configuration variables that are needed to do an install on each of these (e.g. provider, plug-in, bucket, secret-file, etc.)
| | Backup/restore of K8s resources | ✅ | ✅ | ✅ | ✅ | | ||
| | Backup/restore of PVs via plugins | ✅ | ✅ | ✅ | N/A | | ||
| | Backup/restore of PVs with restic | ✅ | ✅ | ✅ | N/A | | ||
|
|
There was a problem hiding this comment.
For plug-ins, do we want to be able to specify plug-in versions separate from Velero versions or do we wrap all of that together in a single "release" and create a new release if we have a Velero or plug-in update?
|
Closing this as it has been done in the TCE repo. |
This is the start of a design document for the guidelines for the Velero installation using Carvel. It only covers goals and requirements.
The issue for the finalized document is tracked here: (#3709)
Signed-off-by: Carlisia [email protected]
Fixes #3742
Please indicate you've done the following:
/kind changelog-not-required.site/content/docs/main.