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

[IA-4137] Add types to desired and existing runtime config #5079

Open
wants to merge 8 commits into
base: dev
Choose a base branch
from

Conversation

jdcanas
Copy link
Contributor

@jdcanas jdcanas commented Sep 12, 2024

No description provided.

};

// Auxiliary functions -- begin
export const isGce = (runtimeType) => runtimeType === runtimeTypes.gceVm;
Copy link
Contributor

Choose a reason for hiding this comment

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

these three isXxxx functions could be ijmproved to be type predicates that return "is TypeX... But from our chat, I assume that will have to wait until we do a 2nd wave of type love.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, since that will require nesting them in an additional field and thus functionally changing the modal itself, which I was able to avoid in this PR

// extract desiredruntimeconfig into a type
// TODO: converge type with getExistingEnvironmentConfig
// TODO: type desired runtimetype
export const buildDesiredEnvironmentConfig = (
Copy link
Contributor

Choose a reason for hiding this comment

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

if these util methods are only used by GcpComputeModal, maybe we can avoid adding them to the generic modal-utils file here and add them to a more specific helper file next to the only modal using it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I agree, this file needs a better name because these two methods (and the smaller helpers) are the main use case for it.

autopauseThreshold: currentRuntimeDetails?.autopauseThreshold,
computeConfig,
Copy link
Contributor

Choose a reason for hiding this comment

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

Should these two be typed as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

...(cloudService === cloudServices.GCE
? {
zone: computeConfig.computeZone,
region: computeConfig.computeRegion,
Copy link
Contributor

Choose a reason for hiding this comment

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

So no need of the region anymore? Only the zone was used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the region was duplicated on line 69 and 82 in both branches of the conditional, I simplified by moving it up to here https://github.com/DataBiosphere/terra-ui/pull/5079/files#diff-32a05189ab14623d039151b28dfee24908fc62cad51bf92afdb7767afbf7ef01R128

return {
hasGpu: computeConfig.hasGpu,
autopauseThreshold: computeConfig.autopauseThreshold,
computeConfig,
Copy link
Contributor

Choose a reason for hiding this comment

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

Same question here about typing these?

Copy link
Contributor

@lucymcnatt lucymcnatt left a comment

Choose a reason for hiding this comment

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

Left a couple questions + small thing I found when testing, the running compute cost is showing unknown specifically for the Standard VM compute type
image

...(currentRuntimeDetails?.timeoutInMinutes
? {
timeoutInMinutes: currentRuntimeDetails?.timeoutInMinutes,
}
Copy link
Contributor

Choose a reason for hiding this comment

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

is the timeout not needed here anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no, it is never used off the existing runtime config object

Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of removing this, it'd be better to fix the bug where this isn't used, and loading a runtime with a custom timeout does not display the correct value - GcpComputeModal line 236 has const [timeoutInMinutes, setTimeoutInMinutes] = useState(null); - this could change to useState(currentRuntime?.timeoutInMinutes || null

Copy link
Contributor

Choose a reason for hiding this comment

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

or at least leaving a comment on that line with the needed change

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this isn't actually a field on existing runtimes! I think the types demonstrate well that this is a field for desired runtime that we submit in the request, but it is not something leo returns back on existing.

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'll add a comment on the type

@@ -153,6 +153,8 @@ export const zonesToGpus = [
{ name: 'US-WEST4-C', validTypes: [] },
];

// **Deprecated**
// Use cloudServiceTypes in `runtime-config-models`
Copy link
Contributor

Choose a reason for hiding this comment

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

since this is deprecated, can we just ✂️ ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not without changing the logic... the TODO on line 135 of modal-utils is necessary before. Currently, we use this instead of the runtimeTypes in a lot of conditional logic. Hopefully if there is time for a second phase of this it can be deleted, but more testing is needed first.

Copy link
Contributor

@mlilynolting mlilynolting left a comment

Choose a reason for hiding this comment

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

Are you able to add some tests of the new logic that builds the existing runtime config/the desired runtime config from the existing runtime config?

@jdcanas
Copy link
Contributor Author

jdcanas commented Sep 17, 2024

Are you able to add some tests of the new logic that builds the existing runtime config/the desired runtime config from the existing runtime config?

it took a lot of lines to test it.. def was a good idea

@jdcanas
Copy link
Contributor Author

jdcanas commented Sep 17, 2024

Left a couple questions + small thing I found when testing, the running compute cost is showing unknown specifically for the Standard VM compute type image

Fixed the cost, thanks! The gpu type was garbled.

@mlilynolting
Copy link
Contributor

Are you able to add some tests of the new logic that builds the existing runtime config/the desired runtime config from the existing runtime config?

it took a lot of lines to test it.. def was a good idea

thank you, the tests look great!

const selectOption = await screen.findByText('2');
await user.click(selectOption);
const nextButton = await screen.findByText('Next');
await user.click(nextButton);
Copy link
Contributor Author

@jdcanas jdcanas Sep 18, 2024

Choose a reason for hiding this comment

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

There was actually a bug that these tests relied on to pass that was fixed.

Essentially, the canUpdateRuntime function compares existing and desired configs and if it finds a difference say 'yes you can update'. The toolLabel in the desired config was incorrectly computed, and was undefined, which signaled to the modal an update was allowed (hence update button Enabled). The test on line 369 now correctly reads update should be disabled when no changes have been made, and this subsequent test actually requires a field to be changed (CPUs) for Update to be enabled.

before (note the undefined):
Pasted Graphic

now (note two objects are now identical):
image

Copy link

sonarcloud bot commented Sep 19, 2024

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.

6 participants