|
|
Post by AMI_Mani on Mar 24, 2022 18:47:39 GMT
Hi,
As per Properties overview we need to provide value as null for supported property in Get response, but in next point it's mention to omit values
Resource instances should omit properties if the underlying product, service, or current configuration does not
provide the function described by the property.
I have many properties depends on another resource(s) which won't populate value always, if I need to populate all attributes with null value, it will increase response size and many attributes with null value in response.
So I'm removing the null value attributes from Get response. But if the attribute is patchable, I'm populating that attribute with null value in get response so that user can know property exists and patch to that property. Please let me know whether we can remove null value attributes(Read only as true) from get response
Copied Property Overview for reference
9.6.1 Properties overview
Every property included in a Redfish response payload shall be defined in the schema for that resource. The
following attributes apply to all property definitions:
• Property names in the request and response payload shall match the casing of the Name attribute value in the
defining schema.
• Required properties shall always be returned in a response.
• Properties not returned from a GET operation indicate that the property is not supported by the implementation,
or by that particular resource instance. Differences in underlying product support or configuration varies among
resource instances, and therefore the properties returned by each instance vary accordingly.
• If an implementation supports a property, it shall always provide a value for that property. If a value is unknown
at the time of the operation due to an internal error, or inaccessibility of the data, the value of null is an
acceptable value if supported by the schema definition.
• Resource instances should omit properties if the underlying product, service, or current configuration does not
provide the function described by the property. For example, a chassis resource instance might not provide a
serial number, and therefore should omit the SerialNumber property, while other chassis resource instances
that have a serial number provide this property. See the Special resource situations clause for handling special
resource situations.
• A service may implement a writable property as read-only.
Thanks,
Mani
|
|
|
|
Post by mraineri on Mar 24, 2022 21:02:41 GMT
Generally speaking, the usage of null is really meant for cases where it's expected that the service will provide real data for a property, but cannot at this time. Can you give some examples for the case you have in mind? It's not clear to me if it's appropriate to remove those properties.
|
|
|
|
Post by jautor on Mar 25, 2022 15:02:53 GMT
Can you give an example of a PATCH-able property that you believe returns NULL but would be usable by a client? The null return is for "internal errors" or "temporarily unavailable data" cases. If you support a property, but it only makes sense in some configurations, you should just omit the property. If the configuration changes (perhaps affecting multiple resources), then those properties would show up, and be populated with real data.
We want you to populate the properties you support so that clients can discover the support - but we don't want to confuse clients by showing properties that are not applicable to a particular instance.
For example, if you support the "IntrusionDetection" feature generally, but a particular product/model doesn't have that hardware, you shouldn't report that property - because the lack of data isn't due to an error condition, nor can the user "do anything about it". Having that property showing up, and always have a NULL value doesn't help anyone, may cause confusion, and just wastes bytes and processing time...
Jeff
|
|
|
|
Post by AMI_Mani on Mar 25, 2022 17:39:31 GMT
Hi,
LDAP in accounservice is patchable and in get response it will be shown as null, so that user knows this property is supported
Assume IPV4 can be disabled by option in BMC, so showing all IPV4 properties in get response with null value wastes bytes and processing time. This is similar to If you support a property, but it only makes sense in some configurations, you should just omit the property. If the configuration changes (perhaps affecting multiple resources), then those properties would show up, and be populated with real data.
Similarly Storage devices can be added, removed and it's not necessary to show all properties as Null since some attribute specific to devices
Can we omit properties like above use cases in Get response even though property is supported, but it will shown in get response based on configuration, availability
Thanks,
Mani
|
|
|
|
Post by mraineri on Mar 25, 2022 17:47:25 GMT
For LDAP, I would not expect the property to be null. That would indicate to the user that there is some LDAP support, but the service is unable to tell you what the configuration is at this time. In addition, showing null doesn't let the client know what they can configure. The properties are very relevant to the client in terms of making decisions on how to configure the feature. Clients might want to configure role mapping, the service addresses, and other properties within LDAP prior to changing "ServiceEnabled" from false to true to ensure the functionality is configured as they expect.
For Storage, this is a very different condition. There is nothing that a client can do via Redfish to enable functionality. For example, if a drive is absent, the Drive resource will show "State" as "Absent", and many properties omitted in this case since it's not possible to convey any additional information.
|
|
|
|
Post by AMI_archerwen on May 4, 2022 8:18:52 GMT
Hi,
So which example you more prefer when user didn't set anything for AD or LDAP?
Ex1 (Not display the properties except array type):
{
"@odata.context": "/redfish/v1/$metadata#AccountService.AccountService",
"@odata.etag": "\"1651646520\"",
"@odata.id": "/redfish/v1/AccountService",
"@odata.type": "#AccountService.v1_6_0.AccountService",
"AccountLockoutCounterResetAfter": 30,
"AccountLockoutCounterResetEnabled": true,
"AccountLockoutDuration": 30,
"AccountLockoutThreshold": 5,
"Accounts": {
"@odata.id": "/redfish/v1/AccountService/Accounts"
},
"ActiveDirectory": {
"Authentication": {
"AuthenticationType": null,
"Password": null,
"Username": ""
},
"RemoteRoleMapping": [
null,
null,
null,
null,
null
],
"ServiceEnabled": false
},
"AdditionalExternalAccountProviders": {
"@odata.id": "/redfish/v1/AccountService/ExternalAccountProviders"
},
"AuthFailureLoggingThreshold": 3,
"Description": "Redfish User Accounts",
"Id": "AccountService",
"LDAP": {
"Authentication": {
"AuthenticationType": null,
"Password": null,
"Username": ""
},
"LDAPService": {
"SearchSettings": {
"BaseDistinguishedNames": [
null
],
"GroupNameAttribute": null,
"GroupsAttribute": null,
"UsernameAttribute": null
}
},
"RemoteRoleMapping": [
null,
null,
null,
null,
null
],
"ServiceAddresses": [
null
],
"ServiceEnabled": false
},
"LocalAccountAuth": "LocalFirst",
"MaxPasswordLength": 20,
"MinPasswordLength": 8,
"Name": "Account Service",
"Oem": {
"Ami": {
"@odata.type": "#AMIAccountService.v1_0_0.AMIAccountService",
"Configuration": {
"@odata.id": "/redfish/v1/AccountService/Oem/Ami/Configurations"
}
}
},
"PrivilegeMap": {
"@odata.id": "/redfish/v1/Registries/Redfish_1.0.3_PrivilegeRegistry.json"
},
"Roles": {
"@odata.id": "/redfish/v1/AccountService/Roles"
},
"ServiceEnabled": true,
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
Ex2 (Display empty string "" for properties except array type):
{
"@odata.context": "/redfish/v1/$metadata#AccountService.AccountService",
"@odata.etag": "\"1651646520\"",
"@odata.id": "/redfish/v1/AccountService",
"@odata.type": "#AccountService.v1_6_0.AccountService",
"AccountLockoutCounterResetAfter": 30,
"AccountLockoutCounterResetEnabled": true,
"AccountLockoutDuration": 30,
"AccountLockoutThreshold": 5,
"Accounts": {
"@odata.id": "/redfish/v1/AccountService/Accounts"
},
"ActiveDirectory": {
"Authentication": {
"AuthenticationType": "",
"Password": "",
"Username": ""
},
"RemoteRoleMapping": [
null,
null,
null,
null,
null
],
"ServiceEnabled": false
},
"AdditionalExternalAccountProviders": {
"@odata.id": "/redfish/v1/AccountService/ExternalAccountProviders"
},
"AuthFailureLoggingThreshold": 3,
"Description": "Redfish User Accounts",
"Id": "AccountService",
"LDAP": {
"Authentication": {
"AuthenticationType": "",
"Password": "",
"Username": ""
},
"LDAPService": {
"SearchSettings": {
"BaseDistinguishedNames": [
null
],
"GroupNameAttribute": "",
"GroupsAttribute": "",
"UsernameAttribute": ""
},
"RemoteRoleMapping": [
null,
null,
null,
null,
null
],
"ServiceAddresses": [
null
],
"ServiceEnabled": false
},
"LocalAccountAuth": "LocalFirst",
"MaxPasswordLength": 20,
"MinPasswordLength": 8,
"Name": "Account Service",
"Oem": {
"Ami": {
"@odata.type": "#AMIAccountService.v1_0_0.AMIAccountService",
"Configuration": {
"@odata.id": "/redfish/v1/AccountService/Oem/Ami/Configurations"
}
}
},
"PrivilegeMap": {
"@odata.id": "/redfish/v1/Registries/Redfish_1.0.3_PrivilegeRegistry.json"
},
"Roles": {
"@odata.id": "/redfish/v1/AccountService/Roles"
},
"ServiceEnabled": true,
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
|
|
|
|
Post by mraineri on May 5, 2022 0:53:04 GMT
Example 2 would be the preferred method. Keep in mind though, the "Password" properties are always expected to be null in responses per their long description. Echoing back a password is a security concern, but we need to show that the property for the password is supported. Some of the properties you have shown with empty strings are also enumerations, so it's expected the service will have some default value for those properties (such as AuthenticationType).
|
|
