-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add extra large scheduler size option #1696
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1696 +/- ##
==========================================
- Coverage 86.24% 86.21% -0.04%
==========================================
Files 117 117
Lines 17095 17111 +16
==========================================
+ Hits 14744 14752 +8
- Misses 1417 1425 +8
Partials 934 934 ☔ View full report in Codecov by Sentry. |
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.
Small comments
cloud/deployment/deployment_test.go
Outdated
@@ -978,6 +978,10 @@ func (s *Suite) TestCreate() { | |||
err = Create("test-name", ws, "test-desc", csID, "4.2.5", dagDeploy, CeleryExecutor, "", "", LargeScheduler, "", "", "", "", "", "", "", "", astroplatformcore.DeploymentTypeHYBRID, 0, 0, mockPlatformCoreClient, mockCoreClient, false) | |||
s.NoError(err) | |||
|
|||
// Call the Create function | |||
err = Create("test-name", ws, "test-desc", csID, "4.2.5", dagDeploy, CeleryExecutor, "", "", ExtraLargeScheduler, "", "", "", "", "", "", "", "", astroplatformcore.DeploymentTypeHYBRID, 0, 0, mockPlatformCoreClient, mockCoreClient, false) |
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.
Should these tests use a hosted deployment type, since scheduler size is not handled with t-shirt sizes in hybrid?
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.
😬 good catch
@@ -327,12 +327,14 @@ func createOrUpdateDeployment(deploymentFromFile *inspect.FormattedDeployment, c | |||
|
|||
var schedulerSize astroplatformcore.CreateStandardDeploymentRequestSchedulerSize | |||
switch strings.ToUpper(deploymentFromFile.Deployment.Configuration.SchedulerSize) { | |||
case deployment.SMALL: | |||
case string(astrocore.CreateStandardDeploymentRequestSchedulerSizeSMALL): |
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.
Should we just do:
switch deploymentFromFile.Deployment.Configuration.SchedulerSize:
case deployment.SmallScheduler:
...
?
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.
it's a case of "small" vs "SMALL" 🙈, we are taking "small" as user input in CLI and API expects "SMALL"
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.
So:
switch strings.ToLower(deploymentFromFile.Deployment.Configuration.SchedulerSize):
case deployment.SmallScheduler:
?
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.
I might prefer relying on the auto-generated enums from the Core API client package, for comparing against the Core API client response, just to avoid any unwanted harm down the line. But I agree the wording is way too verbose.
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.
I like driving this from the (indeed verbose) client constants too. Should we then also do this in the deployment
package and remove the *Scheduler
constants?
It's a shame the client doesn't also provide an enumeration of the constants so that we wouldn't need to refer to individual values in the CLI at all, including the flag description. We could bake something up with the reflect package based on the common prefix but perhaps that's getting too clever.
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.
you mean the smallScheduler
, mediumScheduler
, largeScheduler
, .... I think we might need to live with them because they represent the naming convention (lowercase) that the CLI expects as input for the scheduler size field (it's a case of CLI expecting "small" as input vs API expecting "SMALL" as input 🙂 ).
I am divided if we should just use strings.ToLower(<CORE API CLIENT CONSTANT>)
, let me know if you feel strongly about it.
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.
I'd expect that since we already removed deployment.SMALL
etc we'd also remove smallScheduler
etc. Yeah it's verbose with the strings.ToLower
added on but it's closer to the truth of what is a valid input than redefining it as a constant.
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.
updated the logic
@@ -945,6 +947,8 @@ func Update(deploymentID, name, ws, description, deploymentName, dagDeploy, exec | |||
standardDeploymentRequest.SchedulerSize = astroplatformcore.UpdateStandardDeploymentRequestSchedulerSizeMEDIUM | |||
case LargeScheduler: | |||
standardDeploymentRequest.SchedulerSize = astroplatformcore.UpdateStandardDeploymentRequestSchedulerSizeLARGE | |||
case ExtraLargeScheduler: | |||
standardDeploymentRequest.SchedulerSize = astroplatformcore.UpdateStandardDeploymentRequestSchedulerSizeEXTRALARGE |
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.
Should we sprinkle a standard deployment test in to make this warning go away?
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.
added the unit test 🙃
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.
If you're happy the warnings about code coverage are tested adequately elsewhere, this lgtm.
@@ -327,12 +327,14 @@ func createOrUpdateDeployment(deploymentFromFile *inspect.FormattedDeployment, c | |||
|
|||
var schedulerSize astroplatformcore.CreateStandardDeploymentRequestSchedulerSize | |||
switch strings.ToUpper(deploymentFromFile.Deployment.Configuration.SchedulerSize) { | |||
case deployment.SMALL: | |||
case string(astrocore.CreateStandardDeploymentRequestSchedulerSizeSMALL): |
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.
I like driving this from the (indeed verbose) client constants too. Should we then also do this in the deployment
package and remove the *Scheduler
constants?
It's a shame the client doesn't also provide an enumeration of the constants so that we wouldn't need to refer to individual values in the CLI at all, including the flag description. We could bake something up with the reflect package based on the common prefix but perhaps that's getting too clever.
Description
This PR contains changes to allow the user to pass
extra_large
as a scheduler size option when creating/updating Hosted deployments either via CLI command or via YAML file🎟 Issue(s)
Related #22568
🧪 Functional Testing
Tested Extra Large deployment creation and update via CLI command and via YAML file, attached screenshot for reference
📸 Screenshots
📋 Checklist
make test
before taking out of draftmake lint
before taking out of draft