[RFE] collect orphaned objects #18
Description
User would like some visibility into what objects have been orphaned or not in use.
Since we can't rely on the system for confirming most of this, we have to define all the things we need to search
Objects to search for orphaned status
irules not referenced by
- virtual server
- local traffic policy?
- APM policy?
node not referenced by:
- pools
- irules
- local traffic policy
- data-groups
monitors not referenced by:
- pools
- iRules?
pools not referenced by:
- virtual servers
- iRules
- local traffic policies
- data-groups
files (certs/keys/iFiles/ExternalMonitors) not referenced by:
- ssl profiles (client/server)
- iRules
- local traffic policies?
- data-groups?
snat-pool not referenced by:
- virtual servers
- iRules
- data-groups?
Phase-2
could look deeper for all the different profiles/reference/inheritance options.
- http profiles
- tcp profiles
- logging/hsl
- asm
- apm
- ...
Othere Efforts
Jon has started putting together some basic scripts that work directly with a device
Implementation
I see the following approaches:
1. Find objects not in application extraction (top down approach)
- After app extraction is complete, look through all the different configuration object types (nodes/pools/monitors/...) and look for any reference in any of the extracted application config groups (more like a top down approach)
- This would probably provide the deepest level of inspection since it would identify objects not referenced as part of the whole virtual-server/application config and supporting elements
- But relies on the thoroughness of the application extraction process
- this has proven to be pretty thorough so far
- Good thing is that TMOS will not let you delete directly referenced objects, other than through iRules
- should catch situations like an iRule that references a node/pool+monitor configuration but not actually referenced by anything else (multi-level orphaned object trees)
2. Tag referenced objects as part of the application extraction process
- Tag each parent object with a "referenced_by" array when being pulled into each application extraction
- Then search for all the objects without a tag
- kind of a middle ground of the two approaches
3. Filter through all the object groups for direct references (bottom up approach)
- this would take the same route as any other the referenced scrips or individual methods
- would not reference any of the extracted applications config sets
- loop through each object type and check other key objects to see if it's referenced
- example, loop through every irule name to see if it is referenced by any virtual servers
- This approach would require multiple passes to identify non-referenced objects, remove those object, then run this process again to identify freshly orphaned objects (example, irule referencing a pool with nodes and monitors)
Output
The output of this would be a list of all the objects that are orphaned, but could also provide another array of commands to delete those objects... :)
The delete function/output is probably best left for the vscode-f5 extension where this data is typically presented. This delete function could also be used for the extracted applications (to delete applications being extracted and moved), so feed it a list of tmos parent objects (or object names), then return a list of commands to delete those objects. (would we need to sort and/or group the objects?)
Additional thoughts
Was talking with a customer a while back, and the approach then was to crawl the API for objects and stats, then periodically reset the stats and recollect all the information again. After a couple of iterations the information could be plotted in a dashboard and show, using stats, which object were not actually being used.
Just wanted to mention this to track the idea of confirming orphaned status with stats, but probably little bang for the processing buck when the other options fit the end goal