style tweak for consistency
explain how data structures order in series then in parallel

ServiceObject#apply_role is a grossly overgrown and complicated
method, and also just happens to be probably the most critical
part of Crowbar's core engine.  So anything we can do to make
it more legible is a worthwhile investment.
ServiceObject#apply_role: rename nodes to pending_node_actions

ServiceObject#apply_role is a grossly overgrown and complicated method,
and also just happens to be probably the most critical part of Crowbar's
core engine.  So anything we can do to make it more legible is a
worthwhile investment.  Renaming and explaining cryptic variables helps,
as does moving variables closer to where they are used.

This is a refactoring only, and should not affect behaviour in any way.
rename cryptic "snodes" to "non_admin_nodes"

ServiceObject#apply_role is a grossly overgrown and complicated
method, and also just happens to be probably the most critical
part of Crowbar's core engine.  So anything we can do to make
it more legible is a worthwhile investment.

This is a refactoring only, and should not affect behaviour in any way.
rename cryptic "r_nodes" variable to "nodes_in_batch"

ServiceObject#apply_role is a grossly overgrown and complicated
method, and also just happens to be probably the most critical
part of Crowbar's core engine.  So anything we can do to make
it more legible is a worthwhile investment.

This is a refactoring only, and should not affect behaviour in any way.
rename cryptic "n" variable to "node_name"

ServiceObject#apply_role is a grossly overgrown and complicated
method, and also just happens to be probably the most critical
part of Crowbar's core engine.  So anything we can do to make
it more legible is a worthwhile investment.

This is a refactoring only, and should not affect behaviour in any way.
don't add deleted nodes to the run order (bnc#840255)

If a node is deleted but still associated with a proposal,
and then it is removed from that proposal and the proposal
applied, we need to avoid attempting to adjust the run list
for that node or attempting to run chef-client on that node.
Previously this would result in a

  undefined method `[]’ for nil:NilClass

crash, leaving all nodes stuck in the applying state, and
the proposal stuck in the committing state.

  https://bugzilla.novell.com/show_bug.cgi?id=840255

See also

  https://bugzilla.novell.com/show_bug.cgi?id=839714