nomad icon indicating copy to clipboard operation
nomad copied to clipboard

add default_ineligible configuration option

Open wjordan opened this issue 2 years ago • 6 comments

Specifies if scheduling eligibility should be disabled by default for new client nodes.

Fixes #13081, see this issue for discussion of the use-case.

wjordan avatar May 19 '22 23:05 wjordan

Thanks @jrasell for quick feedback and pointing me in the right direction with the implementation. I've updated the code to pass DefaultIneligible as a NodeRegisterRequest argument to Node.Register RPC, so that the server can apply the configurable default appropriately: https://github.com/hashicorp/nomad/blob/cb2484b3f88585974fbd993e2976b2e96440ed53/nomad/node_endpoint.go#L124-L131

I've updated the test as well. Please take a look and let me know if this is headed in the right direction!

wjordan avatar May 20 '22 17:05 wjordan

To answer your questions:

I am also curious of how this approach would work. If the value is set via a config file value, would the operator be expected to modify this value and then restart the agent?

The intended behavior is to only apply the config value as an initial default for newly-registered nodes, so the operator would be expected to set this via a config file value before starting the agent the first time.

The Nomad API also includes a method for updating node eligibility which operators could use. If this was the case, and the agent restarted (crash or otherwise) would the config value override what the API call did?

No, the config value is only intended to allow configuring the default for newly-registered nodes, so it wouldn't override anything once the node has been registered.

wjordan avatar May 20 '22 17:05 wjordan

Third attempt at this in abc5188bf25935026da8515808cf3a792a2914b2, just set the client node's SchedulingEligibility value based on DefaultIneligible in setupNode: https://github.com/hashicorp/nomad/blob/31e6a62381ba8e9b89f831bc570799c03affd118/client/client.go#L1475-L1479

This value will be sent to the server on the initial registration. Re-registering an existing node (e.g., on agent restart) should already correctly preserve the existing value, thanks to existing logic in upsertNodeTxn that retains SchedulingEligibility: https://github.com/hashicorp/nomad/blob/5b5c8535979de63abb52dc90b8ee0f08f5927dba/nomad/state/state_store.go#L896

wjordan avatar May 20 '22 21:05 wjordan

any update on this? was surprised that this isn't supported yet.

Tyrael avatar Oct 27 '23 21:10 Tyrael

Are there any updates on this?

miguelwhite avatar Feb 06 '24 14:02 miguelwhite