Patching

Patching refers to the process of applying updates, fixes, or patches to the software and configurations including infrastructure upgrades.

More specifically:

• Patching software images and CVEs
• Upgrading infrastructure
• Changing configuration

Info

Like other features, patching is NOT a simple lipstick on stateful sets but something carefully designed for stateful systems.

We overcome the common challenges to have per node configuration, provide visibility into the upgrade process, provide customization etc.

Moreover, patching 1 machine is different from patching the whole fleet. We have built an end-to-end system that allows you to manage different types of upgrades from images, infrastructure, operating system to configuration across all of your customers and have the control/flexibility to meet the needs of different customers at the same time without manual toil.

Types of Patching

Let's look into each of scenarios and understand some of the usecases better:

Patching software

There might be many reasons to patch software:

• Security Updates: to address security vulnerabilities and apply security patches promptly
• Bug Fixes: to address these issues, improving the overall reliability of the service
• Feature Enhancements: to introduce new features or capabilities, enhancing its functionality and usability
• Performance Enhancements: to better response times and infrastructure utilization

Upgrading infrastructure

You may have to upgrade infrastructure due to several reasons:

• Replace end of life hardware
• Improve price to performance ratio
• Feature enhancements

Changing configuration

You may have to change configuration:

• Better defaults
• Add or remove configuration due to feature enhancements/depreciation
• Evolve your SaaS experience

Patching Lifecycle

Now, let's look into how Omnistrate helps address the Patching across different scenarios. The patching lifecycle is divided into 3 phases:

Make changes

At Omnistrate, all the changes across software, configuration or infrastructure are versioned. As soon as you release a new version, that version is locked and immutable.

To better manage different versions, each version has an associated state. Today, there are 3 possible states:

• Active: Active version in the system that are valid versions in the system. They can be marked as Preferred or can be an upgrade target for the existing customer resource instances.
• Preferred: Preferred version in the system that will be used by existing and newer customers for any new usage. There can only be 1 and only 1 Preferred version in the system at any given time. If you promote another Active version as Preferred, the previous Preferred version state will automatically change back to Active.
• Deprecated: Deprecated versions in the system that are no longer valid. By definition, there can't be any customer resource instances associated with the deprecated versions.

Every time, you make a change to your SaaS, Omnistrate will automatically create a new unreleased version or append changes to a unreleased version. Once the changes are released, that version is marked as released and can't be changed anymore.

By default, the newer versions are released as Active that can be marked as Preferred at any time. You may want to run some tests before marking it as Preferred to be a default version used by your customers.

You can see the list of all the plan versions on the View Plan Versions screen.

How to make the changes?

If you have already created a SaaS, you can use CTL/API/UI to make further changes. If you want to update the service with a new version of docker compose, CTL is the recommended way. You can also visit "Build Service" in UI/API. Your SaaS service may have several service plans for your customers.

You have to then select the service plan that you want to update by clicking "Build Plan", see below:

You will then see a DAG of different service components. You can add/remove a service component or update the dependencies or modify different elements of the service component. To learn more about different elements of the service component, see this

Note

Note that Omnistrate versions all of your control plane (or your SaaS) changes so that you can keep track, audit, rollback your changes. In addition, you can define the migration strategy for the existing resources owned by different tenants.

Here is some more information if you are trying to modify different elements of the service component (also see highlighted in green in the picture below):

• Updating API parameters: To make any changes to API parameters, select the component and visit API parameters section to view/modify/delete the corresponding API parameters.
• Updating configuration: To make any changes to your service component configuration, select the component and visit the environment variables section to view/modify/delete them. We support two kinds of configuration: 1/ static 2/ dynamic. For Dynamic configuration, you can wire any API parameter as the value to your configuration. This will allow you to customize the stack for your customers and serve their needs respectively.
• Updating images: To make any changes to image, visit the infrastructure tab and make the required changes
• Updating infrastructure: To make any changes to infrastructure, visit the Compute, Network and Storage tabs and make the required changes. Note that you can also configure your infrastructure dynamically in the same way as service configuration (discussed above) by wiring API parameter to your infrastructure configuration
• Updating action hooks: To make any changes to action hooks, select the component and visit the action hooks section. Action hooks are at two levels: 1/ nodes 2/ cluster. Please select the scope, then select the type of action hook that you want to update.
• Configuring capabilities: To add/remove capabilities, click on the Capabilities tab and make the required changes
• Adding/Removing integrations: To add/remove integrations, click on the Integrations tab and make the required changes
• Updating service dependencies: You can define service dependencies from the dependencies section. Note that, if service component B depends on A, then you have to map all required API params of B from API params of A.

Once the changes are made, you have to release them for them to take effect.

Also - if you want your new customers to see the latest changes, you have to make the release or the new version as Preferred.

Schedule upgrades

Over time, there might be several Preferred versions and you may want to upgrade customer resource instances running on older version to use newer version.

Omnistrate lets you define upgrade paths as one-off patch or upgrade all resource instances on a given version to a different valid version.

Once upgraded, the older version can be deprecated over time to manage the number of active versions in the fleet.

Manage ongoing upgrades

Manage upgrades allows you to manage all the scheduled upgrades and track the status of each one of them. You can look at the details to get a specific status of any resource instance thats part of this upgrade.

Omnistrate automatically figures out the deployment plan and roll it out to your fleet. In addition, Omnistrate act as a central nervous system for all the activities in your fleet and coordinates them appropriately to avoid interference across multiple operations on the same resources.

Separately, Omnistrate follows the dependency structure between your service components to upgrade them in the right order. As an example, if A depends on B, then we will first upgrade dependencies and then the parent resource to ensure minimal disruption and maintain high availability throughout the upgrade process.

If you notice any issue during upgrade, you may pause or cancel a scheduled upgrade, or skip customer resource instance from the scheduled upgrade if its not already started.

Note

If you decide to pause or cancel a scheduled upgrade, it will pause or cancel only unscheduled resource instances. The current resource instances with upgrade in progress will continue to proceed.

If you really want to cancel upgrades to resource instances in progress, you will have to pause or cancel the corresponding workflows