|
|
Post by jkugler on Oct 14, 2022 21:52:15 GMT
Reading over the Redfish specification, I came across this line: www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.16.0.pdf, page 89 Well, that seems to have not been adhered to, as there are names all over the places, such as: where the periods and dashes mess up using those names in Python (and I assume other languages). So, 'NIC.Integrated.1-1-1' violates "naming rules for supported...programming languages." So¸ that brings me to this idea. Do I understand correctly that underscores will NEVER be used in a name, so my Python API could access system_object.Chassis.System_Embedded_1.NetworkAdapters.NIC_Integrated_1.NetworkDeviceFunctionand then my API, behind the scenes, would convert all those underscores to periods as it walks the tree and finds the proper objects? The NIC.Integrated.1-1-1 still presents a problem because dashes are not valid in Python identifiers. I suppose I could get really crazy and make dashes double underscores: NIC_Integrated_1__1__1, and convert __ to -, but that seems a bit excessive. Any better ideas for accessing Redfish names that violate the standard? Thanks! |
|
|
|
Post by jkugler on Oct 15, 2022 0:00:55 GMT
Just discovered another case. Got this as a URL: 'Members': [{'@odata.id': '/redfish/v1/Chassis/1/'}]
I don't know if that technically violates the standard or not, as it's not a "name," but you can't use Chassis.1.blah as an identifier in Python.  |
|
|
|
Post by mraineri on Oct 15, 2022 0:55:36 GMT
Unfortunately that clause you referenced is with regards to property names, like "Name" as a property in a resource. It doesn't cover the value of properties or URI segments; segments like "System.Embedded.1" are values of properties and segments in URIs. Specifically with URI segments, the only rule we have in the Redfish Specification is that RFC1738-defined unsafe characters are not allowed. Characters like "." and "-" are allowed in that RFC. Since these are built from the value of the "Id" property in various resources, the only rules we have here also echo restricting the values to not contain RFC1738-defined unsafe characters. So, while there's nothing in the specification today that disallows what you're seeing, I do see the problem that it's causing for you in some languages. I think this is the first time I've seen someone use the value of a property to walk the model in this manner. Normally I see code that operates on specific selections from a property reference, similar to something like this:
Root.Chassis.Members["Id"=="System.Embedded.1"].NetworkAdapters.Members["Id"=="NIC.Integrated.1"]
I can raise your particular pattern to the rest of the group to see if others have thoughts on this.
|
|
|
|
Post by jkugler on Oct 17, 2022 21:03:37 GMT
Thanks for the clarification. That does make sense. And thanks for the offer to raise the issue. I also thought of this today. Given a URL such as: /redfish/v1/Managers/iDRAC.Embedded.1/EthernetInterfaces/NIC.1Right now, I can get that via: rf_root.Managers.Members[0].EthernetInterfaces.Members[0]Maybe I could have my API respond to this: rf_root.Managers['/iDRAC.Embedded.1'].EthernetInterfaces['/NIC.1']Assumption being: If the subscript is a string starting with a slash it 1) assumes it will be found in the Members collection, and 2) it will be a member that is "below" the current URL in the tree. That feels ugly and elegant all in one. Maybe replacing the underscores is better.  As for your comment: I'm using github.com/xlab-steampunk/redfish-client-python. It is much more OO than any other Python library I've managed to find with most others I've seen just operating on the URIs and not having dynamic object generation at all. That's intriguing. I see that as being a good solution, but unless there are corners of Python I do not know (completely possible) I don't think I could use that in a subscript. Pretty sure "Id"=="System.Embedded.1" would simply evaluate to False, which isn't very useful. As always, thanks for your input! |
|
|
|
Post by mraineri on Oct 27, 2022 17:36:20 GMT
I've had a discussion about this with others. The best course of action at this point would be in the client library to perform character replacements like you thought about earlier. While underscores could be part of URI segments, I don't think you need to be overly cautious with using single underscores vs double underscores; a simple single character replacement should suffice real-world scenarios. So, when the library encounters a name with underscores, it'll need to do some sort of lookup to convert it back to the proper string for URI segment. So, converting something like "NIC.Integrated.1-1-1" to "NIC_Integrated_1_1_1" would be good.
I think if we had considered these types of libraries when Redfish was first being defined, we probably would have been much more firm with regards to URI construction rules and identifiers.
|
|
|
|
Post by jkugler on Oct 27, 2022 17:55:26 GMT
Mike -
Thanks much for the feedback, I do appreciate it.
|
|
|
|
Post by edtanous on Nov 1, 2022 19:08:57 GMT
One very important thing to realize in your implementation is that you're parsing system-specific IDs in your actual code, which for compatibility reasons isn't really something you want to do. Other systems will have VERY different ID topologies compared to what you have above, and if you want to support more than one system-class in redfish, you'll need to adapt to some kind of iteration or filtering of the collections. There is a new specification in process for RedPath, which has a very similar behavior to what you're doing, but very intentionally omits the specific instance IDs, so your code would turn into the equivalent of:
system_object.Chassis[$filterspec].NetworkAdapters[$filterspec].NetworkDeviceFunction
but that would require you in python to overload some of the array subscript parameters rather than solely relying on __attr__ in your classes, but you'll note that there are no specific URI Ids, which would resolve the issue posed above.
|
|
|
|
Post by jkugler on Nov 1, 2022 19:16:30 GMT
Thanks for bringing that up. I have thought about that, and realize I'll mostly likely need to use Member[0] or some such if I want to be cross-vendor in my code. Some of our code attempts to be cross-vendor, other code punts and has vendor-specific branches, so when it's vendor-specific, being able to specify the vendor-specific IDs would be nice.
Either way, we can make it work.
|
|
