-
Notifications
You must be signed in to change notification settings - Fork 346
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
Adds spec cli command #55
Conversation
@ferrell-code |
I wanted to get Spec to fully serialize and de-serialize, unfortunately I'm not sure how to manually impl it for the case of LinuxCapabilityType https://github.com/containers/youki/blob/adb43102e022d05c4730fa95e431b30050dec7d8/oci_spec/src/lib.rs#L94-L105 |
other than that let me know what you think :) @utam0k |
@ferrell-code Also, you can reference the railcar's code. |
I changed LinuxCapabilityType to enum. Thanks for the railcar reference, I think that it is the most sensible solution, unless there is a reason it was a struct I'm unaware of |
oci_spec/src/caps_migrations.rs
Outdated
LinuxCapabilityType::CAP_MAC_ADMIN => Capability::CAP_MAC_ADMIN, | ||
LinuxCapabilityType::CAP_WAKE_ALARM => Capability::CAP_WAKE_ALARM, | ||
LinuxCapabilityType::CAP_BLOCK_SUSPEND => Capability::CAP_BLOCK_SUSPEND, | ||
_ => panic!("not a Linux Capability Type"), |
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.
You can use unreachable! here instead of panic! to communicate the intent a bit better. I am wondering though, is this even necessary? If you exhaustively check for all variants of the enum, a wildcard pattern should not be needed.
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.
Altered it to be fully explicit 👍 . the caps Capability has the field __Nonexaustive
though
oci_spec/src/caps_migrations.rs
Outdated
Capability::CAP_MAC_ADMIN => LinuxCapabilityType::CAP_MAC_ADMIN, | ||
Capability::CAP_WAKE_ALARM => LinuxCapabilityType::CAP_WAKE_ALARM, | ||
Capability::CAP_BLOCK_SUSPEND => LinuxCapabilityType::CAP_BLOCK_SUSPEND, | ||
_ => panic!("not a Linux Capability type"), |
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.
See above
oci_spec/src/caps_migrations.rs
Outdated
use crate::LinuxCapabilityType; | ||
|
||
// utility function to switch between the types LinuxCapabilityType and Capabality | ||
pub fn to_caps(local_cap: &LinuxCapabilityType) -> Capability { |
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.
It is better to use the Into
trait.
https://doc.rust-lang.org/std/convert/trait.Into.html
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 agree but we would need to be able to impl the From
trait for caps::Capability
which cannot be done with an external crate.
See idea below to fix this :)
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 must of been sleepy when I looked at it last night you can totally impl From
for an external crate! I was thinking of the orphan rule but it does not apply here.
updated 👍
I think it would be better to fork the caps dependency and host it in its own crate in youki to avoid the migrations back and forth and modify it as we see fit. Perhaps that should be done in a different PR |
@ferrell-code
|
I'd be happy to add the caps crate if you think it is necessary, but looking at it again that might be overkill. Let me know what you think of the current PR when you get the chance :) |
@ferrell-code I'm going to do a careful review again when the Draft is off, but for now, I think it's good overall. However, it would be nice to comment on why Default is needed (perhaps to be used in the spec command). |
I think its a great project for us to learn more about containers and linux internals! Take as much time as you need, I know its not easy to have time for opensource work. We appreciate your effort! My thought process behind Default was to have a basic boilerplate for I will split the lib.rs file too but probably after this PR would be easier 🍶 |
@ferrell-code
I think your idea is a good one.
👍
|
Ok I added a lot of documentation to it, let me know what you think |
oci_spec/src/lib.rs
Outdated
// Device types | ||
#[derive(Serialize, Deserialize, Debug, Clone, Copy, PartialEq)] | ||
#[serde(rename_all = "lowercase")] | ||
pub enum LinuxDeviceType { | ||
// block (buffered) | ||
B, | ||
// character (unbuffered) | ||
C, | ||
// character (unbufferd) | ||
U, | ||
// FIFO | ||
P, | ||
// ?? | ||
A, | ||
} |
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.
Do you know what A is for? maybe any?
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.
Sorry It's my mistake. Could you like to remove it?
https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md#devices
@utam0k @ferrell-code This looks fine to me. What is us preventing from merging this? (apart from the minor merge conflicts that have accumulated in the mean time) |
@ferrell-code Do you have any implementation left? Other than conflicts, I think this is fine. |
Ah yes sorry for leaving this hanging. It is all good to go, I resolved the conflicts and split lib.rs into multiple files. Unfortunately right now it breaks something related to LinuxCapabilities. Edit: Just needed to add some serde defaults, should of been there anyways :). It is good on my end, although I only did basic stuff to test it locally |
@ferrell-code Can you squash some of the commits? I am talking about the commits from June 10 to June 14 which are basically all "Comments & Formatting" and from June 23 to today which are mostly "Resolve conflicts & compile" |
Could you remove the |
ada394d
to
9d4ed4e
Compare
35cac7e
to
e4b0d33
Compare
I squashed it all to one commit, because rebase would make me resolve all the conflicts (as you can see my 5 force push attempts). I think this is the most reasonable solution. In any future prs I will keep in mind to squash commits before pushing 👍 |
Looks very good to me. If @utam0k also agrees we can do the merge. |
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.
Perfect!
@Furisto thanks for your review |
thought it would be useful to be able to generate the config.json natively like runc :)
Also might be useful for unit tests