Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Add gslb/dns abstraction #25

Closed
DumpySquare opened this issue Apr 3, 2023 · 1 comment
Closed

[RFE] Add gslb/dns abstraction #25

DumpySquare opened this issue Apr 3, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@DumpySquare
Copy link
Member

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.

@DumpySquare DumpySquare added the enhancement New feature or request label Apr 3, 2023
@DumpySquare DumpySquare self-assigned this Apr 16, 2023
@DumpySquare
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant