This discussion seems to hinge on whichever of the following is most important:

clarity / discreteness:

Have separate gRPC calls for each operation:
- OnlineCPU().
- OnlineMem().
Disadvantages:
- 1 rpc call / resource. That might be a problem if we end up having to support a lot of different resources, all with their own gRPC call.
efficiency:
- OnlineCPUMem().
  
  Bundle functionality together to minimise gRPC calls.
Disadvantages:
- current name precludes supporting additional resources in the future.
- current design is arguably a little confusing in the way it determines which resources need onlining.

Compromise solution?

What about the following:

message OnlineResourcesRequest {

    // Define resources as bit values
    enum Resources {
        OnlineNothing = 0x00; // required by proto3
        OnlineCPU = 0x01;
        OnlineMem = 0x02;
        OnlineFoo = 0x04;
                :
    }

    // Used to determine which Resources need to be onlined.
    //
    // For example, the value 0x05 would be equivalent to (OnlineCPU + OnlineFoo).
    fixed64 ResourceBitfield = 1;

    bool wait = 2;
    uint32 nb_cpus = 3;
    bool cpu_only = 4;
   
    // Future:
    ${type} ${resource} = 5;
        :
}

rpc OnlineResources(OnlineResourcesRequest) returns (google.protobuf.Empty);

Advantages:

Still only requires a single call.
Simple to understand (once you comprehend ResourceBitfield).
Extensible if we need to online other resources in the future.

Disadvantages:

Uses enums which can apparently be problematic.

Whatever we decide, I think we should prefer to focus on clarity unless the alternative is (provably) compelling.

Thoughts

How about we formally review the *.proto files? That would allows use to:

Satisfy ourselves that we're adhering to best practise.
Ensure we're in good shape should future changes be necessary.
Document the protocols more fully as we go (Document all protocol elements #150).

It would be great to get input from some gRPC experts here. This would be a good conversation to have at an Architecture Committee meeting I think.

/cc @jon

Shall we separate onlineCPUMem to onlineCPU and onlineMem #357

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions