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

Create Dockerfile and host image publically #109

Closed
evetion opened this issue Feb 12, 2021 · 14 comments
Closed

Create Dockerfile and host image publically #109

evetion opened this issue Feb 12, 2021 · 14 comments
Assignees
Labels
computing Related to computational issues user-experience Improvements to the settings file, logging, error handling, etc.

Comments

@evetion
Copy link
Member

evetion commented Feb 12, 2021

Maybe as a julia tag on the current Wflow image?

@visr
Copy link
Member

visr commented Feb 16, 2021

What would you want the Docker to contain? The main entry point is the wflow_cli app, for which a tarball can be downloaded from https://download.deltares.nl/en/download/wflow/. Is that enough? Or if you need a Julia REPL, I guess we should take the julia docker, and use PackageCompiler.jl to bake Wflow.jl into the system image for fast startup.

@evetion
Copy link
Member Author

evetion commented Feb 16, 2021

I don't need the REPL, I would just like to start the model from the commandline. So that's the cli app I guess? PackageCompiler.jl could be nice, but not a hard requirement I'd say.

@visr
Copy link
Member

visr commented Feb 16, 2021

Ok yes in most cases the cli app would be sufficient, and easiest. Not sure what the best practices are for throwing a generic linux tarball into a Docker container, but that's all that needs to happen.

@visr visr assigned visr and evetion and unassigned visr Feb 17, 2021
@evetion
Copy link
Member Author

evetion commented Feb 18, 2021

Manual tryout. It now runs the test toml found in the documentation from /data. You can mount your own data and the cmd takes the location of the toml file:

ENTRYPOINT [ "/opt/wflow_cli/bin/wflow_cli" ]
CMD ["/data/sbm_simple.toml"]

Now available for public testing:

❯ docker run deltares/wflow:julia
┌ Info: Run information
│   model_type = "sbm"
│   starttime = CFTime.DateTimeStandard(2000-01-01T00:00:00)
│   Δt = 86400 seconds
└   endtime = CFTime.DateTimeStandard(2000-01-10T00:00:00)
Progress:   0%|                                         |  ETA: N/A
Progress:  10%|████▏                                    |  ETA: 0:00:14
Progress:  20%|████████▎                                |  ETA: 0:00:07
Progress:  30%|████████████▎                            |  ETA: 0:00:05
Progress:  40%|████████████████▍                        |  ETA: 0:00:04
Progress:  50%|████████████████████▌                    |  ETA: 0:00:03
Progress:  60%|████████████████████████▋                |  ETA: 0:00:02
Progress:  70%|████████████████████████████▊            |  ETA: 0:00:01
Progress:  80%|████████████████████████████████▊        |  ETA: 0:00:01
Progress:  90%|████████████████████████████████████▉    |  ETA: 0:00:00
Progress: 100%|█████████████████████████████████████████| Time: 0:00:04
Progress: 100%|█████████████████████████████████████████| Time: 0:00:04

@verseve
Copy link
Member

verseve commented Feb 18, 2021

Nice! @Pieter9011 could you test this?

@verseve
Copy link
Member

verseve commented Feb 18, 2021

Suggest to use config.toml for the TOML file. Or as argument to the docker if this is possible?

@evetion
Copy link
Member Author

evetion commented Feb 19, 2021

You can pass the location of the toml file on the command line. You'd still have to mount a data directory with said toml and data next it, correctly referenced.

So if you've got a localdata directory with data and a .toml:

docker -v localdata:/data deltares/wflow:julia /data/config.toml

@evetion
Copy link
Member Author

evetion commented Oct 6, 2022

So I've updated the Dockerfile based on the code https://gitlab.com/deltares/wflow/wflow_cli and pushed it to the :julia tag. I've made sure to also make a :python tag, based on the :latest tag, that still is based on the openstreams repository.

As soon as the Dockerfile is merged into wflow_cli, Teamcity can than build a new :latest tag, next to the manual release.

In the future we might move the cli code here and automate it further.

@JoostBuitink JoostBuitink moved this to Todo in Wflow Oct 31, 2022
@JoostBuitink JoostBuitink added computing Related to computational issues user-experience Improvements to the settings file, logging, error handling, etc. labels Oct 31, 2022
@JoostBuitink
Copy link
Contributor

Thanks again for picking this up @evetion!

It would also be really nice if previous versions of wflow remain accessible through their version as a tag (so wflow:v0.6.3 for example). Is it possible that every release gets two tags (latest and v0.7.1, for example)? This way latest always refers to the latest version, and you can use the version number to get a specific (older) version of Wflow. This is something that needs to be done in TeamCity I guess, right?

@evetion
Copy link
Member Author

evetion commented Jul 5, 2023

Sure, but Teamcity looks to the git repo for tags, and for https://gitlab.com/deltares/wflow/wflow_cli/-/tags, there are none.

I propose to merge the wflow_cli repo here, so we can make use of the releases (and thus tags) made here.

@JoostBuitink
Copy link
Contributor

Ah right, that makes sense! We are indeed planning to merge the wflow_cli repo to here, so lets do that first!

@evetion
Copy link
Member Author

evetion commented Jul 6, 2023

I'm happy to update TC afterwards 👍🏻

@JoostBuitink
Copy link
Contributor

That would be great! I have added the wflow_cli code to this branch https://github.com/Deltares/Wflow.jl/tree/merge_cli. Is there anything else that needs to be added? I see that in Ribasim.jl you have a .teamcity folder, I assume we need something like this as well?

@visr
Copy link
Member

visr commented Jul 6, 2023

Probably best to discuss in #274 or a separate PR. I think it's worth it to copy as much as possibly, e.g. also the build/create_binaries folder, since it will make it easier to create libwflow once we'll start coupling.

Regarding the .teamcity folder, syncing TeamCity settings to the repo can be enabled from the TeamCity side, so no need to do that in your branch.

@evetion evetion closed this as completed Aug 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
computing Related to computational issues user-experience Improvements to the settings file, logging, error handling, etc.
Projects
No open projects
Status: 🔲 Todo
Development

No branches or pull requests

4 participants