[I] Improving `traffic_ctl config reload` [trafficserver]

["cmcfarlen (via GitHub)" <gi...@apache.org>]

cmcfarlen opened a new issue, #12324:
URL: https://github.com/apache/trafficserver/issues/12324

   I would like to propose a new way for ATS to handle `config reload` that will hopefully provide more feedback and information to the user.
   
   Current issues:
   - `traffic_ctl config reload` asks `traffic_server` to reload its config.  The config reload command first enumerates the files it has watches on to check for changes and then it signals subsystems that have changes that they should reconfigure itself.  The file checks happen while the traffic_ctl client is waiting and if that process is slow, could result in a timeout which gives ambiguous results.  When the timeout happens, the configuration still proceeds.
   - There isn't any structured way to get status or results of a reload.  Tooling is left to parse log files if they need to determine when and if the configuration finished successfully.
   
   New proposal:
   - Initiating a reconfigure traffic_ctl config reload should return status immediately without doing more work than necessary to either start a reconfigure or fail (if a reconfig is already running).  The status result should indicate if a reconfigure was started, and return a token representing the current reconfigure operation. (i.e either return the token for the ongoing config, or the token representing the new reconfigure if one is not running currently).  All other work should be done in a background continuation (including spinning through the changed files, even records.yaml).
   - ATS should keep track of the information regarding the outcome and details of the last reconfigure.  This result should be viewable via structured data (json) from a traffic_ctl command.  The information should list the files changed and the result of whatever reconfigure operation resulted from that change (the callback).  The information should also indicate the status of the reconfigure op (success, fail or ongoing) and details about records.yaml validation. Bonus points if there is some indication of progress of incomplete operation (i.e. “10 of 25 files reconfigured”).
   - A client that requests a reconfigure can use the returned token and then poll `traffic_ctl config status`to positively determine when the reconfigure operation is complete.
   
   This change in behavior could be made transparent to traffic_ctl config reload if we adjust the client side of that command to issue the start reconfigure and then poll for status.  This way the config reload command could provide progress if requested or at least be able to give better information should there be issues with the configuration.  (i.e. it could wait until the configuration is started or wait until it is completely finished before returning status)
   
   See the sequence diagram below that shows the new proposal.  Consider a totally hypothetical mechanism where a virtual filesystem is used to access secrets(certificates) that are stored off host and accessed over a network.  This new mechanism will not require the traffic_ctl client to wait on a slow network and could also return progress information to the client.
   
   
   ![Image](https://github.com/user-attachments/assets/fab7e5af-7956-403f-befa-887a74637319)
   
    


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@trafficserver.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Improving `traffic_ctl config reload` [trafficserver]

["djcarlin (via GitHub)" <gi...@apache.org>]

djcarlin commented on issue #12324:
URL: https://github.com/apache/trafficserver/issues/12324#issuecomment-4513278592

   I saw an issue today editing plugin.config (e.g. adding a new global header_rewrite.so /path/to/conf line) followed by traffic_ctl config reload:
   
   - traffic_ctl returns success
   - traffic_ctl config status shows Reconfigured at: `<timestamp>`, Reconfigure required: no, Restart required: no
   - diags.log / traffic.out: nothing
   - The plugin is silently not loaded — only verifiable by behavioral test (e.g. curl shows the header_rewrite rule didn't run)
   
   I had Cursor/Claude trace  through the code: FileManager detects the mtime change (AddConfigFilesHere.cc registers plugin.config), but the only registered callback (process_config_update in FileManager.cc) no-ops for files with empty configName, which plugin.config has. plugin_init() is only called once at startup (traffic_server.cc:2232). PR #12892's design table lists plugin.config as (static, no handler), so the new framework preserves this behavior.
   
   I understand reloading global plugins is out of scope (per the [Reloading Plugins design doc](https://docs.trafficserver.apache.org/developer-guide/design-documents/reloading-plugins.en.html): "Currently only loading of 'remap' plugins (remap.config) is supported"). But could the new framework at least flip Restart required: yes (or emit a Warning) when plugin.config mtime changes during a reload? Right now operators have no signal at all that their edit didn't take effect.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@trafficserver.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Improving `traffic_ctl config reload` [trafficserver]

["brbzull0 (via GitHub)" <gi...@apache.org>]

brbzull0 commented on issue #12324:
URL: https://github.com/apache/trafficserver/issues/12324#issuecomment-3046166778

   I may be working on this as soon as I have some time.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@trafficserver.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org