feat(argocd-understack): split operator install from configs install#1896
feat(argocd-understack): split operator install from configs install#1896
Conversation
ctria
left a comment
There was a problem hiding this comment.
In general looks good to me. It is better to split the application installation from the configuration wherever possible.
skrobul
left a comment
There was a problem hiding this comment.
LGTM, we just have to evaluate if keeping 'enabled' has any meaning and use case
skrobul
left a comment
There was a problem hiding this comment.
One more thing - there seems to be a conflict on what the default for installConfigs is - the config.go has it default to true, while the docs have it as default to false
For some of the operators we need to install them and sometimes install additional things into their namespace. Like the webhook component or additional drivers. Start on this support path with cert-manager and external-secrets as a first start but this will expand to others.
Support the split configuration in the argocd-understack chart and handle the deploy configuration updates to match the behavior.
a8c1dd4 to
a065ee7
Compare
skrobul
left a comment
There was a problem hiding this comment.
Thanks for fixing the defaults. In regards to the merging behavior, I think it still may need some love.
enabledComponents() currently emits one ComponentConfig per scope match, and runDeployUpdate() applies each entry in sequence. For components present in both global and site, that means later entries can undo file changes from earlier entries.
Concrete cert-manager example (deploy.yaml):
global:
enabled: true
cert_manager:
installApp: true
installConfigs: false
site:
enabled: true
cert_manager:
installApp: false
installConfigs: true
Walkthrough with current logic:
enabledComponents()returns two entries for cert-manager (one from global, one from site).- First pass (global) creates cert-manager/values.yaml and removes config files.
- Second pass (site) removes cert-manager/values.yaml and creates cert-manager/kustomization.yaml.
- Final state depends on pass order; one scope can undo the other.
Following test should cover this I think:
func TestDeployUpdateAIOInstallOptionsAreMergedPerComponent(t *testing.T) {
tmpDir := t.TempDir()
clusterName := filepath.Join(tmpDir, "aio-cluster")
config := map[string]any{
"global": map[string]any{
"enabled": true,
"cert_manager": map[string]any{
"installApp": true,
"installConfigs": false,
},
},
"site": map[string]any{
"enabled": true,
"cert_manager": map[string]any{
"installApp": false,
"installConfigs": true,
},
},
}
if err := os.MkdirAll(clusterName, 0755); err != nil {
t.Fatalf("failed to create cluster dir: %v", err)
}
data, err := yaml.Marshal(&config)
if err != nil {
t.Fatalf("failed to marshal config: %v", err)
}
deployYaml := filepath.Join(clusterName, "deploy.yaml")
if err := os.WriteFile(deployYaml, data, 0644); err != nil {
t.Fatalf("failed to write deploy.yaml: %v", err)
}
if err := runDeployUpdate(clusterName); err != nil {
t.Fatalf("runDeployUpdate failed: %v", err)
}
compDir := filepath.Join(clusterName, "cert-manager")
valuesPath := filepath.Join(compDir, "values.yaml")
kustomPath := filepath.Join(compDir, "kustomization.yaml")
if _, err := os.Stat(valuesPath); os.IsNotExist(err) {
t.Fatalf("expected values.yaml for merged installApp=true")
}
if _, err := os.Stat(kustomPath); os.IsNotExist(err) {
t.Fatalf("expected kustomization.yaml for merged installConfigs=true")
}
if err := runDeployCheck(clusterName); err != nil {
t.Fatalf("deploy check should pass for merged AIO config: %v", err)
}
}If something was enabled in global but disabled in site due to the ordering it would be disabled which is not correct. Update the flow to handle this as an OR like the Helm chart does and add a test to validate this case.
|
Good point. I've added your test case and fixed the problem. |
For some of the operators we need to install them and sometimes install
additional things into their namespace. Like the webhook component or
additional drivers. Start on this support path with cert-manager and
external-secrets as a first start but this will expand to others.