You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by James Peach <jp...@apache.org> on 2015/02/05 19:11:01 UTC
RFC: replacing traffic_line
Hi all,
Just a heads-up. I've been frustrated by the limits of traffic_line for a while now, so I finally got around to implementing a replacement. Next week (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is intended as a replacement for traffic_line, with a regular extensible syntax that will let us expose much more functionality.
traffic_line will remain in the tree, but I hope to remove it for the 6.0 release (TS-3368).
A sample traffic_ctl session:
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
Subcommands:
alarm Manipulate alarms
cluster Stop, restart and examine the cluster
config Manipulate configuration records
metric Manipulate performance metrics
server Stop, restart and examine the server
storage Manipulate cache storage
Options:
switch__________________type__default___description
--debug on false Enable debugging output
-h, --help Print usage information
-V, --version Print version string
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
Usage: traffic_ctl config CMD [ARGS ...]
Subcommands:
describe Show detailed information about configuration values
get Get one or more configuration values
match Get configuration matching a regular expression
reload Request a configuration reload
set Set a configuration value
status Check the configuration status
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
Options:
switch__________________type__default___description
--records on false Emit output in records.config format
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match proxy.config.ssl
proxy.config.ssl.number.threads: 0
...
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records proxy.config.ssl
CONFIG proxy.config.ssl.number.threads INT 0
CONFIG proxy.config.ssl.client.verify.server INT 0
...
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get proxy.config.ssl.enabled proxy.config.ssl.session_cache
proxy.config.ssl.enabled: 0
proxy.config.ssl.session_cache: 2
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set proxy.config.dns.resolv_conf /my/great/resolv.conf
set proxy.config.dns.resolv_conf, restart required
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015 at 09:19:53)
Started at Thu Feb 5 09:26:31 2015
Last reconfiguration at Thu Feb 5 09:26:30 2015
Configuration is current
traffic_server requires restarting
Re: replacing traffic_line
Posted by Leif Hedstrom <zw...@apache.org>.
> On Feb 5, 2015, at 6:35 PM, Yongming Zhao <mi...@gmail.com> wrote:
>
> UI is most end user cares, I’d like we should keep the traffic_line. traffic_ctl sounds perfect, can we have both? and can you please think of reimplement some of the commands in the removed traffic_shell?
fwiw, most of the commands to “read” stuff is available in the traffic_shell.pl script.
— Leif
>
> thanks
>
>
> - Yongming Zhao 赵永明
>
>> 在 2015年2月6日，上午5:07，James Peach <jp...@apache.org> 写道：
>>
>>
>>> On Feb 5, 2015, at 12:16 PM, Bin Zeng <bz...@linkedin.com.INVALID> wrote:
>>>
>>> It is great someone is expanding the functionality of traffic_line. *thumbs up*. My questions might sound naive. Why are we replacing traffic_line with traffic_ctl (traffic_ctl is a better name arguably)? It seems disruptive to retire traffic_line because some people might depend on it. Is there a way to expand traffic_line in place with all the functionality you proposed to maintain backwards compatibility?
>>
>> I thought a lot about this, but in the end I don't think it's possible to retain compatibility with the traffic_line options and add the new traffic_ctl subcommands. If it were possible, then the implementation and usage complexity might be an issue.
>>
>> Since traffic_line is unmodified, we can keep it around for as long as we want. However, once traffic_ctl ships, it will be deprecated and no longer enhanced.
>>
>>
>>> ________________________________________
>>> From: James Peach [jpeach@apache.org]
>>> Sent: Thursday, February 05, 2015 10:11 AM
>>> To: dev
>>> Subject: RFC: replacing traffic_line
>>>
>>> Hi all,
>>>
>>> Just a heads-up. I've been frustrated by the limits of traffic_line for a while now, so I finally got around to implementing a replacement. Next week (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is intended as a replacement for traffic_line, with a regular extensible syntax that will let us expose much more functionality.
>>>
>>> traffic_line will remain in the tree, but I hope to remove it for the 6.0 release (TS-3368).
>>>
>>> A sample traffic_ctl session:
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
>>> Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
>>>
>>> Subcommands:
>>> alarm Manipulate alarms
>>> cluster Stop, restart and examine the cluster
>>> config Manipulate configuration records
>>> metric Manipulate performance metrics
>>> server Stop, restart and examine the server
>>> storage Manipulate cache storage
>>>
>>> Options:
>>> switch__________________type__default___description
>>> --debug on false Enable debugging output
>>> -h, --help Print usage information
>>> -V, --version Print version string
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
>>> Usage: traffic_ctl config CMD [ARGS ...]
>>>
>>> Subcommands:
>>> describe Show detailed information about configuration values
>>> get Get one or more configuration values
>>> match Get configuration matching a regular expression
>>> reload Request a configuration reload
>>> set Set a configuration value
>>> status Check the configuration status
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
>>> Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
>>>
>>> Options:
>>> switch__________________type__default___description
>>> --records on false Emit output in records.config format
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match proxy.config.ssl
>>> proxy.config.ssl.number.threads: 0
>>> ...
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records proxy.config.ssl
>>> CONFIG proxy.config.ssl.number.threads INT 0
>>> CONFIG proxy.config.ssl.client.verify.server INT 0
>>> ...
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get proxy.config.ssl.enabled proxy.config.ssl.session_cache
>>> proxy.config.ssl.enabled: 0
>>> proxy.config.ssl.session_cache: 2
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set proxy.config.dns.resolv_conf /my/great/resolv.conf
>>> set proxy.config.dns.resolv_conf, restart required
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
>>> Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015 at 09:19:53)
>>> Started at Thu Feb 5 09:26:31 2015
>>> Last reconfiguration at Thu Feb 5 09:26:30 2015
>>> Configuration is current
>>> traffic_server requires restarting
>>>
>>
>
Re: replacing traffic_line
Posted by James Peach <jp...@apache.org>.
> On Feb 10, 2015, at 4:06 AM, Igor Galić <i....@brainsware.org> wrote:
>
>
>
> ----- On 6 Feb, 2015, at 05:12, James Peach jpeach@apache.org wrote:
>
>>> On Feb 5, 2015, at 5:35 PM, Yongming Zhao <mi...@gmail.com> wrote:
>>>
>>> UI is most end user cares, I’d like we should keep the traffic_line. traffic_ctl
>>> sounds perfect, can we have both?
>>
>> We can have both for a while, but I don't think we should have both forever.
>
> we can replace traffic_line with a (shell?) script which calls to traffic_ctl
> potentially, *maybe* with a deprecation warning. if we do, we can keep it
> around "forever", for "backwards compatibility"
That would work as long as we were not concerned about the exact output of traffic_line.
>
>
>>> and can you please think of reimplement some of the commands in the removed
>>> traffic_shell?
>>
>> Yeh, it's really easy to add new subcommands to traffic_ctl. What commands were
>> you thinking of?
>>
>>>
>>> thanks
>>>
>>>
>>> - Yongming Zhao 赵永明
>>>
>>>> 在 2015年2月6日，上午5:07，James Peach <jp...@apache.org> 写道：
>>>>
>>>>
>>>>> On Feb 5, 2015, at 12:16 PM, Bin Zeng <bz...@linkedin.com.INVALID> wrote:
>>>>>
>>>>> It is great someone is expanding the functionality of traffic_line. *thumbs up*.
>>>>> My questions might sound naive. Why are we replacing traffic_line with
>>>>> traffic_ctl (traffic_ctl is a better name arguably)? It seems disruptive to
>>>>> retire traffic_line because some people might depend on it. Is there a way to
>>>>> expand traffic_line in place with all the functionality you proposed to
>>>>> maintain backwards compatibility?
>>>>
>>>> I thought a lot about this, but in the end I don't think it's possible to retain
>>>> compatibility with the traffic_line options and add the new traffic_ctl
>>>> subcommands. If it were possible, then the implementation and usage complexity
>>>> might be an issue.
>>>>
>>>> Since traffic_line is unmodified, we can keep it around for as long as we want.
>>>> However, once traffic_ctl ships, it will be deprecated and no longer enhanced.
>>>>
>>>>
>>>>> ________________________________________
>>>>> From: James Peach [jpeach@apache.org]
>>>>> Sent: Thursday, February 05, 2015 10:11 AM
>>>>> To: dev
>>>>> Subject: RFC: replacing traffic_line
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Just a heads-up. I've been frustrated by the limits of traffic_line for a while
>>>>> now, so I finally got around to implementing a replacement. Next week
>>>>> (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is
>>>>> intended as a replacement for traffic_line, with a regular extensible syntax
>>>>> that will let us expose much more functionality.
>>>>>
>>>>> traffic_line will remain in the tree, but I hope to remove it for the 6.0
>>>>> release (TS-3368).
>>>>>
>>>>> A sample traffic_ctl session:
>>>>>
>>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
>>>>> Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
>>>>>
>>>>> Subcommands:
>>>>> alarm Manipulate alarms
>>>>> cluster Stop, restart and examine the cluster
>>>>> config Manipulate configuration records
>>>>> metric Manipulate performance metrics
>>>>> server Stop, restart and examine the server
>>>>> storage Manipulate cache storage
>>>>>
>>>>> Options:
>>>>> switch__________________type__default___description
>>>>> --debug on false Enable debugging output
>>>>> -h, --help Print usage information
>>>>> -V, --version Print version string
>>>>>
>>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
>>>>> Usage: traffic_ctl config CMD [ARGS ...]
>>>>>
>>>>> Subcommands:
>>>>> describe Show detailed information about configuration values
>>>>> get Get one or more configuration values
>>>>> match Get configuration matching a regular expression
>>>>> reload Request a configuration reload
>>>>> set Set a configuration value
>>>>> status Check the configuration status
>>>>>
>>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
>>>>> Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
>>>>>
>>>>> Options:
>>>>> switch__________________type__default___description
>>>>> --records on false Emit output in records.config format
>>>>>
>>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
>>>>> proxy.config.ssl
>>>>> proxy.config.ssl.number.threads: 0
>>>>> ...
>>>>>
>>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records
>>>>> proxy.config.ssl
>>>>> CONFIG proxy.config.ssl.number.threads INT 0
>>>>> CONFIG proxy.config.ssl.client.verify.server INT 0
>>>>> ...
>>>>>
>>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get
>>>>> proxy.config.ssl.enabled proxy.config.ssl.session_cache
>>>>> proxy.config.ssl.enabled: 0
>>>>> proxy.config.ssl.session_cache: 2
>>>>>
>>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set
>>>>> proxy.config.dns.resolv_conf /my/great/resolv.conf
>>>>> set proxy.config.dns.resolv_conf, restart required
>>>>>
>>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
>>>>> Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015
>>>>> at 09:19:53)
>>>>> Started at Thu Feb 5 09:26:31 2015
>>>>> Last reconfiguration at Thu Feb 5 09:26:30 2015
>>>>> Configuration is current
>>>>> traffic_server requires restarting
>>>>>
>>>>
>
> --
> 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: replacing traffic_line
Posted by Igor Galić <i....@brainsware.org>.
----- On 6 Feb, 2015, at 05:12, James Peach jpeach@apache.org wrote:
>> On Feb 5, 2015, at 5:35 PM, Yongming Zhao <mi...@gmail.com> wrote:
>>
>> UI is most end user cares, I’d like we should keep the traffic_line. traffic_ctl
>> sounds perfect, can we have both?
>
> We can have both for a while, but I don't think we should have both forever.
we can replace traffic_line with a (shell?) script which calls to traffic_ctl
potentially, *maybe* with a deprecation warning. if we do, we can keep it
around "forever", for "backwards compatibility"
>> and can you please think of reimplement some of the commands in the removed
>> traffic_shell?
>
> Yeh, it's really easy to add new subcommands to traffic_ctl. What commands were
> you thinking of?
>
>>
>> thanks
>>
>>
>> - Yongming Zhao 赵永明
>>
>>> 在 2015年2月6日，上午5:07，James Peach <jp...@apache.org> 写道：
>>>
>>>
>>>> On Feb 5, 2015, at 12:16 PM, Bin Zeng <bz...@linkedin.com.INVALID> wrote:
>>>>
>>>> It is great someone is expanding the functionality of traffic_line. *thumbs up*.
>>>> My questions might sound naive. Why are we replacing traffic_line with
>>>> traffic_ctl (traffic_ctl is a better name arguably)? It seems disruptive to
>>>> retire traffic_line because some people might depend on it. Is there a way to
>>>> expand traffic_line in place with all the functionality you proposed to
>>>> maintain backwards compatibility?
>>>
>>> I thought a lot about this, but in the end I don't think it's possible to retain
>>> compatibility with the traffic_line options and add the new traffic_ctl
>>> subcommands. If it were possible, then the implementation and usage complexity
>>> might be an issue.
>>>
>>> Since traffic_line is unmodified, we can keep it around for as long as we want.
>>> However, once traffic_ctl ships, it will be deprecated and no longer enhanced.
>>>
>>>
>>>> ________________________________________
>>>> From: James Peach [jpeach@apache.org]
>>>> Sent: Thursday, February 05, 2015 10:11 AM
>>>> To: dev
>>>> Subject: RFC: replacing traffic_line
>>>>
>>>> Hi all,
>>>>
>>>> Just a heads-up. I've been frustrated by the limits of traffic_line for a while
>>>> now, so I finally got around to implementing a replacement. Next week
>>>> (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is
>>>> intended as a replacement for traffic_line, with a regular extensible syntax
>>>> that will let us expose much more functionality.
>>>>
>>>> traffic_line will remain in the tree, but I hope to remove it for the 6.0
>>>> release (TS-3368).
>>>>
>>>> A sample traffic_ctl session:
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
>>>> Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
>>>>
>>>> Subcommands:
>>>> alarm Manipulate alarms
>>>> cluster Stop, restart and examine the cluster
>>>> config Manipulate configuration records
>>>> metric Manipulate performance metrics
>>>> server Stop, restart and examine the server
>>>> storage Manipulate cache storage
>>>>
>>>> Options:
>>>> switch__________________type__default___description
>>>> --debug on false Enable debugging output
>>>> -h, --help Print usage information
>>>> -V, --version Print version string
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
>>>> Usage: traffic_ctl config CMD [ARGS ...]
>>>>
>>>> Subcommands:
>>>> describe Show detailed information about configuration values
>>>> get Get one or more configuration values
>>>> match Get configuration matching a regular expression
>>>> reload Request a configuration reload
>>>> set Set a configuration value
>>>> status Check the configuration status
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
>>>> Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
>>>>
>>>> Options:
>>>> switch__________________type__default___description
>>>> --records on false Emit output in records.config format
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
>>>> proxy.config.ssl
>>>> proxy.config.ssl.number.threads: 0
>>>> ...
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records
>>>> proxy.config.ssl
>>>> CONFIG proxy.config.ssl.number.threads INT 0
>>>> CONFIG proxy.config.ssl.client.verify.server INT 0
>>>> ...
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get
>>>> proxy.config.ssl.enabled proxy.config.ssl.session_cache
>>>> proxy.config.ssl.enabled: 0
>>>> proxy.config.ssl.session_cache: 2
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set
>>>> proxy.config.dns.resolv_conf /my/great/resolv.conf
>>>> set proxy.config.dns.resolv_conf, restart required
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
>>>> Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015
>>>> at 09:19:53)
>>>> Started at Thu Feb 5 09:26:31 2015
>>>> Last reconfiguration at Thu Feb 5 09:26:30 2015
>>>> Configuration is current
>>>> traffic_server requires restarting
>>>>
>>>
--
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: replacing traffic_line
Posted by Yongming Zhao <mi...@gmail.com>.
yeah, the perl version is nice to be used in show:xxx, but most of the features in config:xxx is not implemented, as most of the config commands broken and I don’t want to bring them back, I’d like to have the following feature or subcommands:
1, cache: enable disable and clear
2, hostdb: clear(may add more such as bypass/disable etc)
3, the hard-restart, maybe we can put it into server command
4, remap <URL>, load a remap file from the URL, nice or bad?
4, and other product features to be managed, such as socks enable/disable.
I know we have some more detailed documents show us how to enable socks and you can do it by several 'traffic_line -s’ commands, but ATS lack of the product point of view control center, which is build into traffic_shell config commands when back in the old days, the UI is just same a Cisco Router interface. I’d like to bring something nice to the users back if you would rebuild the control commands.
thanks
> 在 2015年2月6日，下午12:12，James Peach <jp...@apache.org> 写道：
>
>
>> On Feb 5, 2015, at 5:35 PM, Yongming Zhao <mi...@gmail.com> wrote:
>>
>> UI is most end user cares, I’d like we should keep the traffic_line. traffic_ctl sounds perfect, can we have both?
>
> We can have both for a while, but I don't think we should have both forever.
>
>> and can you please think of reimplement some of the commands in the removed traffic_shell?
>
> Yeh, it's really easy to add new subcommands to traffic_ctl. What commands were you thinking of?
>
>>
>> thanks
>>
>>
>> - Yongming Zhao 赵永明
>>
>>> 在 2015年2月6日，上午5:07，James Peach <jp...@apache.org> 写道：
>>>
>>>
>>>> On Feb 5, 2015, at 12:16 PM, Bin Zeng <bz...@linkedin.com.INVALID> wrote:
>>>>
>>>> It is great someone is expanding the functionality of traffic_line. *thumbs up*. My questions might sound naive. Why are we replacing traffic_line with traffic_ctl (traffic_ctl is a better name arguably)? It seems disruptive to retire traffic_line because some people might depend on it. Is there a way to expand traffic_line in place with all the functionality you proposed to maintain backwards compatibility?
>>>
>>> I thought a lot about this, but in the end I don't think it's possible to retain compatibility with the traffic_line options and add the new traffic_ctl subcommands. If it were possible, then the implementation and usage complexity might be an issue.
>>>
>>> Since traffic_line is unmodified, we can keep it around for as long as we want. However, once traffic_ctl ships, it will be deprecated and no longer enhanced.
>>>
>>>
>>>> ________________________________________
>>>> From: James Peach [jpeach@apache.org]
>>>> Sent: Thursday, February 05, 2015 10:11 AM
>>>> To: dev
>>>> Subject: RFC: replacing traffic_line
>>>>
>>>> Hi all,
>>>>
>>>> Just a heads-up. I've been frustrated by the limits of traffic_line for a while now, so I finally got around to implementing a replacement. Next week (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is intended as a replacement for traffic_line, with a regular extensible syntax that will let us expose much more functionality.
>>>>
>>>> traffic_line will remain in the tree, but I hope to remove it for the 6.0 release (TS-3368).
>>>>
>>>> A sample traffic_ctl session:
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
>>>> Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
>>>>
>>>> Subcommands:
>>>> alarm Manipulate alarms
>>>> cluster Stop, restart and examine the cluster
>>>> config Manipulate configuration records
>>>> metric Manipulate performance metrics
>>>> server Stop, restart and examine the server
>>>> storage Manipulate cache storage
>>>>
>>>> Options:
>>>> switch__________________type__default___description
>>>> --debug on false Enable debugging output
>>>> -h, --help Print usage information
>>>> -V, --version Print version string
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
>>>> Usage: traffic_ctl config CMD [ARGS ...]
>>>>
>>>> Subcommands:
>>>> describe Show detailed information about configuration values
>>>> get Get one or more configuration values
>>>> match Get configuration matching a regular expression
>>>> reload Request a configuration reload
>>>> set Set a configuration value
>>>> status Check the configuration status
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
>>>> Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
>>>>
>>>> Options:
>>>> switch__________________type__default___description
>>>> --records on false Emit output in records.config format
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match proxy.config.ssl
>>>> proxy.config.ssl.number.threads: 0
>>>> ...
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records proxy.config.ssl
>>>> CONFIG proxy.config.ssl.number.threads INT 0
>>>> CONFIG proxy.config.ssl.client.verify.server INT 0
>>>> ...
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get proxy.config.ssl.enabled proxy.config.ssl.session_cache
>>>> proxy.config.ssl.enabled: 0
>>>> proxy.config.ssl.session_cache: 2
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set proxy.config.dns.resolv_conf /my/great/resolv.conf
>>>> set proxy.config.dns.resolv_conf, restart required
>>>>
>>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
>>>> Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015 at 09:19:53)
>>>> Started at Thu Feb 5 09:26:31 2015
>>>> Last reconfiguration at Thu Feb 5 09:26:30 2015
>>>> Configuration is current
>>>> traffic_server requires restarting
>>>>
>>>
>>
>
- Yongming Zhao 赵永明
Re: replacing traffic_line
Posted by James Peach <jp...@apache.org>.
> On Feb 5, 2015, at 5:35 PM, Yongming Zhao <mi...@gmail.com> wrote:
>
> UI is most end user cares, I’d like we should keep the traffic_line. traffic_ctl sounds perfect, can we have both?
We can have both for a while, but I don't think we should have both forever.
> and can you please think of reimplement some of the commands in the removed traffic_shell?
Yeh, it's really easy to add new subcommands to traffic_ctl. What commands were you thinking of?
>
> thanks
>
>
> - Yongming Zhao 赵永明
>
>> 在 2015年2月6日，上午5:07，James Peach <jp...@apache.org> 写道：
>>
>>
>>> On Feb 5, 2015, at 12:16 PM, Bin Zeng <bz...@linkedin.com.INVALID> wrote:
>>>
>>> It is great someone is expanding the functionality of traffic_line. *thumbs up*. My questions might sound naive. Why are we replacing traffic_line with traffic_ctl (traffic_ctl is a better name arguably)? It seems disruptive to retire traffic_line because some people might depend on it. Is there a way to expand traffic_line in place with all the functionality you proposed to maintain backwards compatibility?
>>
>> I thought a lot about this, but in the end I don't think it's possible to retain compatibility with the traffic_line options and add the new traffic_ctl subcommands. If it were possible, then the implementation and usage complexity might be an issue.
>>
>> Since traffic_line is unmodified, we can keep it around for as long as we want. However, once traffic_ctl ships, it will be deprecated and no longer enhanced.
>>
>>
>>> ________________________________________
>>> From: James Peach [jpeach@apache.org]
>>> Sent: Thursday, February 05, 2015 10:11 AM
>>> To: dev
>>> Subject: RFC: replacing traffic_line
>>>
>>> Hi all,
>>>
>>> Just a heads-up. I've been frustrated by the limits of traffic_line for a while now, so I finally got around to implementing a replacement. Next week (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is intended as a replacement for traffic_line, with a regular extensible syntax that will let us expose much more functionality.
>>>
>>> traffic_line will remain in the tree, but I hope to remove it for the 6.0 release (TS-3368).
>>>
>>> A sample traffic_ctl session:
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
>>> Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
>>>
>>> Subcommands:
>>> alarm Manipulate alarms
>>> cluster Stop, restart and examine the cluster
>>> config Manipulate configuration records
>>> metric Manipulate performance metrics
>>> server Stop, restart and examine the server
>>> storage Manipulate cache storage
>>>
>>> Options:
>>> switch__________________type__default___description
>>> --debug on false Enable debugging output
>>> -h, --help Print usage information
>>> -V, --version Print version string
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
>>> Usage: traffic_ctl config CMD [ARGS ...]
>>>
>>> Subcommands:
>>> describe Show detailed information about configuration values
>>> get Get one or more configuration values
>>> match Get configuration matching a regular expression
>>> reload Request a configuration reload
>>> set Set a configuration value
>>> status Check the configuration status
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
>>> Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
>>>
>>> Options:
>>> switch__________________type__default___description
>>> --records on false Emit output in records.config format
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match proxy.config.ssl
>>> proxy.config.ssl.number.threads: 0
>>> ...
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records proxy.config.ssl
>>> CONFIG proxy.config.ssl.number.threads INT 0
>>> CONFIG proxy.config.ssl.client.verify.server INT 0
>>> ...
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get proxy.config.ssl.enabled proxy.config.ssl.session_cache
>>> proxy.config.ssl.enabled: 0
>>> proxy.config.ssl.session_cache: 2
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set proxy.config.dns.resolv_conf /my/great/resolv.conf
>>> set proxy.config.dns.resolv_conf, restart required
>>>
>>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
>>> Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015 at 09:19:53)
>>> Started at Thu Feb 5 09:26:31 2015
>>> Last reconfiguration at Thu Feb 5 09:26:30 2015
>>> Configuration is current
>>> traffic_server requires restarting
>>>
>>
>
Re: replacing traffic_line
Posted by Yongming Zhao <mi...@gmail.com>.
UI is most end user cares, I’d like we should keep the traffic_line. traffic_ctl sounds perfect, can we have both? and can you please think of reimplement some of the commands in the removed traffic_shell?
thanks
- Yongming Zhao 赵永明
> 在 2015年2月6日，上午5:07，James Peach <jp...@apache.org> 写道：
>
>
>> On Feb 5, 2015, at 12:16 PM, Bin Zeng <bz...@linkedin.com.INVALID> wrote:
>>
>> It is great someone is expanding the functionality of traffic_line. *thumbs up*. My questions might sound naive. Why are we replacing traffic_line with traffic_ctl (traffic_ctl is a better name arguably)? It seems disruptive to retire traffic_line because some people might depend on it. Is there a way to expand traffic_line in place with all the functionality you proposed to maintain backwards compatibility?
>
> I thought a lot about this, but in the end I don't think it's possible to retain compatibility with the traffic_line options and add the new traffic_ctl subcommands. If it were possible, then the implementation and usage complexity might be an issue.
>
> Since traffic_line is unmodified, we can keep it around for as long as we want. However, once traffic_ctl ships, it will be deprecated and no longer enhanced.
>
>
>> ________________________________________
>> From: James Peach [jpeach@apache.org]
>> Sent: Thursday, February 05, 2015 10:11 AM
>> To: dev
>> Subject: RFC: replacing traffic_line
>>
>> Hi all,
>>
>> Just a heads-up. I've been frustrated by the limits of traffic_line for a while now, so I finally got around to implementing a replacement. Next week (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is intended as a replacement for traffic_line, with a regular extensible syntax that will let us expose much more functionality.
>>
>> traffic_line will remain in the tree, but I hope to remove it for the 6.0 release (TS-3368).
>>
>> A sample traffic_ctl session:
>>
>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
>> Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
>>
>> Subcommands:
>> alarm Manipulate alarms
>> cluster Stop, restart and examine the cluster
>> config Manipulate configuration records
>> metric Manipulate performance metrics
>> server Stop, restart and examine the server
>> storage Manipulate cache storage
>>
>> Options:
>> switch__________________type__default___description
>> --debug on false Enable debugging output
>> -h, --help Print usage information
>> -V, --version Print version string
>>
>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
>> Usage: traffic_ctl config CMD [ARGS ...]
>>
>> Subcommands:
>> describe Show detailed information about configuration values
>> get Get one or more configuration values
>> match Get configuration matching a regular expression
>> reload Request a configuration reload
>> set Set a configuration value
>> status Check the configuration status
>>
>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
>> Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
>>
>> Options:
>> switch__________________type__default___description
>> --records on false Emit output in records.config format
>>
>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match proxy.config.ssl
>> proxy.config.ssl.number.threads: 0
>> ...
>>
>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records proxy.config.ssl
>> CONFIG proxy.config.ssl.number.threads INT 0
>> CONFIG proxy.config.ssl.client.verify.server INT 0
>> ...
>>
>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get proxy.config.ssl.enabled proxy.config.ssl.session_cache
>> proxy.config.ssl.enabled: 0
>> proxy.config.ssl.session_cache: 2
>>
>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set proxy.config.dns.resolv_conf /my/great/resolv.conf
>> set proxy.config.dns.resolv_conf, restart required
>>
>> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
>> Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015 at 09:19:53)
>> Started at Thu Feb 5 09:26:31 2015
>> Last reconfiguration at Thu Feb 5 09:26:30 2015
>> Configuration is current
>> traffic_server requires restarting
>>
>
Re: replacing traffic_line
Posted by James Peach <jp...@apache.org>.
> On Feb 5, 2015, at 12:16 PM, Bin Zeng <bz...@linkedin.com.INVALID> wrote:
>
> It is great someone is expanding the functionality of traffic_line. *thumbs up*. My questions might sound naive. Why are we replacing traffic_line with traffic_ctl (traffic_ctl is a better name arguably)? It seems disruptive to retire traffic_line because some people might depend on it. Is there a way to expand traffic_line in place with all the functionality you proposed to maintain backwards compatibility?
I thought a lot about this, but in the end I don't think it's possible to retain compatibility with the traffic_line options and add the new traffic_ctl subcommands. If it were possible, then the implementation and usage complexity might be an issue.
Since traffic_line is unmodified, we can keep it around for as long as we want. However, once traffic_ctl ships, it will be deprecated and no longer enhanced.
> ________________________________________
> From: James Peach [jpeach@apache.org]
> Sent: Thursday, February 05, 2015 10:11 AM
> To: dev
> Subject: RFC: replacing traffic_line
>
> Hi all,
>
> Just a heads-up. I've been frustrated by the limits of traffic_line for a while now, so I finally got around to implementing a replacement. Next week (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is intended as a replacement for traffic_line, with a regular extensible syntax that will let us expose much more functionality.
>
> traffic_line will remain in the tree, but I hope to remove it for the 6.0 release (TS-3368).
>
> A sample traffic_ctl session:
>
> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
> Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
>
> Subcommands:
> alarm Manipulate alarms
> cluster Stop, restart and examine the cluster
> config Manipulate configuration records
> metric Manipulate performance metrics
> server Stop, restart and examine the server
> storage Manipulate cache storage
>
> Options:
> switch__________________type__default___description
> --debug on false Enable debugging output
> -h, --help Print usage information
> -V, --version Print version string
>
> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
> Usage: traffic_ctl config CMD [ARGS ...]
>
> Subcommands:
> describe Show detailed information about configuration values
> get Get one or more configuration values
> match Get configuration matching a regular expression
> reload Request a configuration reload
> set Set a configuration value
> status Check the configuration status
>
> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
> Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
>
> Options:
> switch__________________type__default___description
> --records on false Emit output in records.config format
>
> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match proxy.config.ssl
> proxy.config.ssl.number.threads: 0
> ...
>
> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records proxy.config.ssl
> CONFIG proxy.config.ssl.number.threads INT 0
> CONFIG proxy.config.ssl.client.verify.server INT 0
> ...
>
> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get proxy.config.ssl.enabled proxy.config.ssl.session_cache
> proxy.config.ssl.enabled: 0
> proxy.config.ssl.session_cache: 2
>
> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set proxy.config.dns.resolv_conf /my/great/resolv.conf
> set proxy.config.dns.resolv_conf, restart required
>
> [vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
> Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015 at 09:19:53)
> Started at Thu Feb 5 09:26:31 2015
> Last reconfiguration at Thu Feb 5 09:26:30 2015
> Configuration is current
> traffic_server requires restarting
>
RE: replacing traffic_line
Posted by Bin Zeng <bz...@linkedin.com.INVALID>.
It is great someone is expanding the functionality of traffic_line. *thumbs up*. My questions might sound naive. Why are we replacing traffic_line with traffic_ctl (traffic_ctl is a better name arguably)? It seems disruptive to retire traffic_line because some people might depend on it. Is there a way to expand traffic_line in place with all the functionality you proposed to maintain backwards compatibility?
________________________________________
From: James Peach [jpeach@apache.org]
Sent: Thursday, February 05, 2015 10:11 AM
To: dev
Subject: RFC: replacing traffic_line
Hi all,
Just a heads-up. I've been frustrated by the limits of traffic_line for a while now, so I finally got around to implementing a replacement. Next week (hopefully), I'll be landing a new tool named traffic_ctl (TS-3367). This is intended as a replacement for traffic_line, with a regular extensible syntax that will let us expose much more functionality.
traffic_line will remain in the tree, but I hope to remove it for the 6.0 release (TS-3368).
A sample traffic_ctl session:
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl
Usage: traffic_ctl [OPTIONS] CMD [ARGS ...]
Subcommands:
alarm Manipulate alarms
cluster Stop, restart and examine the cluster
config Manipulate configuration records
metric Manipulate performance metrics
server Stop, restart and examine the server
storage Manipulate cache storage
Options:
switch__________________type__default___description
--debug on false Enable debugging output
-h, --help Print usage information
-V, --version Print version string
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config
Usage: traffic_ctl config CMD [ARGS ...]
Subcommands:
describe Show detailed information about configuration values
get Get one or more configuration values
match Get configuration matching a regular expression
reload Request a configuration reload
set Set a configuration value
status Check the configuration status
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match
Usage: traffic_ctl config match [OPTIONS] REGEX [REGEX ...]
Options:
switch__________________type__default___description
--records on false Emit output in records.config format
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match proxy.config.ssl
proxy.config.ssl.number.threads: 0
...
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config match --records proxy.config.ssl
CONFIG proxy.config.ssl.number.threads INT 0
CONFIG proxy.config.ssl.client.verify.server INT 0
...
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config get proxy.config.ssl.enabled proxy.config.ssl.session_cache
proxy.config.ssl.enabled: 0
proxy.config.ssl.session_cache: 2
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config set proxy.config.dns.resolv_conf /my/great/resolv.conf
set proxy.config.dns.resolv_conf, restart required
[vagrant@localhost ~]$ sudo /opt/ats/bin/traffic_ctl config status
Apache Traffic Server - traffic_server - 5.3.0 - (build # 020509 on Feb 5 2015 at 09:19:53)
Started at Thu Feb 5 09:26:31 2015
Last reconfiguration at Thu Feb 5 09:26:30 2015
Configuration is current
traffic_server requires restarting