> 2. The second option is to define the rollbacks for the
> orchestration actions, and if all the steps of the orestration have
> rollbacks defined, the rollback is doable (it's still questionable
> if it's not better to go for 1. by default letting the user to
> choose if it's better to rollback or try to fix the problem (or
> having the admin to decide)
One important thing is to know when to use fire-and-forget approach and
when not. It is best fit for long running processes, for example the
new host creation is time consuming action and it should be (maybe in
future) handled in a separate task. That's ideal fit in this case but it
deserves some UI changes to support this approach.
But it is important to note that there still be actions (let's say
"short-term actions") that are not good fit. And a good orchestration
engine should be able to support that as well.
(Thread might be broken, my wifi got lost during sending - resent).
> > 2. The second option is to define the rollbacks for the
> > orchestration actions, and if all the steps of the orestration have
> > rollbacks defined, the rollback is doable (it's still questionable
> > if it's not better to go for 1. by default letting the user to
> > choose if it's better to rollback or try to fix the problem (or
> > having the admin to decide)
>
> One important thing is to know when to use fire-and-forget approach and
> when not. It is best fit for long running processes, for example the
> new host creation is time consuming action and it should be (maybe in
> future) handled in a separate task. That's ideal fit in this case but it
> deserves some UI changes to support this approach.
>
> But it is important to note that there still be actions (let's say
> "short-term actions") that are not good fit. And a good orchestration
> engine should be able to support that as well.
I totally agree that we don't need to change everything, however, my point
here is that changing to the new way would require more thought and more
code to implement failure / remediation paths etc.
e.g. dns that foreman wants to commit conflict with an existing value)
was far from trivial, and this is just one usage case.
the fact that orchestrations are now within the db transaction saves us
from many many rollbacks in error conditions, if we change that we would
need to do all of that stuff manually as well.
Ohad
···
On Mon, Aug 19, 2013 at 10:00 PM, Lukas Zapletal wrote:
from my own experience, the overwrite functionality (e.g. when some record
(Thread might be broken, my wifi got lost during sending - resent).
