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 <jpe...@apache.org> 写道： > > >> On Feb 5, 2015, at 5:35 PM, Yongming Zhao <ming....@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 <jpe...@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 [jpe...@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 赵永明
