max
Minnow
Posts: 15
|
Post by max on Jul 16, 2020 13:31:40 GMT
What is the difference between "ForceRestart" and "PowerCycle" ? "ForceRestart" is described in ComputerSystem.v1_4_0.json as "The ForceOff value shall remove power from the system or perform an ACPI Power Button Override (commonly known as a 4-second hold of the Power Button). The ForceRestart value shall perform a ForceOff action followed by a On action." That sounds like a power cycle to me too, and not as the equivalent of pressing the physical reset button. Max, There's a subtle distinction, and one we probably should add to the descriptions to better explain - along with some guidance of which to use if there's no preference... We added the "PowerCycle" separate from "ForceRestart" because a restart does not require the power to be removed from a device. The reset could be accomplished by a hardware reset signal as opposed to cycling power. This may be exposing more of the implementation details than was necessary... This is a good question and one that I'll take back to the Forum. It would be good to clarify what happens for both of those values if the device is not powered on. At least one vendor seems to deny ForceRestart if their implementation thinks the system is off. It would be nice if ForceRestart would always work (as in require that by specification). (Especially since this particular implementation also sometimes thinks the system is off, when it is NOT. Everytime their Redfish lua implementation crashes and get restarted it seems to assume power is off, instead of querying the running system.)
|
|
max
Minnow
Posts: 15
|
Post by max on Jul 15, 2020 20:01:21 GMT
|
|
max
Minnow
Posts: 15
|
Post by max on Jul 15, 2020 18:33:52 GMT
ActionInfo is a newer method of conveying parameter details about a given implementation. However, like with other parts of the data model, there is no requirement to drop older methods; it may be done at some point in time in the future, but ultimately that's the implementations choice. I would hope folks would support both methods until they're confident their customers have migrated to the newer method. I would suggest reaching out to your vendor on this issue. From a Redfish standards perspective, there shouldn't be a reason for the "ResetType@Redfish.AllowableValues" property to have been removed. Your newer method requires yet another HTTP request -while some implementations are already very slow and known to take 5 seconds for each-, while it is not clear to me what advantage the newer method has for the simple and common use case to reset a server. But apart from that, there is nothing in your standard recommending vendors to keep ResetType@Redfish.AllowableValues for compatibility with older implementations, while I do think you should mention it there. And a vendor that is new to Redfish and just grabs the latest Redfish specification from your site to implement has no way of knowing that "older" client implementations rely on the "old" way either, as it does not seem to be mentioned anywhere. The wording you use in the spec. suggests it is fine for a vendor to pick either way to implement, not making it clear what is "old" and what is "new" either: This amount of freedom does not lead to very interoperable client software and servers... Reaching out to vendors is also a bit problematic in practice, because we are not their direct customer. (We sell server provisioning software to datacenters, but do not buy any significant number of servers ourselves. So do not have an account manager at said vendors we can forward the problem to. And our customers do not see the urgent need to get involved either, as RMCP+ still does work for servers on which Redfish is not in an usable state).
|
|
max
Minnow
Posts: 15
|
Post by max on Jul 15, 2020 15:44:53 GMT
Hi, When wanting to "reset" a server, our software used to query /redfish/v1/Systems/<system name> and look at the ResetType@Redfish.AllowableValues field, to see if we can use ForceRestart, GracefulRestart, or if we need to send ForceOff -> sleep some time -> On. This is needed because some vendors did not bother to implement ForeceRestart -even though they all do support "chassis power reset" through RCMP+ protocol-, while others do. An annoyance I wrote about before in 2017 ( Make implementation common reset types mandatory thread) We noticed however that some vendors are now no longer sending ResetType@Redfish.AllowableValues with the system information, but seems to provide a "@redfish.ActionInfo" instead with that information. E.g. Lenovo SR635 sends: { "@odata.context":"/redfish/v1/$metadata#ComputerSystem.ComputerSystem", "@odata.etag":"\"1594825713\"", "@odata.id":"/redfish/v1/Systems/Self", "@odata.type":"#ComputerSystem.v1_7_0.ComputerSystem", "Actions":{ "#ComputerSystem.Reset":{ "@Redfish.ActionInfo":"/redfish/v1/Systems/Self/ResetActionInfo", "@Redfish.OperationApplyTimeSupport":{ "@odata.type":"#Settings.v1_2_1.Settings.OperationApplyTimeSupport", "MaintenanceWindowDurationInSeconds":600, "MaintenanceWindowResource":{ "@odata.id":"/redfish/v1/Systems/Self" }, "SupportedValues":[ "Immediate", "AtMaintenanceWindowStart" ] }, "target":"/redfish/v1/Systems/Self/Actions/ComputerSystem.Reset" } }, "AssetTag":"Free form asset tag", "Boot":{ "BootOptions":{ "@odata.id":"/redfish/v1/Systems/Self/BootOptions" }, "BootSourceOverrideEnabled":"Disabled", "BootSourceOverrideEnabled@Redfish.AllowableValues":[ "Disabled", "Once", "Continuous" ], "BootSourceOverrideMode":"Legacy", "BootSourceOverrideMode@Redfish.AllowableValues":[ "Legacy", "UEFI" ], "BootSourceOverrideTarget":"None", "BootSourceOverrideTarget@Redfish.AllowableValues":[ "None", "Pxe", "Floppy", "Cd", "Usb", "Hdd", "BiosSetup", "Diags" ], "Certificates":{ "@odata.id":"/redfish/v1/Systems/Self/Boot/Certificates" } }, "Description":"System Self", "EthernetInterfaces":{ "@odata.id":"/redfish/v1/Systems/Self/EthernetInterfaces" }, "Id":"Self", "IndicatorLED":"Off", "IndicatorLED@Redfish.AllowableValues":[ "Lit", "Blinking", "Off" ], "Links":{ "Chassis":[ { "@odata.id":"/redfish/v1/Chassis/Self" } ], "Chassis@odata.count":1, "ManagedBy":[ { "@odata.id":"/redfish/v1/Managers/Self" } ], "ManagedBy@odata.count":1, "PoweredBy":[ { "@odata.id":"/redfish/v1/Chassis/Self/Power#/PowerSupplies/1" }, { "@odata.id":"/redfish/v1/Chassis/Self/Power#/PowerSupplies/0" } ], "PoweredBy@odata.count":2 }, "LogServices":{ "@odata.id":"/redfish/v1/Systems/Self/LogServices" }, "Manufacturer":" ", "Memory":{ "@odata.id":"/redfish/v1/Systems/Self/Memory" }, "MemoryDomains":{ "@odata.id":"/redfish/v1/Systems/Self/MemoryDomains" }, "Model":" ", "Name":"System", "NetworkInterfaces":{ "@odata.id":"/redfish/v1/Systems/Self/NetworkInterfaces" }, "PartNumber":" ", "PowerState":"Off", "Processors":{ "@odata.id":"/redfish/v1/Systems/Self/Processors" }, "SKU":" ", "SecureBoot":{ "@odata.id":"/redfish/v1/Systems/Self/SecureBoot" }, "SerialNumber":" ", "SimpleStorage":{ "@odata.id":"/redfish/v1/Systems/Self/SimpleStorage" }, "Status":{ "Health":"OK", "HealthRollup":"OK", "State":"Enabled" }, "Storage":{ "@odata.id":"/redfish/v1/Systems/Self/Storage" }, "SystemType":"Physical" }
And if you then query /redfish/v1/Systems/Self/ResetActionInfo you get the same info as before: { "@odata.context":"/redfish/v1/$metadata#ActionInfo.ActionInfo", "@odata.etag":"\"1594825760\"", "@odata.id":"/redfish/v1/Systems/Self/ResetActionInfo", "@odata.type":"#ActionInfo.v1_1_1.ActionInfo", "Description":"This action is used to reset the Systems", "Id":"ResetAction", "Name":"ResetAction", "Parameters":[ { "AllowableValues":[ "GracefulShutdown", "ForceOff", "On", "ForceRestart" ], "DataType":"String", "Name":"ResetType", "Required":true } ] }
Apparently this construct is allowed in the newer Redfish specification version, but needless to say this breaks any and all existing software that was written before "@redfish.ActionInfo" was part of the spec. Can anybody enlighten me why this breaking change was made? The Redfish protocol offers a lot of flexibility for system vendors about what way they chose to implement things, but that makes it very hard for client software developers to deal with the different implementations.
|
|
max
Minnow
Posts: 15
|
Post by max on Feb 12, 2019 12:30:37 GMT
Don't think what is in there according to the specification is that sensitive, but it does annoy me that vendors put all kind of extra information in there that the server's owner did not consent to disclose. E.g. HP puts there: - iLO firmware version - what authentication mechanism is in use (local username/password vs LDAP/kerberos authentication) - hostname/certificate information that defaults to server's serial number, allowing an attacker to pull the server's hardware configuration from partsurfer.hp.com/ and look for say high value targets, or older gear that may no longer have updates. And while Dell doesn't do that, it does puts enough clues in there to determinate it's a Dell server, and can also grab the server's serial from the SSL certificate's common name. Would be nice if specification strictly disallowed any and all information disclosure without authentication.
|
|
max
Minnow
Posts: 15
|
Post by max on May 9, 2018 21:09:26 GMT
There are multiple server vendors that support Redfish: HPE, Dell, Supermicro, etc. Do note that some vendors like Supermicro charge an extra licensing fee if you want to have Redfish support enabled. Something you may want to take into account when selecting server vendor.
|
|
max
Minnow
Posts: 15
|
Post by max on Oct 12, 2017 21:14:04 GMT
Any update on this? Seems semi-documented vendor specific extensions for this are starting to appear. www.supermicro.nl/manuals/other/RedfishRefGuide.pdf(haven't actually tested it, as this vendor charges a licensing fee if you want to use Redfish, while RCMP+/webinterface usage is free. but it sounds like it does what we would like to see) Would be nice if things were standardized instead of ending up in a situation in which vendors invent their own OEM Redfish command to do the same action...
|
|
max
Minnow
Posts: 15
|
Post by max on Sept 27, 2017 13:12:37 GMT
Sending a "ForceOff" -> sleeping some seconds -> sending "On" sequence turns out to be problematic on some servers as well. They wrongfully try to gracefully shutdown the server first, and if that takes longer than our sleep, will return a "Unable to perform the specified reset action, System is already in Power On state" error in response to our "On" command because turning it off hasn't finished yet. Eventually the system will turn off after all, and then it won't be turned "on" again.
One could argue that we should poll for power state before sending "On", however sleeping for longer periods is not feasible in simple web applications (script will run synchronously and a web browser waiting for its completion may not be so patient, and timeout). And we are not going to jump through such hoops. Be aware that in such cases we will be displaying an error message to the user that the server's RedFish implementation is not usable, and advise them to switch to old fashioned RCMP+ instead.
|
|
max
Minnow
Posts: 15
|
Post by max on Sept 24, 2017 21:26:01 GMT
What is the difference between "ForceRestart" and "PowerCycle" ?
"ForceRestart" is described in ComputerSystem.v1_4_0.json as "The ForceOff value shall remove power from the system or perform an ACPI Power Button Override (commonly known as a 4-second hold of the Power Button). The ForceRestart value shall perform a ForceOff action followed by a On action." That sounds like a power cycle to me too, and not as the equivalent of pressing the physical reset button.
Note that the way ForceRestart is described in the json implies that the command will also work when the system is powered down, as it will always be turned "on" in the end. If you are mapping it to "reset" in your implementation, will that still be the case? As a physical reset button press will normally do nothing if the system is off.
|
|
max
Minnow
Posts: 15
|
Post by max on Sept 23, 2017 19:32:20 GMT
Our PXE server provisioning system likes to know the MAC addresses of the first network port of all servers. And it would be nice if we could retrieve those automatically through Redfish, instead of the current practice of having an admin enter them manually into the system.
Problem is that although the MAC addresses can be retrieved through /redfish/v1/Systems/$systemname/EthernetInterfaces/$interfacename there is currently no easy way for a script to figure out which network interface belongs to the first port, and which to the second, etc., without requiring the user to select the interface manually. When asked for a list of Ethernet interfaces vendors currently seem to return them in some undefined order:
$ curl -k -u user:password https://192.168.178.76/redfish/v1/Systems/System.Embedded.1/EthernetInterfaces {"@odata.context":"/redfish/v1/$metadata#EthernetInterfaceCollection.EthernetInterfaceCollection","@odata.id":"/redfish/v1/Systems/System.Embedded.1/EthernetInterfaces","@odata.type":"#EthernetInterfaceCollection.EthernetInterfaceCollection","Description":"Collection of Ethernet Interfaces for this System","Members":[{"@odata.id":"/redfish/v1/Systems/System.Embedded.1/EthernetInterfaces/NIC.Integrated.1-3-1"},{"@odata.id":"/redfish/v1/Systems/System.Embedded.1/EthernetInterfaces/NIC.Integrated.1-4-1"},{"@odata.id":"/redfish/v1/Systems/System.Embedded.1/EthernetInterfaces/NIC.Integrated.1-1-1"},{"@odata.id":"/redfish/v1/Systems/System.Embedded.1/EthernetInterfaces/NIC.Integrated.1-2-1"}],"Members@odata.count":4,"Name":"System Ethernet Interface Collection"}
Yes, a person can understand "/NIC.Integrated.1-1-1" is the first network port on this system. But it is the third item in the collection, and not the first, which makes things hard to script without knowing the naming convention of each vendor, which is not standardized either. In this particular case an alphabetic sort on id could have put the right port on top, but that may not always be the case either. E.g. I don't know what the ids would be like if an extra PCIe NIC card is added.
Can we add a rule that EthernetInterfaceCollection should be ordered based on port number and that integrated mainboard NIC ports are listed before other ones? Or add an integer network port number field inside each EthernetInterface instead of just a textual description? Or some other way to figure out which EthernetInterface is used for PXE boots?
|
|
max
Minnow
Posts: 15
|
Post by max on Mar 8, 2017 21:55:51 GMT
Most implementations should have a session inactivity timeout (part of the SessionService) that can be configured as required to ensure that inactive sessions get cleaned up. Problem is that we cannot depend on implementations having any such feature, since it is simply not required by specification: That's the problem with Redfish in general. Everything is far too voluntary, and left up to the implementation... Your implementation may do the right thing, but if we buy new servers from vendor X, we do not have any guarantee what implementation we will get, and if it will be usable at all...
|
|
max
Minnow
Posts: 15
|
Post by max on Mar 7, 2017 1:11:41 GMT
>Have you considered using a Redfish session for your needs, when you have multiple requests?
Yes, but same vendor has a 8 concurrent login sessions limit. I am concerned that if there is a bug in my script, and it errors out between operations, the session is kept open, and I'll lock myself out once limit is reached. And there can also be other management or monitoring software active in same organization that uses up sessions.
>Also, another fairly time intensive task for a low powered CPU is the negotiation of an HTTPS connection. If you aren't already, you could consider using a persistent connection. Using curl for single shot >connections wont be doing this, so your HTTPS connection will need to be re-established for every request.
Already use a persistent HTTP keep-alive connection in my own application. But the 0.4 second it would take, if that was not the case (as in my curl example) is not what I am really worried about. The 6 seconds it takes when authentication is used is. In fact it looks more like an intentional 5 second delay on every login to me (to prevent brute forcing of passwords?), than real time spent computing a hash. And would argue that if it did was spent computing some complicated multiround hash (bcrypt?), implementations should add some caching mechanism that keeps hash input (password) and result in memory for some time.
|
|
max
Minnow
Posts: 15
|
Post by max on Jan 22, 2017 11:42:47 GMT
Currently some Redfish implementations are very slow.
Keep in mind that with Redfish client software may have to send multiple requests to perform the action they want. E.g. our server provisioning software may just want to tell the server to perform a PXE network boot. But since there is not any convenient shortcut command in Redfish to do that, it has to send up to 5 separate requests instead:
1) see what the id of the system is by fetching: /redfish/v1/Systems 2) patch the BootSourceOverrideTarget to Pxe at: /redfish/v1/Systems/{id of system} 3) determine what ResetTypes are supported by fetching: /redfish/v1/Systems/{id of system} 4) post to /redfish/v1/Systems/{id of system}/Actions/ComputerSystem.Reset - using "ForceRestart" if that is supported - or if not make two requests. "ForceOff" first, followed by "On" some seconds later.
Especially if HTTP basic authentication is used each individual request takes ages on some implementations. To demonstrate the problem, this is how long it takes to just to fetch the /redfish/v1 endpoint -for which authentication is optional- without and with sending the password:
$ time curl --insecure https://192.168.178.12/redfish/v1 {"@odata.context":"/redfish/v1/$metadata#ServiceRoot.ServiceRoot","@odata.id":"/redfish/v1","@odata.type":"#ServiceRoot.v1_0_2.ServiceRoot","AccountService":{"@odata.id":"/redfish/v1/Managers/iDRAC.Embedded.1/AccountService"},"Chassis":{"@odata.id":"/redfish/v1/Chassis"},"Description":"Root Service","EventService":{"@odata.id":"/redfish/v1/EventService"},"Id":"RootService","JsonSchemas":{"@odata.id":"/redfish/v1/JSONSchemas"},"Links":{"Sessions":{"@odata.id":"/redfish/v1/Sessions"}},"Managers":{"@odata.id":"/redfish/v1/Managers"},"Name":"Root Service","RedfishVersion":"1.0.2","Registries":{"@odata.id":"/redfish/v1/Registries"},"SessionService":{"@odata.id":"/redfish/v1/SessionService"},"Systems":{"@odata.id":"/redfish/v1/Systems"},"Tasks":{"@odata.id":"/redfish/v1/TaskService"}}
real 0m0.476s user 0m0.052s sys 0m0.016s
$ time curl --insecure -u root:mypassword https://192.168.178.12/redfish/v1 {"@odata.context":"/redfish/v1/$metadata#ServiceRoot.ServiceRoot","@odata.id":"/redfish/v1","@odata.type":"#ServiceRoot.v1_0_2.ServiceRoot","AccountService":{"@odata.id":"/redfish/v1/Managers/iDRAC.Embedded.1/AccountService"},"Chassis":{"@odata.id":"/redfish/v1/Chassis"},"Description":"Root Service","EventService":{"@odata.id":"/redfish/v1/EventService"},"Id":"RootService","JsonSchemas":{"@odata.id":"/redfish/v1/JSONSchemas"},"Links":{"Sessions":{"@odata.id":"/redfish/v1/Sessions"}},"Managers":{"@odata.id":"/redfish/v1/Managers"},"Name":"Root Service","RedfishVersion":"1.0.2","Registries":{"@odata.id":"/redfish/v1/Registries"},"SessionService":{"@odata.id":"/redfish/v1/SessionService"},"Systems":{"@odata.id":"/redfish/v1/Systems"},"Tasks":{"@odata.id":"/redfish/v1/TaskService"}}
real 0m6.192s user 0m0.044s sys 0m0.016s
|
|
max
Minnow
Posts: 15
|
Post by max on Jan 21, 2017 23:25:46 GMT
It would be nice if every vendor at least supported the "On", "ForceOff", "ForceRestart" options for the /redfish/v1/Systems/{system}/Actions/ComputerSystem.Reset action. Right now implementation is far too voluntary, leading to at least one major vendor not bothering to implement "ForceRestart". While same vendor did support the "chassis power cycle" command with legacy IPMI.
Always having to query for supported ResetTypes, and having to do workarounds if "ForceRestart" is not available (sending "ForceOff" -> sleeping some seconds -> sending "On"), does not help with performance. And can lead to an unresponsive user interface if the client application is a simple webinterface.
|
|
max
Minnow
Posts: 15
|
Post by max on Aug 13, 2016 14:34:10 GMT
We are a developer of server management software for dedicated server providers. One of the things we currently miss most is a standardized way to start a KVM-over-IP console session to a server without requiring the user to login to the IPMI management webinterface of that server manually first.
It would be very nice if Redfish was extended to support creating sessions on behalf of users for use outside of Redfish.
It could be something similar to the existing SessionService, like:
POST /redfish/v1/ExternalSessionService/Sessions HTTP/1.1 Content-Type: application/json;charset=utf-8 Accept: application/json;charset=utf-8 OData-Version: 4.0
{ "UserName": "username", "Password": "password", "SessionType": "KVM-IP" }
With the only difference that instead of an X-Auth-Token it should return an URL we can redirect the user's browser to. That URL should incorporate a single-use session token that logs the user in without prompting for username and password, and should serve the content necessary to display the console (e.g. JNLP Java webstart file, or HTML5 noVNC console page) straight away.
Location: /redfish/v1/ExternalSessionService/Sessions/1 X-Auth-Single-Use-Url: https://1.2.3.4/kvm-ip-webinterface/?token=80a91934-dd9f-442f-935c-ccfbb737caa2
{ "@odata.context": "/redfish/v1/$metadata#Session.Session", "@odata.id": "/redfish/v1/ExternalSessionService/Sessions/1", "@odata.type": "#Session.v1_0_0.Session", "Id": "1", "Name": "User Session", "Description": "User Session", "UserName": "username" }
|
|