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
Add a sysctl resource #433
Comments
@iamzhout We don't currently have a resource for this, but we are happy to add one or get a patch for it. It's easy to get/set values. The real question is: how can you detect when one of them has changed without simply polling constantly. If you can research this for us, and report back here, we can help you write a resource! |
@purpleidea sorry for late response, it seems to me that it is hard to be noticed of change without periodic polling, the way I can think of is to run |
Apparently So it would be great if someone could do a little digging and post their results here. Make sure to use a relatively modern kernel. |
Did a little digging around as per your suggestion @purpleidea, looks like ionotify works expected. On one window, I set up io notify watcher on the /proc/sys directory. On the other window, I modified the hostname:
which was picked up in the first window:
How would one submit a patch for this; Is there a similar resource present today? |
@SUSHSADA Awesome (btw what's this error: In any case a sysctl resource would be great... Are there upstream docs or an API where we can determine which path to watch for each sysctl key? Maybe we could ask upstream to to add a --printpath type feature to show us that output so we could figure it out directly? Lastly, a resource for this would be great. How's your golang? Docs are in: https://github.com/purpleidea/mgmt/blob/master/docs/resource-guide.md resources go in engine/resources/ |
That error message- Looks like it's trying to resolve the current hostname:
This doesn't seem like it should affect this mgmt resource right? And about mapping from sysctl key to path, looks like a sysctl userspace utility converts |
I wouldn't worry about it for now. I bet it's just sudo being sudo.
Yes of course. We're happy to mentor your patch, and do it at your own pace.
Great! I didn't know it was that straight forward. Feel free to send an early (even non-compiling) rough draft of your Sysctl resource if you'd like early design feedback. For the inotify side, you should use the existing lib in recwatch as used by the file res. LMK how it goes. |
Thanks @purpleidea. I'll send out an early review to get your feedback. |
@SUSHSADA Hey, did you have some early success? |
Here's the sysctl resource I have- first draft, havent proof read it And my script is : cat sysctl1.mcl
sysctl "kernel.hostname" {
value => "sush.com",
} However, 'value' is not being picked up: docker/scripts/exec-development ./mgmt run --tmp-prefix lang --lang sysctl1.mcl
2019-03-11 07:50:12.536873 I | cli: lang: lexing/parsing...
2019-03-11 07:50:12.538339 I | cli: lang: init...
2019-03-11 07:50:12.538381 I | cli: lang: interpolating...
2019-03-11 07:50:12.538498 I | cli: lang: building scope...
2019-03-11 07:50:12.538555 I | cli: lang: running type unification...
2019-03-11 07:50:12.539759 I | run: error: cli parse error: could not unify types: could not determine type for `value` field of `sysctl` Please share your comments on the code. Also, any pointers on the "cli parse error"? Do I need to add a "mapping" between sysctl.go and the cli layer? |
@SUSHSADA Cool... Can you send it as a pull request instead? Don't worry, it doesn't mean we have to merge, but it is more easy to send review comments line by line. Also, the automated tests will tell you about some things that need fixing, so I don't need to bug about those =D As a first simple review, just go through and make sure old copy+pasta comments are removed, and also you'll notice that it's currently based on a slightly older version of the resource API, so if you diff it against something newer, you'll see it has changed slightly. (eg: not Dirty() function, etc) Thanks! |
Here are some docs about this https://www.kernel.org/doc/Documentation/sysctl/README |
Description:
I've read mgmt blog posts and video introduction, and didn't see this use case as in title,
that if I want to keep some kind of os kernel related settings, does it supported currently by mgmt config?
The text was updated successfully, but these errors were encountered: