Suggestion is for NA to offer built-in Reg-Ex tester to work with Policy Rule content creation.
While there are countless Reg-Ex testing websites and applications, this should be focused on handling Network Automation Policy Rule content and aware of what can | cannot be done within them.
This would assist users who are not farmiliar with Reg-Ex to take advantage of it and be confident with their rules as they are able to easily see their expressions perform as they need. Also would provide quick create option to quickly add Policy (Rules) to address issues that have come up by referencing data that is collected by the tools.
The Reg-Ex tester function could contain the following options / look / feel:
a) pop-out window that is user activated when they want it. Example: User is building out a policy rule, they have checked the box for reg-ex content to be included for config block. This activates the Reg-Ex tester and they can move off to the side and use when needed. Within the Reg-Ex tester, have option to load in data to work with (similar to how you can do Policy testing - you can either specify a few devices or data - here you could point to config|OS|diag data or provide your own to test against). When they are satisfied with their Reg-Ex validation, they could press a button in the tester window and the validated expression would be pasted into the policy rule condition. Similar could be done with text block definition as well, just need a check box that would trigger Reg-Ex tester window.
b) could provide option when they are looking at config, OS or diag data and have option to create a specific policy (rule) to the selected problem they are working on. When Policy Rule window is displayed, the built-in Reg-Ex window comes up along with the config|OS|diag data in the test data area. Have option to assist with handling blocks of data (interface blocks, acl blocks, etc) and then referencing that data within the block criteria. (within the tester, you could see what was getting selected or excluded and therefore you could easily see the block setup perspecitive and therefore, from a block condition perspecitive. Example: You set up a block to exclude Loopback and FDDI interfaces, so when you are working on your conditions, you see in the sample data that you have to work with, those interfaces are not active (removed, different color, not highlighted, etc).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.