[dev.operator-integrations] pkg/operator/config: Generate config for integrations - #1503
Conversation
captncraig
left a comment
There was a problem hiding this comment.
Looks good to me. I guess I'm still a little unclear how an integration config will get merged into the various instance configs, but I guess that isn't implemented yet.
| if requested == null then 1 | ||
| else if requested > 1 then requested | ||
| else 1; | ||
|
|
There was a problem hiding this comment.
This is a little confusing. Is this because the default is zero? I'd kinda prefer to explode here if somehow you pass a negative. But maybe this is a deep enough utility this behavior is safe enough?
There was a problem hiding this comment.
Ah, right, I copied this from the existing metrics code since agent-integrations.libsonnet is a combination of metrics + logs + integrations.
We do the logic here because 0 is the default, and we want at least 1 shard. We could probably do a better job at validating input / applying the proper defaults before we pass things over to the jsonnet generator, though.
…integrations (grafana-cold-storage#1503) * pkg/operator/config: Support integration-specific configs * document why we want to skip adding a __replica__ label for integration metrics
* [dev.operator-integrations] Add Integration into operator resource hierarchy (#1417) * add CRDs for integrations * move pkg/operator/config.Deployment to pkg/operator/apis/monitoring/v1alpha1 This allows us to easily generate the DeepCopy implementation for the struct instead of manually creating it. This commit also makes gragent the consistent name to refer to pkg/operator/apis/monitoring/v1alpha1, which is short and understandable. * Mark CRDs as generated to hide their diffs from GitHub PR reviews * test Integrations in resource hierarchy * go mod tidy * fix doc error for ConfigMaps * [dev.operator-integrations] pkg/operator/config: Generate config for integrations (#1503) * pkg/operator/config: Support integration-specific configs * document why we want to skip adding a __replica__ label for integration metrics * [dev.operator-integrations] Reconcile operator integrations (#1556) * pkg/operator: refactor pod template generation into its own function Extract the generation of pod templates out into its own function: the implementation of generating the DaemonSetSpec (for logs) and StatefulSetSpec (for metrics) was incredibly similar, and this will be doubly true for integrations. A shared function for generating the template will help remove duplication and avoid bugs where template generation becomes out of sync for the various generated resources. * pkg/operator: move more common logic to generatePodTemplate * pkg/operator: make generating pod templates its own function * pkg/operator: share generated ObjectMeta between pod controllers * pkg/operator: reconcile integrations * pkg/operator: resolve lint errors * pkg/operator: e2e test deployment of integrations * docs: update docs for RBAC additions * pkg/operator: fix lint errors * pkg/operator/apis: fix "order resources" typo (other resources) * pkg/operator: elaborate why deleteManagedResource gets called * update changelog
This PR adds the ability to generate an integrations-specific agent config for the operator. It is not wired in anywhere; nothing will currently generate the config.
Related to #1414
(Supersedes the original attempt at #1314)