Implement the pre and post runs for volume operations (create, delete, start, stop) about gluster-integration HOT 3 CLOSED

Need more details here

• Are there common actions to be taken before and after any volume op?
• Are there specific actions to be taken for any volume op?
• Do the outcome of these pre/post actions change the atomicity of the volume op atom
• Do these pre/post actions cause changes to other cluster objects?
• Do these pre/post actions trigger any Notifications/Alerts/Flows/Atoms?

from gluster-integration.

Are there common actions to be taken before and after any volume op?

At the moment I dont any common action which are required before and after volume operation. Actions on existing volume like start rebalance etc need to have pre-check to make sure volume exists already. And post check to figure out if the said action was actually a success by checking the rebalance status for the volume. Check to find pre-existance of volume is common code which could be invoked from different flows.

Are there specific actions to be taken for any volume op?

This could be the case in some cases and should be ideally implemented as an atom and linked in the flow.

Do the outcome of these pre/post actions change the atomicity of the volume op atom

So currently the logic is such a way that if some pre-run fails, we dont continue to the actual atoms execution. Yes say during main atoms execution if it fails at certain stage, it might affect the atomicity of the volume. But detailed logging from the individual atoms and updation of the task with proper details might help end user to debug and revert the consequences. I dont think enough thought is given at the moment for ordering the atom's executions in a flow. The final solution to this is fore sure TaskFlow framework only I feel.

Do these pre/post actions cause changes to other cluster objects?

Few of the flows like rebalance, snapshots etc might affect other cluster objects as well. Mostly its like e.g. if rebalance started the cluster should not allow other actions. Even brick operation like delete etc should be disabled. This scenario in oVirt is handled with different levels of locking. Say for certain volume operation we hold lock at cluster level and no actions can be performed on any objects of the cluster. The hierarchy is cluster -> volume -> brick

Do these pre/post actions trigger any Notifications/Alerts/Flows/Atoms?

Again it depends on the specific flows and might be the case.

@r0h4n this PR is specific to create and delete volume flows only which are existing at the moment. May be I should change the description of the issue here :)

from gluster-integration.

Taken care as part of #154. Closing now.

from gluster-integration.