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

Minor stonith fixes and refactoring #742

Merged
merged 10 commits into from Jul 1, 2015
Merged

Conversation

kgaillot
Copy link
Contributor

While this includes a couple of minor fixes and some additional developer documentation, the main goal is to lay the groundwork for being able to remap reboot to off+on.

@kgaillot
Copy link
Contributor Author

The fencing regression tests and a 100-random-test run of CTS with broadcast, levels-or and levels-and fencing ran fine with this.

@beekhof
Copy link
Member

beekhof commented Jun 25, 2015

Merge now?

stonith_create_op() already adds the call options attribute to the operation
XML, and then initiate_remote_stonith_op() was explicitly adding the
attribute again. Now it passes the correct value to stonith_create_op()
so it is added once.
…to fence

This has no effect now but will be needed when reboot is remapped
to off+on, and eligibility will need to be checked separately for
off and on.
…es to XML

This has no effect now but will be needed when reboot is remapped
to off+on, and properties will need to be added separately for
off and on.
…ies from XML

This has no effect now but will be needed when reboot is remapped
to off+on, and properties will need to be parsed separately for
off and on.
This has no effect now but will be helpful when reboot is remapped
to off+on, and device lists will need to take into account whether
the device can execute off, on or both.
This renames the "devices" member to "ndevices" in st_query_result_t.
It's a little easier to read since "devices" is often used in other contexts as
a list or such, but the main reason is because it allows the current
"device_list" member be renamed to "devices" if its implementation changes
as planned for remapping reboot to off+on.
If a fence agent does not advertise support for reboots, the executing
stonithd will remap the reboot to off at execution time. Previously,
that meant the action-specific timeout for reboot had already been
applied. Now, the remapping is checked when determining the timeout,
as well as when executing.
@kgaillot
Copy link
Contributor Author

When you asked, no -- now, yes :)

@davidvossel
Copy link
Contributor

@kgaillot these changes all look good to me. great work!

davidvossel added a commit that referenced this pull request Jul 1, 2015
Minor stonith fixes and refactoring
@davidvossel davidvossel merged commit c4d6be4 into ClusterLabs:master Jul 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants