If a user manually deletes (I know is a bad practice and totally undesirable) the WORKDIR (containing the revert script), this converts the deployment in undeployable from the portal.
Problably we cannot expect to have this situation from end-users, but only to highlight that this incorrect usage can generate issues.
I think this (weird) situation can be managed from the orchestrator too. I mean, If the WORKDIR or the revert script does not exist, return an error message telling the deployment was not successful, but remove the deployment from cloudify.
What to you think?
This is a preliminary description of the issue/solution. To think
If a user manually deletes (I know is a bad practice and totally undesirable) the WORKDIR (containing the revert script), this converts the deployment in undeployable from the portal.
Problably we cannot expect to have this situation from end-users, but only to highlight that this incorrect usage can generate issues.
I think this (weird) situation can be managed from the orchestrator too. I mean, If the WORKDIR or the revert script does not exist, return an error message telling the deployment was not successful, but remove the deployment from cloudify.
What to you think?
This is a preliminary description of the issue/solution. To think