|
|
Post by paligill on Aug 16, 2024 21:19:10 GMT
Hi
In LogService schema i don't see a way one can specify which host or instance to target in case of multi host scenarios or in case multiple instances of a device exists? Is this somehow possible?
Regards
|
|
|
|
Post by mraineri on Aug 19, 2024 13:07:15 GMT
In that case, if the log service is for host or some other non-manager entity, you should use the LogServices property on the appropriate resource. So, for a multi-host type of design, you can stick logs specific to that host under /redfish/v1/Systems/{SystemId}/LogServices. That way it's placement in the tree gives the user the context for what the log is used for.
Keep in mind, even if the log physically resides on the BMC, it doesn't necessarily need to be placed under /redfish/v1/Managers/{ManagerId}/LogServices. If the intent of the log is for another device, you should surface it elsewhere in the tree based on the functional usage (like under the ComputerSystem resource for system logs).
|
|
|
|
Post by paligill on Aug 22, 2024 22:24:30 GMT
Thanks for the response. The device of intent is NIC but while checking the EthernetInterface schema i don't see any references to LogService redfish.dmtf.org/schemas/v1/EthernetInterface.json. On the other discussion thread (https://redfishforum.com/thread/1081/logservice-entry-nic-logdiagnosticdatatypes) you mentioned that original use cases for data collection were only for BMC, OS and Pre-OS. Do you think it would be possible to extend this use case to NIC as well? (At Meta we have a use case to collect diagnostic data for NIC too) |
|
|
|
Post by mraineri on Aug 23, 2024 12:10:47 GMT
Got it. Unfortunately there isn't anything standard I can recommend at the moment. I'll raise this to the group to discuss further.
|
|
|
|
Post by jagpalgill on Sept 25, 2024 17:38:10 GMT
Would LogService be updated to include/support EthernetInterface URIs?
|
|
|
|
Post by mraineri on Sept 27, 2024 19:04:54 GMT
There hasn't been a formal decision on the direction, but that's technically one path we could go. However, I'd imagine that could be quite intrusive to the model to have LogService resources everywhere potentially, but this is just my opinion.
|
|
