Comment 1 for bug 1832418

Discussed the proposed solution to use upstart's service 'override' with Felipe.
Unfortunately, this would not allow granular control of which OSDs get enabled/disabled.

Stepping back and looking at the code flow in this scenario: The only reason the
charm needs granular control to disable an OSD is because file ownership changes
may take a significantly long time to complete within the osd directory.

Some thoughts here:
* Why does the OSD need to be stopped while ownership updates are completed?
* Why aren't the OSDs disabled prior to updating code?

It seems like the flow should be:
1. Disable all OSDs
2. Update Version
3. Fix Ownership
4. Enable all OSDs
5. Restart all OSDs

The disable should be on the leading edge in case the update or ownership
changes get interrupted or fail. If we can't guarantee the OSDs are sourcing a
stable update with proper permissions, they shouldn't be allowed to start.