The Bigtable client takes an admin flag, defaulting to False: if it isn't set to True, the client avoids adding scopes for the instance / cluster admin APIs, and blocks creation of the corresponding stubs. It has the effect of a "safety" knob, preventing a user (likely at the REPL prompt?) from accidentally creating / deleting "expensive" resources. The client also takes a readonly flag, defaulting to False, and uses it to decide which of two scopes to use.
Logically, if such a pattern is a good idea, it would be equally good to have such protection for the "expensive"-ish resources in other APIs: storage buckets, bigquery datasets / tables(?), pubsub topics / subscriptions (feel free to add others as they occur to you).
As an alternative, perhaps we need to make it more obvious how to configure clients with reduced scopes, maybe even requiring a non-default flag to set the more permissive ones.
The Bigtable client takes an
adminflag, defaulting toFalse: if it isn't set toTrue, the client avoids adding scopes for the instance / cluster admin APIs, and blocks creation of the corresponding stubs. It has the effect of a "safety" knob, preventing a user (likely at the REPL prompt?) from accidentally creating / deleting "expensive" resources. The client also takes areadonlyflag, defaulting toFalse, and uses it to decide which of two scopes to use.Logically, if such a pattern is a good idea, it would be equally good to have such protection for the "expensive"-ish resources in other APIs: storage buckets, bigquery datasets / tables(?), pubsub topics / subscriptions (feel free to add others as they occur to you).
As an alternative, perhaps we need to make it more obvious how to configure clients with reduced scopes, maybe even requiring a non-default flag to set the more permissive ones.