> 1) Roll back support : I came across few blueprints that talk about the 
> roll-back support but not sure if they are delivered yet, I wanted to check 
> if something is there out of the box that I should be aware of. Ofcourse, 
> roll-back being very specific, I'd expect a user defined action being called 
> for rolling back, just wondering if there is any construct after (on-error : 
> ) to be used in YAML

Yes, it’s really specific. We ourselves discussed several options on what 
facilities we could provide regarding rollbacks. None of the BPs that you’ve 
probably seen is implemented yet though and more importantly there haven’t been 
any decisions made on that. I think we should start a wider discussion on that.

As far as the idea itself, the whole point is that it may not be required to 
implement any specific in addition to existing functionality because from what 
we learned we can make a conclusion that most often rollback is a different 
workflow. Meaning that rolling back all the tasks in the same but reverse order 
(assuming they have a roll back action) doesn’t make too much sense. It’s 100% 
true if workflow tasks change some state in a non-revertable manner, for 
example. If so then Mistral already has ‘on-error’ clause which could be used 
to jump to a task associated with calling a workflow (rollback workflow).

I really wonder what your input on this would be?

> 2) Execution context predefined ids - Here is what I found that talks about 
> task and execution ids that I can access (execution context 
> <https://wiki.openstack.org/wiki/Mistral/DSLv2#Predefinted_Values_in_execution_data_context>),
>  it would be great if you could point me to the list of all possible 
> variables like $.execution_id that are accessible inside the YAML.

Not too many things at this point:
* $.__execution consisting of fields ‘id’, ‘wf_spec’ (workflow specification as 
a dictionary), ‘input’ and ‘start_params’ (which can contain some additional 
start parameters like ‘task_name’ for reverse workflows and ‘env’ containing 
the environment variables or a name of the previously saved environment, but 
environments are not officially announced yet).
* $.openstack which contains whatever is listed in the doc (project_id etc.)

This part is slightly changing now and there isn’t still a final doc on that. 
It will be created by the end of kilo-3.


Renat Akhmerov
@ Mirantis Inc.

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to