Components

Components are what make OpsLevel a truly extensible Software Catalog. They allow you to track, standardize best practices against, and relate any object in your software catalog.

Getting Started with Components

To get started with Components, you must first define a Component Type in OpsLevel. You can do this directly from OpsLevel's UI. This can be done by using the navigation menu Settings > Component Types.

Every account comes with a default Component Type of Service. This Type cannot be deleted or have its name changed.

To define a new component type, select + New Component Type.

Component Types contain 3 pieces of information:

Display Name: The name of the property users will see when navigating around the OpsLevel UI.
Identifier: The unique identifier used to identify the component type from our API, tools, opslevel.yml, etc. Note: The Identifier is auto generated based on the Display Name but can be changed.
Description: Helper text that will provide more context into what this Component Type is used to track in your software catalog.

After filling out the required fields and adding a description, press Save to create a Component Type definition.

Once your new Component type is defined, you will be navigated to the Component Edit Page. From here you can see the Default Properties applied to your component and a place to define new Custom Properties.

To learn more about Custom Properties and how to define them, refer to our Custom Properties documentation.

Changing Types

A component's type can be modified from the UI the same as any other component field in OpsLevel.

Warning: Since component types are tied to a specific set of property definitions, they should be changed with care. When re-assigning a property type:

• All default property values will remain the same
• All custom property value assignments will be lost, except those that have a matching property definition on both the old and new type.

OpsLevel protects against this in a number of different ways, depending on the use case:

UI

To facilitate component type migrations, the entire property diff can be seen on the UI before saving changes to a component's type. Here's an example:

Here, we can see "Mobile App" has 5 properties on the left, while "Library" has only 2. All Mobile App properties that don't have a matching definition on library will be permanently lost on updating the component type. These are marked in red, i.e. device_compatibility, last_update, platform, and release_date. Library has a new property definition for eol, seen in green, which will be set initially as null. Finally, both types have a definition for version, so that value assignment will be left in tact.

On pressing "Update", the component type will be updated, and the red property values will be irrevocably lost.

API & Tooling

To update a component's type via API token, all property definitions that exist on the source type and not on the destination type must have no assigned values.

To simplify migration of a large number of components using the API or CLI, either:

1. Ensure the destination component type has an equal property definition for every source component type property, OR
2. Unassign all component property values corresponding to source properties that don't exist on the new type.

Config

When changing an existing component's type via opslevel.yml, there are a few different scenarios:

• If no property assignments will be lost by changing types your component will be updated immediately.
• If only property assignments managed in opslevel.yml will be lost or changed, same as above.
• If one or more property assignments not in opslevel.yml will be lost, then OpsLevel will generate an error on the service which an owner must confirm via the UI. This uses the same modal as in the above UI section, and will show any new property values from the opslevel.yml in the right side of the diff. The component type will only be changed after this error has been manually confirmed.