Repository navigation
Conversation
The deployment, its database, its labels and its configmaps are Ascender now. The operator managing them was still awx-operator-controller-manager, which is the most visible awx left in a namespace. The kustomize namePrefix moves to ascender-operator-, and the three base names that said awx before the prefix was applied move with it: the manager Role, its RoleBinding and its config map. The container in the Deployment becomes ascender-manager. Every patch that selects on those names follows, including the ones under config/testing. hack/rename-operator-objects.sh removes what an upgrade leaves behind. Kubernetes has no rename and kubectl apply only touches the names it is given, so an upgrade creates eleven new objects beside eleven old ones, including a second operator Deployment. The script deletes the old set by name, refuses to run before the new Deployment exists, and refuses to delete anything that is not prefixed or that is a CRD. That last guard is the point: config/default includes ../crd, so reaching for kubectl delete -k would take the CRDs and cascade to every deployment in the cluster. --leader-election-id stays awx-operator deliberately. Both operators pass the same id, so they contend for one lease and only one is ever active: an upgrade that has not been cleaned up yet is an idle standby rather than two controllers reconciling the same objects. It can be retired once no old operator is left anywhere. The namespace also stays awx here, for a different reason. The operator is namespace scoped, so changing the default would leave a raw-manifest user with a second operator in an empty namespace while their deployment carried on under the old one, and their upgrade would silently do nothing. That wants its own change, with a migration and release notes. awx-devel stays too: it is a development-mode volume name tied to the hostPath /awx_devel, and renaming one without the other only creates an inconsistency. Tested on a kind cluster by installing the old manifests, applying the new ones over them, and running the script: it refuses before the new Deployment exists, finds exactly the eleven duplicates, and after --apply leaves one operator, all eight CRDs, and the AWX resource untouched.
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
hack/ now holds two scripts with rename in their purpose, and the question they raise is which one somebody needs. They stay separate: one acts on the operator's own install and the other on a single deployment, they take different arguments, and one of them renames a PostgreSQL database and stops the deployment serving while the other touches no deployment at all. Folding them together would make the disruptive one easier to reach by accident to save twenty lines of shared logging. So a README instead. It says what each of the four scripts does, that neither rename needs the other, and that the operator goes first if both are being done, because the migration needs a working operator to rebuild what it removes and the rename never stops one running. Each script's header names the other, so whichever is opened first points across. It also repeats the rule both scripts enforce in code: nothing here deletes a CustomResourceDefinition, and neither should anyone else, because config/default includes ../crd and deleting those cascades to every deployment in the cluster. The added header lines pushed --help past the range it prints, which cut the rename script's usage off mid sentence. The range is derived from where the comment block ends now.
cigamit
approved these changes
Sep 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The deployment, its database, its labels and its configmaps are Ascender now. The operator managing them was still
awx-operator-controller-manager, which is the most visibleawxleft in a namespace.What moves
namePrefix: awx-operator-→ascender-operator-, which renames eleven objectsawxbefore the prefix was applied: the managerRole, itsRoleBinding, itsConfigMapawx-manager→ascender-managerconfig/testingincludedgalaxy_tagson four rolesKustomize rewired the references: the RoleBinding points at the renamed Role and the renamed ServiceAccount, and the Deployment uses the renamed ServiceAccount.
Why a cleanup script is needed
Kubernetes has no rename, and
kubectl applyonly creates or updates the names in the manifest it is given. An upgrade therefore creates eleven new objects beside eleven old ones, including a second operator Deployment.hack/rename-operator-objects.shremoves the old set. It is dry-run by default and:ascender-operator-controller-managerexists, so it cannot leave a cluster with no operator at allconfig/defaultincludes../crd, so reaching forkubectl delete -k config/defaultwould take the CRDs with it and cascade to every AWX and Ascender in the clusterThree things deliberately left
--leader-election-id=awx-operator. Both operators pass the same id, so they contend for one lease and only one is ever active. An upgrade that has not been cleaned up yet is an idle standby, not two controllers reconciling the same objects. Changing it here would give them separate leases and let both act. It can be retired once no old operator is left anywhere.namespace: awx. The operator is namespace-scoped, so changing the default would leave a raw-manifest user with a second operator in an empty namespace while their deployment carried on under the old one, and their upgrade would silently do nothing. That needs its own change, with a migration and release notes.awx-devel. A development-mode volume name tied tohostPath: /awx_devel. Renaming one without the other only creates an inconsistency.Verification
On a kind cluster: installed the old manifests, applied the new ones over them, then ran the script.
shellcheckis clean. Should land together with the two installer PRs that scale and wait on the Deployment by name.