• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (5)

1 nukite8d commented Permalink

Hi,
that looks great.
But ...

 
We are working mainly with Nominal-Online and Stop-Requests. So to start a ResourceGroup, the operator has to cancel the request.
 
With the new implementation, I see a high risk of unwanted Start-Requests by "unexperienced" operators. When those want to start a ResourceGroup, they might just request a Start, which stays in the system and may interfere future votes.
 
Would it be possible to have only two choices (Request, Cancel) at the object level, and have a choice between online and offline in the Request-dialog? The Default Request could be dependend on the state as implemented in ISC/OC.
 
This would help the usebility.
Anyway, it's great to get this function!! Thanks a lot.

2 WolfgangSchäberle commented Permalink

Hi,
thanks for your comment! This is valuable feedback.
We basically have the same concern that "inexperienced" operators might rather override an existing request instead of canceling it in certain cases.
This would lead to unwanted requests in the system.
This is why we have guided the operator in the past in the way that only a Cancel is possible if a request exists.

 
I think we can solve these somehow conflicting requirements using the following approach:
- As long as no requests exist, you can choose either request online or offline independent of the resource's state
- As long as a request exists, you can only issue a request in the same direction, for example to increase the priority, but you cannot issue a request in the opposite direction.
 
Some examples:
 
Scenario A:
A resource with default desired state Online has been requested Offline. Now an operator wants to start the resource again. With the new approach he would have to cancel the existing Offline Request (we would not offer Request Online).
So, this would prevent the unwanted Online Requests that inexperienced operators might add if they were allowed.
==> your requirement with more guidance for operators fulfilled
 
Scenario B:
A resource is offline and no request exists. An operator can place any request in this situation. For example, he could add an Offline Request with priority Force in order to ensure that this resources stays offline.
==> requirement to place requests independent of resource state fulfilled
 
I think this approach would address all scenarios. The only drawback of that solution is that in the case of scenario A) there might be rare situations where the Cancel does not start the resource because of other votes keeping the resource offline. In this situation the operator would have to first Cancel the existing offline request and then afterwards issue a new Online Request to override the votes on that resource. So the drawback is that he has to perform two steps (1. cancel, 2. request online) instead of just overriding the existing offline request with a new online request in one step.
But I think this is not a problem.
 
What do you think?

3 thomas.quadflieg commented Permalink

Hi,
that looks great. I think it won't be a problem to perform 2 steps Cancel + Start/Stop in some specific scenarios, especially with regards to the benefits regarding minimizing number of requests.

 
Do you have some additional information regarding this feature:
 
What is the default priority value? Will it be possible to change this default value in config?
 
The 2nd screenshot shows a "Reset" button in the context menu. I assume, its the "resetrsrc" Command-Implementation. Did you think of integration other Options here, e.g. for startrsrc and stoprsrc?
 
Thanks,
Thomas

4 WolfgangSchäberle commented Permalink

Hi Thomas,

 
thanks for your feedback!
 
Regarding your questions:
 
1. The default priority value is "High".
We currently do not plan to make this configurable. Is this important for you?
If yes, there are a couple of things to consider: For the e2e automation domain, a priority value of at least 'High' is required to override the current desired state because the default votes created by the SA AM automation engine are prio 'High' as well. 'Low' does not make much sense for resources on the e2e automation domain.
For resources in a first-level automation domain, however, it could make sense to use 'Low' as an operator, because the 'Low' request with source operator would still override a 'Low' vote from the automation. So, if the default priority value was configurable, it might make sense to only configure a default priority for FLA domains (you could even think about having different defaults for different domains). In my opinion there are other items that are more important which we should address first.
 
2. The "Reset" task in the menu is the same "Reset" function that has been available in the existing SA Operations Console. For SA MP this maps to 'resetrsrc'. There is one key difference, however, in the implementation that we plan to do for the new GUI: We plan to have the 'Reset' task available independent of the current state of the resource. In the past releases, the 'Reset' button was only available for resources which are in a Fatal compound state (FailedOffline).
This allows to issue a 'Reset' in certain other situations where a resource is somehow stuck but not in FailedOffline.
 
3. We currently do not plan to have other resource tasks available than the following: Request Online, Request Offline, Restart, Suspend/Resume automation, Move.
I think with the ability to submit Request Online/Offline and Reset in more situations than before, it should be possible to cover all important use cases. Are there any operational use cases for which you would need startrsrc / stoprsrc that you cannot cover with the other tasks (in particular with the new possibility to issue resetrsrc any time)?
 
Kind regards,
Wolfgang

5 thomas.quadflieg commented Permalink

Hi,

 
regarding your questions:
 
1.)
changeable default priority: "Is this important for you?"
--> We had the same consideration regarding E2E. But, with default value 'high' everything is fine.
 
2.)
Great!
 
3.)
Are there any operational use cases for which you would need startrsrc / stoprsrc that you cannot cover with the other tasks?
--> Yes, there are 2 use cases, where we sometimes use start/stoprsrc. In most cases because of
a) error / problem situations --> in this case, we work directly on the FLA, so it's not necessary to handle this via OpCon.
b) as a workaround for scenarios where we want to ignore relationsships. Example:
Relationship A stopAfter B.
Request: A should be restarted without touching B.
With Request that's not possible, because A does not stop or B is automatically stopped. In this case we lock the resource and stop/start the resource with stoprsrc/startrsrc.
 
So, regarding your questions: Yes, there is a Use Case as Workaround for "Override Dependency". BUT: we don't need stoprsrc/startrsrc if a "Override Dependency" function is available (in OpCon and for eezcs).
 
Cheers,
Thomas

Add a Comment Add a Comment