-
Notifications
You must be signed in to change notification settings - Fork 15
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
Updating DMOD Install Process and Docs #456
Updating DMOD Install Process and Docs #456
Conversation
| Dependency | Constraints | Notes | | ||
|-------------------------------------------|:--------------------------------------------|:----------------------------------------------------------------------:| | ||
| [Usage Dependencies](#usage-dependencies) | Same as above | | | ||
| Python | \>=3.8.x | | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.md
file and other documentation related to setting up DMODngen
image build)