A proposal for Helm 3 using CRDs and a custom controller. This README comprises the proposal for CRDs in Helm 3. In addition to this document, there are other examples of what the objects will look like contained in this repo. This is not meant to be a completely exhaustive description of all behavior, but is intended to give a enough details as a starting point for actual implementation details should this proposal be accepted.
NOTE: Although I am a core maintainer, this does not represent the direction that the project will go. It is solely a proposal for what I personally think should be done for Helm 3
Originally, Helm was built as a way to share reusable components. However, as its usage has grown, many want to use Helm more as a configuration management tool. Also, many of the assumptions made when Helm 2 was first released have not proved true now that Kubernetes has evolved. Below is the list of issues current users of Helm 2 face and that can be addressed by this proposal.
The following points capture the high level changes compared to Helm 2.
Lifecycle
object for registering custom lifecyclesLifecycle
object in Helm 3Release
, Values
, Manifest
, and Secret
objects.This is a simple list of logic that the controller will handle
Manifest
, Values
, or Secret
specified in the Release
. It should also watch for changes in the Release
object. When a change is observed, a new release occurs.Release
and on subsequent updates, a ReleaseAudit
event is created to track the history of the releaseOwnerRef
that points to the
Release
object that created it.LifecycleEvent
with the configured eventKey
for each
Lifecycle
specified in a Release
. It will watch these events until the
lifecycle controller responsible for handling that event marks it as done (or
errored), update the Release
object, and then delete the event. If it doesn't
complete after a certain amount of time, the event will be cleaned up and failure
information added to the Release
status.Lifecycle
object
specifies its name and what key the controller should watch for. This key will
be used as the label value for filtering events in a lifecycle controller. Both
built in and custom lifecycles will be registered in the same way.This is a list of open questions that should be resolved before the proposal is fully accepted. If a larger discussion is needed, we will open an issue and link it to the question.
ClusterRelease
object that is non-namespacedenforce: true
in the Release
values.yaml
that can be used for configuring
lifecycle behaviorThis is an active proposal and feedback is definitely needed. If you see something you'd like to change, please open a Pull Request. We can discuss the change you add and either merge it in or close based on the outcome of the discussion.