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

Added stub / spec for executor interface #36

Merged
merged 14 commits into from
Sep 16, 2015
Merged

Added stub / spec for executor interface #36

merged 14 commits into from
Sep 16, 2015

Conversation

cbednarski
Copy link
Contributor

This is very basic but I think will give us a way to write a ulimit executor, cgroup executor, lxc executor, etc. This allows the drivers to be more OS agnostic and also lets us handle fiddly switching logic based on capabilities in the exec package instead of mixing it into the driver code where it gets mixed in with other logic.

Ideally exec stays low level and close to the OS, while the driver can assume that "run this thing with these constraints" just works using best-available techniques on the target platform.

/cc @catsby

Fixes #20

@armon
Copy link
Member

armon commented Sep 14, 2015

@cbednarski Seems like a solid spec to use as a starting point

@catsby
Copy link
Contributor

catsby commented Sep 14, 2015

Could we support the idea of wrapping these?
Alternative question, could the Drivers retain knowledge of how to exec things, and we have things like ulimit context, cgroup context, so we compose a context in which the Driver executes?

I may be overcomplicating things

EDIT: I'm not actually sure this would even work, but wanted to throw it out there

// ones should be at the top and fallbacks at the bottom.
// TODO refactor this to be more lightweight.
executors := []Executor{
&LinuxExecutor{},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this will compile on non-Linux, since this type is defined in a _linux.go file. Maybe instead the executors should register in somehow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I will look into this. Registration makes things a bit more complicated because the write is racy and/or I have to reflect to copy the type from the registry (if you have a good example please link me!).

Here each goroutine gets its own (new) resource. The solution I have now is not elegant but it's simple and thread safe so if there is a compiler issue I will try to fix that for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking more like having a type ExecutorFactory func() Executor, then each executor could just use like it's init() method to add its own factory in. Or something like that. Whatever is easiest, I suppose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see. That makes sense. Thanks!

@cbednarski
Copy link
Contributor Author

I've tested this via the exec and java drivers and everything looks good. I'd like to add some more local tests but this is technically tested already. Also exec now works as non-root so this should not break running tests during development.

@catsby I'm going to merge this as-is but feel free to tweak if you need to for the cgroup stuff.

cbednarski added a commit that referenced this pull request Sep 16, 2015
Added executor interface, includes drop privileges for linux
@cbednarski cbednarski merged commit 2c4d21b into master Sep 16, 2015
@armon armon deleted the f-executor branch September 20, 2015 22:45
benbuzbee pushed a commit to benbuzbee/nomad that referenced this pull request Jul 21, 2022
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Drop privileges on exec'd processes
5 participants