Nicely formatted convergence messages for logging and Cloud Feeds

[manishtomar]

Forked from #884. This ticket is to decide the kind of messages that will be logged by convergence. Unfortunately, the discussion has been in different places. My suggestion copied from https://github.com/rackerlabs/otter/issues/838#issuecomment-69071481:

• [x] At the end of convergence cycle when it is going to execute the plan. The idea is to describe the actions in short readable format, i.e. combine multiple steps into one single message.
  • Launching x servers
  • Deleting x servers
  • Adding x servers to CLB id
  • Removing x servers from CLB id
  • Going to drain node id with ip ip
• [x] When group's status is changed:
  • Group's status is changed to ERROR due to error
  • Group's status is changed to ACTIVE
• [ ] When executing policy
  • [x] Executing scheduled policy - scheduleTime attribute will contain the timestamp of when the policy execution (that should ideally be as close to event time as possible)
  • [ ] Executing policy from REST call
  • [ ] Executing policy from webhook call
• [ ] When configuration changes
  • Launch configuration changed
  • Group configuration changed (could be min/max/cooldown)
  • Policy CRUD
  • webhook CRUD

[manishtomar]

Original ask from @cyli:

Should logs be synthesized by the steps provided?

Also, what happens if we want to log a step not taken? For instance, not adding a server to a CLB because that server does not have a ServiceNet address? Possibly we want to produce reporting objects/steps/structures so that they can also be optimized later. For instance, instead of the following messages:

Server 1 not added to CLB 1 because Server 1 does not have ServiceNet configured.
Server 2 not added to CLB 1 because Server 2 does not have ServiceNet configured.
Server 3 not added to CLB 1 because Server 3 does not have ServiceNet configured.
Server 1 not added to CLB 2 because Server 1 does not have ServiceNet configured.
Server 2 not added to CLB 2 because Server 2 does not have ServiceNet configured.
Server 3 not added to CLB 2 because Server 3 does not have ServiceNet configured.

Maybe we just want:

Servers 1, 2, and 3, cannot be added to CLBs 1 and 2 because Servers 1, 2, and 3, do not have ServiceNet configured.

Alternately, just 3 separate messages, 1 for each server. Alternately, 2 separate messages, 1 for each CLB. But that can be up to the optimizer.

[manishtomar]

@radix suggestion: I think whatever we do, we should probably log based on a bag of steps, instead of sprinkling log statements throughout our convergence functions. And I guess it should be done post-optimization. What would be really nice is if we also logged the inputs to convergence, so if we need to debug something, we can reproduce those inputs and call the functions to get the same outputs.