You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The global-workflow has begun deployment to the NOAA cloud-service providers (CSP). As a result, all related utilities will need to be compiled against stacks specific to the respective CSPs.
Currently, UFS-UTILS does not provide this option. The steps to accomplish this are as follows.
Add capabilities to detect the respective CSP platform;
Point to the correct set up modules;
Build the UFS-UTILS package within the global-workflow build system using the UFS-UTILS build system (see here.
The current blocker is which compiled stack to use; that supported by the global-workflow team or EPIC.
Proposed/temporary solution: Build against the current global-workflow maintained stack. Once the questions related to EPIC are resolved, the global-workflow supported stack can be swapped out for the EPIC supported stack (i.e., load a different module path).
This would require two different PRs as dictated by the current CSP stacks. However, once the infrastructure bits are added to the build system the impact of pointing to a new stack path (e.g., EPIC) should be small/minimal and accompanied by a short PR.
The text was updated successfully, but these errors were encountered:
The global-workflow has begun deployment to the NOAA cloud-service providers (CSP). As a result, all related utilities will need to be compiled against stacks specific to the respective CSPs.
Currently, UFS-UTILS does not provide this option. The steps to accomplish this are as follows.
The current blocker is which compiled stack to use; that supported by the global-workflow team or EPIC.
Proposed/temporary solution: Build against the current global-workflow maintained stack. Once the questions related to EPIC are resolved, the global-workflow supported stack can be swapped out for the EPIC supported stack (i.e., load a different module path).
This would require two different PRs as dictated by the current CSP stacks. However, once the infrastructure bits are added to the build system the impact of pointing to a new stack path (e.g., EPIC) should be small/minimal and accompanied by a short PR.
The text was updated successfully, but these errors were encountered: