-
Notifications
You must be signed in to change notification settings - Fork 148
[base/kvm] Add KVM enabled base container #949
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
base: main
Are you sure you want to change the base?
Conversation
[Frontend/Submissions] fix - change class for file code icon
add - submission date to feedback
…ous#821) * using tabs to simplify display * fix tiny bug if "activate lti" is checked and then unchecked, it displays "access control type" independently of selected access control * Hide lti tab if lti option is not activated in general tab
This keeps the file metadata (permissions, dates, ...). Fix INGInious#390
…nious#849) Warning: this doesn't ensure retrocompatibilty with previous weighing system.
The new router does not perform correctly when using regex groups. Moreover, it is now required to explicitely tell it the converter can match the forward / using ``part_isolating``.
[backend] do not erase previous state in case of errors
Currently translated at 92.3% (680 of 736 strings) Translation: INGInious/Frontend Translate-URL: https://weblate.info.ucl.ac.be/projects/inginious/frontend/fr/
Translations update from Weblate
[agent/docker] replace SSH opt-in by env types
Translations update from Weblate
Fixes INGInious#697. This is a first mitigation and in all case useful, as the limit is set on the total command sent to the MongoDB server, which cannot be computed before.
[frontend/submission_manager] catch DocumentTooLarge exception
Updated setup requirements to Flask 2.0+ that introduces the new function. Fix INGInious#942
|
This PR should solve #939. |
|
Some slowness is observed during the execution of a simple mininet command such as |
anthonygego
left a comment
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.
This is very a first pass. I'd like to see those issues addressed first because I'm wondering if there is a possibility to make this fully modular and if it would be relevant.
Indeed, the added lines seem very tied to the additional container architecture and make code harder to understand. I would know if it's possible to put these additional piece of codes in a kind of hook folder provided in the container image.
| runtime=runtime, | ||
| ulimits=[nofile_limit] | ||
| ulimits=[nofile_limit], | ||
| devices=['/dev/kvm'] if kvm and image_requires_kvm else [] |
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 fear that unwanted behaviours can happen silently here. If the container image requires kvm and the agent does not support/enable it, no notification will be given. There seems to be no way for the user to know if the agent supports kvm, and, moreover, nothing prevents the job to be assigned to an inappropriate agent.
I'm however more likely to deploy an agent that do support kvm into a cluster of other agents that don't.
For me it would probably be more relevant to implement this as the ssh or nvidia filters : announce another agent type that will allow container images tagged with org.inginious.kvm to be listed as available environment, so that we can ensure appropriate routing and ensure the user selected the right environment.
Implementation of nvidia is here f842bee
However, I realize that implementing a kvm filter, as it may be compatible with other agent type, would require to duplicate all those one to have a kvm-enabled flavour.
Maybe it would be useful to rethink the way this is done and add some kind of feature flags in addition to the agent type, so that we can handle docker or nvidia with ssh or kvm as supported features or not.
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.
After discussion with @anthonygego, this will be implemented as existing filters (ssh, nvidia, ..).
The features flags common to all the Agents will be grouped in a new data-class.
Front-end side, the grading environment should not include the feature flags in the dropdown and those will be added as check boxes.
| # Check the runtimes | ||
| runtime = sys.argv[1] | ||
| parent_runtime = sys.argv[2] | ||
| kvm_enabled = sys.argv[3] == "True" |
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'd document the args at both sides, here and at the call side in _docker_interface.py (to avoid implementing a useless argumentparser that would be self documenting)
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 arguments managment will be replaced by an argparser.
e53b0e2 to
9a6d192
Compare
|
v1.32 of virtme now supports SSH. We should bump the version and replace the telnet hack with this new feature. |
|
Can you rebase your branch against |
This PR adds a new base container able to launch a specific Linux kernel within a KVM.
New grading environments should inherit from this container as it is the case for the base container.
Task leveraging such grading environments must support the SSH feature of INGInious.
TODO
TODO in further PRs
https://github.com/UCL-INGI/INGInious/blob/a9962cad2a18caf87a73f10c627fc98f561f0e6c/base-containers/base/inginious_container_api/utils.py#L79
Such logs could be used in further grading scripts.