Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

Dell PowerFlex 4.6.x Administration Guide

PDF

Run script on host

Use this method to run a script on all or some of the Linux-based nodes with an optional reboot and an optional verification script.

CAUTION:PowerFlex Manager is required to perform run script on the host operation. A target script is run without validation or verification.

The script files must be stored in the folder node folder: /opt/emc/scaleio/lia/bin. The script file used to run script on the host operation must be named as patch_script.

If verification is required, a script to verify the work can be written and named verification_script.

The filenames are hard coded and cannot be changed: patch_script and verification_script. The scripts are required to have these names. Alternatively, they can be uploaded by PowerFlex Manager to the PowerFlex node.

To copy the script file onto the block-legacy-gateway pods, use the kubectl cp command from any of the PowerFlex management platform hosts or VMs.

For example,

kubectl cp -n powerflex patch_script block-legacy-gateway-0:/usr/local/tomcat/temp/

kubectl cp -n powerflex patch_script block-legacy-gateway-1:/usr/local/tomcat/temp/

The scripts can be either taken from a gateway local folder or downloaded from HTTP or HTTPS share.

A list of SdsIds or mdmIds can be provided to explicitly choose the PowerFlex nodes to run on.

Table 1. API commandAPI command required and optional parameters
API command Required parameters Optional parameters
/im/types/Configuration/actions/liaRunOsPatching
NOTE:Before running the liaRunOsPatching command, log in to PowerFlex and get the system configuration. For more information, see the example workflow below.
Either one of the following parameters is mandatory:
  • pdIds: Run on all PowerFlex nodes that are part of the following protection domains (PD Ids), in decimal format.
  • fsIds: Run on all PowerFlex nodes that are part of the following fault sets (FS Ids), in decimal format.
  • sdsIds: Run on all SDSs listed by Ids, in decimal format
  • mdmIds: Run on all MDMs listed by Ids, in decimal format
  • executeOnAllSdss: Run on all SDSs (true/false)
    NOTE:All nodes running PowerFlex management platform processes are skipped for reboots. The action must be performed manually.
  • executeOnAllMdms: Run on all MDMs (true/false)
  • isRebootRequired: Indicates if each node reboot is required after running the patch script (values: true/false)
    NOTE:All nodes running PowerFlex management platform processes are skipped for reboots. The action must be performed manually.
  • isVerificationScriptRequired: Indicates if the verification script is run on each node (values: true/false)
  • isRunningInParallelOnPds: Indicates if the operation is run in a parallel way on nodes that belong to different PDs (values: true/false)
  • isStopProcessingOnScriptFailure: Indicates if the entire operation must be stopped if there is a script failure (values: true/false
  • TimeoutMs: Indicates timeout value for running the patch script in milliseconds
  • isUploadFileNeeded: Indicates if the gateway upload scripts to the PowerFlex nodes (values: true/false)
    The following fields are relevant when isUploadFileNeeded is true:
    • patchScriptFilePath: Either the local folder name on the block-legacy-gateway pods or an http/https URL of the patch script
    • verificationScriptFilePath: Either the local folder name on the block-legacy-gateway pods or an http/https URL of the verification script
    • maintenanceModeType: Maintenance Mode type (values: IMM/PMM)
    • verificationScriptTimeoutSec: Verification script timeout in seconds
    • rebootTimeoutSec: Node reboot timeout in seconds
The following are the example commands that are used during run script on the host process:
  1. Obtain an access token from the PowerFlex Manager instance. The easiest method is to create a shell script that can be sourced to add the proper variables to the user environment
    INGRESS_IP=<powerflex manager IP>
    INGRESS_USER=<powerflex manager user>
    INGRESS_PASSWORD=<powerflex manager password> 
    
    1. Get JWT token with POST /rest/auth/login.
      TOKEN=$(curl -s -k --location --request POST "https://${INGRESS_IP}/rest/auth/login" --header "Accept: application/json" --header "Content-Type: application/json" --data "{\"username\": \"${INGRESS_USER}\",\"password\": \"${INGRESS_PASSWORD}\"}")
    2. Parse out the access token which is used to call the API and is valid for 5 minutes by default.
      ACCESS_TOKEN=$(echo "${TOKEN}" | jq -r .access_token)
    3. Parse out the refresh token which can be used to get a new JWT token if the access token has expired. It is valid for 30 minutes by default.
      REFRESH_TOKEN=$(echo "${TOKEN}" | jq -r .refresh_token)
      NOTE:The expiration time for access token is five minutes. If required, the above file can be sourced to refresh all variables.
  2. Get the JSON of a system configuration, which will be the payload of the patch command (need to replace liaPassword and mdmPassword manually from null to some string).
    1. Create and save a JSON file like the following, replacing MDM addresses, MDM user, and MDM password with the appropriate values.
      {
         "mdmIps":["<MDM IP-1>","<MDM-IP2>"],
         "mdmUser":"<mdm user>",
         "mdmPassword":"<mdm password>”,
         "securityConfiguration":
         {
            "allowNonSecureCommunicationWithMdm":"true",
            "allowNonSecureCommunicationWithLia":"true",
            "disableNonMgmtComponentsAuth":"false"
         }
      }
      
    2. Insert the output of this command (with fixed passwords) into the config.json file:
      curl -s -X POST -k -H "Content-Type: application/json" --data <json file>  -H "Authorization: Bearer ${ACCESS_TOKEN}" https://<powerflex manager IP>/im/types/Configuration/instances > config.json 
  3. Run the patch command (loading the config.json):
    NOTE:The cookiefile stores session cookies which keep the command flow directed to the same gateway pod.
    curl -v -k -c cookiefile -X -i POST -H "Content-Type:application/json" -H "Authorization:
    Bearer ${ACCESS_TOKEN}" "https://<powerflex manager IP>/im/types/Configuration/actions/liaRunOsPatching?executeOnAllSdss=true
    &isRebootRequired=true&isPatchScriptRequired=true&isVerificationScriptRequired=true&patchScriptFilePath=”https://
    <ipaddress>/patch_script”&verificationScriptFilePath=”https://<ip-address>/verification_script”&maintenanceModeType=IMM&rebootTimeoutSec=600" -d @config.json
    
  4. Query command state by running the following command:
    curl -k -b cookiefile -X GET -H "Content-Type: application/json" -d @config.json -H "Authorization: Bearer $ACCESS_TOKEN" "https://10.234.89.250/im/types/ProcessPhase/actions/queryPhaseState" | jq
    {
      "phaseStatus": "idle",
      "phase": "idle",
      "numberOfRunningCommands": 0,
      "numberOfPendingCommands": 0,
      "numberOfCompletedCommands": 0,
      "numberOfAbortedCommands": 0,
      "numberOfFailedCommands": 0,
      "failedCommands": []
    }
    
    or 
    {
      "phaseStatus": "running",
      "phase": "execute",
      "numberOfRunningCommands": 1,
      "numberOfPendingCommands": 1,
      "numberOfCompletedCommands": 35,
      "numberOfAbortedCommands": 0,
      "numberOfFailedCommands": 0,
      "failedCommands": []
    }
    
    or 
    {
      "phaseStatus": "completed",
      "phase": "validate",
      "numberOfRunningCommands": 0,
      "numberOfPendingCommands": 0,
      "numberOfCompletedCommands": 2,
      "numberOfAbortedCommands": 0,
      "numberOfFailedCommands": 0,
      "failedCommands": []
    }
    
    Look for: 
    
    {
      "phaseStatus": "completed",
      "phase": "execute",
      "numberOfRunningCommands": 0,
      "numberOfPendingCommands": 0,
      "numberOfCompletedCommands": 37,
      "numberOfAbortedCommands": 0,
      "numberOfFailedCommands": 0,
      "failedCommands": []
    }
    
  5. Move to NextPhase by running the following command.
    curl -k -b cookiefile -X POST -H "Content-Type: application/json" -d '' -H "Authorization: Bearer $ACCESS_TOKEN" https://10.234.89.250//im/types/ProcessPhase/actions/moveToNextPhase
  6. Cancel the phase by running the following command
    curl -k -b cookiefile -X POST -H "Content-Type: application/json" -d '' -H "Authorization: Bearer $ACCESS_TOKEN" https://10.234.89.250/im/types/Command/instances/actions/abort
    
  7. Clear the phase by running the following command
    curl -k -b cookiefile -X POST -H "Content-Type: application/json" -d '' -H "Authorization: Bearer $ACCESS_TOKEN" https://10.234.89.250/im/types/Command/instances/actions/clear
    
  8. Move to idle phase by running the following command
    curl -k -b cookiefile -X POST -H "Content-Type: application/json" -d '' -H "Authorization: Bearer $ACCESS_TOKEN" https://10.234.89.250/im/types/ProcessPhase/actions/moveToIdlePhase
    

Logs

Gateway pod log locations:
  • /usr/local/tomcat/logs/scaleio.log
  • /usr/local/tomcat/logs/scaleio-trace.log

LIA log location: /opt/emc/scaleio/lia/logs/trc.x

NOTE:Special switch to keep the script in the node when troubleshooting or testing:
  1. Edit file /usr/local/tomcat/webapps/ROOT/WEB-INF/classes/gatewayInternal.properties
  2. Find the field "ospatching.delete.scripts=false"
  3. Change to true for troubleshooting (Default is false)

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\