<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 3/22/21 15:14, Mike Hammett wrote:<br>
<br>
</div>
<blockquote type="cite"
cite="mid:1947061781.397.1616418878602.JavaMail.mhammett@Thunderfuck2">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<style type="text/css">p { margin: 0; }</style>
<div style="font-family: arial,helvetica,sans-serif; font-size:
10pt; color: #000000">I would love to have HTTP GUI that just
does all of the dirty work. However, a sufficient number of
people affiliated with that organization do indeed need to be
able to CLI their way through the troubleshooting process for
when the HTTP GUI inevitably fails (everything inevitably
fails).<br>
</div>
</blockquote>
<br>
And this is where it tends to fall flat - when the GUI fails and an
engineer can no longer setup a peering session with CLI.<br>
<br>
The GUI is written in code, much of which will be via CLI. So we
can't really run away from CLI, unless we are saying that CLI is
reserved for those who use it to build the GUI, and not for those
for whom the GUI is being built.<br>
<br>
You can also implement a reasonable amount of automation without a
GUI.<br>
<br>
My goal is to babysit as few layers as possible.<br>
<br>
Mark.<br>
</body>
</html>