Shouldn't Cluster.hdd_bytes and Cluster.ssd_bytes be in a oneof block? about java-bigtable-hbase HOT 7 CLOSED

/cc @tseaver @jgeewax

from java-bigtable-hbase.

/cc @coryoconnor @carterpage @maxluebbe -- Can a Bigtable cluster have both hdd_bytes and ssd_bytes ? I'd think no, and that these below in a one-of (union) like @dhermes is saying.

from java-bigtable-hbase.

The cluster api is not currently enabled. There will be some iteration on it. This fields are likely to not be used any time soon, prefer using only default_storage_type instead.

Right now clusters are only created via the UI and a cluster can only be SSD. In the future we plan to enable HDD clusters, and maybe one day mixed HDD and SSD in the same cluster, which would make these fields meaningful.

from java-bigtable-hbase.

OK.

This leads to a second question. If we were to send a pull request to modify these protos, would it be worthwhile? Or is this "read-only" open source that will have changes blasted out during some sync job?

from java-bigtable-hbase.

Thanks for the reply @mgarolera !

Regarding

The cluster api is not currently enabled.

I have been able to use it (with a user account, not with a service account) when enabling the "Cloud Bigtable Table Admin API" in the APIs console. See googleapis/google-cloud-python#872 for discussion.

@jgeewax It doesn't seem we'd want to make a PR for this issue.

from java-bigtable-hbase.

@jgeewax: Yes, there protos are not yet the authoritative source and a change would be overwritten.
@dhermes: The api shouldn't be enabled for external users. If you are writing tooling to use it, don't use hdd_bytes and ssd_bytes. HDD clusters are coming soon so it would be useful to be able to control the default_storage_type field.

from java-bigtable-hbase.

Thanks @sduskis!

from java-bigtable-hbase.