|
Post by malbolge on Mar 3, 2023 23:18:39 GMT
1. Suppose a schema defines a property as RW. But we don't support writes on that property for some reason. Or we support it in the Settings version of that schema. Either way, you open this Resource up, you see a true, put a false, and it don't work.
1A Is it allowed for the RDE device to implement an RW property as RO? 1B Should the RDE device mark the writeable flag in output BEJ as false? 1C Should the RDE device dictionary have the writeable flag for this property as false? 1D In the case that a property that is RW in schema is implemented as RO in code, does the RDE device need to send any ADDITIONAL or DIFFERENT annotations compared to when the client would try to write a RO property? 1D In the case that a property that is RW in schema is implemented as RO in code, does the RDE device need to do anything else it wouldn't do compared to when the client would try to write a RO property?
2. How about nullable?
3. Cacheable?
|
|
|
Post by mraineri on Mar 6, 2023 13:55:13 GMT
I'm going to respond to this in the mindset of a Redfish service since the same topics apply, and I would expect the same behaviors in RDE devices.
1A: You're certainly allowed to make a writable property read-only. Redfish services are allowed to do this, so there shouldn't be any reason an RDE device couldn't also do this. 1B: I'll say that I'm not familiar enough with the payload transport of RDE devices to know for sure, but I would assume that yes, you can change that flag. 1C: Given that the Redfish Specification does allow for local copies of schemas to be modified in certain manners (such as changing a writable property to read-only), I would expect the same thing should be allowed for dictionaries. The "Schema modification rules" clause of the Redfish Specification calls out what is allowed to be modified. 1D: You don't NEED to do anything different, but there was a payload annotation added to the specification recently for this very scenario. The "Writeable properties annotation" (which appears in payloads as @redfish.WriteableProperties) lists out the properties the service (or in this case the RDE device) supports write operations on. 1E: No, you'd handle it like any other read-only property; you'd reject modification requests to it and state that the property is read-only.
2: Do you have a specific scenario in mind for null? Null is almost always reserved for cases where a service cannot determine the value of the property at that time, so it provides null back to the user. I would not expect null to be given by a client (and if they did I would expect the request to be rejected). So, I don't think there's anything necessary to do in this case.
3: This may be very specific to RDE since this topic does not come up with a Redfish service (at least not beyond normal HTTP cache policies shown in response headers).
|
|
|
Post by malbolge on Mar 8, 2023 21:16:43 GMT
Thanks for your reply! 1B: I'll say that I'm not familiar enough with the payload transport of RDE devices to know for sure, but I would assume that yes, you can change that flag. The RDE device developers can change the flag, and it doesn't seem to do anything. I think BMCs don't use it for anything right now. BejTupleF format exists in both BEJ output and the dictionary. As do both flags. [7:4] - principal data type; see Table 9 below for values [3] - reserved flag. 1b indicates the flag is set [2] - nullable_property flag ***. 1b indicates the flag is set [1] - read_only_property_and_top_level_annotation flag **. 1b indicates the flag is set [0] - deferred_binding flag *. 1b indicates the flag is set With the flags being duplicated in dictionary and BEJ output, I thought that the dictionary ought to contain RW/RO bits as in the schema, whereas BEJ output would contain the ACTUAL RW/RO status, under the assumptions that the duplicate presence of these flags is deliberate and allows for some precision metadata descriptors. Perhaps the intended behavior is that both the dictionary and BEJ output should always expose the same bits on the same properties and the redundancy is accidental. One thing that RDE next should probably clarify. 1C: Given that the Redfish Specification does allow for local copies of schemas to be modified in certain manners (such as changing a writable property to read-only), I would expect the same thing should be allowed for dictionaries. The "Schema modification rules" clause of the Redfish Specification calls out what is allowed to be modified. Makes sense, thanks! 1D: You don't NEED to do anything different, but there was a payload annotation added to the specification recently for this very scenario. The "Writeable properties annotation" (which appears in payloads as @redfish.WriteableProperties) lists out the properties the service (or in this case the RDE device) supports write operations on. Makes sense for Redfish, where JSON is all you get. But for RDE, the BMC has access to the dictionary and BEJ, which encodes this metadata. I guess no introspection/reflection of dictionaries by the BMC (for purpose of autogenerating these annotations) is planned? Still the RDE device's job, even if this data is technically available to BMC? 2: Do you have a specific scenario in mind for null? Null is almost always reserved for cases where a service cannot determine the value of the property at that time, so it provides null back to the user. I would not expect null to be given by a client (and if they did I would expect the request to be rejected). So, I don't think there's anything necessary to do in this case. My understanding was that nullable: 1) For RO, this value may return a Null when data isn't available, such as Null optical module for a network card with an empty cage 2) For RW, that the user may literally put in a Null value which is meaningfully different from 0 - say VLAN tag 0 or 1 meaning tag packets with 0 or 1, vs Null meaning don't tag them at all However, suppose we have a network card where the module is by design welded into the cage (or otherwise tightly integrated) and non-user-removable / non-user-serviceable. It shouldn't ever return a null. The user shouldn't ever need to be prepared to service a null, or expect one. 3: This may be very specific to RDE since this topic does not come up with a Redfish service (at least not beyond normal HTTP cache policies shown in response headers). You're right, cacheable is actually per-Resource not per-property.
|
|
|
Post by mraineri on Mar 9, 2023 14:26:30 GMT
1B: I'll say that I'm not familiar enough with the payload transport of RDE devices to know for sure, but I would assume that yes, you can change that flag. The RDE device developers can change the flag, and it doesn't seem to do anything. I think BMCs don't use it for anything right now. BejTupleF format exists in both BEJ output and the dictionary. As do both flags. [7:4] - principal data type; see Table 9 below for values [3] - reserved flag. 1b indicates the flag is set [2] - nullable_property flag ***. 1b indicates the flag is set [1] - read_only_property_and_top_level_annotation flag **. 1b indicates the flag is set [0] - deferred_binding flag *. 1b indicates the flag is set With the flags being duplicated in dictionary and BEJ output, I thought that the dictionary ought to contain RW/RO bits as in the schema, whereas BEJ output would contain the ACTUAL RW/RO status, under the assumptions that the duplicate presence of these flags is deliberate and allows for some precision metadata descriptors. Perhaps the intended behavior is that both the dictionary and BEJ output should always expose the same bits on the same properties and the redundancy is accidental. One thing that RDE next should probably clarify. It's still a bit over my head, but I at least think it's something the RDE folks should address. 1D: You don't NEED to do anything different, but there was a payload annotation added to the specification recently for this very scenario. The "Writeable properties annotation" (which appears in payloads as @redfish.WriteableProperties) lists out the properties the service (or in this case the RDE device) supports write operations on. Makes sense for Redfish, where JSON is all you get. But for RDE, the BMC has access to the dictionary and BEJ, which encodes this metadata. I guess no introspection/reflection of dictionaries by the BMC (for purpose of autogenerating these annotations) is planned? Still the RDE device's job, even if this data is technically available to BMC? There is a supplemental schema from Redfish that expresses all of the payload annotation. The RDE dictionary tool does process this file and generates a dictionary called "annotation.bin". So, you should be able to use this to include these terms to convey capabilities to the BMC (and the external user); however, I'm not familiar with how the mechanics of this working with RDE are, but it should be possible. 2: Do you have a specific scenario in mind for null? Null is almost always reserved for cases where a service cannot determine the value of the property at that time, so it provides null back to the user. I would not expect null to be given by a client (and if they did I would expect the request to be rejected). So, I don't think there's anything necessary to do in this case. My understanding was that nullable: 1) For RO, this value may return a Null when data isn't available, such as Null optical module for a network card with an empty cage 2) For RW, that the user may literally put in a Null value which is meaningfully different from 0 - say VLAN tag 0 or 1 meaning tag packets with 0 or 1, vs Null meaning don't tag them at all However, suppose we have a network card where the module is by design welded into the cage (or otherwise tightly integrated) and non-user-removable / non-user-serviceable. It shouldn't ever return a null. The user shouldn't ever need to be prepared to service a null, or expect one. I don't think that would apply here. In Redfish, we don't have that sort of concept to clear a value with "null" (with some exceptions specifically called out in the specification). Specifically for that VLAN case, we have the VLANEnabled flag to signify whether to use VLAN tagging, which sits at the same level as VLANId. So, a user would set VLANEnabled to false, and not even touch VLANId. I would expect VLANId to retain the last value it was configured, so if a user flips the switch on VLANEnabled, it will tag with the last VLANId configured. We use this same pattern elsewhere in the model to avoid clients providing null for property values.
|
|