Contributor.. komai00 Contributor..
Contributor..
227 views

Executing the SSH Shell v2.0 operation fixes the workers that will execute subsequent processing.

When SSH Shell operation (v2.0) is executed, the processing worker group of the subsequent step does not return to the worker group name "RAS_OPERATOR_PATH" even after "SSH Shell Logoff" steping, and always becomes "Worker_ <WORKER ID>".
The target operation is as follows.
----------------
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v2.0/SSH Shell Login
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v2.0/SSH Shell
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v2.0/SSH Shell Logoff
----------------
Therefore, even when OO is configured as an OO cluster, Even if the worker goes down in subsequent processing, processing will not switch to the active worker.

 

image1.png

 

When you execute SSH Shell operation (v1.0), the worker group of the subsequent step becomes the worker group name "RAS_OPERATOR_PATH".

image2.png

 

Is this a specification?
I want the same specification as SSH Shell v1.0.

Labels (1)
0 Likes
3 Replies
AndreiTruta Outstanding Contributor.
Outstanding Contributor.

Re: Executing the SSH Shell v2.0 operation fixes the workers that will execute subsequent processing

From the screenshots I am not seeing any differences even though I think I got your text explanation right.

Isn't it related to the fact that you might have opted to keep the session?

 

however, If you spotted differences feel free to open a support ticket so that someone will have a proper look and replicate and get back to you through the ticketing mechanism. A change might be due so you'll need the ticket anyway.

 

Andrei Vasile Truta
0 Likes
Contributor.. komai00 Contributor..
Contributor..

Re: Executing the SSH Shell v2.0 operation fixes the workers that will execute subsequent processing

Thank you for an answer.

What will the ticket (a support ticket, ticketing mechanism) be?
Is it HPE company tech support teller? Or do you mean internal handling of OO?

Is a session SSH session?
Because I log off by "SSH Shell logoff" step, I think that the SSH session is not maintained.

 

If, in the case of OO cluster environment, WorkerGroup is "RAS_Operator_Path," Active Worker is chosen among plural Worker registered with "RAS_Operator_Path" automatically, and processing is carried out.
In the case of the following images, Worker handling is chosen among two Worker automatically.

image3.png

In addition, Worker processing hears that there are fixed specifications than Engineer HPE Corporation until logoff processing is done for internal processing (transfer of SSH SessionID) when I use "SSH Shell" operation.
However, the state that Worker handling was fixed to is maintained though logoff processing was accomplished by "SSH Shell logoff v2.0" operation.
When one Worker falls though it is oo cluster environment, the flow cannot continue taking next step.

0 Likes
Contributor.. komai00 Contributor..
Contributor..

Re: Executing the SSH Shell v2.0 operation fixes the workers that will execute subsequent processing

This event seems to occur also in "SSH Command v2.0". It also does not occur in "SSH Command v1.0".
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v1.0/SSH Command
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v2.0/SSH Command

SSH Command v2.0 of "SSH Command v2.0"
The worker group of "SSH Command v2.0" onwards will become a fixed worker.

 

 

image02.png

 

SSH Command v1.0 of "SSH Command v1.0"
The worker group for all steps is "Ras_Operator_path"

image01.png


Overall flow chart

image00.png

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.