On 17 May 2017, at 15:54, Nishant Gaurav wrote:
Hi everyone,
I work as a part of Traffic team at LinkedIn. Our team has a use case
where
we want to reload ‘remap.config’ without restarting trafficserver.
I
understand that I can use ‘traffic_ctl config reload’ command for
the same,
but we don’t want dependence on an external process to run
traffic_ctl.
In the medium term, can you reconsider this? I don’t know of any
drawbacks to running traffic_manager.
In order to achieve this I submitted this pull request
<https://github.com/apache/trafficserver/pull/1815/files> last week,
in
which I introduced a new API function 'TSRemapConfigReload()' which
can
reload remap.config. The way we are using it is that we have a thread
(running as a part of plugin) which keeps on polling a git mirror at
regular interval. Once it identifies that there is a change in
remap.config
file in that git mirror, it pulls the new file and replaces the the
old
config file with the new one on disk (with creating a backup of the
previous one). After doing that it calls TSRemapConfigReload() to
reload
the new remap.config.
To elaborate a bit … I think that just having TSRemapConfigReload() is
not sufficient. There are potentially lots of reload cases and I think
that having a single API that covers just one of those makes for
unwieldy and unsatisfying usage. What I would like to see is a really
good reason that the existing management API could not be used, in
conjunction with a proposal that covers approximately the same set of
use cases.
Without knowing anything about your deployment, it seems so easy to
write something like a small Go program to do the poll and call
TSReconfigure that I don’t really understand why you’d want to do
this in a plugin :)
The corresponding pull request for this was not accepted as James
pointed
out that plugin is not the correct place to do it. As an alternative
he
suggested that we can use ‘TSReconfigure()’ which is part of
‘mgmtapi.h’.
The problem with that is, the functions as a part of management API
are not
available inside plugins.
AFAIK it’s fine for plugins to use the management API, but of course
you would need to be running traffic_manager for it to work. The main
drawbacks to using the management API that I can think of are that it is
blocking, and that it uses a single global socket internally, so you
would need to guarantee that only one plugin at a time is using it.
cheers,
James