-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Orch] Add CRD RC handler #1340
Conversation
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.
This pull request does not contain a valid label. Please add one of the following labels: bug, enhancement, refactoring, documentation, tooling, dependencies
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1340 +/- ##
==========================================
- Coverage 48.88% 48.65% -0.23%
==========================================
Files 223 224 +1
Lines 19728 19850 +122
==========================================
+ Hits 9644 9658 +14
- Misses 9577 9685 +108
Partials 507 507
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Sentry.
|
pkg/remoteconfig/updater.go
Outdated
CoreAgent *CoreAgentFeaturesConfig `json:"config,omitempty"` | ||
SystemProbe *SystemProbeFeaturesConfig `json:"system_probe,omitempty"` | ||
SecurityAgent *SecurityAgentFeaturesConfig `json:"security_agent,omitempty"` | ||
CRDs *CustomResourceDefinitionURLs `json:"crds,omitempty"` |
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.
Take this with a grain of salt since I'm not too familiar with the operator, but this looks to me like structurally, configs are broken out by agent binary. Should the CRD configs be wrapped inside a ClusterAgentFeatureConfig type?
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.
Yeah that's a great call. I think this is a good idea for future work
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.
pkg/remoteconfig/updater.go
Outdated
@@ -137,7 +146,7 @@ func (r *RemoteConfigUpdater) Start(apiKey string, site string, clusterName stri | |||
"", | |||
r.serviceConf.baseRawURL, | |||
r.serviceConf.hostname, | |||
[]string{fmt.Sprintf("cluster_name:%s", r.serviceConf.clusterName)}, | |||
r.getTags, |
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.
This is a required breaking change
72892db
to
994024f
Compare
/merge |
🚂 MergeQueue: waiting for PR to be ready This merge request is not mergeable yet, because of pending checks/missing approvals. It will be added to the queue as soon as checks pass and/or get approvals. Use |
/remove |
🚂 Devflow: |
This merge request was unqueued If you need support, contact us on Slack #devflow! |
@@ -65,6 +65,8 @@ github.com/DataDog/datadog-agent/pkg/proto v0.55.0-rc.10 h1:ERkVmUoDPttyVKSCJM1f | |||
github.com/DataDog/datadog-agent/pkg/proto v0.55.0-rc.10/go.mod h1:gHkSUTn6H6UEZQHY3XWBIGNjfI3Tdi0IxlrxIFBWDwU= | |||
github.com/DataDog/datadog-agent/pkg/remoteconfig/state v0.55.0-rc.10 h1:nwJ2JWfjCmf6tpJD1RYHh4JV5HO2Njg6smxOGi8MyOE= | |||
github.com/DataDog/datadog-agent/pkg/remoteconfig/state v0.55.0-rc.10/go.mod h1:3yFk56PJ57yS1GqI9HAsS4PSlAeGCC9RQA7jxKzYj6g= | |||
github.com/DataDog/datadog-agent/pkg/remoteconfig/state v0.59.0-rc.1 h1:CIXKFvUsp5zgE+egvx+QrRTw8r54FMPZVu+z25UNqWs= |
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.
are there any changes between rc1 and rc4?
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.
There is only go mod change. The latest 2 commits: https://github.com/DataDog/datadog-agent/commits/pkg/remoteconfig/state/v0.59.0-rc.4/pkg/remoteconfig/state
internal/controller/datadogagent/feature/orchestratorexplorer/feature.go
Outdated
Show resolved
Hide resolved
internal/controller/datadogagent/feature/orchestratorexplorer/feature_test.go
Outdated
Show resolved
Hide resolved
} | ||
|
||
// Merge configs | ||
var finalConfig DatadogAgentRemoteConfig |
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.
i wonder if it would be clearer to return ClusterAgentFeaturesConfig
instead of the entire DatadogAgentRemoteConfig
. i got nervous for a moment that we were going to overwrite other parts of the status
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.
I think it follows the default pattern, which always returns the entire configuration.
datadog-operator/pkg/remoteconfig/updater.go
Line 317 in 03611c4
func (r *RemoteConfigUpdater) parseReceivedUpdates(updates map[string]state.RawConfig, applyStatus func(string, state.ApplyStatus)) (DatadogAgentRemoteConfig, error) { |
Ultimately, we need to adhere to the function getAndUpdateDatadogAgentWithRetry
, which takes the complete configuration and an update function as its input.
datadog-operator/pkg/remoteconfig/updater.go
Line 253 in 03611c4
func (r *RemoteConfigUpdater) getAndUpdateDatadogAgentWithRetry(ctx context.Context, cfg DatadogAgentRemoteConfig, f func(v2alpha1.DatadogAgent, DatadogAgentRemoteConfig) error) error { |
internal/controller/datadogagent/feature/orchestratorexplorer/feature_test.go
Outdated
Show resolved
Hide resolved
pkg/remoteconfig/updater.go
Outdated
@@ -63,6 +65,7 @@ type DatadogAgentRemoteConfig struct { | |||
ID string `json:"id,omitempty"` | |||
Name string `json:"name,omitempty"` | |||
CoreAgent *CoreAgentFeaturesConfig `json:"config,omitempty"` | |||
ClusterAgent *ClusterAgentFeaturesConfig `json:"cluster_agent,omitempty"` |
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.
This structure is unmarshalled from the RawConfig here and
datadog-operator/pkg/remoteconfig/updater.go
Lines 330 to 331 in 03611c4
var configData DatadogAgentRemoteConfig | |
if err := json.Unmarshal(c.Config, &configData); err != nil { |
And this config won't contain ClusterAgentFeatureConfig so curious why is this added here?
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.
This struct has several updaters, and we have the CRD updater running after the agent updater, where we populate the ClusterAgent
field.
datadog-operator/pkg/remoteconfig/updater.go
Line 183 in 03611c4
rcClient.Subscribe(string(state.ProductOrchestratorK8sCRDs), r.crdConfigUpdateCallback) |
datadog-operator/pkg/remoteconfig/orchestrator_k8s_crd.go
Lines 74 to 81 in 03611c4
if finalConfig.ClusterAgent == nil { | |
finalConfig.ClusterAgent = &ClusterAgentFeaturesConfig{} | |
} | |
if finalConfig.ClusterAgent.CRDs == nil { | |
finalConfig.ClusterAgent.CRDs = &CustomResourceDefinitionURLs{} | |
} | |
finalConfig.ClusterAgent.CRDs.Crds = &crds | |
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.
Sorry if my question wasn't clear. I'm confused why the ClusterAgentFeaturesConfig
is added here.
This structure
datadog-operator/pkg/remoteconfig/updater.go
Lines 64 to 71 in 03611c4
type DatadogAgentRemoteConfig struct { | |
ID string `json:"id,omitempty"` | |
Name string `json:"name,omitempty"` | |
CoreAgent *CoreAgentFeaturesConfig `json:"config,omitempty"` | |
ClusterAgent *ClusterAgentFeaturesConfig `json:"cluster_agent,omitempty"` | |
SystemProbe *SystemProbeFeaturesConfig `json:"system_probe,omitempty"` | |
SecurityAgent *SecurityAgentFeaturesConfig `json:"security_agent,omitempty"` | |
} |
is for RC product ProductAgentConfig
supporting CoreAgent, SystemProbe and SecurityAgent features. It's subscribed here
datadog-operator/pkg/remoteconfig/updater.go
Line 181 in 03611c4
rcClient.Subscribe(string(state.ProductAgentConfig), r.agentConfigUpdateCallback) |
While
datadog-operator/pkg/remoteconfig/updater.go
Line 183 in 03611c4
rcClient.Subscribe(string(state.ProductOrchestratorK8sCRDs), r.crdConfigUpdateCallback) |
subscribes a different ProductOrchestratorK8sCRDs
. So I'm curious why it's put under DatadogAgentRemoteConfig
structure instead of having it's own structure?
if finalConfig.ClusterAgent.CRDs == nil { | ||
finalConfig.ClusterAgent.CRDs = &CustomResourceDefinitionURLs{} | ||
} | ||
finalConfig.ClusterAgent.CRDs.Crds = &crds |
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.
Current implementation for security products unmarshals configuration_order
and uses to merge multiple configs:
datadog-operator/pkg/remoteconfig/updater.go
Lines 323 to 324 in 03611c4
if c.Metadata.ID == "configuration_order" { | |
if err := json.Unmarshal(c.Config, &order); err != nil { |
do we need similar logic for CRDs too?
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.
In the agentConfigUpdateCallback
, we have several components that need to be updated and merged in a specific order.
datadog-operator/pkg/remoteconfig/updater.go
Lines 181 to 183 in 03611c4
rcClient.Subscribe(string(state.ProductAgentConfig), r.agentConfigUpdateCallback) | |
rcClient.Subscribe(string(state.ProductOrchestratorK8sCRDs), r.crdConfigUpdateCallback) |
But for CRD, we only need to update its specific section, so maintaining an order isn't necessary in this case.
* [Orch] Add CRD RC handler * Remove print statement * Refactor to separate file * Move last function * Use CRD specific status * Add cluster agent config to RC * Correctly set product * Fix product and add logging * Add fixes for crd nil pointers * Revert accidental commit * Update dependencies and add tag getter function * Go.mod change * Reset go.mod * Update remoteconfig/state * Fix updater package and work sum * Clean up logs and force restart of DCA on CR changes * Add a lock around get and update of DDA * Improve comments and change test to use orchexp for annotation * Change to not do annotations every single time * Fill in orchestrator explorer for tests * Go mod update * Modify retry logic so it doesn't it for the entire update * Fix go.mod * Check in config crd stuff * Remove hard coded product and update go.mod * Revert go.mod back and fix errors * Go.sum update * overwrite cr by incoming data instead of appending to the old data (#1473) * feedback * feedback * rename to OrchestratorK8sCRDRemoteConfig --------- Co-authored-by: Kangyi LI <kangyi.li@datadoghq.com> Co-authored-by: levan-m <116471169+levan-m@users.noreply.github.com>
* [Orch] Add CRD RC handler * Remove print statement * Refactor to separate file * Move last function * Use CRD specific status * Add cluster agent config to RC * Correctly set product * Fix product and add logging * Add fixes for crd nil pointers * Revert accidental commit * Update dependencies and add tag getter function * Go.mod change * Reset go.mod * Update remoteconfig/state * Fix updater package and work sum * Clean up logs and force restart of DCA on CR changes * Add a lock around get and update of DDA * Improve comments and change test to use orchexp for annotation * Change to not do annotations every single time * Fill in orchestrator explorer for tests * Go mod update * Modify retry logic so it doesn't it for the entire update * Fix go.mod * Check in config crd stuff * Remove hard coded product and update go.mod * Revert go.mod back and fix errors * Go.sum update * overwrite cr by incoming data instead of appending to the old data (#1473) * feedback * feedback * rename to OrchestratorK8sCRDRemoteConfig --------- Co-authored-by: Joshua Lineaweaver <JLineaweaver@gmail.com> Co-authored-by: Kangyi LI <kangyi.li@datadoghq.com> Co-authored-by: Fanny Jiang <fanny.jiang@datadoghq.com>
What does this PR do?
Adds remote config support for custom resources in the operator. This new code will merge the user defined configuration with the configuration stored in remote config. Operator users with remote config enabled should no longer require a custom operator configuration to send custom resources.
Motivation
What inspired you to submit this pull request?
Additional Notes
Anything else we should know when reviewing?
Minimum Agent Versions
Are there minimum versions of the Datadog Agent and/or Cluster Agent required?
Describe your test plan
DD_SITE
todatad0g.com
.remoteConfig
is enabled on the Operator deployment-remoteConfigEnabled=true
in the args of the containerstatus
of DatadogAgentChecklist
bug
,enhancement
,refactoring
,documentation
,tooling
, and/ordependencies
qa/skip-qa
label