Updating DMOD Install Process and Docs#456
Updating DMOD Install Process and Docs#456christophertubbs merged 23 commits intoNOAA-OWP:masterfrom
Conversation
| | Dependency | Constraints | Notes | | ||
| |-------------------------------------------|:--------------------------------------------|:----------------------------------------------------------------------:| | ||
| | [Usage Dependencies](#usage-dependencies) | Same as above | | | ||
| | Python | \>=3.8.x | | |
There was a problem hiding this comment.
Might want to bump that up to 3.9.x - we've got 3.9 somewhere in the pipeline (don't remember where). It's probably the github action.
There was a problem hiding this comment.
The (perhaps unofficial) rule of thumb has been for DMOD to support all the versions of Python that are currently, officially supported, which includes 3.8 for now. Given ecosystems like RHEL's that aren't as quick to move to new versions, I think this could make a difference in community adoption (which this particular PR is also geared toward).
I could have sworn we had a matrix in the Github Actions to support testing on a handful of different Python versions, including 3.8 and 3.9. Maybe I'm mixing that up with somewhere else and we should add it here.
Regardless, if there is something specific for which we need to consider breaking with the current approach, then let's open a separate issue and formally consider it.
There was a problem hiding this comment.
I could have sworn we had a matrix in the Github Actions to support testing on a handful of different Python versions, including 3.8 and 3.9. Maybe I'm mixing that up with somewhere else and we should add it here.
Ah, looks like I was remembering what Nels had set up in the ngen-cal project. We probably should adopt something similar.
|
Is this supposed to have all the DMOD client work? |
|
All looks solid - I'll approve if it turns out that the client code wasn't an accidental branch leak. |
|
@christophertubbs , hmm, yeah that's probably a leak. Let me figure out what I just did. |
Update example.env for correct wrf_hydro and troute branches.
Adding commented out examples for absent items and commenting out examples for items that need to be handled with defaults.
Picking subnets for configured Docker networks that are less likely to be encountered in the real world
Adding flag and option to helper script to init all standard service self-signed SSL certs for a deployment.
Documenting several additional required dependencies: - MinIO CLI client - Pip - Python dev headers/libs - A C++ compiler
- docker_pre_deploy_bind_mount_dir_check - docker_pre_deploy_create_secrets - docker_pre_deploy_scheduler_resources
Temporarily deactivate subset service until things can be address (and it is clear that it is necessary).
Updating script to automatically create necessary SSH keys built into job worker images.
Update control_stack.sh to use single node if deploying when there is only one available in the Docker Swarm.
Updating to support a couple different default command names, accept a specified command name for minio client, avoid DNS issues with 'localhost' and avoid SSL issues.
Add script to simplify creating scheduler resource config.
Automating pre-deploy checks/gen of Docker secret files, configured bind mount directories, and scheduler configuration files.
2954c80 to
07428be
Compare
|
@christophertubbs, good catch. Thanks for that. I'm not exactly sure how I did that, but I've removed the superfluous commits now. |
|
If I had a nickel for every time I had a branch leak I'd have enough money for a pack of post-its to remind me not to cause a branch leak. |
christophertubbs
left a comment
There was a problem hiding this comment.
Everything looks great
| ### Different Python Executable Names | ||
| It is quite common for the Python executables to be named `python3`, `python311`, `pip3`, etc. in the *global* Python environment, instead of just `python` and `pip`. This is accounted for when [creating a virtual environment](#using-a-virtual-environment), provided the right Python command was used to create it. Users not doing this should consider setting up shell aliases, symlinks in their path, or some other mechanism to ensure `python` and `pip` execute the desired versions appropriately. | ||
|
|
||
| > [!NOTE] |
There was a problem hiding this comment.
Neat! I didnt know about these markdown directives.
|
|
||
| ngen: | ||
| version: | ||
| 1: '127.0.0.1:5000/ngen:latest' |
There was a problem hiding this comment.
It is probably worth tracking that both ngen and nwm image names these are hard coded in service.py at the moment. Im sure we will refactor this in the future to be more flexible.
INSTALL.mdfile and other documentation related to setting up DMODngenimage build)