As we continue to develop Tator, our web platform for video annotation and analysis, we have identified two distinct user groups. The first group consists of Open Source Software (OSS) Users who are typically small teams or individual researchers looking to use Tator for a single project or field work. They prefer to install Tator on a single on-premise machine, without relying on cloud services. They have limited data, typically less than 10TB, and require access for a small team of 1-10 users. On the other hand, Enterprise Users are medium to large organizations that require high availability and data durability, with scalability and security being their top concerns. They are interested in using the cloud and require access to large amounts of data, often in the range of tens or hundreds of TB.

As developers, we recognize the importance of serving both types of users, and have endeavored to do so with a single open source codebase. However, we have found that our current codebase is not optimal for either group. For OSS Users, Tator is difficult to install and configure due to its reliance on Kubernetes. Despite the development of our install script and support for microk8s, OSS Users often experience issues related to container networking, particularly with DNS, firewalls, and proxies. Meanwhile, for Enterprise Users, the value proposition of a Tator Enterprise Subscription is unclear since Tator is entirely open source.

To address these issues, our repository will be split into two separate repositories, Tator OSS and Tator Enterprise, starting with release 1.1.0, which is our next big milestone release.

Introducing v1.0.0​

We are excited to announce the latest update to our web-based software platform, Tator v1.0.0, which marks a significant milestone for the product. This release brings about changes at both the architectural layer and API level, providing a rock-solid foundation for future iterations of the platform. In addition to laying the groundwork for future features, Tator v1.0.0 brings a plethora of bug fixes, UI consistency improvements, and quality of life enhancements that we believe our users will appreciate.

One of the most noteworthy changes in this update is the removal of the Elasticsearch subsystem, which caused significant ripples throughout the API. Although Elasticsearch and PostgreSQL can complement each other, managing their integration can lead to challenges related to data consistency and maintenance. By utilizing structured metadata in PostgreSQL, we can achieve our search and analytics requirements without the need for Elasticsearch, reducing maintenance costs and improving scalability.

This blog post will go over the procedure for upgrading a Tator deployment to the upcoming major release, 1.0.0, with most features recently merged with the main branch. This release requires an upgrade to Postgresql 14 and drops the Elasticsearch dependency for standard queries (although it is still used for storing logs). Deprecated bucket definition formats are also removed in this release. This post assumes that the tator deployment is currently running version 0.2.23, was installed with the install script, and is running on microk8s.

What changed​

In the 1.0.0 release of Tator, the fields related to default upload, live, and backup buckets in the values.yaml configuration file have changed to match the changes from the 0.2.22 release. This is a breaking change and your tator deployment will be broken if your deployment administrator does not follow these instructions during the upgrade to 1.0.0.

What changed​

In the 0.2.22 release of Tator, support for OCI Object Storage as a bucket was added. This required a refactor of how bucket configurations are stored by Tator, which is not backwards compatible. The 0.2.22 release deprecates the existing method of creating and updating buckets, but still allows for buckets created this way to function. Release 1.0.0 will deprecate the functionality of buckets created this way, but there is a utility that will assist your migration from the old configuration to the new one.

Creating a tator-py AWS Lambda Layer​

To use python packages that are not included in the AWS Lambda runtime, you must create a Layer. This post explains what AWS Lambda is and outlines how to create a Layer containing tator-py and add it to your Lambda.

Using Okta as an Identity Provider for Tator​

This will require setting up a SAML-based application integration in Okta and then setting the SAML metadata configuration URL in Tator.

As a video data analyst, it doesn't matter whether you're looking at coral reef or discarded haddock, every pixel counts. In upcoming versions of Tator higher video quality of 4k and 8k are unleashed for analysis. While maintaining frame accurate playback, between multiple sources, video sources can now scale up to 8k resolution.

Figure 1: Comparison of common video resolutions

This blog post will go over the procedure for upgrading a Tator deployment to the latest release, 0.2.19. This release updates the versions of some dependencies, which require more user actions than the standard upgrade process. It assumes that the tator deployment was set up using the install script and is running on microk8s.

In this blog post, we will cover how to install Tator on a GCP VM. The main trick is updating the domain to the virtual machine's public IP address after running the install script. This is necessary because by default the install script will discover the internal IP address only, and use that IP address for the load balancer, Kubernetes API server, and domain name. For the most part we simply need to run the install script and make one change to the Helm config file, but we will also cover VM setup in the GCP console.