manifoldai / orbyter-cookiecutter Goto Github PK

• The readme refers to manifoldai/docker-ml-cookiecutter.git. This project no longer exists. It should be manifoldai/docker-cookiecutter
• When running the cookiecutter, you are prompted for the base image. The user has no idea what the possibilities are there. Different options for the images are documented under https://github.com/manifoldai/orbyter-docker. We should copy or reference this documentation here, so user knows what to do

Buggy versions keep getting commited to master. This is somewhat tolerable if we had some semi-regular release cadance. Alongside of this, some structure around releasing/versioning would be helpful.

The default README is rather long, and it's sometimes hard to find project-specific content below all the setup information. I propose moving the setup info to a separate file.

This was causing out-of-the-box CI to fail due to a typo. I am going to put up a bandaid PR to fix this, but we really want out out CI to run the same command as make ci.

This is related to #28. However, ideally the CI should:

1. build docker image
2. run make ci

Jeff and I can fix this up.

I am running into issues with the env file, which is causing make dev-start to fail:

make dev-start failing with docker compose 1.28.x, docker 20.10.x

Write a paragraph pointing people to right resources.

Right now, everything runs in mounted containers. However, most deployments involve a baked image. We should add a docker build command to the Makefile and CI/CD should run in this.

I was having a nightmare trying to get this up on windows. In the docker compose file you have 127.0.0.1 mapped. If you use 0.0.0.0 instead, it will work.

Because of this:
docker/for-win#204

You have to actually go to the IP returned by docker-machine ip. And get the port like in the README.

The default documentation is somewhat abstract. Adding a toy dataset and simple prediction model (e.g., linear regression on the radon dataset) would help make things a lot more concrete.

there is conflicts that occur when we have separate compose files for cloud and local.

for orbyter-dl-dev, the following lines need to be added to the develop service of docker-compose.yml:

    deploy:
      resources:
        reservations:
          devices:
          - capabilities: [gpu]

see https://docs.docker.com/compose/gpu-support/

Python modules cannot have dashes - in their name. It is recommended to use underscores _. However, I bunch of paths and made with dashes in the names. A user has to manually edit these.

Would love to see Jenkins integration where a job is created upon repo creation based on cookiecutter input.

Notes from running Orbyter-dl-dev:3.2 in AWS

1. You have to use an Ubuntu Deep Learning AMI. Our Docker container does not work with Amazon Linux (as far as we’ve tested).
2. We have tested on the g4dn.xlarge EC2 instance. It works there. Pretty sure it should work on the other GPU enabled instances as well.
3. You need to install docker compose. Follow the instructions here: https://docs.docker.com/compose/install/. i.e. it's some curl commands.
4. After installing docker compose, you need to edit the /etc/docker/daemon.json file so that the default runtime is set FIRST. If you don’t make it first, then the container will not pick up the runtime. Don’t make that mistake #devops. Here’s what the file should look like after editing:

{
    "default-runtime": "nvidia",
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
}

Hi,
I was wondering if there is a sample output of the cookiecutter - in order to analyze it before setting up the entire project?

isort needs a new "flag" to be compatible with black. It is:

	docker exec -t $(CONTAINER_NAME) isort $(PROJ_DIR) --profile black

Error:

Probably need to take a look at the dependencies for the DVC initialization or the sequencing in the setup hook file

When cutting a new repository with orbyter 3.5, black complains about how train.py is formatted.

We need to look into how to best test this repo. I'm not familiar with testing cookiecutters, but it looks like we can cookiecut a local repo so this shouldn't be too crazy (just do it in a fresh docker continer):

At the most basic level:

• verify cookiecutter can build
• verify starting tests pass
• verify docker containers can build

I could probably get to this in 1-2 weeks, but taggin others if they are available @joegoldbeck @jeffmm, @TensorDuck

Add some commands that facilitate easier testing, maybe within a containerized workflow.

took me forever to find this bug, but I get a warning when running docker-compose -f docker/docker-compose.yml config.

WARNING: The MLFLOW_TRACKING_URI variable is not set. Defaulting to a blank string.

This results in the MLFlow container crashing. I don't know why but reverting from docker-compose version 1.29.2 to 1.27.4 fixed this.

There are a few broken links in the README:

1. https://cookiecutter.readthedocs.io/en/latest/readme.html
2. https://medium.com/manifold-ai/torus-a-toolkit-for-docker-first-data-science-bddcb4c97b52

The README could probably also use a few adjustments to come up-to-date.