OpenAPI CLI

[nfx]

This PR adds the following command groups:

Workspace-level command groups

• bricks alerts - The alerts API can be used to perform CRUD operations on alerts.
• bricks catalogs - A catalog is the first layer of Unity Catalog’s three-level namespace.
• bricks cluster-policies - Cluster policy limits the ability to configure clusters based on a set of rules.
• bricks clusters - The Clusters API allows you to create, start, edit, list, terminate, and delete clusters.
• bricks current-user - This API allows retrieving information about currently authenticated user or service principal.
• bricks dashboards - In general, there is little need to modify dashboards using the API.
• bricks data-sources - This API is provided to assist you in making new query objects.
• bricks experiments - MLflow Experiment tracking.
• bricks external-locations - An external location is an object that combines a cloud storage path with a storage credential that authorizes access to the cloud storage path.
• bricks functions - Functions implement User-Defined Functions (UDFs) in Unity Catalog.
• bricks git-credentials - Registers personal access token for Databricks to do operations on behalf of the user.
• bricks global-init-scripts - The Global Init Scripts API enables Workspace administrators to configure global initialization scripts for their workspace.
• bricks grants - In Unity Catalog, data is secure by default.
• bricks groups - Groups simplify identity management, making it easier to assign access to Databricks Workspace, data, and other securable objects.
• bricks instance-pools - Instance Pools API are used to create, edit, delete and list instance pools by using ready-to-use cloud instances which reduces a cluster start and auto-scaling times.
• bricks instance-profiles - The Instance Profiles API allows admins to add, list, and remove instance profiles that users can launch clusters with.
• bricks ip-access-lists - IP Access List enables admins to configure IP access lists.
• bricks jobs - The Jobs API allows you to create, edit, and delete jobs.
• bricks libraries - The Libraries API allows you to install and uninstall libraries and get the status of libraries on a cluster.
• bricks metastores - A metastore is the top-level container of objects in Unity Catalog.
• bricks model-registry - MLflow Model Registry commands.
• bricks permissions - Permissions API are used to create read, write, edit, update and manage access for various users on different objects and endpoints.
• bricks pipelines - The Delta Live Tables API allows you to create, edit, delete, start, and view details about pipelines.
• bricks policy-families - View available policy families.
• bricks providers - Databricks Providers REST API.
• bricks queries - These endpoints are used for CRUD operations on query definitions.
• bricks query-history - Access the history of queries through SQL warehouses.
• bricks recipient-activation - Databricks Recipient Activation REST API.
• bricks recipients - Databricks Recipients REST API.
• bricks repos - The Repos API allows users to manage their git repos.
• bricks schemas - A schema (also called a database) is the second layer of Unity Catalog’s three-level namespace.
• bricks secrets - The Secrets API allows you to manage secrets, secret scopes, and access permissions.
• bricks service-principals - Identities for use with jobs, automated tools, and systems such as scripts, apps, and CI/CD platforms.
• bricks serving-endpoints - The Serving Endpoints API allows you to create, update, and delete model serving endpoints.
• bricks shares - Databricks Shares REST API.
• bricks storage-credentials - A storage credential represents an authentication and authorization mechanism for accessing data stored on your cloud tenant.
• bricks table-constraints - Primary key and foreign key constraints encode relationships between fields in tables.
• bricks tables - A table resides in the third layer of Unity Catalog’s three-level namespace.
• bricks token-management - Enables administrators to get all tokens and delete tokens for other users.
• bricks tokens - The Token API allows you to create, list, and revoke tokens that can be used to authenticate and access Databricks REST APIs.
• bricks users - User identities recognized by Databricks and represented by email addresses.
• bricks volumes - Volumes are a Unity Catalog (UC) capability for accessing, storing, governing, organizing and processing files.
• bricks warehouses - A SQL warehouse is a compute resource that lets you run SQL commands on data objects within Databricks SQL.
• bricks workspace - The Workspace API allows you to list, import, export, and delete notebooks and folders.
• bricks workspace-conf - This API allows updating known workspace settings for advanced users.

Account-level command groups

• bricks account billable-usage - This API allows you to download billable usage logs for the specified account and date range.
• bricks account budgets - These APIs manage budget configuration including notifications for exceeding a budget for a period.
• bricks account credentials - These APIs manage credential configurations for this workspace.
• bricks account custom-app-integration - These APIs enable administrators to manage custom oauth app integrations, which is required for adding/using Custom OAuth App Integration like Tableau Cloud for Databricks in AWS cloud.
• bricks account encryption-keys - These APIs manage encryption key configurations for this workspace (optional).
• bricks account groups - Groups simplify identity management, making it easier to assign access to Databricks Account, data, and other securable objects.
• bricks account ip-access-lists - The Accounts IP Access List API enables account admins to configure IP access lists for access to the account console.
• bricks account log-delivery - These APIs manage log delivery configurations for this account.
• bricks account metastore-assignments - These APIs manage metastore assignments to a workspace.
• bricks account metastores - These APIs manage Unity Catalog metastores for an account.
• bricks account networks - These APIs manage network configurations for customer-managed VPCs (optional).
• bricks account o-auth-enrollment - These APIs enable administrators to enroll OAuth for their accounts, which is required for adding/using any OAuth published/custom application integration.
• bricks account private-access - These APIs manage private access settings for this account.
• bricks account published-app-integration - These APIs enable administrators to manage published oauth app integrations, which is required for adding/using Published OAuth App Integration like Tableau Cloud for Databricks in AWS cloud.
• bricks account service-principals - Identities for use with jobs, automated tools, and systems such as scripts, apps, and CI/CD platforms.
• bricks account storage - These APIs manage storage configurations for this workspace.
• bricks account storage-credentials - These APIs manage storage credentials for a particular metastore.
• bricks account users - User identities recognized by Databricks and represented by email addresses.
• bricks account vpc-endpoints - These APIs manage VPC endpoint configurations for this account.
• bricks account workspace-assignment - The Workspace Permission Assignment API allows you to manage workspace permissions for principals in your account.
• bricks account workspaces - These APIs manage workspaces for this account.

[pietern]

Double negative is bad UX. If the default is to wait, then let's have --wait=true and to skip waiting --wait=false. Cobra may actually emit a --no-wait itself if the flag is binary.

[nfx]

cobra treats booleans as binary flags 🤷

Usage:
bricks clusters start CLUSTER_ID [flags]
Flags:
-h, --help helpfor start
--no-wait do not wait to reach RUNNING state
--timeout duration maximum amount of time to reach RUNNING state (default 20m0s)

if double negation in the generated code is the concern, I've fixed it. I don't think that anything else than --no-wait makes sense from UX perspective 🤷‍♂️

[pietern]

Mandatory args but they don't show up in the usage string of the command.

[pietern]

Why do this? Can pipe to jq if folks want to work with json.

[nfx]

not all machines have jq installed.

[pietern]

I can imagine ordering sometimes matters when showing a select box (e.g. order of profiles in ~/.databrickscfg) and then this should take a slice and return an index. Also removes the need for alphabetical sorting in the Select function.

[nfx]

the UX with cmdio.Select for profiles is not great. I want to keep the UX of the current PR. let's address unification in a separate PR.

[pietern]

Colors or not when rendering a template depends on stdout. For spinner it depends on stderr. The constant color.NoColor depends on stdout alone.

[nfx]

github.com/fatih/color performs these checks already and is properly skipping render in the non-tty outputs

[pietern]

Please add a todo to make this check depend on w being a TTY or not to make this generic. The implied assumption is that w is equal to stdout for check in color to work here.

[pietern]

Good to merge bar the final set of comments. Please take a look.

[pietern]

Please add a todo to make this check depend on w being a TTY or not to make this generic. The implied assumption is that w is equal to stdout for check in color to work here.

[pietern]

JSON fancification must only happen if w is a TTY.