Make slots work with parallel=true

[max-arnold]

Previous Behavior

Slots were completely ignored when states used parallel: true

New Behavior

Slots are expanded as expected

Tests written?

Yes

Commits signed with GPG?

No

@DmitryKuzmenko I'm not sure if you had any reasons not to expand slots in parallel mode. Any downsides? Please review the PR if you have some time.

[max-arnold]

re-run full amazon1-py2
re-run full amazon2-py2
re-run full centos6-py2

[DmitryKuzmenko]

Good catch @max-arnold ! Thank you for PR

[dhiltonp]

The other execution of format_slots is like this:

                    # Execute the state function
                    if not low.get('__prereq__') and low.get('parallel'):
                        # run the state call in parallel, but only if not in a prereq
                        ret = self.call_parallel(cdata, low)
                    else:
                        self.format_slots(cdata)
                        ret = self.states[cdata['full']](*cdata['args'],
                                                         **cdata['kwargs'])

format_slots loads the cdata structure, would this still work if your code altered the main invocation like this:

                    # Execute the state function
                    self.format_slots(cdata)
                    if not low.get('__prereq__') and low.get('parallel'):
                        # run the state call in parallel, but only if not in a prereq
                        ret = self.call_parallel(cdata, low)
                    else:
                        ret = self.states[cdata['full']](*cdata['args'],
                                                         **cdata['kwargs'])

If it does work, I believe that would be better.

What do you think?

[max-arnold]

@dhiltonp This approach is less preferred, because the slots expansion won't be paralellized.

[dhiltonp]

Parallelizing the expansion seems bad. We can either expand it once, or expand it tons of times, duplicating work.

What am I missing?

[max-arnold]

Could you please elaborate on how we are duplicating the work? Slots are basically execution module calls, and those calls could be expensive. I may be missing something, but I believe that if we offload a state execution to a separate process, it makes total sense to expand slots (that belong to the state) in the same separate process. Otherwise the state would not be paralellized as a whole.

[DmitryKuzmenko]

@dhiltonp one more argument to keep this as is: slots expansion must be the last step prior to the state execution. So placing it far from the execution makes a risk. If we'll have a performance penalties lets work on it in the future. Currently it's more correct to keep the slots call right before the state call.

[max-arnold]

@DmitryKuzmenko Rebased & blackened, all tests are passing!