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

feat: spec a config file #8

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

ktfth
Copy link
Contributor

@ktfth ktfth commented Feb 12, 2022

Now supporting a spec file with optional rootless mode

Now supporting a spec file with optional rootless mode
@ktfth
Copy link
Contributor Author

ktfth commented Feb 12, 2022

That change are based on youki spec when the unique example of oci spec exists for spec, can you help me organize the code with your vision?

@penumbra23
Copy link
Owner

No problem @ktfth !

When I started this project, besides learning how stuff works in the Linux kernel (namespaces, cgroups) I also had in mind to keep pura as lightweight as possible.

For the start I would rather go with the built-in, minimal OCI spec models, than including oci-spec. It's a 45+ kB overhead with additional models that aren't actually used. It isn't a problem to switch to that later on, once the project grows, but I would leave that for a major refactoring so that the whole project moves to oci-spec (or if you have enough time you can migrate it, simply remove the whole /oci/spec.rs module and migrate the models). For anyhow I would skip it definitely, 40+kB for a Result wrapper seems too much at this point.

Regarding new commands (exec, spec, pause, etc.) just create a new model under /spec/ops.rs. Regarding linting and code style, cargo clippy and rust-analyzer in VS Code is used.

All "inside-container" related stuff goes under /core/container.rs , the rest can go inside main.rs for now, until it gets crowded or unreadable.

One more thing, keep the code as light as possible, skip unnecessary mount flags if not needed for the bare minimum runtime, reuse functions from already imported libraries prior to installing/including new ones (for example, serde_json::to_string is used mostly on any occurrence instead of pretty_write, file.write_all instead other std::fs write functions, etc.). ALso, Rust comments are more than welcome and one-liner comments above some important or hard-to-grasp concepts are also a big big plus.

Again, many thanks for your effort! I've started to implement cgroupsV2 and exec, but didn't find enough time to implement and test it. Also, we can use the Project tab to "plan" or enumerate features that could be added later on.

@ktfth
Copy link
Contributor Author

ktfth commented Feb 12, 2022

I'm gonna make all the changes to be more close of your vision, and a plan for the Project is a good way to improve all project needs to be a project for study and as close to real success cases in the community.

Thank you for your instructions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants