You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Grpc is a rpc mechanism implemented by google. This is known for being light weight. This uses http/2 with binary encoding for messages. It is recognized for being able to deliver higher message rates which will give a big boost to delivering events to north bound event subscribers esp. telemetry events. There is also wide adaptation in the industry which will aid in integrations with third party products. In ODIM we think this might be required in four areas

  1. A grpc version of redfish API exposed to north bound clients
  2. Event streaming to clients subscribed to event service
  3. Inter micro service communication within ODIMRA using grpc
  4. Plugin communication with managed devices. These devices are ones which expose a grpc API.

Note:

For #c above is being worked on currently in ODIM project as a replacement to go-micro. As discussed earlier go-micro pins us to go language only implementation of micro services. A work around would be to implement go language side cars which talk to the micro service implemented using other languages using say a http/s interface. However we still cannot use go-micro as it has moved from an apache license to a non-favorable license.

For #d above as there is no restrictions on the south bound API the plugin has to use we leave it upto the plugin implementer to use grpc as and when needed. This will not impact the overall ODIM project.

The BMC implementers are not too keen to support grpc as it is seen as heavy weight

Support for the northbound interface

  1. All the grpc requests will terminate on the API service(svc-api)
  2. svc-api will be talking to the other microservices using grpc shortly as mentioned in the note above.
  3. Adding support for grpc will require
    • Proto definitions for the redfish APIs
    • Implement stubs that will invoke current redfish API handlers in the ODIM Resource Aggregator

Open questions about the new development.

  • There will be a large number of Redfish APIs that need to be supported. So do we define
    1. a proto file per Resource URI ?
      1. this is going to be a lot of work for ODIM
    2. a single proto that embeds all the resource request ?
  • How feasible would it be to auto generate the proto files for each resource using a tool?
    1. This tool could potentially take the schema files as input and auto generate proto files
    2. grpc provides a proto compiler that can generate stubs from these proto file
  • How do we handle the different versions of the resource schemas?
    1. Redfish defines newer version about three times a year

Support for the event/telemetry report delivery

Using grpc streaming of events/telemetry reports to subscribers of the same.

Open questions

  • Should the plugin stream the events to clients directly or should the event service do this?
    1. If we send it via the event service we can leverage existing functionality like filtering and subscription based forwarding.
  • No labels