[j-nsp] router-jockeys and gui tools

[Keegan Holley]

I agree.  I could even add a few.  A big one is control.  I had a supervisor once who now works for juniper ironically  say he didn’t like tools because he didn’t want to start forgetting the commands.  I asked if he was ok with all of engineering using prod routers as a practice ground.  He just shrugged...

It definitely depends on the work to be done though.  Repetitive tasks or large scale changes are easier and less prone to error when done by a computer of some sort. Upgrading JunOS on more than one router at a time.  deploying VRF’s, or LSP’s, modifying routing policies across a bunch of routers.

 I usually subscribe to the skepticism, but as with everything the devil is in the details.  Sometimes it’s annoying when engineers disparage a tool when it is clearly better for the task at hand.

Good post though,

Keegan

On Mar 5, 2014, at 10:32 AM, Phil Shafer <phil at juniper.net> wrote:

> [hijacking part of a thread from Keegan]
> 
> Keegan Holley writes:
>> My gut says this is as much a product of Space being new as the general skeptcisim most 
>> router-jockeys have towards GUI/WebUI based management tools.
> 
> As the on-box CLI developer, this has always been an area of interest
> to me.  My gut says the router-jockey/gui repulsion is powered by:
> 
> a) completeness
>   Everything one can do with a router is available in the CLI,
>   where GUIs tend to carry a subset and will have a time lag
>   WRT availability.  Part of this is driven by the tool-makers
>   view of how their particular customer set works, and part
>   is driven by the need to attack the biggest and most visible
>   problems.
> 
> b) text/email friendly
>   Pasting config into email and using "show | compare" allow
>   simple obvious differences.  Diffing the output of two
>   HTML divs is, well, difficult.
> 
> c) power tools
>   If you want to repeat a command, "^P" is blindingly fast.
>   Add in bindings like ESC-. and ESC-/ (and ^R) and you can
>   get many jobs done faster at a CLI than in a GUI.
> 
> d) trust
>   If I say "set interfaces xe-0/0/0 family inet filter output foo",
>   then I know exacly what I did and how it will work.  When the GUI has
>   a field/drop-down and I select "foo", I'm trusting the app to do
>   the right thing, and to let me know when it cannot.
> 
> e) inertia
>   I completely understand inertia.  I'm writing this email using
>   vi under mh, chiefly because no one can pull the procmail needle
>   from my arm.  Tools are addictive.  If they work, you use them
>   more.  If they don't, you use them less.
> 
> Even in the face of these factors, there's definitely movement in
> the GUI arena.  As tools evolve and are able to show more data and
> as the volume of data demands tools that let you explore (not just
> view) data, we need to find ways to keep the valuable portions of
> the CLI world, while allowing data access for web tools.  Visualization
> is becoming more important, and as someone who tried to make
> Sparklines in ascii for op script output, I can definitely say that
> the tty-based CLI is very limiting.
> 
> In JUNOS, we've had our XML APIs for >13 years, and the tight binding
> between the CLI and the API ensure that feature parity is constant
> and consistent.  We're working to find ways to expand on this, and
> while I don't have anything to share yet, I'd love to hear back (on
> or off list) regarding the items listed above and any additional
> factors that keep you committed to the CLI with a loyalty that would
> do Charlton Heston proud.
> 
> Thanks,
> Phil
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp