-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Link helm-created resources to FluxHelmReleases #1134
Conversation
integrations/helm/status/status.go
Outdated
|
||
// Get the corresponding HelmRelease status | ||
// Annotate/Status things | ||
// (will probably need to keep a worklist) |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
for { | ||
select { | ||
case <-stop: | ||
break bail |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
integrations/helm/status/status.go
Outdated
default: | ||
} | ||
|
||
if err := a.rateLimiter.Wait(ctx); err != nil { |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
@aaron7 Wanna check the fixups? Then I'll squash them and meeerge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Some cosmetic changes to smooth the way. - remove dead wood - remove redundant allocations - dedup getting release - use return type *T rather than derefing *T
This introduces a loop which checks each FluxHelmRelease and updates its status depending on the status of its corresponding Helm release. This is so that you (or the Flux API) can see from just the FHR what is happening.
We want to be able to identify the resources created, indirectly, by a FluxHelmRelease. We don't get access to the creation process, since that's managed by Helm; but we do get to see, afterwards, which resources were involved, in a big YAML string. The simplest way to get the annotation done is to hand the big YAML string directly to `kubectl annotate`.
To present the annotation in the flux API, I've added a field to the API response. - rename the annotation to `antecedent` (meaning something that logically precedes), since we already use "cause" elsewhere, albeit not as an annotation - minorly refactor the way controllers (workloads) from the cluster are converted into cluster.Controller values
8daf5d0
to
0ff33b1
Compare
This does two things:
it records the "release status" of a Helm release that corresponds to a FluxHelmRelease, in the FluxHelmRelease
it marks each resource that's created as a consequence of a FluxHelmRelease as linked to that FHR. This is then included in the ListControllers response in the API, as the field
Antecedent
, in the form of a stringified resource ID.For example,