Skip to content
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

fix(types)!: improve types in index.ts #720

Merged
merged 16 commits into from Jun 15, 2020

Conversation

AVaksman
Copy link
Contributor

@AVaksman AVaksman commented Apr 23, 2020

BREAKING CHANGE: cluster.setMetadata(): only node count is updatable on an existing cluster; getInstancesCallback/Response: dropped nextQuery property as it is deprecated for this method, exposed failedLocations property; instance.createCluster(): removed unsupported params serveNodes and defaultStorageType

  • Ensure the tests and linter pass
  • Code coverage does not decrease (if any source code was changed)
  • Appropriate docs were updated (if necessary)

Improve type annotations, some clean up and minor refactoring.

@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Apr 23, 2020
@codecov
Copy link

codecov bot commented Apr 23, 2020

Codecov Report

Merging #720 into master will increase coverage by 0.04%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #720      +/-   ##
==========================================
+ Coverage   99.23%   99.28%   +0.04%     
==========================================
  Files          15       15              
  Lines       15735    15724      -11     
  Branches      953      952       -1     
==========================================
- Hits        15615    15611       -4     
+ Misses        117      110       -7     
  Partials        3        3              
Impacted Files Coverage Δ
src/cluster.ts 100.00% <100.00%> (+0.65%) ⬆️
src/index.ts 100.00% <100.00%> (+0.17%) ⬆️
src/instance.ts 100.00% <100.00%> (+0.17%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 21f8fef...db97e9f. Read the comment docs.

@@ -59,16 +59,21 @@ export type GetClustersCallback = (
clusters?: Cluster[],
apiResponse?: google.bigtable.admin.v2.IListClustersResponse
) => void;
export interface SetClusterMetadataOptions {
nodes: number;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only nodes are updatable in cluster after it's creation

src/cluster.ts Outdated
Comment on lines 417 to 431
if (metadata.location) {
reqOpts.location = Cluster.getLocation_(
this.bigtable.projectId,
metadata.location
);
}

if (metadata.nodes) {
reqOpts.serveNodes = metadata.nodes;
}

if (metadata.storage) {
reqOpts.defaultStorageType = Cluster.getStorageType_(metadata.storage);
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

storage and location can not be updated on an existing cluster

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't tested this or anything, but the docs say that the UpdateCluster rpc accepts a full "Cluster" object: https://cloud.google.com/bigtable/docs/reference/admin/rpc/google.bigtable.admin.v2#google.bigtable.admin.v2.BigtableInstanceAdmin.UpdateCluster-table

Will it return an error if certain fields are attempted to be updated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't return an error,
This change is done to eliminate a possibility of a confusion from the user side if attempted to change a filed that is not supported.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks. I'm not sure we should use the whitelist approach of only allowing "serveNodes", when the API could evolve someday to accept something else, and we'd be blocking it. Does the upstream team know their API docs state multiple unsupported properties can be sent during the UpdateCluster call, and maybe they would want to make it return an error from their end, or some other solution?

We could also throw from our library if we receive unsupported input, but in general, we're best to simply match what the official docs state is supported. As soon as we go off that path, things get shaky.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the upstream team know their API docs state multiple unsupported properties can be sent during the UpdateCluster call

While UpdateCluster rpc does accept a full "Cluster" object, it seems that upstream API docs do specify that among Cluster properties

  • name is an OutputOnly field
  • state is an OutputOnly field as well
  • location is a CreateOnly field
  • default_storage_type is a CreateOnly field as well
  • leaving only serveNodes field that can be updated

when the API could evolve someday to accept something else, and we'd be blocking it

If/when upstream API evolves to accept something else, that logic could be added as a new feature PR?

WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If/when upstream API evolves to accept something else, that logic could be added as a new feature PR?

There's usually a big lag before we notice.

If the upstream API silently drops properties, I would think our best bet is to do the same. In terms of code, let's pass them all through. In terms of types, maybe that's where you could just list "serveNodes"? At least then, if the user knows better and is trying to set a property we haven't added to the types yet, they could have their TypeScript compiler ignore that (I think?).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the logic back, left the types with nodes only.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nextQuery?: {} | null,
response?: google.bigtable.admin.v2.IListInstancesResponse | null
result?: Instance[],
failedLocations?: string[],
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BREAKING CHANGE
exposing failedLocations in the callback/response

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's make sure we add docs for this new response argument.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, an example in the code block showing "if (failedLocations.length > 0) { // These locations contain instances which could not be retrieved. }"

Comment on lines -59 to -65
export interface ClusterInfo {
id?: string;
location?: string;
serveNodes?: number;
nodes?: number;
storage?: string;
defaultStorageType?: number;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BREAKING CHANGE
Removing serveNodes and defaultStorageType as these are expected by GAPIC client, user facing parameters are nodes and storage respectively.

@AVaksman AVaksman added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Apr 24, 2020
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Apr 24, 2020
Copy link
Contributor

@bcoe bcoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think our parser is smart enough for BREAKING CHANGES, to pull in the bullets. So I'd just do:

BREAKING CHANGE: cluster.setMetadata(): only node count is updatable on an existing cluster; getInstancesCallback/Response: dropped nextQuery property as it is deprecated for this method; etc

@JustinBeckwith
Copy link
Contributor

@AVaksman we prolly want to land this before shipping v3, right? Can I trouble you to run through the open PRs and try to get these ready to go?

@AVaksman
Copy link
Contributor Author

AVaksman commented Jun 2, 2020

BREAKING CHANGE:

  • cluster.setMetadata()
    • only node count is updatable on an existing cluster
    • removed location and storage from the params
  • getInstancesCallback/Response
    • exposed failedLocations property that is also returned along with array of Instnaces
    • dropped nextQuery property as it is deprecated for this method
  • createInstance(id, options)
    • made options into a required param as it is not possible to create an instance without providing at least one cluster (part of options param)
  • createCluster
    • removed duplicated, unsupported (by implementation), undocumented params serveNodes and defaultStorageType in favor of nodes and location respectfully

src/cluster.ts Outdated
};

if (metadata.location) {
// eslint-disable-next-line @typescript-eslint/no-explicit-any
if ((metadata as any).location) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the API actually drops these parameters, I think we can skip all of the logic where we worry about formatting them.

src/cluster.ts Outdated
? gaxOptionsOrCallback
: ({} as CallOptions);

const reqOpts: ICluster = {
name: this.name,
serveNodes: metadata.nodes,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is where I think we should pass all user-provided input straight through, as opposed to the whitelist approach where we only recognize certain parameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(mapping metadata.nodes to serveNodes is still good)

Copy link
Contributor Author

@AVaksman AVaksman Jun 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If applicable, user will need to pass
the location as a full path in the form of
projects/<project>/locations/<zone_id>

and a defaultStorageType (not storage) param with a value in upper case characters.

Done

test/cluster.ts Outdated Show resolved Hide resolved
src/index.ts Show resolved Hide resolved
src/index.ts Outdated Show resolved Hide resolved
@AVaksman
Copy link
Contributor Author

@stephenplusplus before merging, does PR description look OK?

BREAKING CHANGE: cluster.setMetadata(): only node count is updatable on an existing cluster; getInstancesCallback/Response: dropped nextQuery property as it is deprecated for this method, exposed failedLocations property; instance.createCluster(): removed unsupported params serveNodes and defaultStorageType

@stephenplusplus
Copy link
Contributor

It looks good to me!

@AVaksman AVaksman merged commit 508d1f9 into googleapis:master Jun 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants