Skip to content

Should we broaden the 'admin' flag pattern? #2131

@tseaver

Description

@tseaver

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    type: processA process-related concern. May include testing, release, or the like.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions