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

Convert environment generation logic to lazy / implcit instead of explicit #433

Merged

Conversation

douglasjacobsen
Copy link
Collaborator

This merge converts the logic around generating software environments and packages away from being explicitly defined in the workspace configuration file.

Instead, packages and environments are now generated lazily when processing experiments. This avoids several issues related to vector / matrix logic causing problems rendering individual packages and environments.

@douglasjacobsen douglasjacobsen added documentation Improvements or additions to documentation enhancement New feature or request testing Modifications to testing labels Mar 6, 2024
@douglasjacobsen douglasjacobsen requested a review from rfbgo March 6, 2024 22:58
@douglasjacobsen douglasjacobsen force-pushed the exp_specific_envs branch 3 times, most recently from 1fc88c4 to 3999010 Compare March 7, 2024 02:51
This commit updates the way software environments are generated.

Previously, software environments were required to be explicitly defined
in the workspace configuration file. This raised some problems relating
to the vector / matrix logic being unable to process vectors that didn't
actually impact the software environments.

This commit changes the behavior to cause experiments to render their
own software environments based on their variable definitions. This
prevents the previously mention issue by presenting only scalar variable
definitions to the software environment.
@douglasjacobsen douglasjacobsen marked this pull request as ready for review March 7, 2024 04:05
rfbgo
rfbgo previously approved these changes Mar 7, 2024
Copy link
Collaborator

@rfbgo rfbgo left a comment

Choose a reason for hiding this comment

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

Few comments, overall LGTM

@rfbgo rfbgo merged commit f8a9aa2 into GoogleCloudPlatform:develop Mar 7, 2024
5 checks passed
@douglasjacobsen douglasjacobsen deleted the exp_specific_envs branch April 16, 2024 21:53
linsword13 added a commit to linsword13/ramble that referenced this pull request May 20, 2024
This helps with saving redundant spack concretization, when experiments
under different workloads are actually using the same software environment.

Some more contexts (courtesy of Bob and Doug):

* Historically the spack env was rendered during workspace render time,
  that's why the existing namespacing.

* That's changed in
  GoogleCloudPlatform#433.

* And it's safe to assume same `env_name` always 1-1 maps to a spack
  env. There's a check to guarantee that:
  https://github.com/GoogleCloudPlatform/ramble/blob/f4e0e06c7f4ab0efd5d05000cb7ebec7b3ad33b2/lib/ramble/ramble/software_environments.py#L371-L374.

Tested: tested with the following:

* A new created workspace with gromacs ran fine.

* (backward-compt) An existing workspace created from the current
  develop head ran fine after running `ramble workspace setup` under the
  current branch.
linsword13 added a commit to linsword13/ramble that referenced this pull request May 20, 2024
This helps with saving redundant spack concretization, when experiments
under different workloads are actually using the same software environment.

Some more contexts (courtesy of Bob and Doug):

* Historically the spack env was rendered during workspace render time,
  that's why the existing namespacing.

* That's changed in
  GoogleCloudPlatform#433.

* And it's safe to assume same `env_name` always 1-1 maps to a spack
  env. There's a check to guarantee that:
  https://github.com/GoogleCloudPlatform/ramble/blob/f4e0e06c7f4ab0efd5d05000cb7ebec7b3ad33b2/lib/ramble/ramble/software_environments.py#L371-L374.

Tested: tested with the following:

* A new created workspace with gromacs ran fine.

* (backward-compt) An existing workspace created from the current
  develop head ran fine after running `ramble workspace setup` under the
  current branch.
linsword13 added a commit to linsword13/ramble that referenced this pull request May 20, 2024
This helps with saving redundant spack concretization, when experiments
under different workloads are actually using the same software environment.

Some more contexts (courtesy of Bob and Doug):

* Historically the spack env was rendered during workspace render time,
  that's why the existing namespacing.

* That's changed in
  GoogleCloudPlatform#433.

* And it's safe to assume same `env_name` always 1-1 maps to a spack
  env. There's a check to guarantee that:
  https://github.com/GoogleCloudPlatform/ramble/blob/f4e0e06c7f4ab0efd5d05000cb7ebec7b3ad33b2/lib/ramble/ramble/software_environments.py#L371-L374.

Tested: tested with the following:

* A new created workspace with gromacs ran fine.

* (backward-compt) An existing workspace created from the current
  develop head ran fine after running `ramble workspace setup` under the
  current branch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request testing Modifications to testing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants