Appframeworks s1 tests stability fix#1712
Conversation
… was able to identify while running CI for 10.2 certification
** Claude analysis **Bug Explanation: MonitoringConsole Restart Loop Due to Empty SPLUNK_STANDALONE_URL The Problem When a Standalone CR with a MonitoringConsoleRef was deployed, the MonitoringConsole pod would enter a restart loop, timing out on its startup probe after ~6.7 minutes and continuously restarting. Root Cause The bug stems from a race condition in the operator's reconciliation logic combined with Go's zero-value semantics:
spec := enterpriseApi.StandaloneSpec{ Why the Fix Works By explicitly setting Replicas: 1 in the test spec: spec := enterpriseApi.StandaloneSpec{ The Replicas field is already 1 when ApplyMonitoringConsoleEnvConfigMap() is called, so GetSplunkStatefulsetUrls() correctly generates SPLUNK_STANDALONE_URL=splunk--standalone-0...svc.cluster.local instead of an empty string. Potential Operator-Level Fix The proper fix in the operator code would be to apply default values before creating dependent resources like ConfigMaps. This would involve reordering the logic in pkg/splunk/enterprise/standalone.go to apply defaults before line 228. |
Pull Request Test Coverage Report for Build 22190232827Details
💛 - Coveralls |
Description
Small fix to
appframeworksS1tests as the standalone specs that reference the MC cause some issues (as identified by claude). Will post claude explanation of bug and fix in commentsKey Changes
Just adding
Replicas: 1to standalone specs with MC refTesting and Verification
Ran tests locally
Related Issues
Stemmed from 10.2 certification: https://splunk.atlassian.net/browse/CSPL-4531
PR Checklist