You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initial release of this feature is complete and will be released with v1.0.0.
This feature is a draft of the next stage of corkscrew, where key parent objects fully parsed (~90%) into the json tree. A function hooked in between when the individual nested parent object is first created, but right before it gets merged into the bigger tree.
this function, looks for key objects (maily gtm for now), and works through the process of deeper parsing. I tried a second attempt at making some logic to loop through the object and parse out the structure, but ultimately concluded it's complexity vs value was not good enough compared to the regex tree method. It's just so much more clear to break down the config piece by piece with regexes. It's certainly more code, but I believe it will be easier for others to follow should they need to update this project.
Doing all the parsing up front, makes the abstraction process much more simple. The initial code to parse and abstract the gslb details, was about 350 lines. After the deep abstraction refactor, the abstraction is less than 50 lines.
The deeper parsing is critical to enable output for application conversions to other f5 technologies (xc/next/nginx).
So, the key gtm parent objects are fully parsed (gtm server/pool/wideip) and the abstraction process just loops through all the details and collects all the referenced pieces. Starting with the wideip (fqdn) and ending with the server/virtual-server IP:PORT destinations.
Some possible future enhancements to consider;
inspect the gtm iRules to pull out key details like dns destinations/responses
see if topology records may also provide key details to how the wideip may respond (probably not)
provide a list of all possible responses as a single array on the parent wideip object
this would provide a single place to understand all the possible responses without knowing how to analyze the config
like ltm virtual servers, it would be nice to abstract all dns details also.
Starting with a wideIP, and map it back through all the pools and servers it is associated with.
The text was updated successfully, but these errors were encountered: