FiftyOne Enterprise Plugins#

FiftyOne Enterprise provides native support for installing and running FiftyOne plugins, which offers powerful opportunities to extend and customize the functionality of your Enterprise deployment to suit your needs.

Note

What can you do with plugins? Check out delegated operations to see some quick examples, then check out the FiftyOne plugins repository for a growing collection of prebuilt plugins that you can add to your Enterprise deployment!

Plugins page#

Admins can use the plugins page to upload, manage, and configure permissions for plugins that are made available to users of your Enterprise deployment.

Admins can access the plugins page under Settings > Plugins. It displays a list of all installed plugins and their operators, as well as the enablement and permissions of each.

enterprise-plugins-page

Installing a plugin#

Admins can install plugins via the Enterprise UI or Management SDK.

Note

A plugin is a directory (or ZIP of it) that contains a top-level fiftyone.yml file.

Enterprise UI#

To install a plugin, click the “Install plugin” button on the plugins page.

enterprise-plugins-page-install-button

Then upload or drag and drop the plugin contents as a ZIP file and click install.

enterprise-plugins-page-install-page

You should then see a success message and the newly installed plugin listed on the plugins page.

enterprise-plugins-page-install-success-page

SDK#

Admins can also use the upload_plugin() method from the Management SDK:

1import fiftyone.management as fom
2
3# You can pass the directory or an already zipped version of it
4fom.upload_plugin("/path/to/plugin_dir")

Upgrading a plugin#

Admins can upgrade plugins at any time through the Enterprise UI or Management SDK.

Enterprise UI#

To upgrade a plugin, click the plugin’s dropdown and select “Upgrade plugin”.

enterprise-plugins-page-upgrade-btn

Then upload or drag and drop the upgraded plugin as a ZIP file and click upgrade.

enterprise-plugins-page-upgrade-page

Note

If the name attribute within the uploaded plugin’s fiftyone.yml file doesn’t match the existing plugin, a new plugin will be created. Simply delete the old one.

You should then see a success message and the updated information about the plugin on the plugins page.

enterprise-plugins-page-upgrade-success-page

SDK#

Admins can also use the upload_plugin() method from the Management SDK with the overwrite=True option:

1import fiftyone.management as fom
2
3# You can pass the directory or an already zipped version of it
4fom.upload_plugin("/path/to/plugin_dir", overwrite=True)

Uninstalling a plugin#

Admins can uninstall plugins at any time through the Enterprise UI or Management SDK.

Note

Did you know? You can enable/disable plugins rather than permanently uninstalling them.

Enterprise UI#

To uninstall a plugin, click the plugin’s dropdown and select “Uninstall plugin”.

enterprise-plugins-page-uninstall-btn

SDK#

Admins can also use the delete_plugin() method from the Management SDK:

1import fiftyone.management as fom
2
3fom.delete_plugin(plugin_name)

Enabling/disabling plugins#

Enterprise UI#

When plugins are first installed into Enterprise, they are enabled by default, along with any operators they contain.

Admins can enable/disable a plugin and all of its operators by toggling the enabled/disabled switch.

enterprise-plugins-page-disable

Admins can also disable/enable specific operators within an (enabled) plugin by clicking on the plugin’s operators link.

enterprise-plugins-page-operators-btn

and then toggling the enabled/disabled switch for each operator as necessary.

enterprise-plugins-page-operators-disable

SDK#

Admins can also use the set_plugin_enabled() and set_plugin_operator_enabled() methods from the management SDK:

1import fiftyone.management as fom
2
3# Disable a plugin
4fom.set_plugin_enabled(plugin_name, False)
5
6# Disable a particular operator
7fom.set_plugin_operator_enabled(plugin_name, operator_name, False)

Plugin permissions#

Admins can optionally configure access to plugins and individual operators within them via any combination of the permissions described below:

Permission

Description

Minimum Role

The minimum role a user must have to execute the operation.

Minimum Dataset Permission

The minimum dataset permission a user must have to perform the operation on a particular dataset.

Enterprise UI#

To configure the permissions for an operator, first click on the plugin’s operators link.

enterprise-plugins-page-operators-btn

Then change the dropdown for the operator to reflect the desired permission level.

enterprise-plugins-page-operators-perms enterprise-plugins-page-operators-perms2

SDK#

Admins can also use the set_plugin_operator_permissions() method from the Management SDK:

 1import fiftyone.management as fom
 2
 3# Set minimum role permission only
 4fom.set_plugin_operator_enabled(
 5    plugin_name,
 6    operator_name,
 7    minimum_role=fom.MEMBER,
 8)
 9
10# Set minimum dataset permission only
11fom.set_plugin_operator_enabled(
12    plugin_name,
13    operator_name,
14    minimum_dataset_permission=fom.EDIT,
15)
16
17# Set both minimum role and minimum dataset permissions
18fom.set_plugin_operator_enabled(
19    plugin_name,
20    operator_name,
21    minimum_role=fom.EDIT,
22    minimum_dataset_permission=fom.EDIT,
23)

Default permissions#

When new plugins are installed, any operators they contain are initialized with the default permissions for your deployment.

By default, the initial permissions are:

Permission

Default

Minimum Role

Member

Minimum Dataset Permission

Edit

Enterprise UI#

Default operator permissions can be configured by navigating to the page at Settings > Security and looking under the Plugins header. Click the dropdown for the permission you want to change and select the new value.

enterprise-plugins-page-org-settings

SDK#

Admins can also use the set_organization_settings() method from the Management SDK:

1import fiftyone.management as fom
2
3fom.set_organization_settings(
4    default_operator_minimum_role=fom.MEMBER,
5    default_operator_minimum_dataset_permission=fom.EDIT,
6)

Delegated operations#

Delegated operations are a powerful feature of FiftyOne’s plugin framework that allows users to schedule tasks from within the App that are executed in the background on a connected compute cluster.

With FiftyOne Enterprise, your team can upload and permission custom operations that your users can execute from the Enterprise App, all of which run against a central orchestrator configured by your admins.

Why is this awesome? Your AI stack needs a flexible data-centric component that enables you to organize and compute on your data. With delegated operations, FiftyOne Enterprise becomes both a dataset management/visualization tool and a workflow automation tool that defines how your data-centric workflows like ingestion, curation, and evaluation are performed. In short, think of FiftyOne Enterprise as the single source of truth on which you co-develop your data and models together.

What can delegated operations do for you? Get started by installing any of these plugins available in the FiftyOne Plugins repository:

@voxel51/annotation

✏️ Utilities for integrating FiftyOne with annotation tools

@voxel51/brain

🧠 Utilities for working with the FiftyOne Brain

@voxel51/evaluation

✅ Utilities for evaluating models with FiftyOne

@voxel51/io

📁 A collection of import/export utilities

@voxel51/indexes

📈 Utilities working with FiftyOne database indexes

@voxel51/utils

⚒️ Call your favorite SDK utilities from the App

@voxel51/voxelgpt

🤖 An AI assistant that can query visual datasets, search the FiftyOne docs, and answer general computer vision questions

@voxel51/zoo

🌎 Download datasets and run inference with models from the FiftyOne Zoo, all without leaving the App

For example, wish you could import data from within the App? With the @voxel51/io, plugin you can!

../_images/import.gif

Want to send data for annotation from within the App? Sure thing, just install the @voxel51/annotation plugin:

../_images/annotation.gif

Have model predictions on your dataset that you want to evaluate? The @voxel51/evaluation plugin makes it easy:

../_images/evaluation.gif

Need to compute embedding for your dataset so you can visualize them in the Embeddings panel? Kick off the task with the @voxel51/brain plugin and proceed with other work while the execution happens in the background:

../_images/embeddings.gif

When you choose delegated execution in the App, these tasks are automatically scheduled for execution on your connected orchestrator and you can continue with other work. Meanwhile, all datasets have a Runs tab in the App where you can browse a history of all delegated operations that have been run on the dataset and their status.

Configuring your orchestrator(s)#

FiftyOne Enterprise offers a builtin orchestrator that is configured as part of your team’s deployment with a default level of compute capacity.

It is also possible to connect your FiftyOne Enterprise deployment to an externally managed workflow orchestration tool (Airflow, Flyte, Spark, etc).

Note

Contact your Voxel51 support team to scale your deployment’s compute capacity or if you’d like to use an external orchestrator.

Managing delegated operations#

Every dataset in FiftyOne Enterprise has a Runs page that allows users with access to monitor and explore delegated operations scheduled against that dataset.

All scheduled operations are maintained in a queue and will be automatically executed as resources are available on the targeted orchestrator.

Note

The Runs page only tracks operations that are scheduled for delegated execution, not operations that are executed immediately in the App.

Runs page#

All users with at least Can View access to a dataset can visit the Runs page by clicking on the “Runs” tab.

On the Runs page, you will see a table with a list of delegated operations. Admins can choose whether to view operations for all datasets or only the current dataset, while non-admins can only view operations associated with the current dataset.

The table provides options to sort, search, and filter runs shown to refine the list as you like:

../_images/runs_general.png

Statuses#

Delegated operations can have one of 5 potential statuses:

  • Scheduled: the run has been scheduled for execution and is awaiting execution quota. All delegated operations begin life in this state

  • Queued: the run has been allocated execution quota and it will start running as soon as orchestrator resources become available

  • Running: the run is currently being executed

  • Completed: the run has completed successfully

  • Failed: the run failed to complete

Note

FiftyOne Enterprise offers a builtin orchestrator that is configured as part of your team’s deployment with a default level of execution quota.

Contact your Voxel51 support team to discuss running more jobs in parallel, or if you’d like to use an external orchestrator.

../_images/runs_statuses.png

You can hover over the status badge of a run in Scheduled or Queued state to see additional information about its execution, including its position in the Scheduled queue:

../_images/runs_hover_scheduled.png ../_images/runs_hover_queued.png

Sorting#

By default, the runs table is sorted by recency, with the most recently scheduled run at the top. You can use the dropdown menu in the upper right of the table to sort by other criteria, including last updated, oldest, or operator name:

../_images/runs_sorting.png

Filtering#

You can also filter the runs table to see a subset of runs.

Users with sufficient privileges can toggle between “My Runs” and “All Runs” to see runs you have scheduled versus runs that others in your organization have scheduled on the current dataset:

../_images/runs_my_vs_all.png

All users can further refine the list of runs using the Status dropdown to select one or more statuses you would like to filter by:

../_images/runs_statuses.png

Admins can also toggle to show “All Datasets” or “This Dataset” to control whether to show all runs for your organization versus only runs for the dataset you are currently viewing:

../_images/runs_this_vs_all.png

Searching#

You can also use the search functionality to filter the list of runs by keyword. As you type your query in the search box, the list of runs will be updated to show only the runs matching your query:

../_images/runs_search.png

Note

Search is case-sensitive and you can currently only search by operator name, not label. For example, the search “bright” does not match against the label “compute_brightness” in the image above but instead the operator URI “@voxel51/panels/compute_brightness”.

Re-running#

From the Runs page, you can trigger a re-run of any run by clicking the kebab menu and selecting “Re-run”:

../_images/run_re_run.png

Pinning#

Pinned runs are displayed to the right of the runs table. By default, five pinned runs will be displayed, and if there are more than five pinned runs, you will see a button to expand the list.

To pin a run, hover over its row in the runs table and click the pin icon that appears beside the operator label:

Note

Pinned runs are stored at the dataset-level and will be visible to all users with access to that dataset.

../_images/run_pinning.png ../_images/runs_pinned_sidebar.png

Renaming#

When delegating an operation multiple times on the same dataset, you may wish to give the runs custom labels so that you can easily identify each run later.

To edit the label of an operator run, move your mouse cursor over the label of interest and click the pencil button as indicated by “1” below. This will present an input field indicated by “2” where you can update the label to the text of your choice. Once you are ready to apply changes, click the save button indicated by “3”:

../_images/run_rename.png

Mark as failed#

If a delegated operation run terminates unexpectedly without reporting failure, you can manually mark it as failed from the Runs page.

To mark a run as failed, click the three dots indicated by “1”. Then, in the menu, click “Mark as failed” as indicated by “2”. The run status will be updated and will now display as failed:

../_images/runs_mark_as_failed.png

Warning

If the delegated operation is, in fact, still in progress in your orchestrator, marking the run as failed will not terminate the execution of operation. It will continue executing until completion but the operation will be marked as failed regardless of its outcome.

Monitoring progress#

Delegated operations can optionally report their progress during execution.

If progress is available for a run, it will be displayed in the Runs table as indicated by “2”.

By default, the general status of a run and the progress of running operations is automatically refreshed. You can disable the auto-refresh of running operations by toggling the auto-refresh setting indicated by “1”.

../_images/runs_running_basic.png ../_images/runs_progress_enabled.png

Run page#

The Run page for a specific run allows you to see information about a specific delegated operation, including its inputs, outputs, logs, and errors.

You can visit the Run page for a run by clicking on the run in the runs table, the Pinned runs section, or the Recent runs widgets.

Input#

The Input tab on the Run page lets you see the input parameters that were provided when the delegated operation was scheduled:

../_images/run_input_general.png

By default, a rendered version of input parameters is displayed, similar to what is displayed when invoking an operator via a prompt modal. However, you can switch to raw format by clicking the “Show raw” toggle button:

../_images/run_input_raw.png

Output#

The Output tab on the Run page lets you see the rendered output of a delegated operation that has completed, if there is any:

../_images/run_output.png

Errors#

The Errors tab on the Run page will appear if the run failed, and it will display the error message and stack trace that occurred:

../_images/run_error.png

Logs#

The Logs tab on the Run page allows you to view available logs associated with a delegated operation:

../_images/logs_general.png

Viewing logs

Once log storage is configured, logs will automatically appear in the Logs tab of a run once they are available:

Note

Logs are currently only available after the run completes.

../_images/logs_not_available_pre_completion.png ../_images/logs_now_available_post_completion.png

Logs structure

Logs are displayed in a tabular format as pictured below, including the timestamp, severity, and message associated with each log entry:

../_images/logs_general_with_columns.png

For logs that exceed 1MB, no content will be shown and instead a “Download logs” button will appear:

../_images/logs_too_large.png

Downloading logs

You can directly download the logs for a delegated operation from both the Runs table and the operation’s Run page:

../_images/logs_download_runs_list_kebab.png ../_images/logs_download_preview_pane.png

Logs setup

Viewing run logs for delegated operations requires some one-time deployment-level configuration.

A deployment admin on your team will need to explicitly define log generation behavior for your orchestrator(s). We provide simple setup instructions for the two deployment configurations we support for the builtin orchestrator:

../_images/logs_configure_not_setup.png

Note

If you are using a third-party orchestrator like Airflow, simply configure your orchestrator to store logs to a persistent location and then report this path for each run via the log_path argument.

View#

The View tab on the Run page lets you see the specific view (which could be the full dataset) on which the operation was performed:

../_images/run_view.png