update_firmware_using_catalog.py compatible with OME Ent ?

[markatdxb]

Hello, just tested the script against our OME Enterprise and getting following error. Script actually creates new Catalog calles Test:Date:Time but after it crash.

Creating new catalog.! Traceback (most recent call last): File "update_firmware_using_catalog.py", line 656, in CATALOG_ID = catalog_creation(ip_address=IP_ADDRESS, headers=HEADERS) File "update_firmware_using_catalog.py", line 122, in catalog_creation raise Exception("Exiting the code, Unable to create catalog") Exception: Exiting the code, Unable to create catalog

[RaajeevKalyan]

There have been significant changes in this script due to added functionality - could you retry with the latest version and update if you are still seeing issues

[markatdxb]

hi i just tested the latest version from github and im really confused if there is anything im doing wrong as i still cant make it running. my environment is CentOS 8 with Pyhton 3 version 3.6.8

i have a device in OME Ent - https://ome02/core/console/console.html#/core/device/device/device_portal?id=78412&tab=summary

i run the following syntax: python3 update_firmware_using_catalog.py --ip 10.10.10.10 --user 'domain\username' --password 'password' --updateaction upgrade --repotype DELL_ONLINE --deviceid 78412 Traceback (most recent call last): File "update_firmware_using_catalog.py", line 630, in ARGS.deviceid, IP_ADDRESS)) ValueError: Device 78412 not found on 10.4.9.10 ... Exiting

i tried to use ServiceTag instead of deviceID but results is the same

any hint whats wrong here? thx

[RaajeevKalyan]

Can you run the device enumeration script (get_device_list.py) and provide the output - what does device id of 78412 map to?

The script usually tries to validate if the device ID does map to an actual device managed by OME - in this case I assume ome02 maps to the 10.10.10.10 (example?) IP you used -

Also looking at the new changes the following parameters seem to be required python update_firmware_using_catalog.py --ip "ome ip" --user "ome admin level user" --password "password for user" --updateactions "upgrade" --deviceid "device id retrieved from get_device_list.py"

[markatdxb]

i just ran the script - 78412 map to correct device with id 78412. but there is another "ManagementId": 61979, - is this the one need to put to fw upgrade script ?

[RaajeevKalyan]

Just the deviceID is sufficient - the management ID is usually under the DeviceManagement blob if i am not mistaken and is not required for this operation - I assume 78412 shows up like below - is the Type 1000?

"value": [ { "@odata.type": "#DeviceService.Device", "@odata.id": "/api/DeviceService/Devices(10110)", "Id": 10110, "Type": 1000,

[RaajeevKalyan]

Sorry - there is an issue with the script - I expect you have more than 50 devices and it looks like some recent changes didn't take into account pagination. My deduction is that your device ID isn't returned in the first page of results which is all that is parsed now and hence the script is failing to get it to work

For now you could add that device to a new static group and provide the group id - I'll push in an update to fix this asap

[RaajeevKalyan]

I've pushed an untested snippet to help get past the issue temporarily if the group creation and usage isn't an option - Will update the script further to handle pagination across catalogs and groups and test out across more devices

[markatdxb]

Sorry - there is an issue with the script - I expect you have more than 50 devices and it looks like some recent changes didn't take into account pagination. My deduction is that your device ID isn't returned in the first page of results which is all that is parsed now and hence the script is failing to get it to work

For now you could add that device to a new static group and provide the group id - I'll push in an update to fix this asap

yes thats right - we have close to 1000 devices. i ran into pagination issue before when using API calls to OME as well - good catch

[markatdxb]

I've pushed an untested snippet to help get past the issue temporarily if the group creation and usage isn't an option - Will update the script further to handle pagination across catalogs and groups and test out across more devices

just tested with the latest code you released - got the following error Traceback (most recent call last): File "update_firmware_using_catalog.py", line 639, in mapping = get_device_list(IP_ADDRESS, HEADERS) File "update_firmware_using_catalog.py", line 87, in get_device_list data = get_device_from_uri(next_link_url, headers) File "update_firmware_using_catalog.py", line 71, in get_device_from_uri json_data = device_response.json() AttributeError: 'dict' object has no attribute 'json'

[RaajeevKalyan]

I fixed that issue and pushed a new commit in - could you try with that please

[markatdxb]

bug seems to be fixed - no similar error. now i get different error related to the fact that we already have Catalog based on Dell online repository. Is there any way to specify this existing Catalog in the script parameters ? I found option Catalogpath but not sure thats the right option

--repotype {DELL_ONLINE,NFS,CIFS} [--catalogpath CATALOGPATH] [--force FORCE]

Creating new catalog.! Traceback (most recent call last): File "update_firmware_using_catalog.py", line 665, in repo_domain=ARGS.repodomain) File "update_firmware_using_catalog.py", line 155, in catalog_creation raise Exception("Unable to create catalog", data) Exception: ('Unable to create catalog', b'{"error":{"code":"Base.1.0.GeneralError","message":"A general error has occurred. See ExtendedInfo for more information.","@Message.ExtendedInfo":[{"MessageId":"CUPD3063","MessageId":"CUPD3063","RelatedProperties":[],"Message":"Unable to create or update the catalog because an Online Repository already exists.","MessageArgs":[],"Severity":"Critical","Resolution":"No response action required."}]}}')

[RaajeevKalyan]

You can use the --force flag - this should clean out the old catalog that was already created by pointing to dell and will create a new catalog with the latest content from dell to be used for this operation

[markatdxb]

tried that - getting error that baseline associated with catalog cant be deleted

Traceback (most recent call last): File "update_firmware_using_catalog.py", line 659, in delete_online_catalog(IP_ADDRESS, HEADERS) File "update_firmware_using_catalog.py", line 547, in delete_online_catalog delete_baseline(ip_address, headers, target_baseline_ids) File "update_firmware_using_catalog.py", line 515, in delete_baseline raise Exception("Failure in deleting baselines associated to dell online catalog") Exception: Failure in deleting baselines associated to dell online catalog

[markatdxb]

actually it would be great if script checks for existing Online catalog and use that instead of creating new one. we dont really want to delete the existing catalog as its used by our team to manually upgrade devices as well

[RaajeevKalyan]

A catalog that is managed by OME does not automatically refresh it's contents (even a catalog pointing to Dell) - we can look into enhancing the script to refresh the catalog if it exists already and utilize that. I'll look into that enhancement

For your error do you have multiple baselines associated with this catalog - in the UI do you see some of them removed / anything different about the ones that didn't get deleted?

[grantcurell]

@markatdxb - I'd be willing to mod the behavior. Is the behavior you're looking for:

1. Check if online catalog is present
2. If it is, use that catalog (I'll have to look into the refresh behavior @RaajeevKalyan mentioned)
3. If it isn't, make one and go from there

[grantcurell]

@markatdxb - I know this ticket has been open for a long time, but if you happen to get this, let me know if the changes I just made address your concern.

[markatdxb]

@grantcurell - actually im sorry not coming back to you earlier - buried with other projects. ill run the test again next week and come back to you

[grantcurell]

@markatdxb np - no rush

[markatdxb]

@grantcurell - again sorry for delay testing your code. seems to be working as you developed it. It goes and pulls the configuration details of the specific idrac(s) which are part of specific OME group. Unfortunately i just figured out that this is just a first of the story.
Second part is that when i look at the configuration compliance baseline after getting configuration inventory , it shows grey question mark for this new specific idrac. I guess there must be another job which compares the idrac configuration data against the baseline and builds the report. Any idea how to trigger that job again only for single specific idrac? The last piece of puzzle would be then to run the Remediation process to make the idrac compliant with the selected baseline

[grantcurell]

@grantcurell - again sorry for delay testing your code. seems to be working as you developed it. It goes and pulls the configuration details of the specific idrac(s) which are part of specific OME group. Unfortunately i just figured out that this is just a first of the story. Second part is that when i look at the configuration compliance baseline after getting configuration inventory , it shows grey question mark for this new specific idrac. I guess there must be another job which compares the idrac configuration data against the baseline and builds the report. Any idea how to trigger that job again only for single specific idrac? The last piece of puzzle would be then to run the Remediation process to make the idrac compliant with the selected baseline

Hmmm I'm kind of tracking? I have had to fix instances where compliance shows as unknown (the gray question mark) but I'm not entirely sure where in the update process that's happening for you. If you're game, we can hop on a quick Zoom or something. You can shoot me an e-mail at grant_curell (at) dell (dot) com

If not no big deal - if you shoot me some screenshots of what's happening I'll probably catch up.