"Revision" field disambiguation

[seaneagan]

Suggestions:

LastAttemptedRevision > LastAttemptedChartRevision
LastAppliedRevision >: LastSuccessfulChartRevision
LastReleaseRevision > no change needed

"ChartRevision" to me helps disambiguate from the "ReleaseRevision" in "LastReleaseRevision', which represents a different kind of revision (chart vs release). I think "Successful" is more accurate than "Applied" since even a failed attempt could be considered applied unless/until it is uninstalled or rolled back.

[stefanprodan]

The LastAppliedRevision/LastAttemptedRevision are intended to be common fields for all the toolkit reconcilers, as of now these are used in kustomize and helm controllers. I get your point that from a Chart/Release perspective they are ambiguous.

[hiddeco]

We could record the chart revision as given by Helm in another *ChartRevision status field, question is if this gives us anything of additional value.

[seaneagan]

I see, what about "Source" or "Artifact" rather than "Chart" then:

LastAttemptedSourceRevision
LastSuccessfulSourceRevision

LastAttemptedArtifactRevision
LastSuccessfulArtifactRevision

[stefanprodan]

@seaneagan using the same stats fields e,g, LastAppliedRevision/LastAttemptedRevision as a standard across all toolkit controllers allows other controllers/integrations to rely on those for detecting drift. These integrations don't have to depend on our API packages, using the dynamic client-go you could lookup an object.status and check the 2 fields. If we change them in helm-controller, then it will would break the standard. I propose we document these fields in helm-controller docs and explain what they mean in the Helm context.

[seaneagan]

Sure, I guess it's easy enough for an end user to distinguish based on the field values what it likely means as well, it's just something that tripped me up for a second when looking at the field names only, before actually using the tool. Thanks for considering!