|
|
Post by JenHuang on Apr 23, 2020 14:24:57 GMT
There is two properties IPv6StaticAddress and IPv6Addresses in EthernetInterface schema.
Why we need to have the extra property IPv6StaticAddress?
|
|
|
|
Post by mraineri on May 1, 2020 15:11:48 GMT
IPv6StaticAddress is the control surface the client can use to request what the static address should be, whereas the IPv6Addresses property shows the actual address of the interface. The reason we have two properties is in case the static address requested by the user cannot be applied at that time, or if there was some fallback condition where a different address was used. Bundling it into a single property could cause confusion where the client PATCHes it to one value, and comes back 5 minutes later to see something else.
|
|
|
|
Post by magesh on May 5, 2020 6:54:26 GMT
mraineri For your above explanation I think simillar for IPv4 also. It is not advisable to have IPv4Addresses as patchable? If IPv4StaticAddresses fails to set in backend then should we clear IPv4StaticAddresses? Thanks, Magesh
|
|
|
|
Post by mraineri on May 5, 2020 13:47:26 GMT
Yes, the same problem exists for IPv4Addresses, which is why IPv4StaticAddresses was added to version 1.4.0 of the EthernetInterface schema.
I don't think you necessarily need to clear the static addresses property; there could be periodic retry semantics, or simply try to apply the settings again when the interface or device resets.
|
|
|
|
Post by AMI_Mani on May 6, 2020 4:08:23 GMT
Hi,
Thanks for explaining details about IPV4Addresses, IPV6Addresses
As per EthernetInterface.v1_5_1.json we have below details
"IPv4Addresses": {
"description": "The IPv4 addresses currently assigned to this interface.",
"items": {
"$ref": "http://redfish.dmtf.org/schemas/v1/IPAddresses.json#/definitions/IPv4Address"
},
"longDescription": "This property shall contain an array of objects that represent the IPv4 connection characteristics for this interface. It is recommended that this property be regarded as read-only with configuration of static addresses performed by updating the values within IPv4StaticAddessses. Services may reject updates to this array for this reason.",
"type": "array"
}
Clarification based on above schema
1. We don't have Readonly attribute for this attribute in schema and provided details in longdescription as recommended to be Read-only. Do we have any reason for not mentioning ReadOnly as True in schema?
2. If we refer IPAddresses.json(IPAddresses.v1_1_1.json), there address is mentioned as readonly as false for Staticaddress, so patching IPv4Addresses is allowed, please confirm
"Address": {
"description": "The IPv4 address.",
"longDescription": "This property shall contain an IPv4 address assigned to this interface. If DHCPv4 is enabled on the interface, this property becomes read-only.",
"pattern": "^(?:[0-9]{1,3}\\.){3}[0-9]{1,3}$",
"readonly": false,
"type": [
"string",
"null"
]
},
3. If we consider IPv4Addresses as readonly, as per long description It is recommended that this property be regarded as read-only with configuration of static addresses performed by updating the values within IPv4StaticAddessses. Do we need to show only StaticAddresses in IPv4Addresses? If we have DHCPV4 enabled, we can show that IP also in IPv4Addresses. Do we need to change long description to include DHCP also?
Above clarification is applicable for IPV6Addresses also
Thanks,
Mani
|
|
|
|
Post by jautor on May 10, 2020 3:28:44 GMT
Hi, Thanks for explaining details about IPV4Addresses, IPV6Addresses As per EthernetInterface.v1_5_1.json we have below details Clarification based on above schema 1. We don't have Readonly attribute for this attribute in schema and provided details in longdescription as recommended to be Read-only. Do we have any reason for not mentioning ReadOnly as True in schema? It was published originally as "read-write", which was a mistake, but because that was not caught until long after v1.0 was published, it was deemed too late to change it to read-only in the schema as an errata - because by that point, implementations may have been available using it as read-write, so changing that would break compatibility. The best we could do was to add that recommendation to the normative "long description" to guide future implementations to follow the corrected behavior. Same issue as above. We were unable to change that property to read-only as an errata due to compatibility with shipping implementations. You should show the current, in-use IP addresses in the IPv4Addresses and IPv6Addresses objects, regardless of the source of the address (e.g. Static or DHCP). This allows client software to always find the IP addresses in the same place, regardless of configuration. The IPv4StaticAddresses allows configuration of the static address, even if it is not currently in use. Hope that clarifies everything, Jeff |
|
|
|
Post by ginugeorge on Jun 9, 2023 12:25:57 GMT
 As per the schema for Ethernet Interfaces, we see that the IPv4StaticAddresses attribute shall contain an array of objects that represent all IPv4 static addresses assigned to, but not necessarily in use by this interface whereas the IPv4Addresses property shall also list the addresses that this interface uses. Is there any upper limit on the number of Static IPv4 Addresses that can be patched for an Interface (i.e. in other words, is there any upper limit on the number of objects the IPv4StaticAddresses array-type attribute can have) ? Suppose if the user has configured 5 Static IPv4 Addresses for an Interface, and if the user desires to remove 2 Addresses and update 3 of the Addresses from the IPv4StaticAddresses array, what is the request body the user needs to pass ? Does Redfish Service needs to remove all the currently configured IPv4Static Addresses and apply only those that the user has specified in the request body ? |
|
|
|
Post by mraineri on Jun 9, 2023 17:19:01 GMT
It's very much going to depend on what drivers/OS you have running on the system/BMC in question. Most implementations I would expect only support a single IPv4 address on an interface, so I would also expect these implementations to limit the array size to 1.
For the array manipulation portion, it's like every other PATCH request with arrays; you use null in the request to remove a specific array index, an empty object to leave the specific array index alone, and if the user's array is smaller than what's configured the service removes the trailing entries. The "PATCH on array properties" clause in the specification has a good example of how this works.
|
|
