Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return MAC address from Supermicro and HP systems #54167

Open
wants to merge 1 commit into
base: devel
from

Conversation

Projects
None yet
4 participants
@panticz
Copy link
Contributor

panticz commented Mar 21, 2019

On HP Servers the MAC address is available in "MacAddress" key and on Supermicro under "MACAddress". Empty values are suppressed so only available values from the respective system will by shown.

SUMMARY
ISSUE TYPE
  • Bugfix Pull Request
  • Docs Pull Request
  • Feature Pull Request
  • New Module Pull Request
COMPONENT NAME
ADDITIONAL INFORMATION

Return MAC address from Supermicro and HP systems
On HP Servers the MAC address is available in "MacAddress" key and on Supermicro under "MACAddress". Empty values are suppressed so only available values from the respective system will by shown.
@ansibot

This comment has been minimized.

@billdodd
Copy link
Contributor

billdodd left a comment

Thanks for the PR.

MACAddress is a standard Redfish property in EthernetInterface, so adding it is a good change.

But MacAddress is not a defined property, so I don't think we should add that. It's a small thing, but if we set a precedent for adding non-standard properties the code could get cluttered and confusing.

@mraineri What are your thoughts?

@panticz

This comment has been minimized.

Copy link
Contributor Author

panticz commented Mar 21, 2019

Unfortunately, every hardware manufacturer (HP, Dell, Supermicro, ...) implements Redfish differently. Starting with different structure up to different names of the keys.

This will probably be the biggest challenge for the Redfish module to cover all these differences as well as possible, because only then this module will by usable for the users with all the different hardware.

@mraineri

This comment has been minimized.

Copy link

mraineri commented Mar 21, 2019

Since "MACAddress" is the proper name, we really need to push back on vendors who are violating the schema definitions. We don't want to encourage bad behavior by working around these issues in clients.

@panticz

This comment has been minimized.

Copy link
Contributor Author

panticz commented Mar 22, 2019

Hi mraineri, i agree with you that the hardware manufacturers should stick to the Redfish specification, however, this is a purely academic approach. The practice shows us that, at least currently, this is not the case.

Actualy the Redfish module supports a small subset of the Redfish API adapted especially for DELL with is one of the major vendors. In order to make this module usable for the broad masses, it has to be designed more modular with support for different hardware. This module is currently too insignificant to enforce any change to the manufacturers and if its not supports they current APIs implementetions propably never will.

@ansibot ansibot added the stale_ci label Mar 30, 2019

@panticz

This comment has been minimized.

Copy link
Contributor Author

panticz commented Apr 8, 2019

How about case insensitive key parsing? In this case MACAddress and MacAddress will be valid values.

@mraineri

This comment has been minimized.

Copy link

mraineri commented Apr 11, 2019

Discussing this in the group, we still think that the proper thing to do is honor the language of the Redfish specification in that there is a hard rule about following the casing of property names per the schema. We are not in support of bending the rules here to allow for the incorrect MacAddress property.

I would recommend updating the firmware for your system to see if the vendor has fixed it in a subsequent release. If the problem still persists, it would be good to reach out to the vendor for support.

@billdodd

This comment has been minimized.

Copy link
Contributor

billdodd commented Apr 15, 2019

@panticz We found last week that on some HP systems, if the client request does not contain an OData-Version header, the service will return a response with the property named MacAddress. But with the OData-Version header included, it returns the spec conformant MACAddress.

PR #55193 has been merged into the devel branch and updates the Redfish modules to send the OData-Version header in requests.

If you try out the latest devel branch, hopefully, you will see better results for the MACAddress vs. MacAddress issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.