-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add support for Managed Autoscaler #2624
Conversation
claire921
commented
Sep 14, 2023
•
edited by arpan14
Loading
edited by arpan14
- Add the ability to create / update an instance with autoscaling config
- Note that now user can only specify one of the node_count, processing_units or autoscaling_config as the compute capacity for an instance.
- Add the ability to see autoscaling config with an instance
Warning: This pull request is touching the following templated files:
|
google-cloud-spanner/src/main/java/com/google/cloud/spanner/InstanceInfo.java
Show resolved
Hide resolved
google-cloud-spanner/src/main/java/com/google/cloud/spanner/InstanceInfo.java
Show resolved
Hide resolved
if (info.getAutoscalingConfig() != null) { | ||
return new InstanceField[] {DISPLAY_NAME, AUTOSCALING_CONFIG, LABELS}; | ||
} else if (info.getNodeCount() > 0) { | ||
return new InstanceField[] {DISPLAY_NAME, AUTOSCALING_CONFIG, NODE_COUNT, LABELS}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this array contain both NODE_COUNT
and AUTOSCALING_CONFIG
? It should contain just NODE_COUNT
? Could you check if any unit tests broke here or this was a silent error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you switch from an autoscaler instance to a non-autoscaler instance, the backend requires both the autoscaling_config and node_count field masks to make sure the intention is to clear the autoscaling_config and set a node_count.
LMK if there is a better alternative for this approach; otherwise I can add a comment for this to make it less confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few edge cases and open question here:
- when
getAutoscalingConfig != null
, we are updating justAUTOSCALING_CONFIG
. Shouldn't we have checks to includeNODE_COUNT
andPROCESSING_UNITS
(to be set to 0) ? - If
getNodeCount > 0
, we are updating justNODE_COUNT
. What if an instance already hadPROCESSING_UNITS
? I assume the backend will throw a validation error. Similar question for theelse
condition. - If we are not marking
PROCESSING_UNITS
orNODE_COUNT
as 0 in the second check, then why are we explicitly markingAUTOSCALING_CONFIG
as null?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For #1, customers can only autoscaling_config once autoscaler is enabled. node_count and processing_units are output_only params. An instance can still have node_count and processing_units, it is just customers cannot modify them. This is consistent with CBT autoscaling API: https://screenshot.googleplex.com/6mi2r2QUKMfTk7x
For #2, this seems to be the logic before the autoscaler related changes. My understanding is that this method is to provide a default field mask when user did not specify one. I'm not sure why we did this in the first place -- as you pointed out, if an instance is specified with both nodes and processing units, this can be wrong. I'm following an existing pattern here.
For #3, if the autoscaling_config is not null, that means this is an autoscaler instance, and users should not specify processing_units or node_count as part of the field mask. If it is null, then the user intention will be to update a non-autoscaling instance.
google-cloud-spanner/src/main/java/com/google/cloud/spanner/InstanceInfo.java
Show resolved
Hide resolved
@@ -193,9 +193,18 @@ public Operation fromProto(Operation proto) { | |||
@Override | |||
public OperationFuture<Instance, CreateInstanceMetadata> createInstance(InstanceInfo instance) | |||
throws SpannerException { | |||
boolean valid_capacity_with_autoscaling = | |||
instance.getAutoscalingConfig() != null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this validation just specific to createInstance
RPC? What about other RPCs ? I am wondering if these validations are better suited when we invoke setAutoscalingConfig
method than within RPC.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, how are such validations supported in auto-generated languages (for ex - Golang) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this validation just specific to createInstance RPC? What about other RPCs ? I am wondering if these validations are better suited when we invoke setAutoscalingConfig method than within RPC.
When they updateInstance, they should also only specify one of the PU, nodes or autoscaling config.
The check was here before so I modified it to take autoscaling config into account, but I can move it to another place if that makes more sense.
Also, how are such validations supported in auto-generated languages (for ex - Golang) ?
So the backend will do the validation check any way, so if it is auto-generated languages, it will be rejected by the backend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, let's get rid of the validation all together and rely on the backend validation. Some simpler validation on primitive types can be considered to be moved to the protos. This in general is preferred since we are gradually moving in a direction on how we can simplify our handwritten clients (similar to our auto-generated clients). So, this would be a step in that direction.
No region tags are edited in this PR.This comment is generated by snippet-bot.
|
google-cloud-spanner/src/test/java/com/google/cloud/spanner/InstanceAdminClientImplTest.java
Outdated
Show resolved
Hide resolved
import com.google.cloud.spanner.IntegrationTestEnv; | ||
import com.google.cloud.spanner.Options; | ||
import com.google.cloud.spanner.ParallelIntegrationTest; | ||
import com.google.cloud.spanner.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert this change and bring back the full imports. I think this could be an IDE setting which might be automatically opimizing the imports. You may need to switch off this IDE setting. Reference - https://www.jetbrains.com/help/idea/creating-and-optimizing-imports.html#optimize-imports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted.
google-cloud-spanner/src/test/java/com/google/cloud/spanner/it/ITInstanceAdminTest.java
Show resolved
Hide resolved
google-cloud-spanner/src/test/java/com/google/cloud/spanner/InstanceTest.java
Show resolved
Hide resolved
if (info.getAutoscalingConfig() != null) { | ||
return new InstanceField[] {DISPLAY_NAME, AUTOSCALING_CONFIG, LABELS}; | ||
} else if (info.getNodeCount() > 0) { | ||
return new InstanceField[] {DISPLAY_NAME, AUTOSCALING_CONFIG, NODE_COUNT, LABELS}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few edge cases and open question here:
- when
getAutoscalingConfig != null
, we are updating justAUTOSCALING_CONFIG
. Shouldn't we have checks to includeNODE_COUNT
andPROCESSING_UNITS
(to be set to 0) ? - If
getNodeCount > 0
, we are updating justNODE_COUNT
. What if an instance already hadPROCESSING_UNITS
? I assume the backend will throw a validation error. Similar question for theelse
condition. - If we are not marking
PROCESSING_UNITS
orNODE_COUNT
as 0 in the second check, then why are we explicitly markingAUTOSCALING_CONFIG
as null?
google-cloud-spanner/src/test/java/com/google/cloud/spanner/InstanceAdminClientImplTest.java
Show resolved
Hide resolved
google-cloud-spanner/src/test/java/com/google/cloud/spanner/InstanceAdminClientImplTest.java
Show resolved
Hide resolved
google-cloud-spanner/src/test/java/com/google/cloud/spanner/InstanceAdminClientImplTest.java
Show resolved
Hide resolved
.build())) | ||
.thenReturn(rawOperationFuture); | ||
InstanceInfo instanceInfo = | ||
InstanceInfo.newBuilder(InstanceId.of(INSTANCE_NAME)) | ||
.setInstanceConfigId(InstanceConfigId.of(CONFIG_NAME)) | ||
.setNodeCount(3) | ||
.setProcessingUnits(3000) | ||
.setAutoscalingConfig(getAutoscalingConfigProto()) | ||
.build(); | ||
OperationFuture<Instance, UpdateInstanceMetadata> operationWithFieldMask = | ||
client.updateInstance(instanceInfo); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Can we add more assertions on what we expect the node count, processing unit and autoscaling config to contain, similar to how we are asserting
INSTANCE_NAME
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same above.
OperationFuture<Instance, UpdateInstanceMetadata> operationWithFieldMask = | ||
client.updateInstance(instanceInfo); | ||
assertTrue(operationWithFieldMask.isDone()); | ||
assertEquals(INSTANCE_NAME, operationWithFieldMask.get().getId().getName()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add more assertions on fields being updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same above
OperationFuture<Instance, UpdateInstanceMetadata> operation = | ||
client.updateInstance(instanceInfo); | ||
assertTrue(operation.isDone()); | ||
assertEquals(INSTANCE_NAME, operation.get().getId().getName()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add few more assertions on value of nodecount, processing units and autoscaling config. Applicable at other tests as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The assertions are probably not needed, because we mock the RPC to return an instance only with processing_units: https://screenshot.googleplex.com/7fF5jTJZ8hbQ2nn. So if we add assertions, the assertions will only be to test the mocking of the RPC, instead of the actual code.
🤖 I have created a release *beep* *boop* --- ## [6.52.0](https://togithub.com/googleapis/java-spanner/compare/v6.51.0...v6.52.0) (2023-10-19) ### Features * Add support for Managed Autoscaler ([#2624](https://togithub.com/googleapis/java-spanner/issues/2624)) ([e5e6923](https://togithub.com/googleapis/java-spanner/commit/e5e6923a351670ab237c411bb4a549533dac1b6b)) --- This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).