Emit stopping/starting events when "salt-cloud -a stop/start" is used.

[vitaliyf]

What does this PR do?

salt-cloud emits numerous events when instances are created, configured and destroyed, but not when they are stopped or started.

New events were added using code from "destroy" method, so they follow the same naming pattern and have same attributes.

What issues does this PR fix or reference?

Previous Behavior

No events are fired when stop/start is used.

New Behavior

New events will be seen on the event bus, for example:

salt/cloud/my-server.example.com/stopping {
    "_stamp": "2017-11-01T21:16:39.772554",
    "event": "stopping instance",
    "instance_id": "i-17517664499b5503a",
    "name": "my-server.example.com"
}

Tests written?

No

Commits signed with GPG?

Yes

[vitaliyf]

PR against develop as requested in #44375

[cachedout]

Is this a new event? If so, does it need to be added to other providers other than just EC2?

[rallytime]

This will be useful to have! But, yes, these are both new events and should be added to the other cloud providers. As well as documented here.

Would you be able to make those additions @vitaliyf?

[vitaliyf]

Good question - only about half of drivers have stop/start methods in them and I am actually planning to add support to one more (softlayer and maybe softlayer_hw). But yes, it would make sense to add these to those that already support stop/start and of course document them.

I can do that - though I can't test majority of them.

Before I go copy/pasting the same thing into 20 files - any idea why there isn't a helper function to emit all cloud events, since they are all structured very similarly?

[rallytime]

Thanks @vitaliyf! All salt events are fired like this, whether they are cloud, master, or minion events. Obviously, there is some cloud-specific tags in there, but the general structure & idea is the same. Copying and pasting that information into each of the start & stop functions is the way to go in this case.

I would add the new start and stop functions for the softlayer/softlayer_hw drivers in a new PR. That way it can be reviewed separately from adding these new cloud events.

I think in addition to documenting these events as I mentioned above, it would also be prudent to make a note of these new events in the cloud section of the Oxygen release notes.

[rallytime]

Hi @vitaliyf - Just checking in here. Did you have a chance to come around to this PR?

[rallytime]

Hi @vitaliyf - Just a bump on this to see if you had a chance to come back around.

[vitaliyf]

Yes, I'll try to get some time this week and add events to all stop/start functions that exist.

[rallytime]

Hey @vitaliyf - Just checking in here. Were you ever able to come back to this?

[rallytime]

After further consideration, we don't need to wait on adding this to all cloud drivers. Let's get this in and future events can be added later. Thanks for this @vitaliyf!