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

Add extra large scheduler size option #1696

Merged
merged 7 commits into from
Aug 8, 2024
Merged

Conversation

neel-astro
Copy link
Contributor

@neel-astro neel-astro commented Aug 2, 2024

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

List the functional testing steps to confirm this feature or fix.

Tested Extra Large deployment creation and update via CLI command and via YAML file, attached screenshot for reference

📸 Screenshots

Add screenshots to illustrate the validity of these changes.

Screenshot 2024-07-31 at 4 15 16 PM Screenshot 2024-07-31 at 4 18 50 PM Screenshot 2024-07-31 at 4 20 29 PM Screenshot 2024-07-31 at 4 22 43 PM Screenshot 2024-07-31 at 4 23 53 PM

📋 Checklist

  • Rebased from the main (or release if patching) branch (before testing)
  • Ran make test before taking out of draft
  • Ran make lint before taking out of draft
  • Added/updated applicable tests
  • Tested against Astro-API (if necessary).
  • Tested against Houston-API and Astronomer (if necessary).
  • Communicated to/tagged owners of respective clients potentially impacted by these changes.
  • Updated any related documentation

Copy link

codecov bot commented Aug 2, 2024

Codecov Report

Attention: Patch coverage is 46.66667% with 16 lines in your changes missing coverage. Please review.

Project coverage is 86.21%. Comparing base (be4ca15) to head (a1f39ae).

Files Patch % Lines
cloud/deployment/fromfile/fromfile.go 30.00% 14 Missing ⚠️
cloud/deployment/deployment.go 75.00% 2 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

@neel-astro neel-astro requested review from ianbuss and pritt20 August 5, 2024 05:44
Copy link

@ianbuss ianbuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small comments

@@ -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)
Copy link

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😬 good catch

cmd/cloud/deployment.go Show resolved Hide resolved
@@ -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):
Copy link

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:
...

?

Copy link
Contributor Author

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"

Copy link

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:

?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added the unit test 🙃

cmd/cloud/deployment.go Show resolved Hide resolved
Copy link

@ianbuss ianbuss left a 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):
Copy link
Contributor

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.

cloud/deployment/deployment_test.go Show resolved Hide resolved
@neel-astro neel-astro merged commit 63c58bc into main Aug 8, 2024
3 checks passed
@neel-astro neel-astro deleted the extra-large-deployment branch August 8, 2024 15:01
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.

3 participants