[RFE] collect orphaned objects

[DumpySquare]

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

https://github.com/johnalam/F5_BigIP_Orphaned_objects

---

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

[DumpySquare]

notes from Hyde:

irules not referenced by
• virtual server
• local traffic policy? # Pretty sure traffic policies can’t reference iRules.
• APM policy? # Need to look into this
node not referenced by:
• pools
• irules # Interestingly, the iRule node reference does not have to be to a node configured on the device – don’t know if this would create a run time error, but likely not. Wouldn’t complicate orphan checking.
• local traffic policy # Same thing as node references in iRules. Though it does bark if you specify a port with a “:” separator. It does take a space followed by a port, though the instructions say to enter the IPv4 / 6 address.
• data-groups # For node references, only usable in iRules, so the same observation applies.
monitors not referenced by:
• pools
• pool members
• nodes
• default node monitor
• iRules? # There isn’t an iRule command to specify a monitor that I’ve seen. Maybe iRulesLX?
pools not referenced by:
• virtual servers
• iRules
• local traffic policies
• data-groups
files (certs/keys/iFiles/ExternalMonitors) not referenced by: # These have different potential use cases, so I’d think breaking them out is easier to manage. Certs / keys can be referenced in SSL profiles and monitors.. maybe in rules.
# I haven’t looked into iFiles and External Monitors yet..
• ssl profiles (client/server)
• iRules
• local traffic policies?
• data-groups?
snat-pool not referenced by:
• virtual servers
• iRules
• data-groups? # I’d think so. I’m going with the idea that if you can reference it in an iRule, than you can pull that reference from a data-group.
Persistence profile not referenced by:
• virtual servers # persist is an iRule command, but doesn’t reference a defined persistence profile
Non-persistence profile not referenced by:
• virtual servers
• iRules # Looks like SSL profiles can be referenced in iRules. Need to look at other profiles.