search

openbmc / openbmc-test-automation

Apache License 2.0
100 stars 92 forks source link

dependence on hard-coded Redfish paths that should depend on reading OData #2174

Closed generatz closed 2 years ago

generatz commented 2 years ago

As with issues #2172 and #2173, the terminal elements ('bmc', 'FirmwareInventory', etc.) in these paths should not be hard-coded, but should instead be obtained from the available OData:

There are likely more cases.

Admittedly, it seems that most of these are unlikely to change. However, there may be differences with character case as can be seen with the DTMF mockup 'redfish/v1/Managers/BMC' vs. the hard-coded redfish/v1/Managers/bmc.

In fact, the root paths should probably all be obtained from the OData in the json from the base path redfish/v1/. For example, finding the /redfish/v1/Managers path using the Odata key "Managers" in the /redfish/v1/ json.

Again, see issue #2172 for method to fix.

williamspatrick commented 2 years ago

If the openbmc code itself is planning to use these paths and this repository is to test the openbmc code, does it matter if they are hard-coded? Are you trying to leverage this repository against a non-openbmc product? If so, are you willing to contribute the code to make it more generic?

generatz commented 2 years ago

@williamspatrick You are correct, but are these paths (forever) hard-coded into the openbmc code, and if so, where? I'm guessing that since the DMTF/Redfish schema doesn't hard-code the paths, then some future openbmc developer might assume that they could be changed (especially, given the 'redfish/v1/Managers/BMC' mockup example) and might do so.

williamspatrick commented 2 years ago

The openbmc/bmcweb repo has all the code for our Redfish providers. There are tons of hardcoded strings in there so I think it'd be pretty obvious if someone starts mucking around with it:

$ git grep -i "managers/bmc" | wc -l                
117

TBH, I only looked at this because I've seen a bunch of issue alerts created in the last few days by you. Maybe you're working closely with the maintainers of this repository (I don't recognize your name to know who you work for/with), but generally opening a number of issues with no intention of fixing them isn't really favorable in this community and is likely to just get all your issues ignored.

At least one of the issues I recall was something simple like "your documentation is missing three characters here". It would have been less effort to just contribute the fix rather than open an issue an expect someone else to fix it. Being a partner in development is much more likely to get attention to whatever issues you're having.

generatz commented 2 years ago

@williamspatrick Points taken, thanks. And thanks for pointing me to openbmc/bmcweb. This was a bad call.