|
|
Post by josephreynolds1 on Jan 20, 2020 22:48:08 GMT
The ManagerNetworkProtocol has a SSDP property, to be able to enable or disable SSDP discovery. OpenBMC uses Avahi discovery (https://github.com/openbmc/docs/blob/256050decea920eb99bd297242061a02c871e509/designs/management-console/service_discovery.md). I would like to have a Redfish supported way to disable Avahi discovery. This request is to add Avahi to the ManagerNetworkProtocol.
|
|
|
|
Post by jautor on Jan 27, 2020 19:51:19 GMT
Avahi is name of one software package/implementation of mDNS/DNS-SD, so if we added that to ManagerNetworkProtocol we'd want to name it as "mDNS" or something similar.
But these protocols are all part of the configuration of a Redfish Manager, not a general purpose server/service.
The concern is if we add this to ManagerNetworkProtocol, it would seem to indicate that Redfish supports mDNS/DNS-SD for discovery of Redfish services, which it does not (SSDP is the standard discovery mechanism).
If OpenBMC is attempting to use Avahi for discovery of the service, that would be an implementation-specific service that would not be interoperable. Is there something driving its usage instead of the standard SSDP mechanism?
Jeff
|
|
|
|
Post by josephreynolds1 on Apr 3, 2020 15:14:17 GMT
I see the Redfish spec DSP0266 specifies SSDP for discovery. I had not previously understood that; thank you.
Because of this, I can accept why you don't want to add mDNS to the ManagerNetworkProtocol.
That leaves the option of using ManagerNetworkProtocol.Oem.OpenBMC.mDNS.
If that sounds right to you, the OpenBMC project can implement that property and we can close this discussion.
|
|
|
|
Post by josephreynolds1 on Apr 6, 2020 14:59:03 GMT
|
|
|
|
Post by josephreynolds1 on Apr 7, 2020 15:29:35 GMT
|
|
|
|
Post by josephreynolds1 on Apr 8, 2020 20:22:43 GMT
|
|
|
|
Post by gmills on Apr 16, 2020 20:03:38 GMT
Hi Joseph,
This was discussed on the Redfish call today. Redfish members on the call felt SSDP has wider adaption than mDNS and adding a 2nd discovery service would do a disservice to interoperability. The members on the call really wanted to encourage OpenBMC to implement SSDP instead. I have replied the same on the OpenBMC mailing list.
Thanks,
Gunnar
|
|
|
|
Post by ratagupt on May 4, 2020 14:15:34 GMT
Avahi is name of one software package/implementation of mDNS/DNS-SD, so if we added that to ManagerNetworkProtocol we'd want to name it as "mDNS" or something similar. But these protocols are all part of the configuration of a Redfish Manager, not a general purpose server/service. The concern is if we add this to ManagerNetworkProtocol, it would seem to indicate that Redfish supports mDNS/DNS-SD for discovery of Redfish services, which it does not (SSDP is the standard discovery mechanism). If OpenBMC is attempting to use Avahi for discovery of the service, that would be an implementation-specific service that would not be interoperable. Is there something driving its usage instead of the standard SSDP mechanism? Jeff Jeff,I am confused here, we have configuration for SNMP in Redfish, which is used to manage the server, kind of parallel protocol as redfish as both can be used to manage the server, Now for discovery we have the following protocols 1) SSDP
2) mDNS 3) SLP I am hoping that redfish should have a way to configure all the discovery protocols.It is up to the user whethere they want SSDP/mDNS/SSDP etc.
|
|
|
|
Post by jautor on May 8, 2020 5:44:39 GMT
]Jeff,I am confused here, we have configuration for SNMP in Redfish, which is used to manage the server, kind of parallel protocol as redfish as both can be used to manage the server, Now for discovery we have the following protocols 1) SSDP
2) mDNS 3) SLP I am hoping that redfish should have a way to configure all the discovery protocols.It is up to the user whethere they want SSDP/mDNS/SSDP etc.
SNMP support is common for many devices that also (now) support Redfish - we added the SNMP configuration support because of end user desire to fully configure their systems using one interface (Redfish). We didn't have that in the schema originally because it seemed odd to configure "old" protocols with a new one - but the user feedback showed that it was necessary - because SNMP is going to be around for a long, long time, in parallel with anything we do. The difference for mDNS, as I understand it's use in OpenBMC, is that its purpose is to provide a means of discovery for the BMC. I believe that is unique to the OpenBMC implementation - I'm not aware of any other BMC FW that supports it for that purpose. If that is incorrect, then we should look at it again under ManagerNetworkProtocol (so that it can be configured via Redfish in a standard way). But we don't want to add what would appear to be a "second discovery protocol and method" that would imply a choice for discovery of Redfish-enabled devices - unless that provided some significant improvement in functionality or support in the ecosystem. But we haven't seen anything to suggest that the addition of mDNS would increase interoperability - but rather create a "must implement two" just to get coverage that should have been possible with one of them. And as there are millions of Redfish-enabled devices deployed with the existing SSDP support, it would take years before an alternative discovery protocol would become useful for most customers. It would be much more productive, in my opinion, for OpenBMC to implement the small amount of SSDP necessary to perform Redfish discovery - as that would make it interoperable with all the other Redfish devices. And nothing wrong with OpenBMC continuing to support mDNS for "OpenBMC discovery" and compatibility with its existing ecosystem. Jeff |
|
