Sneak Peek: Simple Development Environment for Automation Scripting

IKL Development
#1

Hi Crowd Members,

See below for an exclusive sneak peak of a new capability our product team is working on. We would like your feedback and any ideas for how to improve.

Simple Development Environment for Automation Scripting

We are seeing a growing number of customers who are consuming our automation scripts, now wanting to build their own. We added a text editor in the product. By default, the development environment is disabled. To enable the development environment (6.1.5 or later):

  • Directly go to:https://<indeni-server>/#!/dev/inde

  • From any page add to the url ā€œff=indeā€
    (For example: https://<indeni-server>/#!/alerts/summary?ff=inde) and press enter, you will now see the editor icon on the left side.

Here are a few scenarios that we are exploring to enable everyone:

  • Ability to view script repository. See the collection interval, CLI command or API call used to collect the metrics.
  • Ability to view rule repository. See the rules that are used to trigger the notification along with the remediation steps.
  • Ability to search the alert headline and view the corresponding automation script and the rule.


Image title



Please provide us feedback, such as:

  • Would you want to modify the script? If yes, what woud you change? Interval? Collect additional metrics?
  • What other funcitons we should provide? Text-search?
June Member of the Month: Akshay Desai
#2

1 Like
#3

This is very cool, thanks for sharing!

#4

Fellow IKEā€™sā€¦

@Patrik_Jonsson, @Vasileios_Bouloukos @Hawkeye_Parker @Joakim_Hedberg @JZ1 @Johnathan_Browall_No @Brad_Spilde @Satya_Sreenivas1ā€¦

What do you guys think?

Yes we would like to include Patrikā€™s automated quality code checker at some pointā€¦

#5

This is great stuff, love the syntax highlighting. Easily the best Iā€™ve seen for Indeni scripts.

Brainstorming a bit:

  • Where is the code fetched from?
  • Is content of the overwrite folder reflected here?
  • I think customers will want to be able to edit fully. Maybe there could be a flag next to the ind file name that says ā€œmodifiedā€ in case a customer chooses to edit a script?
  • The mouse cursor when exploring the folder structure changes to a text cursor. Maybe a hand would be more appropriate?
  • If IKEā€™s can develop scripts using the editor, perhaps adding a parse-only option to run the script against a set output (in a separate text area) could be interesting?
  • Would it be possible to add an option to explore the last results by each script on a specific device? Could be really helpful when troubleshooting.

/Patrik

4 Likes
#6

Great feedback! @Amit_Nizri

Where is the code fetched from?
Code source from /usr/share/indeni-knowledge/stable/ā€¦ I think

Is content of the overwrite folder reflected here?
Thatā€™s a great question. I suspect not. But @Amit_Nizri ?

Definitely the ability to explore the last result is particular useful. Thatā€™s on the roadmap already.

#7

Would you want to modify the script? If yes, what woud you change? Interval? Collect additional metrics? Yes, all of the above!
What other funcitons we should provide? Text-search? Search would be great!

Another thing I think would be needed is if we allow for edits, maybe we clone and disable the existing rule prepending the rule name with a ā€œ_ā€ or something to identify that it is a custom edit. The original needs to be disabled so that we donā€™t double write to the database. Also, we should have some way to block the Indeni disabled scripts and rules aka ā€œintentionally disabledā€ from even showing up on the client side.

Thoughts on my suggestions for disabling, naming and blocking?

1 Like
#8

I guess what Iā€™m after here is to know which scripts that is actually loaded in the collector. Would save us from a lot of confusion. :slight_smile:

#9

Brad, just want to clarify, when you say intentionally blocking the ruleā€¦ many of the rules are cross vendor in nature, we donā€™t really want to ā€œintentionally disabledā€ the rule unless we know for sure that other devices are not impacted. Or do you mean stopping the collector from executing the commands on the network device?

#10

@alon or @amit, Patrik has a great question here, are we currently showing the scripts actually loaded in the collector?

#11

This is really neat. I can imagine indeni users being really interested even just to see this kind of information.

Would you want to modify the script? If yes, what woud you change? Interval? Collect additional metrics?

Once I saw the script, I would want to be able to change anything. Interval, definitely; additional metrics, certainly.

What other funcitons we should provide? Text-search?

Text-search, yes. I think certain users will want to explore this space. And, it seems like a great way to encourage users to ā€œbecome IKEsā€. And, providing some view of the rule data and logic would seem pretty critical ā€“ I would love to be able to more easily get a detailed sense of what the rule is doing without having to brain-parse scala.

Otherwise, I guess the big question is: do you try to build an actual development environment? I mean, you could give users full view access, but very limited edit access (just ā€œchange time intervalā€, etc.).

In terms of providing edit access, we already have many, many great text editors and IDEs. Maybe another approach would be to contribute syntax defs for some of the more common environments out there ā€“ i.e., bring ind script to the editor instead of the other way around.

I think thereā€™s a real danger if you give users full edit access to these scripts, without providing a full-featured, robust debugging environment: you risk really frustrating potential IKEs. So, either you need to build the debugging tools (command-runner, metrics data view/edit, psql view edit) into the indeni UI, or make sure that users understand (clear, copious documentation) there are a lot of other tools and information that you will need to make things work.

Writing a script is one thing, but properly debugging and testing a script takes a lot of additional tools and knowledge ā€“ basically the full dev environment (including the wiki) that a lot of us have built up bit by bit.

2 Likes
#12

Hi Hawkeye,
Thank you for your feedback. Very insightful.

Weā€™re in violent agreement when it comes to the rule without being a whiz bang scala programmer :slight_smile: And yes to your next question, we are considering building an actual development environment but like you pointed out, thereā€™re a lot more to it, hence weā€™re soliciting inputs from the industry experts. Besides all the dev and test activities, building the dev environment into the product that is deployed into a production environment also requires more well thought out authorization mechanism.

Interesting thought about bringing ind script to other environment. Weā€™ve thought about that today. If we were to do that, what are the environments we should start looking into?

Good stuffā€¦

Thanks,
Ulrica

1 Like
#13

Iā€™m not sure I know. I donā€™t have much insight into what IDEs/text editors network engineers prefer. I think the wiki recommends Sublime (somewhere). Others that come to mind:

  • Notepad++
  • vim
  • VisualStudio Code
  • atom

But, I would have to do a lot more research to come up with the right (prioritized) list. Good git integration would seem like a really-nice-to-have. Any decent editor should support custom file types (for syntax highlighting, etc.) and/or plugins. Iā€™ve added syntax highlighting to my IDE (intellij idea ā€“ aside from the git integration, I donā€™t recommend for IKE development ā€“ way too heavyweight), and I have a macro for quickly batch-running unit tests. Again, any decent editor should let you integrate with the commandline for hotkey-running common tasks.

I know that as a software developer, youā€™ll never get me out of my IDE ā€“ I have too much customization even for basic editing. If I swtiched to anything else, it would be another lightweight text editor. Itā€™s really hard for me to imagine doing any ā€˜serious editingā€™ with an indeni ā€˜in productā€™ editor. There are just too many great tools either built in to my editor or available on the commandline.

Another point: if a network engineer is interested in indeni to become a better scripter/programmer, then they want to get better at a popular IDE/editor, not a custom indeni thing (that they canā€™t use for any other coding).

I can see how an in-product editor could live nicely alongside the ā€˜every dayā€™ editor ā€“ user uses the in product for quick tweaks and indeni-specific tasks (testing, deployment, etc.) but copies the code out to do anything more serious. But, if thatā€™s the case, the in product editor should probably just have the very basics (think Windows Notepad with syntax highlighting).

You guys know all this. Just thinking outloud.

#14

As Hawkeye pointed out there are alot of popular IDEs.
Notepad++ is nice but feels a bit outdated imho.
Sublime is nice and uses python for extensions which is nice of course, it does come with a price tag(however small).
Atom is very popular as well and has git integration(seeing as itā€™s developed by github).
Itā€™s freeware and(according to themselves the most customizable text-editor).
Atom uses coffee-script/javascript for extensions.

Both Atom and Sublime supports customized languages, and both are nice editors, but for the moment I favor Atom.

2 Likes
#15

I think was I was trying to say is that if we allowed editing we should keep the default rule but disable it. That way there is a rule to revert back to easily if the user edits arenā€™t working correctly. In several other products I work with it is their recommendation that you clone the default rule and prepend the rule with your company name to easily filter rules you know that you customized.

#16

Makes sense. Thanks!