AJ-1074 - Have WDS manage certain config variables on its own vs getting them from Leo #364
Conversation
...src/main/java/org/databiosphere/workspacedataservice/generated/ImportRequestServerModel.java
Outdated
Show resolved
Hide resolved
|
This is gonna be so great! Thanks for working on this. I like the changes in general but agree with @calypsomatic's observation that the TDR URL might need to be updated. Approving under the assumption that you'll work that out :) |
There was a problem hiding this comment.
A few comments inline - overall I like this approach and am so glad to see it happening.
We should review everything Leo sends and see if anything else can move over - for instance, the instrumentationEnabled value.
A kinda pedantic note: I don't think that Leo should know anything about WDS's Spring profiles. Leo should just send an "env" specification of prod, bee, dev, etc. …. then it's up to WDS and WDS's Helm chart to translate the "env" into a profile. This gives use more freedom in the future to interpret Leo's "env" in different ways.
service/src/main/java/org/databiosphere/workspacedataservice/sam/SamConfig.java
Outdated
Show resolved
Hide resolved
do we actually use instrumentationEnabled? I cant seem to find it referenced anywhere in terra-helm. And the million dollar question, is it time to remove the local pod postgres configuration? |
There was a problem hiding this comment.
👍 for syntax.
Before you merge - what is the rollout plan for this? In other words, what is the order of operations for merging PRs in Leo, terra-helmfile, WDS and releasing those to production? We need to make sure that we don't break older versions of WDS (see also: what's our plan for updating existing WDS deployments in prod), or break the app-upgrade process.
service/src/main/java/org/databiosphere/workspacedataservice/InstanceInitializer.java
Outdated
Show resolved
Hide resolved
|
Kudos, SonarCloud Quality Gate passed!
|
I choose to use Spring Profiles since it is built in functionality that provides easy configuration per profile. The main change that we will need in Leo is for Leo to provide the profile name using the following env variable "spring_profiles_active". Based on that value WDS will first load the default application.yaml and then the specific profile (specific profile will overwrite any values application already defined, for example in local profile I am setting workspace_id)
I created 4 new profiles:
Will need to make change in Leo to exclude all the values moved to profile and instead set the spring_profiles_active for WDS and provide a BEE name when one is present.
Reminder:
PRs merged into main will not automatically generate a PR in https://github.com/broadinstitute/terra-helmfile to update the WDS image deployed to kubernetes - this action will need to be triggered manually by running the following github action: https://github.com/DataBiosphere/terra-workspace-data-service/actions/workflows/tag.yml. Dont forget to provide a Jira Id when triggering the manual action, if no Jira ID is provided the action will not fully succeed.
After you manually trigger the github action (and it completes with no errors), you must go to the terra-helmfile repo and verify that this generated a PR that merged successfully.
The terra-helmfile PR merge will then generate a PR in leonardo. This will automerge if all tests pass, but if jenkins tests fail it will not; be sure to watch it to ensure it merges. To trigger jenkins retest simply comment on PR with "jenkins retest".