You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2014/01/25 14:37:39 UTC
Replacement for traffic_shell
Hi all,
I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
The new version is virtually identical to the old version, with one small exception; show:alarms does not work. It does mean that in order to use traffic_shell, you must have Perl installed.
Thoughts? I’d like to land this for v5.0.0.
— Leif
Re: Replacement for traffic_shell
Posted by Leif Hedstrom <zw...@apache.org>.
On Jan 25, 2014, at 2:37 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>
> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>
> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
>
>
> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
I should point out that the perl script implements “show:” style commands, I did not implement the “config:” commands. Do people feel that we need the “config:” commands as well?
— Leif
Re: Replacement for traffic_shell
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2014 15:04, schrieb Leif Hedstrom:
> On Jan 25, 2014, at 2:42 PM, Reindl Harald <h....@thelounge.net> wrote:
>>
>> Am 25.01.2014 14:37, schrieb Leif Hedstrom:
>>> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>>>
>>> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>>>
>>> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
>>>
>>>
>>> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
>>>
>>> The new version is virtually identical to the old version, with one small exception; show:alarms does not work. It does mean that in order to use traffic_shell, you must have Perl installed.
>>>
>>> Thoughts? I’d like to land this for v5.0.0
>>
>> sounds reasonable, on a unix system perl is de-facto always there (logwatch, logrotate...)
>> but "leaving only the hash TCL code left" i fear it does not change effective dependencies
>> in case of RPM packages
>
> Correct, but, with traffic_shell (in TCL) out of the way, there’s hope and reason to fix the remaining (small) piece of TCL dependency. The end goal (IMO at least) is to eliminate TCL.
thanks for feedback
i am in general a fan of as less dependencies as possible
you can see that in the df-output of our trafficserver-VM :-)
the 5.8 GB rootfs is because all machines are from the same image
installed 2008 with Fedora 9 and at that time i did not expect
how extremly that can be stripped down over the years.....
the benefit is a lightning fast dist-upgrades with zero dependency troubles
07-01-2014 14:00:00 start dist-upgrade proxy
07-01-2014 14:01:36 dist-upgrade proxy finished
[root@proxy:~]$ df
Filesystem Type Size Used Avail Use% Mounted on
/dev/sdb1 ext4 5.8G 679M 5.2G 12% /
/dev/sda1 ext4 493M 34M 460M 7% /boot
[root@proxy:~]$ rpm -qa | wc -l
287
Re: Replacement for traffic_shell
Posted by Leif Hedstrom <zw...@apache.org>.
On Jan 25, 2014, at 2:42 PM, Reindl Harald <h....@thelounge.net> wrote:
>
> Am 25.01.2014 14:37, schrieb Leif Hedstrom:
>> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>>
>> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>>
>> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
>>
>>
>> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
>>
>> The new version is virtually identical to the old version, with one small exception; show:alarms does not work. It does mean that in order to use traffic_shell, you must have Perl installed.
>>
>> Thoughts? I’d like to land this for v5.0.0
>
> sounds reasonable, on a unix system perl is de-facto always there (logwatch, logrotate...)
> but "leaving only the hash TCL code left" i fear it does not change effective dependencies
> in case of RPM packages
Correct, but, with traffic_shell (in TCL) out of the way, there’s hope and reason to fix the remaining (small) piece of TCL dependency. The end goal (IMO at least) is to eliminate TCL.
— Leif
Re: Replacement for traffic_shell
Posted by Reindl Harald <h....@thelounge.net>.
Am 25.01.2014 14:37, schrieb Leif Hedstrom:
> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>
> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>
> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
>
>
> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
>
> The new version is virtually identical to the old version, with one small exception; show:alarms does not work. It does mean that in order to use traffic_shell, you must have Perl installed.
>
> Thoughts? I’d like to land this for v5.0.0
sounds reasonable, on a unix system perl is de-facto always there (logwatch, logrotate...)
but "leaving only the hash TCL code left" i fear it does not change effective dependencies
in case of RPM packages
[root@proxy:~]$ rpm -qa | grep -i tcl
tcl-8.5.14-1.fc19.x86_64
Re: Replacement for traffic_shell
Posted by Leif Hedstrom <zw...@apache.org>.
The "problem" is that traffic_shell implements the full mgmt APIs in TCL bindings. My replacement only implements the show: commands.
> On Jan 27, 2014, at 2:28 AM, Arno Töll <ar...@debian.org> wrote:
>
> Hi,
>
>> On 25.01.2014 14:37, Leif Hedstrom wrote:
>> Thoughts? I’d like to land this for v5.0.0.
>
> Yay! Do it! Do it!
>
>
>
>> The downside is that we lose the ability to write TCL script using
>> the traffic_shell interpreter. I honestly don’t feel this being a
>> huge problem, particularly if we focus efforts on getting the
>> MgmtAPI’s into modern scripting languages.
>
> if you split actual user interface / CLI handling apart from a
> TrafficServer::Shell module, it's still scriptable for those who need it.
>
> --
> with kind regards,
> Arno Töll
> IRC: daemonkeeper on Freenode/OFTC
> GnuPG Key-ID: 0x9D80F36D
>
Re: Replacement for traffic_shell
Posted by Arno Töll <ar...@debian.org>.
Hi,
On 25.01.2014 14:37, Leif Hedstrom wrote:
> Thoughts? I’d like to land this for v5.0.0.
Yay! Do it! Do it!
>
> The downside is that we lose the ability to write TCL script using
> the traffic_shell interpreter. I honestly don’t feel this being a
> huge problem, particularly if we focus efforts on getting the
> MgmtAPI’s into modern scripting languages.
if you split actual user interface / CLI handling apart from a
TrafficServer::Shell module, it's still scriptable for those who need it.
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
Re: Replacement for traffic_shell
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
>
> On Jan 27, 2014, at 10:27 AM, James Peach <jp...@apache.org> wrote:
>
> >
> > I do want to echo Nick's thoughts about the purpose of traffic_shell
> > though. What's it really for? Does the need for it still exist? Would it
> > make sense to roll its useful parts into traffic_line?
>
>
> A lot of traffic_shell (most?) I don’t think belong in traffic_line. For
> example, all the show: commands. I’ve added the following commands to
> traffic_line so far, I’m still looking for what else might be useful:
>
> —alarms - shows all alarm events which have not been acknowledged
> —clear_alarms [all | #num | name] - Clear the selected alarm(s)
> —status - shows the proxy server state (just like show:status)
>
>
> A lot of traffic_shell just encapsulates two existing traffic_line commands
> (-r and -s -v). I don’t (personally) feel these are useful to add into
> traffic_line, but we could if we wanted to. Instead, I think a script like
> the Perl version of traffic_shell’s show: commands is better.
We should get rid of the duplicate efforts. I'm fairly certain we don't
need 3 or 5 ways to do the same thing. (Even when we only have one way
that is generally poorly documented ;)
> I’d also iterate that traffic_shell was intended as a scripting environment,
> using it in e.g. scripts with #!/usr/bin/traffic_shell. It exposes most of
> the ts/mgmtapi.h C-APIs to the TCL language. Seeing that TCL is pretty much
> an obsolete language, I don’t feel that it’s worthwhile to retain this
> functionality. But if it is, then traffic_shell needs to stay for now.
Seeing how Ruby is becoming a thing in Ops it would be extremely useful
to be able expose the MGMT API to Ruby.
> Cheers,
>
> — Leif
>
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: Replacement for traffic_shell
Posted by Leif Hedstrom <zw...@apache.org>.
On Jan 27, 2014, at 10:27 AM, James Peach <jp...@apache.org> wrote:
>
> I do want to echo Nick's thoughts about the purpose of traffic_shell though. What's it really for? Does the need for it still exist? Would it make sense to roll its useful parts into traffic_line?
A lot of traffic_shell (most?) I don’t think belong in traffic_line. For example, all the show: commands. I’ve added the following commands to traffic_line so far, I’m still looking for what else might be useful:
—alarms - shows all alarm events which have not been acknowledged
—clear_alarms [all | #num | name] - Clear the selected alarm(s)
—status - shows the proxy server state (just like show:status)
A lot of traffic_shell just encapsulates two existing traffic_line commands (-r and -s -v). I don’t (personally) feel these are useful to add into traffic_line, but we could if we wanted to. Instead, I think a script like the Perl version of traffic_shell’s show: commands is better.
I’d also iterate that traffic_shell was intended as a scripting environment, using it in e.g. scripts with #!/usr/bin/traffic_shell. It exposes most of the ts/mgmtapi.h C-APIs to the TCL language. Seeing that TCL is pretty much an obsolete language, I don’t feel that it’s worthwhile to retain this functionality. But if it is, then traffic_shell needs to stay for now.
Cheers,
— Leif
Re: Replacement for traffic_shell
Posted by Leif Hedstrom <zw...@apache.org>.
On Jan 27, 2014, at 10:27 AM, James Peach <jp...@apache.org> wrote:
>
> I do want to echo Nick's thoughts about the purpose of traffic_shell though. What's it really for? Does the need for it still exist? Would it make sense to roll its useful parts into traffic_line?
A lot of traffic_shell (most?) I don’t think belong in traffic_line. For example, all the show: commands. I’ve added the following commands to traffic_line so far, I’m still looking for what else might be useful:
—alarms - shows all alarm events which have not been acknowledged
—clear_alarms [all | #num | name] - Clear the selected alarm(s)
—status - shows the proxy server state (just like show:status)
A lot of traffic_shell just encapsulates two existing traffic_line commands (-r and -s -v). I don’t (personally) feel these are useful to add into traffic_line, but we could if we wanted to. Instead, I think a script like the Perl version of traffic_shell’s show: commands is better.
I’d also iterate that traffic_shell was intended as a scripting environment, using it in e.g. scripts with #!/usr/bin/traffic_shell. It exposes most of the ts/mgmtapi.h C-APIs to the TCL language. Seeing that TCL is pretty much an obsolete language, I don’t feel that it’s worthwhile to retain this functionality. But if it is, then traffic_shell needs to stay for now.
Cheers,
— Leif
Re: Replacement for traffic_shell
Posted by James Peach <jp...@apache.org>.
On Jan 25, 2014, at 5:37 AM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>
> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>
> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
This sounds very promising. I'm fine with perl, as long as it is written cleanly and carefully :)
> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
I do want to echo Nick's thoughts about the purpose of traffic_shell though. What's it really for? Does the need for it still exist? Would it make sense to roll its useful parts into traffic_line?
J
Re: Replacement for traffic_shell
Posted by Leif Hedstrom <zw...@apache.org>.
> On Jan 26, 2014, at 4:55 AM, Nick Kew <ni...@apache.org> wrote:
>
>
>> On 26 Jan 2014, at 08:38, Leif Hedstrom wrote:
>>
>> Thoughts?
>
> [Pointy-hair] a full merger of traffic_line and traffic_shell?
Well, traffic_shell is a TCL interpreter. I think many if us would really like to get rid of TCL :).
>
> I haven't tried to think it through (hence poiny hair), but if you've
> hacked on a new replacement for t_s and contemplated what
> functionality belongs in what tool, you could no doubt tell us your
> thoughts on whether/why they should be unified/remain separate?
I think the long term solution is to make bindings for the mgmt APIs for modern scripted languages . Perhaps using SWIG?
That much said, I think there is value to move some traffic_shell functionality over to yraffic_line. I've finished implementing three if them, but let me go back and see what else makes sense.
A lot if the traffic_shell extensions are about presentation of metrics, and as such I don't think they belong in traffic_line, which already has support for reading and writing configs and metrics.
Cheers,
-- Leif
>
> --
> Nick Kew
Re: Replacement for traffic_shell
Posted by Nick Kew <ni...@apache.org>.
On 26 Jan 2014, at 08:38, Leif Hedstrom wrote:
> Thoughts?
[Pointy-hair] a full merger of traffic_line and traffic_shell?
I haven't tried to think it through (hence poiny hair), but if you've
hacked on a new replacement for t_s and contemplated what
functionality belongs in what tool, you could no doubt tell us your
thoughts on whether/why they should be unified/remain separate?
--
Nick Kew
Re: Replacement for traffic_shell
Posted by Tomasz Kuzemko <to...@kuzemko.net>.
Hello,
for me this would be ok.
--
Tomasz Kuzemko
tomasz@kuzemko.net
W dniu 26.01.2014 09:38, Leif Hedstrom pisze:
>
>
>> On Jan 25, 2014, at 7:29 PM, Tomasz Kuzemko <to...@kuzemko.net> wrote:
>>
>> Hello,
>>
>> I use show:alarms in a monitoring script to check if there was any alarm triggered. Is there some other way to do it not using traffic_shell?
>>
>
>
>
> I was thinking of moving a couple of these "status" like commands into traffic_line. So e,g.
>
> traffic_line -a
>
>
> would produce identical output to the old show:alarms command . Would that be acceptable for now?
>
> Long term I wish to implement all the mgmt APIs for scripted languages , but it's a lot more work. And I do feel that e.g. show:alarms functionality should be in traffic_line anyways .
>
> Thoughts?
>
> -- Leif
>
>
>> --
>> Tomasz Kuzemko
>> tomasz@kuzemko.net
>>
>> W dniu 25.01.2014 14:37, Leif Hedstrom pisze:
>>> Hi all,
>>>
>>> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>>>
>>> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>>>
>>> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
>>>
>>>
>>> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
>>>
>>> The new version is virtually identical to the old version, with one small exception; show:alarms does not work. It does mean that in order to use traffic_shell, you must have Perl installed.
>>>
>>> Thoughts? I’d like to land this for v5.0.0.
>>>
>>> — Leif
>>>
Re: Replacement for traffic_shell
Posted by Leif Hedstrom <zw...@apache.org>.
> On Jan 25, 2014, at 7:29 PM, Tomasz Kuzemko <to...@kuzemko.net> wrote:
>
> Hello,
>
> I use show:alarms in a monitoring script to check if there was any alarm triggered. Is there some other way to do it not using traffic_shell?
>
I was thinking of moving a couple of these "status" like commands into traffic_line. So e,g.
traffic_line -a
would produce identical output to the old show:alarms command . Would that be acceptable for now?
Long term I wish to implement all the mgmt APIs for scripted languages , but it's a lot more work. And I do feel that e.g. show:alarms functionality should be in traffic_line anyways .
Thoughts?
-- Leif
> --
> Tomasz Kuzemko
> tomasz@kuzemko.net
>
> W dniu 25.01.2014 14:37, Leif Hedstrom pisze:
>> Hi all,
>>
>> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>>
>> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>>
>> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
>>
>>
>> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
>>
>> The new version is virtually identical to the old version, with one small exception; show:alarms does not work. It does mean that in order to use traffic_shell, you must have Perl installed.
>>
>> Thoughts? I’d like to land this for v5.0.0.
>>
>> — Leif
>>
Re: Replacement for traffic_shell
Posted by Tomasz Kuzemko <to...@kuzemko.net>.
Hello,
I use show:alarms in a monitoring script to check if there was any alarm
triggered. Is there some other way to do it not using traffic_shell?
--
Tomasz Kuzemko
tomasz@kuzemko.net
W dniu 25.01.2014 14:37, Leif Hedstrom pisze:
> Hi all,
>
> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>
> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>
> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
>
>
> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
>
> The new version is virtually identical to the old version, with one small exception; show:alarms does not work. It does mean that in order to use traffic_shell, you must have Perl installed.
>
> Thoughts? I’d like to land this for v5.0.0.
>
> — Leif
>
Re: Replacement for traffic_shell
Posted by Leif Hedstrom <zw...@apache.org>.
On Jan 25, 2014, at 2:37 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>
> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>
> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
>
>
> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
I should point out that the perl script implements “show:” style commands, I did not implement the “config:” commands. Do people feel that we need the “config:” commands as well?
— Leif
Re: Replacement for traffic_shell
Posted by James Peach <jp...@apache.org>.
On Jan 25, 2014, at 5:37 AM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I’ve written a replacement for traffic_shell, entirely in Perl using our Perl Admin module. This has two benefits:
>
> 1) It eliminates a huge dependency on TCL (and readline or similar lib), leaving only the hash TCL code left.
>
> 2) I feel it makes for a more manageable tool, that we can now improve / work on more easily.
This sounds very promising. I'm fine with perl, as long as it is written cleanly and carefully :)
> The downside is that we lose the ability to write TCL script using the traffic_shell interpreter. I honestly don’t feel this being a huge problem, particularly if we focus efforts on getting the MgmtAPI’s into modern scripting languages.
I do want to echo Nick's thoughts about the purpose of traffic_shell though. What's it really for? Does the need for it still exist? Would it make sense to roll its useful parts into traffic_line?
J