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

Enable v1 APIs for Disk, App, and Runtime for Azure hosted Leonardo instances #4737

Merged
merged 21 commits into from
Aug 13, 2024

Conversation

bennettn4
Copy link
Contributor

Jira ticket: https://broadworkbench.atlassian.net/browse/TOAZ-366

Summary of changes

Enable v1 APIs for Disk, App, and Runtime for Azure hosted Leonardo instances.

What

Why

  • v1 APIs are still used in TerraUI for data retrieval even when hosted on Azure. This will be changed with ongoing development of platform agnostic v2 APIs

  • This change is covered by automated tests

    • NB: Rerun automation tests on this PR by commenting jenkins retest or jenkins multi-test.
  • I validated this change

  • Primary reviewer validated this change

  • I validated this change in the dev environment

Copy link

codecov bot commented Aug 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.94%. Comparing base (4553066) to head (a50a8f3).

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #4737      +/-   ##
===========================================
+ Coverage    73.90%   73.94%   +0.03%     
===========================================
  Files          161      161              
  Lines        15054    15077      +23     
  Branches      1222     1234      +12     
===========================================
+ Hits         11125    11148      +23     
  Misses        3929     3929              
Files Coverage Δ
...bench/leonardo/http/AzureDependenciesBuilder.scala 97.36% <100.00%> (+2.36%) ⬆️
...rkbench/leonardo/http/GcpDependenciesBuilder.scala 73.14% <100.00%> (ø)
.../dsde/workbench/leonardo/http/api/HttpRoutes.scala 98.48% <100.00%> (+0.09%) ⬆️
...ench/leonardo/http/service/DiskServiceInterp.scala 91.00% <100.00%> (ø)
...rkbench/leonardo/http/service/RuntimeService.scala 100.00% <ø> (ø)
...h/leonardo/http/service/RuntimeServiceInterp.scala 87.52% <100.00%> (+0.02%) ⬆️

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4553066...a50a8f3. Read the comment docs.

@bennettn4 bennettn4 assigned bennettn4 and unassigned bennettn4 Aug 7, 2024
@@ -122,10 +122,10 @@ class DiskServiceInterp[F[_]: Parallel](config: PersistentDiskConfig,
): F[Unit] =
for {
ctx <- as.ask
sourceAncestry <- F.fromFuture(F.delay(googleProjectDAO.getAncestry(sourceGoogleProject.value)))
sourceAncestry <- F.fromFuture(F.delay(googleProjectDAO.get.getAncestry(sourceGoogleProject.value)))
Copy link
Collaborator

@rtitle rtitle Aug 8, 2024

Choose a reason for hiding this comment

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

My concern with sprinkling .get in this code is that the API will fail with a HTTP 500 scala.MatchError if these APIs are called in a Leo deployment with no GCP dependencies.

A cleaner option might be doing something like this in the appropriate endpoints (e.g. create/delete runtime/disk):

projectDAO <- F.fromOption(googleProjectDAO, BadRequestException("GCP is not enabled"))
// then use projectDAO as needed

Then you would get a sensible error message and HTTP status code if a GCP-specific API is called.

(I realize that this only affects the VA deployment and v1 create/delete runtime/disk will never actually be called. So just a minor suggestion.)

Copy link
Collaborator

@rtitle rtitle left a comment

Choose a reason for hiding this comment

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

Approving, but with a minor suggestion above.

@giventocode giventocode self-requested a review August 12, 2024 16:11
@bennettn4 bennettn4 merged commit 1bf54b3 into develop Aug 13, 2024
24 checks passed
@bennettn4 bennettn4 deleted the azure-v1-apis branch August 13, 2024 15:09
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