OVGS protobuf changes for performance improvement

[haussli]

Experience has shown that the RTT for GetSerial and GetOwnershipvoucher make the OVGS process rather slow. I am impatient. I would like to improve this.

For example:

• A GetGroup-like RPC that returns all of the GetSerialResponse data. This could be quite large though. Perhaps a streaming version?
• A GetSerial-like RPC that accepts multiple requests at once.
• A GetOwnershipVoucher-like RPC that accepts multiples requests at once.

@harshitk-arista has some ideas too.

[haussli]

From chat, @harshitk-arista said there were no concerns with these.

Any comments from other implementers?

[nick-langford]

If bulk operations are being added then we need to understand the failure conditions:
if one or more operations fail:

• Are partial results returned?
  Is the returned data to indicate the scope of the partial success/failure (i.e. which specific requests failed) along with the results of the successful operations

• Does the whole operation fail ?
  Should one failure cause the whole bulk operation to fail, and will the specific cause of the failure be identified?

Should the failure(s) be in the response message body or the meta data? Nominally I would expect error responses and messages to be in the meta-data but when a bulk operation fails for multiple reasons is the meta-data a suitable place for this. There is likely a standard gRPC standard for this.

---

BTW: What do you see as the benefit to performing bulk operations. Is it the reduction of the number of authorizations required being reduced form N -> 1 or is there another reason. I suspect the amount of data transferred and the level of processing at either end to be similar.

Also what is regarded as slow, wrt OVGS operations?

[haussli]

Hi Nick,
I expect that there will some improvement from a reduction in authorization calls, but I also expect a significant improvement in just RTT from the processes that are singular (eg: getgroup followed by individual calls to retrieve each new component, in the normal update process). For a process that checks inventory, retrieval of each component is slow and significant when the number of components exceeds 10k.

[haussli]

Nick, Great points about the failure mode behavior. It appears that both approaches are common.

These are read-only or ephemeral, so the entire operation failing would be safe, though wasted time.

I prefer to allow individual requests to fail without the entire request failing. Providing feedback about failures in an added google.rpc.Status field(s). A Status field could be added to GetSerialsResponse for the entire response with the Components from GetSerialsRequest that failed returned in the Status.details . Or, the response could be more detailed, returning a Status field for each failed GetSerialResponse, like:

+message GetSerialsResponse {

• // The order of serials must reflect the order of the components in the
• // GetSerialsRequest.
• repeated GetSerialResponse serials = 1;
• repeated google.rpc.Status failures = 2;
  +}

Where each record in failures contains the Component record from the GetSerialsRequest in Status.details.

Is this is a reasonable approach to you?

[nick-langford]

I am not sure I like the way in which the bulk requests responses are being defined.

I believe any bulk request should return data identifying the result of the bulk operation and then hold a list of the results for each operation in the bulk request. For the result of each operation, the data usually held in the meta data, should be included in the individual result data not in a separate list.

[haussli]

Hi Nick, Are you saying that you do not agree with the suggestion of adding a google.rpc.Status per-repeated record? Could you suggest your alternative?