Summary
ComputeInstanceState_COMPUTE_INSTANCE_STATE_UNSPECIFIED and ClusterState_CLUSTER_STATE_UNSPECIFIED (proto3 zero-values, fulfillment-service/proto/public/osac/public/v1/{compute_instance_type,cluster_type}.proto) are both documented only as:
Unspecified indicates that the state is unknown.
This doesn't say whether "unknown" means "transient, not yet observed" or "a genuine anomaly," leaving each API consumer to guess.
Observed behavior
Get/List on a freshly-created ComputeInstance or Cluster returns _UNSPECIFIED for a real window (measured ~3-5s in our environment) between object creation and osac-operator's first reconcile pass, before any real state is set. This is normal, not an error.
Impact
A downstream DCM service provider (dcm-project/osac-service-provider) mapped _UNSPECIFIED to a generic "ambiguous state" default and reported it as FAILED, per its status-reporting contract's guidance to "default to FAILED if functionality is impaired." Since this window occurs on every single Create, every VM/Cluster showed a false FAILED immediately after creation, self-correcting seconds later.
Ask
Document the enum's temporal semantics explicitly, e.g.:
- Clarify in the proto comment that
_UNSPECIFIED is expected before the first reconcile and should be treated as in-progress/pending, not failed.
- Alternatively (or additionally), consider having the reconciler stamp an initial non-zero state (e.g.
STARTING/PROGRESSING) synchronously before the object is ever visible via Get, closing the race at the source.
Evidence
Measured live against a real fulfillment-service/osac-operator pair: state observed as _UNSPECIFIED-equivalent at T+0.1s and T+2.6s after Create, self-corrected to a real state by T+5.2s.
Summary
ComputeInstanceState_COMPUTE_INSTANCE_STATE_UNSPECIFIEDandClusterState_CLUSTER_STATE_UNSPECIFIED(proto3 zero-values,fulfillment-service/proto/public/osac/public/v1/{compute_instance_type,cluster_type}.proto) are both documented only as:This doesn't say whether "unknown" means "transient, not yet observed" or "a genuine anomaly," leaving each API consumer to guess.
Observed behavior
Get/Liston a freshly-createdComputeInstanceorClusterreturns_UNSPECIFIEDfor a real window (measured ~3-5s in our environment) between object creation andosac-operator's first reconcile pass, before any real state is set. This is normal, not an error.Impact
A downstream DCM service provider (
dcm-project/osac-service-provider) mapped_UNSPECIFIEDto a generic "ambiguous state" default and reported it asFAILED, per its status-reporting contract's guidance to "default to FAILED if functionality is impaired." Since this window occurs on every single Create, every VM/Cluster showed a falseFAILEDimmediately after creation, self-correcting seconds later.Ask
Document the enum's temporal semantics explicitly, e.g.:
_UNSPECIFIEDis expected before the first reconcile and should be treated as in-progress/pending, not failed.STARTING/PROGRESSING) synchronously before the object is ever visible viaGet, closing the race at the source.Evidence
Measured live against a real
fulfillment-service/osac-operatorpair: state observed as_UNSPECIFIED-equivalent at T+0.1s and T+2.6s after Create, self-corrected to a real state by T+5.2s.