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 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.
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.
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.
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
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.
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:
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.
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:
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.
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.