more fixes for orchestrator script#81
more fixes for orchestrator script#81rostalan wants to merge 2 commits intoredhat-developer:mainfrom
Conversation
rostalan
force-pushed
the
install-orch-fix
branch
from
8ec71f5 to
91baec2
Compare
…hecks - Handle 409 conflict race in createNamespaceIfNotExists - Restore startingCSV pinning and use OLM labels for operator status checks - Add prepack script to build dist for git deps - Bump to 1.1.29 Made-with: Cursor
rostalan
force-pushed
the
install-orch-fix
branch
from
aa78a03 to
f60a828
Compare
rostalan
force-pushed
the
install-orch-fix
branch
from
a6c7ea9 to
1b762a2
Compare
| createError.message.includes("409") | ||
| ) { | ||
| console.log(`✓ Namespace ${namespace} already exists`); | ||
| return await this._k8sApi.readNamespace({ name: namespace }); |
There was a problem hiding this comment.
The 409 handling itself looks fine as a defensive measure, but I'm not sure the race condition scenario described actually happens in practice. createNamespaceIfNotExists already does a read-before-create, and the callers within this package don't seem to race configure() and deploy() run sequentially. Different Playwright workers get different project names so they'd be creating different namespaces too.
Can you share what failure you actually hit that led to this? If it was a flaky CI run, it might have been something else (retry after timeout, namespace stuck in Terminating, etc.) rather than a true parallel create race.
There was a problem hiding this comment.
The original logs expired, but it was a real CI failure on PR #2052 (2026-04-08T12:34:12Z). The orchestrator workspace has one project with two spec files, but playwright runs them on 2 separate workers. Both workers initialize concurrently, each calls the createNamespaceIfNotExists("orchestrator"), however then there is a race and the the slower worker fails with 409:
Running 52 tests using 2 workers
✓ Created namespace orchestrator
✗ Failed to create namespace orchestrator: HTTP-Code: 409
Error: HTTP-Code: 409
Body: {"status":"Failure","message":"namespaces \"orchestrator\" already exists",
"reason":"AlreadyExists","code":409}
at CoreV1ApiResponseProcessor.createNamespaceWithHttpInfo
at KubernetesClientHelper.createNamespaceIfNotExists
at RHDHDeployment.configure
Will try to find the full log in cursor convo...
There was a problem hiding this comment.
Relevant section:
Global setup completed successfully
Running 52 tests using 2 workers
✓ Created namespace orchestrator
✗ Failed to create namespace orchestrator: HTTP-Code: 409
Message: Unknown API Status Code!
Body: "{\"kind\":\"Status\",\"apiVersion\":\"v1\",\"metadata\":{},\"status\":\"Failure\",\"message\":\"namespaces \\\"orchestrator\\\" already exists\",\"reason\":\"AlreadyExists\",\"details\":{\"name\":\"orchestrator\",\"kind\":\"namespaces\"},\"code\":409}\n"
Headers: {"audit-id":"4844d4df-0a1d-41cd-9240-872f6fac29f1","cache-control":"no-cache, private","connection":"close","content-length":"214","content-type":"application/json","date":"Wed, 08 Apr 2026 13:05:50 GMT","strict-transport-security":"max-age=31536000; includeSubDomains; preload","x-kubernetes-pf-flowschema-uid":"c2e2b597-a15c-475b-b2e8-882bbf41352d","x-kubernetes-pf-prioritylevel-uid":"1edd6b33-5208-4fd1-8533-25509e5145b4"}
There was a problem hiding this comment.
The orchestrator workspace has one project with two spec files
that's the issue. and its expected if you use rhdh fixture then a project should have single spec file.
There was a problem hiding this comment.
There was a problem hiding this comment.
I see, so if that pattern is to be followed, I either have to merge the two spec files (which would result in a 2500 line spec file) or move them to separate pw projects, which would increase the setup time...
There was a problem hiding this comment.
so both spec file depends on same deployment?
in that case we have two option as you already understood.
- merge both spec file. (downside - will increase line of code in single file)
- have two sepearte projects (downside - although projects run parallel but still could take a little more time and consume more resource)
I guess, its upto you to make a educated call and choose one option to align with the other workspace and our overlay testing framework.
IMO, for the option 1 other than increasing line of code in single file i don't see any other issue.
There was a problem hiding this comment.
another option which i havenot realy tested but just sharing thoughts, what if we have parent spec and import the other spects into it?
There was a problem hiding this comment.
Okay so I tested last option and it works, which means we can have one project and one spec and import others into it.
let me know if you require more context/help, we can even have quick call.
There was a problem hiding this comment.
I'll take a look on monday, thanks for the suggestions.
2 participants
check_operator_statuswithwait_for_operatorusing OLM label selectors for deterministic operator selection