Conversation
The operator serves the same four resources under two groups, but every platform template here asked for kind: AWX, so a fresh install had no way to land on the Ascender kind at all. The kind is now resolved once per run, and the eight platform templates, the backup, restore and migrate roles, and the CR patch in awx_migrate_ascender all follow that decision instead of naming a kind themselves. That last one names its instance differently, so it calls the resolver with its own name. The decision is deliberately conservative: - A new install gets Ascender. - An install where an AWX of this name already exists keeps AWX. Changing the kind of a running deployment means moving ownership of every object it manages, which is what the operator's hack/migrate-awx-to-ascender.sh does, and not something a re-run of the installer should do behind the operator's back. - An operator that does not serve ascender.ansible.com yet gets AWX, since the kind would otherwise not exist. Both questions go to the CustomResourceDefinition API, which always resolves, so an absent CRD comes back as an empty list rather than an error, leaving a genuine failure free to stop the run instead of being answered with a guess. Verified against a kind cluster carrying the real CRDs: a fresh namespace picks Ascender, an existing AWX keeps AWX. All eight platform templates render and parse in both modes, mesh ingress included, which sits at v1alpha1 and needed its own pair.
ascender-operator#47 makes deployment_type follow the kind, so a deployment created as an Ascender labels its objects app.kubernetes.io/managed-by: ascender-operator rather than awx-operator. Seven label selectors in awx_migrate_ascender named awx-operator outright, so against such a deployment they would have matched nothing and the role would have looked like it had nothing to do: no route, no web pod, no postgres statefulset. They take the label from the same resolver that decides the kind, which the role now runs once for every task file it includes, with its own instance name. An AWX deployment still resolves to awx-operator, so nothing changes for one of those.
These playbooks scale, wait on and restart the operator's Deployment by name. ascender-operator#54 renames it to ascender-operator-controller-manager, so every one of those references would find nothing: an install would wait its full timeout for a Deployment that does not exist, then carry on against a deployment nothing is reconciling. Hardcoding the new name would move the same breakage onto anyone still running the old operator, so the name is resolved once per run, in the same place that already decides which API kind is in play. It asks for both names and prefers the new one, because both exist at once during an upgrade until the old set is cleaned up. A playbook that runs outside a role includes the resolver for itself, having no role to inherit the fact from.
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
1 participant
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.
Goes with ctrliq/ascender-operator#54, which renames the operator's own objects, and builds on the resolver this repo's Ascender-kind PR adds. Merge that one first.
The problem
These playbooks name the operator's Deployment outright when they scale it, wait on it, or restart it. Once the operator is
ascender-operator-controller-manager, every one of those finds nothing: an install would wait 360s for a Deployment that does not exist and then carry on against a deployment nothing is reconciling.Hardcoding the new name instead just moves the breakage to anyone still on the old operator.
What this does
The name is resolved once per run, in the same
common/tasks/resolve_cr_kind.ymlthat already decides the API kind, by asking for both names and preferring the new one. Every hardcoded reference becomes{{ ascender_operator_deployment }}.Preferring the new name matters because both exist at once during an upgrade, until
hack/rename-operator-objects.shremoves the old set.Verified against a kind cluster
A playbook that runs outside a role gets the resolver included for itself, since it has no role to inherit the fact from.