API/CLI Reference

API-Reference

`burla.remote_parallel_map`

Run any python function on many remote computers at the same time.

remote_parallel_map(
  function_,
  inputs,
  func_cpu=1,
  func_ram=4,
  background=False,
  spinner=True,
  generator=False,
  max_parallelism=None,
)

Run provided function_ on each item in inputs at the same time, each on a separate CPU. If more inputs are provided than there are available CPU's, they are queued and processed sequentially on each worker. remote_parallel_map can reliably queue millions of inputs.

While running:

If the provided function_ raises an exception, the exception, including stack trace, is re-raised on the client machine in a way that looks like it was running locally.
Your print statements (anything written to stdout/stderr) are streamed back to your local machine, appearing like they would have if running the same code locally.

When finished remote_parallel_map returns a list of values returned by each function_ call.

Parameters

Name

Description

function_

Callable

Python function. Must have single input argument, eg: function_(inputs[0]) does not raise an exception.

inputs

List[Any]

Iterable of elements passable to function_.

func_cpu

int

(Optional) Number of CPU's made available to each running instance of function_. Max possible value is determined by your cluster machine type.

func_ram

int

(Optional) Amount of RAM (GB) made available to each running instance of function_. Max possible value is determined by your cluster machine type.

background

bool (Optional) remote_parallel_map returns as soon as your inputs and function have been uploaded. The job then continues to run independently in the background until done.

spinner

bool

(Optional) Set to False to hide the status indicator/spinner.

generator

bool (Optional) Set to True to return a Generator instead of a List. The generator will yield outputs as they are produced, instead of all at once.

max_parallelism

int

(Optional) Maximum number of function_ instances allowed to be running at the same time.

Returns

Type

Description

List or Generator

List of objects returned by function_ in no particular order. If Generator=True, returns generator yielding objects returned by function_ in the order they are produced.

CLI-Reference

Burla's CLI contains the following commands:

burla install Install a self-hosted Burla instance in your Google Cloud project.
burla login Authenticate your machine.

The global arg --help can be placed after any command or command group to see CLI documentation.

`burla install`

Install a self-hosted Burla instance in your Google Cloud project. Running burla install multiple times will update the existing installation with the latest version.

Description:

Installs Burla inside the Google Cloud project that your gcloud CLI is currently pointing to. For a more user-friendly installation guide see: Installation: Self-Hosted

To view your current gcloud project run: gcloud config get project To change your current gcloud project run: gcloud config set project <desired-project-id>

Prerequisites:

Have the gcloud CLI installed (how do I install the gcloud CLI?).
Be logged in to the gcloud CLI (how do I log in?) (gcloud auth login & gcloud auth application-default login)
Have a Google Cloud user account with at least the minimum required permissions to install Burla. Or: Just run burla install, if you're missing any permissions it will tell you which ones!

Here are three sets of permissions, each of which would authorize somebody to run burla install:

Exact minimum required permissions

Service Usage API (serviceusage.googleapis.com):
- serviceusage.services.enable for enabling:
  - compute.googleapis.com
  - run.googleapis.com
  - firestore.googleapis.com
  - cloudresourcemanager.googleapis.com
  - secretmanager.googleapis.com
Compute Engine API (compute.googleapis.com):
- compute.firewalls.create
- compute.firewalls.get (to check if firewall rule exists)
- compute.networks.updatePolicy
Secret Manager API (secretmanager.googleapis.com):
- secretmanager.secrets.create
- secretmanager.secrets.get
- secretmanager.versions.add
Firestore API (firestore.googleapis.com):
- datastore.databases.create
- datastore.databases.get
- datastore.documents.create
- datastore.documents.write
Cloud Run API (run.googleapis.com):
- run.services.create
- run.services.update
- run.services.get
- run.services.setIamPolicy (for --allow-unauthenticated flag)

Here is an IAM role definition for this permission set:

title: "Burla Installation Role"
description: "Minimum permissions needed to install Burla"
stage: "GA"
includedPermissions:
- serviceusage.services.enable
- compute.firewalls.create
- compute.firewalls.get
- compute.networks.updatePolicy
- secretmanager.secrets.create
- secretmanager.secrets.get
- secretmanager.versions.add
- datastore.databases.create
- datastore.databases.get
- datastore.documents.create
- datastore.documents.write
- run.services.create
- run.services.update
- run.services.get
- run.services.setIamPolicy

Generic role based permissions (less complicated)

Burla can be installed by users having the following generic roles:

Service Usage Admin (roles/serviceusage.serviceUsageAdmin)
Cloud Run Admin (roles/run.admin)
Compute Network Admin (roles/compute.networkAdmin)
Secret Manager Admin (roles/secretmanager.admin)
Firestore Database Admin (roles/datastore.owner)

Simplest possible permissions

Burla can be installed with either of the following roles:

Project Owner (roles/owner)
Project Editor (roles/editor)

Here is exactly what happens when burla install is run:

On install, your Google account (the one you are currently logged in to gcloud with) is set as the only account authorized to access this new Burla deployment.

To access the deployment you will need prove your identity by signing in to this same Google account through a Google sign-in page. Burla follows the standard Google OAuth 2.0 authorization flow.

Exact installation operations

Required services are enabled (if they are not already enabled):
- gcloud services enable is called on:
  - compute.googleapis.com
  - run.googleapis.com
  - firestore.googleapis.com
  - cloudresourcemanager.googleapis.com
  - secretmanager.googleapis.com
Port 8080 is opened on any GCE VM having the tag burla-cluster-node:
- gcloud compute firewall-rules create burla-cluster-node-firewall \ --action=ALLOW --rules=tcp:8080 --target-tags=burla-cluster-node ...
A secret is created that's used to encrypt auth cookies in the dashboard:
- gcloud secrets describe burla-cluster-id-token
- gcloud secrets create burla-cluster-id-token ...
A Google Cloud Firestore database is created: (manages information displayed in the dashboard)
- gcloud firestore databases create --database=burla ...
Your Google account (that you are currently logged in to gcloud with) is set as the only account authorized to access this new Burla deployment.
- This account is discovered using the following command: gcloud auth list --filter=status:ACTIVE --format="value(account)"
- Once set, this cannot be changed by other users running burla install again.
The main-service (dashboard) is deployed on Google Cloud Run:
- gcloud run deploy burla-main-service \ --image=burlacloud/main-service:latest ...
- gcloud run services update-traffic burla-main-service --to-latest ...
Thats it!

We encourage you to check out _install.py in the client for even more specific installation details.

After Installing:

burla install prints the following:

Success! To view your new dashboard run `burla login`
Quickstart:
  1. Start your cluster by hitting "⏻ Start" in the dashboard.
  2. Import and call `remote_parallel_map`!

Authenticates the current machine through a Google OAuth consent screen. Allows you to call remote_parallel_map on Burla deployments where you're authorized to do so.

Description:

Launches the "sign in with google" page in your default web browser. This gives our backend access to only your email and name according to your google account. See our privacy-policy to learn how we protect this information.

This is used to ensure that only people you have explicitly authorized have access to your Burla instance.

Once signed-in successfully, an auth-token is saved in the text file burla_credentials.json. This file is stored in your operating system's recommended user data directory which is determined using the appdirs python library.

This token is refreshed each time the burla loginauthorization flow is completed.

Questions? Schedule a call with us, or email [email protected]. We're always happy to talk.