Skip to content

[FEATURE] Add support for NodeReadinessRule ordering #272

@natherz97

Description

@natherz97

Is your feature request related to a problem or existing issue? Please describe.

Suppose I have 2 NodeReadinessRules which correspond to DaemonSet A and DaemonSet B and I want DaemonSet A to run before DaemonSet B on a target node. I can accomplish this ordering by specifying that DaemonSet A should tolerate taints from both NodeReadinessRules and DaemonSet B should only tolerate taints from its own rule. As long as my NodeReadinessRules correspond to DaemonSets, I can control the ordering that the DaemonSets run on the node with tolerations.

Now, suppose I have 2 NodeReadinessRules which correspond to DaemonSet A running on a node and a validation test that should succeed against the node. If my validation test relies on DaemonSet A being ready, there is not a way to declare this relationship between the NodeReadinessRules. I want to specify that the NodeReadinessRule corresponding to my validation test should only become active after DaemonSet A is running because my validation test would fail if DaemonSet A wasn't healthy.

Describe the solution you'd like

It would be useful if we could declare any peer NodeReadinessRules which must be satisfied before a rule should be processed. Currently, the controller which runs the validation test cannot refer to only its NodeReadinessRules to get this context and we would have to embed logic that it should check for either the taint or node status condition corresponding to DaemonSet A being ready before initiating the validation test.

Please let me know if this use-case for NodeReadinessRule ordering is outside the scope of NRC and that this use-case for keeping a node tainted a node for a validation test (after all of its required components are deployed) should be handled with a different mechanism.

Describe alternatives you've considered

Since our validation test runs last, an alternative implementation would be to deploy our DaemonSets with NRC but manage the last taint without NRC. Our controller could wait for all NodeReadinessRules to be satisfied (either by checking for taint removal or that all node status conditions are healthy) prior to running the validation test and removing the last taint after the test succeeds.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new feature.needs-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions