-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consume Topology CR by reference #304
Consume Topology CR by reference #304
Conversation
tests/kuttl/tests/galera_deploy_topology/01-deploy_galera_topology.yaml
Outdated
Show resolved
Hide resolved
) | ||
if err != nil { | ||
instance.Status.Conditions.Set(condition.FalseCondition( | ||
condition.TopologyReadyCondition, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to reorder/amend the other Conditions checks in the existing unit tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to change any existing unit test because if .Spec.TopologyRef
doesn't exist (which is the case of the tests already in place) the order is preserved. This provides fully backward compatibility and TopologyCondition
is not part of the default conditions (see L455), but only added if the current reconciliation has this parameter in its spec.
We can improve the newly introduced topology kuttl test (when I see a working execution) to assert all the conditions including Topology.
3bafdf2
to
8660efb
Compare
We need openstack-k8s-operators/install_yamls#1015 to make topology CRD available in kuttl. |
/retest |
Build step failed:
re-kicking kuttl. |
/test mariadb-operator-build-deploy-kuttl |
This patch provides more granular control over Pod placement and scheduling through the Topology CR integration introduced in [1]. In particular it provides: - a new API parameter (TopologyRef) defined for each Component that allows to reference an existing Topology CRs in the same namespace - the operator logic that retrieves and processes the referenced Topology CR through the functions provided by lib-common [2] - enhanced StatefulSet and Deployment configuration that incorporates the processed Topology - kuttl test to verify a referenced topology has been applied to the StatefulSet and the resulting Pods Note that webhooks are in place to prevent referencing a Topology from a different namespace (which is not a supported scenario). Signed-off-by: Francesco Pantano <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fmount, stuggi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
a4fdf76
into
openstack-k8s-operators:main
This patch provides more granular control over Pod placement and scheduling through the Topology CR integration introduced in [1]. In particular it provides:
a new API parameter (TopologyRef) defined for each Component that allows to reference an existing Topology CRs in the same namespace
the operator logic that retrieves and processes the referenced Topology CR through the functions provided by lib-common [2]
enhanced Deployment configuration that incorporates the processed Topology
kuttl test to verify a referenced topology has been applied to the Deployment and the resulting Pods
Note that webhooks are in place to prevent referencing a Topology from a different namespace (which is not a supported scenario).
Jira: https://issues.redhat.com/browse/OSPRH-13836