nvme_controller_id is a zero-based value. Since a default value for int field is zero, it is hard to distinguish if a client requested to set a controller id to 0, or a value was not specified at all and was set by default to 0. For such a case, optional label was used as outlined in AIP-149.
PciEndpoint was set as REQUIRED to avoid ambiguity. That field is used by all the bridges to create different devices.
Later, if we decide that bridges must be able to allocate values automatically to a PciEndpoint we can mark it as OPTIONAL and this action is treated as backward compatible
We use zero-based values for PciEndpoint fields like virtual_function, based on AIP-149, we should mark those fields with optional label. However, it leads to a linter error complaining on optional label and REQUIRED annotation, despite the fact AIP-149 explicitly allows such a case. As a workaround, all field types within PciEndpoint are changed to google.protobuf.Int32Value.
Used AIPs: 203, 149
Some considerations applied in this patch:
nvme_controller_id
is a zero-based value. Since a default value forint
field is zero, it is hard to distinguish if a client requested to set a controller id to 0, or a value was not specified at all and was set by default to 0. For such a case,optional
label was used as outlined in AIP-149.PciEndpoint
was set asREQUIRED
to avoid ambiguity. That field is used by all the bridges to create different devices.PciEndpoint
we can mark it asOPTIONAL
and this action is treated as backward compatiblePciEndpoint
fields likevirtual_function
, based on AIP-149, we should mark those fields withoptional
label. However, it leads to a linter error complaining on optional label andREQUIRED
annotation, despite the fact AIP-149 explicitly allows such a case. As a workaround, all field types withinPciEndpoint
are changed togoogle.protobuf.Int32Value
.