-
Notifications
You must be signed in to change notification settings - Fork 102
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 support for AIX System Resource Controller services promises #2959
Conversation
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 looks OK to me. I commented a bit and have some non-blocking suggestions.
lib/services.cf
Outdated
{ | ||
vars: | ||
# current state can be: active, inoperative, stopping | ||
"current_state" string => execresult("/usr/bin/lssrc -s $(service) | tail -1 | awk '{print $NF}'", useshell); |
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 have some small amount of worry about cached result here, it might benefit from action => immediate but I think it should be ok without it since $(service) comes from the parameter and that won't be set until real 3 pass actuation and not during pre-eval.
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.
Ok. :) Yeah, ideally folks shouldn't have to worry about it right?
What would be the problem about "cached result"?
I know that the commands in execresult are run a few times and cached in pre-eval and then in the real passes right?
Seems OK to me regardless as things will "work out"/stabilize eventually.
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 problem with the cached result is that the state from pre-eval could be used instead of the state from when this is actuated.
Again, I don't think it applies here because $(service) would not be defined during pre-eval since it's only available as a parameter which will only happen during the normal 3 pass evaluation.
However, if this bundle happens to be called for the same service multiple times within the policy, then the cache is likely to apply which could cause some issue if you for example do:
start (but say it was already running), stop, start
In that second start the cached value from the first start would be used and with the knowledge it was running it may not try to start again.
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.
Yeah. I suppose it would be good to include a warning of some sort if you try to change the state of a service that has already been managed in the current agent run... kind of like a global class that signified e.g. "sshd_service_managed" and if you re-entered the aix_services() bundle and that class was set then log a warning that you shouldn't try to enforce more than one state on a service in a policy run.
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 made a ticket: https://northerntech.atlassian.net/browse/CFE-4448
15d2f28
to
440978c
Compare
On AIX the default will use AIX System Resource Controller commands to manage service state. bundle agent main { services: "sendmail" service_policy => "start"; } service_policy options supported are: start, stop and reload. Ticket: CFE-4447 Changelog: title
440978c
to
6f559dd
Compare
@nickanderson do you want me to back-port this? |
Yeah I'd bring it to 3.24.x |
#2960 (3.24) |
On AIX the default will use AIX System Resource Controller commands to manage service state.
service_policy options supported are: start, stop and reload.
Ticket: CFE-4447
Changelog: title