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

Trying to implement a different container engine other than Docker, questions about image build #804

Open
mbacon-renci opened this issue May 17, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@mbacon-renci
Copy link

We're trying to run otter grade inside a running kubernetes pod, and because of security limits those pods can't run Docker (which creates a container-in-container).

I am working on a patch to the otter grader code that would abstract the container creation that happens in otter.grade.containers.grade_submission so that it uses Docker by default but that can be overridden with an environment variable or similar.

One of the issues we're having in trying to use other container runtimes, like possibly kubernetes or OpenShift, is that otter grader wants to build a new image every time otter grade is run on an assignment.

From what I can see, the main changes to the image every time is that the config and assignment files are copied in.

Is there any reason that code couldn't be refactored slightly so that the same image is used for every assignment, and the assignment data copied in along with the submission data in the grade_submission method. This would make it much easier to deploy in more complex environments by making it much easier to have a single grader image published on a repository that could just be updated for each assignment. It looks like this should be possible and not cause any major headaches, but I wanted to check before doing the work and submitting a PR that I'm not missing something.

@mbacon-renci mbacon-renci added the enhancement New feature or request label May 17, 2024
@chrispyles
Copy link
Member

I think this is a really good idea. It should be possible to do a refactor like this; the main thing is that the new logic would need to make sure that it rebuilds the "base" image if the autograder zip has different requirements. To achieve, this it should be relatively easy to create two images in otter grade, one with only the requirements that's tagged with a hash of the environment.yml file from the autograder zip file, and a second built on top of that image with the tests and configurations loaded in. When otter grade runs, it can hash the environment.yml file, check whether an image with that tag exists, and then it won't need to rebuild the image.

If you'd like to contribute this refactor, I'm happy to review any PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

No branches or pull requests

2 participants