Skip to content
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

Optionally constrain to connected, approved compute nodes when selecting/ranking them #3768

Merged
merged 6 commits into from
Apr 10, 2024

Conversation

rossjones
Copy link
Contributor

@rossjones rossjones commented Apr 8, 2024

When ranking jobs to send a job to, exclude those that are not connected or not approved. By defaults nodes MUST be both approved and connected, but we have added options to the NodeSelector (in the form of orchestrator.NodeSelectionCriteria) to allow for explicit specification of whether we want them to be approved/connected.

# Show top matching approved nodes whether they are connected 
# or not 
selectedNodes, err := b.nodeSelector.TopMatchingNodes(
	ctx,
	job,
	len(execs),
	&orchestrator.NodeSelectionConstraints{
		RequireApproval:  true,
		RequireConnected: false,
	},
)

To make this workable, we change the default node state to APPROVED, requiring aconfig-option to rely on manual approval - it is this way around to ensure there is no required change for users upgrading to use this feature until they are ready to enforce it.

# Require manual node approval (not default)
node:
    requester:
        manualnodeapproval: true

# Do not require manual node approval (default)
node:
    requester:
        manualnodeapproval: false

Copy link
Contributor

coderabbitai bot commented Apr 8, 2024

Important

Auto Review Skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository.

To trigger a single review, invoke the @coderabbitai review command.


Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@rossjones rossjones force-pushed the schedule-approved-connected-nodes branch from 4c55e38 to d3e94bd Compare April 9, 2024 10:18
@rossjones rossjones changed the title Only consider connected, approved compute nodes when ranking Optionally constrain to connected, approved compute nodes when selecting/ranking them Apr 9, 2024
@rossjones rossjones force-pushed the schedule-approved-connected-nodes branch from d3e94bd to 2ff7abb Compare April 9, 2024 10:37
@rossjones rossjones marked this pull request as ready for review April 9, 2024 16:26
@rossjones rossjones requested a review from a team April 9, 2024 16:45
@rossjones rossjones merged commit c304c42 into main Apr 10, 2024
13 checks passed
@wdbaruni wdbaruni deleted the schedule-approved-connected-nodes branch April 16, 2024 13:44
aronchick pushed a commit that referenced this pull request Apr 27, 2024
…ing/ranking them (#3768)

When ranking jobs to send a job to, exclude those that are not connected
or not approved. By defaults nodes MUST be both approved and connected,
but we have added options to the NodeSelector (in the form of
`orchestrator.NodeSelectionCriteria`) to allow for explicit
specification of whether we want them to be approved/connected.

```go 

# Show top matching approved nodes whether they are connected 
# or not 
selectedNodes, err := b.nodeSelector.TopMatchingNodes(
	ctx,
	job,
	len(execs),
	&orchestrator.NodeSelectionConstraints{
		RequireApproval:  true,
		RequireConnected: false,
	},
)
```

To make this workable, we change the default node state to APPROVED,
requiring aconfig-option to rely on manual approval - it is this way
around to ensure there is no required change for users upgrading to use
this feature until they are ready to enforce it.

```yaml
# Require manual node approval (not default)
node:
    requester:
        manualnodeapproval: true

# Do not require manual node approval (default)
node:
    requester:
        manualnodeapproval: false
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants