BlackPearl Version 4.0 Upcoming Changes

Spectra Logic’s BlackPearl has seen wide adoption across various industries and multiple use cases. To meet the requirements of many user groups, Spectra’s Engineering team has continued to improve the functionality of the product, while at the same time postponing any changes that could affect existing software client integrations. As we described in a previous blog post, we try to restrict changes to the BlackPearl API to major version releases.

With the upcoming major release of BlackPearl code version 4.0 currently scheduled for August, we do expect changes to the API to support these new features. Some of these changes could affect existing BlackPearl software client integrations. Next month we will provide the exact definitions of the API changes of version 4.0 code to our developer community to ensure that all organizations have ample time to make and test any necessary modifications before the BlackPearl 4.0 code is released to end customers.  We will provide developers with:

  • Documentation of the exact API changes
  • Beta SDKs using the new 4.0 code
  • Access to a BlackPearl running version 4.0

Please stay tuned for more communications about API changes.

BlackPearl version 4.o will also include changes to the way the system handles object metadata. Starting with version 4.0, the metadata will need to be included with every blob/part of an object that is uploaded. Previously the metadata was only required to be provided on the first object part. This change will be handled automatically in the Java and C#/.NET SDKs simply by upgrading to a new SDK. Developers who utilize C or Python SDKs will need to make changes to their code. This change can be made and tested with a current BlackPearl system, since older versions of BlackPearl already support this behavior. Please use our Forums if you need assistance with this change.


Getting started with BlackPearl Partial File Restore integration

In ​the Media & Entertainment world​, data files have reached very large sizes,​ particularly in cases of high resolution video ​that can exceed the one terabyte in size. In order to efficiently work with very large files, the media file processing is done in sections, with​ the end-user requesting content “snippets” based on timecodes. Object storage devices​​ that are used to store very large files are typically not aware of the timecode-to-byte relationship, and have no content awareness that’s necessary to extract and create partial media files.  In order to bridge the gap between time and bytes, BlackPearl has added a Partial File Restore (PFR) feature to enable the media processing application to efficiently retrieve a complete media file based on timecode offsets.

In​​ a typical Media Asset Management (MAM)/BlackPearl environment, the architecture would involve the following elements:

--        MAM – provides end user interface

--        BlackPearl MAM Plugin – handles all interactions between BlackPearl and MAM

--        BlackPearl – object storage

--        PFR Server – provides PFR processing services

--        NAS – network storage – permanent storage location for index files, temporary storage location for file processing

 

In the BlackPearl environment, there are two parts to the PFR processing of media files. The first part involves creating the media-aware index file for timecode/byte-offset information during file storage (writing) process. The second part of the process involves recalling a range of bytes that are based on a specified timecode, and creating complete, a self-contained media file that contains only the requested frames. In order to make this integration efficient, the PFR Server has a defined set of services that can be called by the media application using a REST interface (in this architecture – via the BlackPearl plugin).

The interface supports three basic request calls and two status calls to monitor the progress of the requested execution:

--        Request File Indexing
--        Request File Indexing Status
--        Request File Byte Offsets
--        Request Partial File Creation
--        Request Partial File Creation Status

For storing the file, the typical flow of execution would be:

  1. Copy media file to NAS storage
  2. Request creation of media index file
  3. Monitor status for completion
  4. Write file to BlackPearl Storage

For retrieving the partial file, the flow of execution would be:

  1. Request File Byte Offsets based on timecode
  2. Read specified byte range from BlackPearl to NAS
  3. Request partial file creation
  4. Monitor file creation status
  5. Supply partial file to Media Application

Spectra’s development team has created an C# SDK to support the rapid development and integration of the PFR with BlackPearl Storage into existing M&E environments. The SDK provides “wrapper” calls for the REST API calls. The documentation and code samples can be found at the PFR GitHub site:

https://github.com/SpectraLogic/tpfr_client

The Quick Start Guide is a required reading to understand the services and locations that have to be setup in order to start PFR development:

https://github.com/SpectraLogic/tpfr_client/raw/master/Documents/Black%20Pearl%20PFR%20-%20Quick%20Start%20Guide%20-%20Feb%202017.pdf

The REST API definition is available for reference at:

https://github.com/SpectraLogic/tpfr_client/blob/master/Documents/Extended%20PFR%20Indexer%20Web%20Service%20API_SF_3rdJan2017.pdf

If you are considering creating a PFR integration with a BlackPearl environment, please contact the Spectra Logic Developer Program Team.


BlackPearl SDK for Python 3 Now Available

Spectra Logic provides software development kits (SDKs) to make it easier to create applications that integrate with BlackPearl. We provide these SDKs in Java, C#/.NET, C, and Python. Our initial Python SDK was built to be used with Python 2. We have now also released a Python SDK that is intended for Python 3.

You can download the Python 3 SDK now. Note that this is a beta release, so please send us any feedback you have on this SDK.

If you are not sure which Python version to use, read about Python 2 versus Python 3 on Python.org.


Minimizing Changes to the BlackPearl API

Spectra Logic’s BlackPearl is a gateway to our deep storage that uses an Application Programming Interface (API) for archive and restore operations. This API is used by our partners to integrate their software with BlackPearl. With the success of BlackPearl, the list of partner software clients is growing quickly. With the larger list comes a very important question: what should Spectra do to keep changes in BlackPearl code from affecting partner integrations? Retesting every release of BlackPearl code with every client version is obviously not feasible. Instead, Spectra Logic has chosen to tightly control and minimize API changes to prevent problems with partner integrations. To achieve this, we have established an API change review process that involves all stakeholders within the Spectra organization, as well as external partners and customers.

The release process:

-- Requires that every type of proposed change to an existing API call has a sponsor and is logged in the engineering feature tracking system.

-- The proposed change has to be reviewed and approved by both Spectra’s Engineering and Product Management departments before it becomes scheduled for development.

-- Even when approved, any changes to API with potential to affect partners and customers have to be scheduled with sufficient lead time to allow proper communications to and changes by all stakeholders, including customers, partners, and Spectra Logic.

-- Finally, the process restricts API changes which affect backward compatibility with existing clients to major releases of BlackPearl code (e.g. version 3.x to version 4.x), unless the change is deemed critical by the directors of both Engineering and Product Management departments.

-- New XML response elements and attributes are permitted, as they should be ignored by clients not taking advantage of a new response element. This behavior allows existing older clients to keep functioning with newer versions of API.

 

With all the controls built into the process, Spectra Logic aims to assure a stable and consistent API for interfacing with BlackPearl. At the same time, the process provides a means to expand the API to meet the needs of end users and support new applications and markets as they develop in the future.


Importing Foreign LTFS Tapes into BlackPearl

When BlackPearl writes data to tape, it uses the open Linear Tape File System (LTFS) file format. Because of this LTFS support, Spectra Logic was able to add the ability to import non-BlackPearl or “foreign” LTFS tapes to BlackPearl. This is useful for any customer that receives LTFS-formatted tapes from another source and wishes to read those same tapes in the BlackPearl environment. This workflow is particularly common in the Media and Entertainment industry as a way to transfer video files from one group to another. Since every application may utilize the open LTFS format in a different manner when writing data to tapes, it is important that the user verify the various LTFS tape formats will be properly imported for read only use in the BlackPearl environment.

BlackPearl will support the import of foreign LTFS tapes in version 3.5, which is due out in Q1 of 2017. Importing can be done manually via the BlackPearl web management interface or via an external application that calls the BlackPearl API. The “import” process we discuss herein assumes that the foreign LTFS tapes have already been physically imported into the tape library partition to which BlackPearl is connected. Additionally, when a foreign LTFS tape is added to a BlackPearl tape partition, the write-protect switch on the tape cartridge must be set to “read only” before BlackPearl will allow the tape to be imported.  We strongly recommend that the tape be kept in read-only mode so that BlackPearl will not be able to modify the tape in any way. Also note that the API import commands must be initiated by the administrator or “spectra” user.

To manually import foreign LTFS tapes via the web management interface of BlackPearl, users will go to the Tape Management page (Status > Tape Management), click on the tape(s) to be imported, and then go to the Action menu and select Import Foreign Tape.

The tapes can also be imported via an external application that calls the BlackPearl API. While there are several possible workflows that can be taken to import the tapes into BlackPearl by an application, this is one we are currently recommending to our partners:

  1. Application calls API command Get Tapes to get a list of all tapes and their state. Tapes with a state of LTFS_WITH_FOREIGN_DATA should be recorded along with their barcodes.
  2. Application calls API command Raw Import All Tapes to start the process of importing the foreign LTFS tapes. Make sure to make this call using the admin user “spectra”. The application must provide a bucket name in which to import the files on the foreign LTFS tapes. Alternatively the application can call Raw Import Tape to import individual foreign LTFS tapes based on the barcodes recorded from Step 1 above. Again, each time this is called, a bucket name will need to be provided and using this method can allow the application to import different tapes into different buckets if desired.
  3. Application should periodically call API command Get Tapes again to check the state of all tapes. Once there are no more tapes with a state of LTFS Foreign, it means all foreign LTFS tapes have been successfully imported.
  4. Application calls API command Get Physical Placement for Object Parts on Tape to get a list of all files that are on each LTFS tape, using the barcodes recorded in Step 1 above as the input parameter for this call. The application can then read each of these files if needed, such as to create video proxies or to copy them to another location in BlackPearl. If the application doesn’t need to read the files, it can simply record the list of file names.
  5. If the application no longer needs the files on the foreign LTFS tapes, for example because it has read the files and copied them to another bucket in BlackPearl, it can then issue an Eject Tape command for each tape.

As you can see, it is quite easy for applications to work with foreign LTFS tapes in BlackPearl. It is important to remember that the user and/or developer need to confirm that the user’s LTFS tapes can be read by BlackPearl by testing them out. Also, note that BlackPearl will not generate a checksum for the files on foreign LTFS tapes as it does for other files that are imported into BlackPearl. We also don’t currently support importing foreign LTFS tapes that use “tape spanning”, or spanning one file across multiple tapes.

Foreign LTFS tape import is supported in released Java SDK 3.4.0-RC1, and it will be supported by any BlackPearl hardware with code 3.5 and higher. We will soon (in the next two months) also have the foreign LTFS tape import operations available in our other SDKs (C#/.NET, Python, C). We will also soon update our BlackPearl API documentation to include the new foreign LTFS tape import operations.

If you want help working with foreign LTFS tapes in your BlackPearl integration, please contact the Developer Program.


Developer Summit 2016 Recording and Slides

On November 10, 2016, we had a successful, second annual BlackPearl Developer Summit. We have provided a recording, slides, and agenda from the Summit below.

Summit Recording

Slides

Agenda

  • Corporate updates from Spectra CEO Nathan Thompson
  • BlackPearl product overview and enhancements
  • Learn what tools are available to help develop a BlackPearl client
  • Partner presentation detailing client development
  • Learn how easy it is to integrate an existing BlackPearl client into your workflow
  • Demonstration of Avid PAM and BlackPearl integration
  • Demonstration of CatDV BlackPearl integration
  • Question and answer with our BlackPearl Developer Program Team

 

 


Second Annual BlackPearl Developer Summit – Nov 10 2016

Thursday, November 10, 2016 — 9:00 a.m. MDT (UTC -7), WebEx

Join us for Spectra Logic’s second annual BlackPearl Developer Summit, a virtual conference for current and potential developers of Spectra® BlackPearl® Deep Storage Gateway.

Event Agenda:

  • Corporate updates from Spectra CEO Nathan Thompson
  • BlackPearl product overview and enhancements
  • Learn what tools are available to help develop a BlackPearl client
  • Partner presentation detailing client development
  • Learn how easy it is to integrate an existing BlackPearl client into your workflow
  • Demonstration of Avid PAM and BlackPearl integration
  • Question and answer with our BlackPearl Developer Program Team

November 10, 2016 — 9:00 a.m. MDT (UTC -7)
Check Time by Country

REGISTER NOW


Python SDK 3.0 Released

We have released new version 3.0.0 of our BlackPearl Software Development Kit (SDK) for the Python programming language. It is now available for download on GitHub. You can also view code documentation, code examples, and installation instructions on our Documentation page.

This new SDK is compatible with our current BlackPearl 3.0.1 release and allows access to all BlackPearl 3.0 API commands. Note that the previous version of the Python SDK (1.2.0) is also compatible with the current BlackPearl 3.0.1 release but does not give access to all API commands.

Significant code structure changes were made between the 1.2.0 and 3.0.0 release of the Python SDKs. If you will be upgrading an existing client from 1.2.0 to 3.0.0, you should read our Migration Guide, which describes the changes in more detail. We do not anticipate major code structure changes in the future.

The previous 1.x versions of the Python SDK required that that C SDK also be installed. This new 3.0.0 Python SDK is no longer dependent on the C SDK and therefore no longer requires that the C SDK be installed.

We call this 3.0.0 release a “Pre-Release” because, while it has been tested internally, it is not yet in use by any of our partners or customers.

With this SDK release, all four of our SDKs -- Python, C, Java, and .NET/C# -- are now up to date with BlackPearl 3.x code and support all BlackPearl API commands.

If you have any questions or run into any problems, please post your questions to our Forum.


BlackPearl 3.0 C SDK Now Available

We have released new version 3.0.0 of our BlackPearl Software Development Kit (SDK) for the C programming language. It is now available for download on GitHub. You can also view code documentation, code examples, and installation instructions on our Documentation page.

This new SDK is compatible with our current BlackPearl 3.0.1 release and allows access to all BlackPearl 3.0 API commands. Note that the previous version of the C SDK (1.2.0) is also compatible with the current BlackPearl 3.0.1 release but does not give access to all API commands.

Some code structure changes were made between the 1.2.0 and 3.0.0 release of the C SDKs. If you will be upgrading an existing client from 1.2.0 to 3.0.0, you should read our previous blog post Preparing for the BlackPearl 3.0 Release, which describes the changes in more detail.

We call this 3.0.0 release a “Pre-Release” because, while it has been tested internally, it is not yet in use by any of our partners or customers.

If you have any questions or run into any problems, please post your questions to our Forum.


Managing Ejected Tapes in BlackPearl

BlackPearl is an object storage gateway to Spectra’s archive disk and tape library products. Tape libraries have a unique feature not typically available in disk systems – the tapes can be ejected and removed from the tape library. This removal can allow for additional data protection by taking the tapes offsite, and it can also facilitate sharing of the data via physical transport. But once ejected and removed, the data on the tape can no longer be accessed by the tape library.

When a BlackPearl client requests data to be restored from BlackPearl, it is possible that the only copy of the data resides on tape(s) that have been ejected from the library. BlackPearl clients should be designed to handle this ejected tape scenario. Handling the ejected tape scenario is a requirement to pass Spectra certification.

BlackPearl Response to Data on Ejected Tape

When a client attempts to restore data from BlackPearl, it first issues a Create Bulk Get API command to BlackPearl. This command is used by the client to let BlackPearl know which files it wants to retrieve. If any of these files are only available on ejected tape(s), then BlackPearl’s raw API response will be as follows:

If the BlackPearl client is using one of our Software Development Kits (SDKs), which themselves call the Create Bulk Get API command, the SDK will throw an exception in this scenario. Here is the exception thrown by the Java SDK when requested files are only on ejected tapes:

Properly Handling Requests for Data on Ejected Tapes

You can see that in both responses above, BlackPearl indicates that one or more needed tapes are outside of the tape library and provides the barcode label(s) of the tape(s) that have been ejected in brackets. In the example above, the barcode label of the ejected tape is TEST079L7 . In most cases, simply displaying this message to the user should be adequate for the user to use the barcode label to go find the tapes and place them back in the tape library. The user can then try their restore request again and BlackPearl should be able to service it.

In some cases, the user may need more information about the tapes than just the barcode label. Tapes also have other ejection information associated with them, such as Eject Label and Eject Location, that users may need to find the tape. In that case, clients can register to receive a job failure notification. A job is what BlackPearl attempts to create when the Create Bulk Get command above is called. A notification is a message that BlackPearl sends to the client application. If the Create Bulk Get command can’t be serviced because a needed tape is outside of the library, then the job creation fails. BlackPearl clients can register to receive Job Creation Failed Notifications. These notifications includes detailed information about the ejected tapes that are needed to service the file restore request, including the Eject Label and Eject Location.

If a BlackPearl client wants to take a more proactive approach, the client can provide users with a means of checking to see if tapes are ejected before attempting a file restore. The Get Physical Placement API call, and its associated SDK calls, can be used to check the placement of a file or list of files. The Get Physical Placement response will include a list of specific locations where the files are located, whether that location is on disk, tape, or another BlackPearl. If the files are located on tape, the response will include the tape barcode labels and whether or not the tapes are ejected from the library. If the tapes are ejected, additional ejection information will be provided, including the Eject Label and Eject Location.

Message from BlackPearl Web Interface About Ejected Tapes

The BlackPearl web management interface includes a Messages page (Status > Messages) for viewing system event messages. Users can also set up their BlackPearl user account to receive these messages via email.

If a BlackPearl client attempts to restore files that are only available on ejected tapes, a warning message will be added to the Messages page. The message will indicate that a GET request was attempted but couldn’t be serviced because it requires tapes that are ejected from the library. The message will also include the barcode label, Eject Label, and Eject Location of all required ejected tapes. While these messages can be useful to the user, BlackPearl clients shouldn’t depend on the user having to access this Messages page to learn about the ejected tapes.

Conclusion

Developers should ensure that their BlackPearl client applications properly handle requests for data on ejected tapes. There are several methods available to address this scenario. Please Contact the Developer Team if you have any questions about managing ejected tapes.