Merge lp:~1chb1n/charm-helpers/amulet-svc-restart-race into lp:charm-helpers
| Status: | Merged |
|---|---|
| Merged at revision: | 444 |
| Proposed branch: | lp:~1chb1n/charm-helpers/amulet-svc-restart-race |
| Merge into: | lp:charm-helpers |
| Diff against target: |
241 lines (+101/-53) 1 file modified
charmhelpers/contrib/amulet/utils.py (+101/-53) |
| To merge this branch: | bzr merge lp:~1chb1n/charm-helpers/amulet-svc-restart-race |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Billy Olsen | 2015-09-01 | Approve on 2015-09-02 | |
| Adam Collard (community) | Abstain on 2015-09-01 | ||
| charmers | 2015-08-25 | Pending | |
|
Review via email:
|
|||
Description of the Change
Add exception handling to the retry logic in service_
Add deprecation warn re: service_restarted amulet helper, in favor of validate_
FYI - The following charm MPs for updated tests are dependent on this C-H change landing first:
https:/
https:/
https:/
| Ryan Beisner (1chb1n) wrote : | # |
See comment on the same bug. Thank you.
| Ryan Beisner (1chb1n) wrote : | # |
Since pgrep -p doesn't work on Precise, and we already have another helper to get a process ID, I've refactored _get_proc_
Note that that renders pgrep_full a no-op, and I've also updated the calling helpers to ensure the user receives a deprecation WARN about that, while still ensuring that the default use of the refactored _get_proc_
| Ryan Beisner (1chb1n) wrote : | # |
FYI, the proposed charm-helpers changes are working well in 2 charms where the race was prevalent, and in 1 charm where the race was seldom seen (keystone):
# openstack-dashboard
https:/
# neutron-api
https:/
# keystone
https:/
| Ryan Beisner (1chb1n) wrote : | # |
As we are needing to move forward with this and the child MPs, and we have addressed the original concerns, and Adam isn't in a position to be able to fully review at this time, I'm adding Wolsen back for a review.
PS. Thanks to Adam for raising that issue, so that we could propose something even more robust.
| Billy Olsen (billy-olsen) wrote : | # |
So I've made a few (mostly) editorial comments in-line. I think at the root of whether this should go ahead and go forward or not is based upon whether there exists any implementation dependent upon the pgrep_full behavior. I'm a big +1 on the switch to the use of pidof rather than pgrep because the pgrep implementation allows charm authors to fall into an obscure bug here if they were not careful enough (though admittedly, it'd be due to some lazy coding which could be fixed via being more explicit).
The intention of the pgrep_full flag appears to be to allow amulet test authors to also search script processes rather than just executable names. The -x parameter for pidof allows the same thing to occur. If we define the pgrep_full flag as 'also match script names' rather than the literal interpretation of pgrep_full, then the flag doesn't need to be deprecated.
Most of my in-line comments are based upon the parameter being deprecated. After thinking hard, I'm not entirely sure its required to be deprecated if there is a successful argument in the intent outweighing what is conveyed by the name of the parameter.
| Ryan Beisner (1chb1n) wrote : | # |
I totally know what you're saying, this is a tricky one for sure. There are other methods there, intended to check the same thing, but they are also broken in some way, and are basically dying on the vine (and without user warnings).
Deprecation reasoning:
The pgrep_full option will be ill-named after switching to pidof behind the scenes.
We could preserve the parameter and just re-plumb it to pidof's -x, but that would be confusing to consume, and no longer self-descriptive, if not actually misleading.
We could add a new option, such as check_scripts_too, and perhaps just aliased pgrep_full for backward compatibility. That would still be confusing in that the pgrep_full option is out of context, and in that we are inviting user error by exposing that control in the first place.
Which brought me to: can we just get to the core of the intention of the method, and make it smart enough to just do-the-
ie. my_thing_
We are already using pidof -x reliably in an existing is_my_service_
And that is the journey of my arrival at: just deprecate it and announce in any case that it is defined.
I did backwards-
I recognize that there is a remote possibility that someone outside our awareness is using that helper function, and this could possibly break them. I think we've minimized that risk, and we've given user feedback appropriately. That's always debatable of course.
So..
What I want to avoid is adding yet-another rewrite of a my_thing_
Ideas?
| Ryan Beisner (1chb1n) wrote : | # |
See replies inline. The more I look over this, and it's ancestors, the more I want to just revert all of this and add a new helper that just works.
Talk me out of doing that?
| Billy Olsen (billy-olsen) wrote : | # |
Okay, let's go deprecation warnings for the parameter, which is where you went anyway. I probably should not have gone in the direction that I went in with the possibility of not deprecating the parameter. The deprecation warnings serve to notify charm authors but also to allow for this to be a drop-in replacement with as little backwards compatibility issues as possible, so it gets my upvote for that.
Please do NOT add a new option for checking scripts and just use the pidof -x. By deprecating the pgrep_full option we're favoring the desirable approach. If someone can make a really strong use case for adding another flag lets consider adding the flag or something at that point.
I haven't gone through all the ancestry for the method yet, but if we add yet another way then it becomes to confusing as to which method to use. So let's just do the right thing and fix the behavior to work as advertised/expected as this MP is doing.
| Ryan Beisner (1chb1n) wrote : | # |
Thanks again for the good questions and replies and advice.
Add'l replies in-line.
| Billy Olsen (billy-olsen) wrote : | # |
Ah, thanks for the updates Ryan - I think we're now fully on the same page. Just a few minor edits then I guess and it gets my +1.
- 438. By Ryan Beisner on 2015-09-02
-
update comments, pgrep_full conditional
| Billy Olsen (billy-olsen) wrote : | # |
Thanks for making the changes. LGTM - I added an additional comment for follow up later but it shouldn't hold this MP up in my mind.
| Ryan Beisner (1chb1n) wrote : | # |
Replied inline. Thanks again!
| Billy Olsen (billy-olsen) wrote : | # |
One more back at ya. Let's get it merged.
| Ryan Beisner (1chb1n) wrote : | # |
Thanks again, are we ready to land this, so we can also land the related charm test updates?
| Billy Olsen (billy-olsen) wrote : | # |
Yes, I think this is ready to be landed.


See https:/ /bugs.launchpad .net/charm- helpers/ +bug/1474030/ comments/ 2 for explanation on why this isn't sufficient