-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFE] Allow max_retries override at instance level #163
Comments
@mkanoor @tinaafitz What do you think about this ? The idea comes from my implementation on V2V state machines, where the state machine class is just a scaffold. So, I had to set a max_retries for all states as I don't know in advance what it will be used for. Regarding the impact of such change, I expect it to be minimal as the existing classes and instances wouldn't have to be modified. This adds a new opportunity on top of the existing logic. |
@fdupont-redhat @tinaafitz @gmcculloug |
Awesome, I didn't expect less from you 👍 |
Yes, lets open an issue in the UI repo, the MiqAeValue table allows for setting of the max_retries. If they can make these fields show up only for state machines it would be good. e.g. on_entry/on_exit/on_error/max_retries/max_time should only be visible if the field is a state. For relationships and attributes it doesn't make sense. The Automate Engine might work I am not sure but once the MiqAeValue has the max_retries/max_time we can fix the engine if it doesn't take care of it already. |
@mkanoor RFE opened: ManageIQ/manageiq-ui-classic/issues/3560. |
I added an assignee to the ui-classic issue. |
I manually changed a state machine instance max_retries value and verified the instance value is used in resolution. |
@fdupont-redhat With PR ManageIQ/manageiq-ui-classic#3562 merged can this issue and ManageIQ/manageiq-ui-classic#3560 be closed now? |
@gmcculloug Yes, we can. |
When one creates a state machine, the maximum number of retries for a state is set at the class level. However, a use case of state machines is to create generic state machines where the state name is 'StateX' and URI is specified only at the instance level, not the class. In this case, to stay generic, one is tempted to set the maximum number of retries to a very high number for each state, to cover whatever situation at the instance level.
Allowing to override the maximum number of retries at the instance level would help creating generic state machine classes (scaffolds) with no maximum retries set, and then let the instance specify the maximum retries based on the actual URI.
The text was updated successfully, but these errors were encountered: