As discussed with @davepacheco offline, there are a couple renames that might improve clarity within the codebase.
Note: These don't necessarily need to correlate with API changes, but given the combination of internal / external state nexus is handling, it might be worthwhile for readability.
-
Service -> ServiceInstance: Within the DB schema, "Service" currently refers to a single Zone, executing somewhere. However, under some circumstances, "Serivce" can refer to a collection of "Service Instances", where each is interchangeable, but provides redundancy. For example, each of the CRDB frontends acts like an "instance" for a "service". (RFD 248 has more detail).
By naming these "ServiceInstances", the ambiguity is lessened.
-
Instance -> VmInstance: Similarly, the thing called "Instance" in Nexus currently refers to an "Instance of a VM". Given that the word "instance" is useful in other contexts, disambiguating here may be useful too.
As discussed with @davepacheco offline, there are a couple renames that might improve clarity within the codebase.
Note: These don't necessarily need to correlate with API changes, but given the combination of internal / external state nexus is handling, it might be worthwhile for readability.
Service -> ServiceInstance: Within the DB schema, "Service" currently refers to a single Zone, executing somewhere. However, under some circumstances, "Serivce" can refer to a collection of "Service Instances", where each is interchangeable, but provides redundancy. For example, each of the CRDB frontends acts like an "instance" for a "service". (RFD 248 has more detail).
By naming these "ServiceInstances", the ambiguity is lessened.
Instance -> VmInstance: Similarly, the thing called "Instance" in Nexus currently refers to an "Instance of a VM". Given that the word "instance" is useful in other contexts, disambiguating here may be useful too.