send refresh command with updated login credentials

[BradV]

I know I can send a refresh command to all of my servers with:

# Get session credentials
# Get a list of all hardware in OneView into a file.
HARDW=hardw-all
DATA='{"refreshState" : "RefreshPending"}'
i=0
for SERVER in $(jq -r .members[] | "\(.uuid)"' ${HARDW}); do
   REFRESH[${i},0]=$(echo -n "${SERVER}")
   REFRESH[${i},1]=$(curl --insecure --include --silent \
      --header "content-type: application/json" \
      --header "auth: ${sessionID}" \
      --header "X-API-Version: ${currentVersion}" \
      --data "${DATA}" \
      --request PUT ${OneView}/rest/server-hardware/${SERVER}/refreshState | grep '^Location:' | awk '{ print $2 }')
   ((i++))
done
#
j=${i}
i=0
while [[ ${i} -lt ${j} ]]; do
   curl --insecure --silent \
      --header "auth: ${sessionID}" \
      --header "X-API-Version: ${currentVersion}" \
      --request PUT ${OneView}${REFRESH[${i},1]%$'\r'} | jq -r '.associatedResource.resourceName,.taskState'
   ((i++))
done   

The problem is, it is not working for some.  I'm getting task status of Error.  When I go into the gui and ask for a refresh, it asks me to provide the user login credentials.  Which does not make sense.  If I click on the "iLO host name" or "iLO address" in OneView, it correctly opens the iLO interface.

Does anyone know how to send a refresh command and supply iLO credentials?

Note: all of our iLOs are running in high production mode.  We had to do that for TLS compliance reasons.

[ChrisLynch]

Check for the server hardware state is Unmanaged and the stateReason is Unconfigured.  You will need to supply credentials to the iLO as the appliance is no longer able to communicate to the iLO with the defined credentials as part of the Body in your PUT request.  You will need a dictionary object with:

refreshState = RefreshPending
hostname [string]
username [string]
password [string]

[BradV]

@ChrisLynch 

Thanks Chris.  I don't see any of our servers in an "Unmanaged" state.   So, not sure why we had such problems.  I do see a number that are in "ProfileError" state.  I extracted a list of all of the hardware (REST-API-getting-list-of-current-hardware ).  If I then run:

jq -r '.members[] | { name: .name, state: .state, stateReason: .stateReason }' ${HARDW} | jq '. | select(.state!="ProfileApplied")'

I can see everything that is not in the normal "ProfileApplied" state.  I'll work on that to check for state Unmanaged and stateReason of Unconfigured to craft a reply.

Thanks!