4.7. Deleting an SSL Orchestrator Configuration

4.7.1. What it is

SSL Orchestrator objects are reusable. That is, the objects that SSL Orchestrator workflows create (i.e. SSL settings, services, service chains, and policies) are reusable across topologies. This is a beneficial characteristic because it allows you to create configurations that are simple and easy to manage.

For example, if you need to create separate outbound L3 and explicit forward proxy topologies that will basically do the same thing, decrypt the same way, and send to the same services, both of these topologies can use the same reusable objects. This is also an important consideration when deleting topologies. As objects are shareable across topologies, deleting a topology does not delete the relying objects, like SSL settings, services, service chains, and policies. The one exception to this is Interception Rules, which are specific to the topology and thus deleted with it. In this chapter, we will explore the different ways that topologies and objects can be removed from the system.

4.7.2. How to remove it

Because topologies, and their dependent SSL Orchestrator objects, can be deleted using various method, each will be explored below.

Deleting topologies

Deleting a topology is done by selecting the topology in the SSL Orchestrator UI and clicking the Delete button. This action will also delete the respective interception rule(s).

Deleting dependent objects

While deleting a topology also removes its respective interception rule(s), it does not remove the other objects that it creates, as these are shareable across multiple topologies. These can, however, be removed individually. Like other F5 BIG-IP objects, SSL Orchestrator objects are hierarchical. That is, they possess nested dependencies.

For example, an LTM virtual server references pools and profiles. Therefore, it would not be possible to delete a pool or profile referenced by a virtual server without either removing the dependency or deleting the virtual server. The same goes for SSL Orchestrator. A topology minimally references SSL settings and security policies. Security policies reference service chains. And service chains reference services. So, to delete any of these objects requires deleting them in the correct dependency order.


Figure 77: Object Dependencies

From the above diagram:

  • A topology, as the base container object, can be deleted anytime.

  • SSL settings can be deleted once they are no longer referenced by a topology.

  • A security policy can be deleted once it is no longer referenced by a topology.

  • A service chain can be deleted once it is no longer referenced by a security policy.

  • Services can be deleted once they are no longer referenced by any service chains.

To delete dependent objects, select them in the SSL Orchestrator UI and click the Delete button.

Deleting everything

To completely remove the SSL Orchestrator configuration, including topologies and all dependent objects, a separate delete function is provided in the UI. Click on the trash can icon in the top right corner of the screen.


Figure 78: Deleting a Configuration

This process will take some time as it moves through all of the objects and dependencies to remove all SSL Orchestrator configurations. At this point you can begin building new configurations.

Starting from scratch

There may be occasions when simply deleting an SSL Orchestrator configuration is not enough, or when there are issues that are not resolved by doing this. In this case, to completely rebuild SSL Orchestrator, follow these steps in order, up to a desirable clean state.

Starting from Scratch

User Input

Standard delete functions

In the SSL Orchestrator UI, click the Delete button (trash can). This process will take some time as SSL Orchestrator moves through all of the objects and dependencies.

Deleting iApp objects

In the event that deleting SSL Orchestrator configurations is not successful using the above action, deleting all of the template objects may be useful to reset to a stable state.

  • Under iApps -> ApplicationServices -> ApplicationsLX, un-deploy any remaining deployed objects. Then delete all of the SSL Orchestrator objects. If using the Access Guided Configuration for APM, these objects will appear here, too. Make sure to only delete the SSL Orchestrator objects. Note that any applications in a “deploying” state cannot be deleted. In this case, select the object and toggle the deploy and un-deploy buttons until the object is no longer in a deploying state. It can then be deleted.

  • Under iApps -> Templates -> Templates LX, delete all of the SSL Orchestrator templates.

  • Under iApps -> Package Management LX, uninstall the SSL Orchestrator package.

Once all of the above are deleted, re-install an SSL Orchestrator RPM package.

HA mode considerations

If in an HA mode and individual iApp objects must be deleted, the above procedure must be performed on both devices.

Clearing rest storage

In the event that objects remain after performing the above actions, it may be necessary to clear and reset the restnoded database. Issue the following command from the BIG-IP command line:

clear-rest-storage -l (lowercase L)

This command will remove any remaining (potentially corrupted) SSL Orchestrator objects from the restnoded database. Check to see if SSL Orchestrator-related configuration objects remain, including LTM virtual servers, pools, profiles, and iRules. Keep in mind that this option will completely remove and reset any SSL Orchestrator configuration, so only use if the above options are not successful in returning to a functional state.

Seek assistance

If after all of the above are performed and the SSL Orchestrator remains in an unstable state, seek assistance from F5 support.

Recovering from a failed deployment

In the event when updating an object fails and leaves the SSL Orchestrator in a “pending operation” state, there are generally two options:

  1. Attempt to delete the pending object. This is the object that failed the update and shows in the SSL Orchestrator UI as being in a pending operation state. Deleting the object will delete the pending operation, leaving the original (pre-update) object behind.

  2. Navigate to iApps -> Applications -> Applications LX in the F5 Big-IP UI. The failed object(s) will display a red square (error). Delete any objects in an error state to recover from the failed update.