[GitHub] [trafficserver] bneradt opened a new issue, #8785: 9.2.x: invalid remap.config files are no longer FATAL

[GitBox <gi...@apache.org>]

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

   While testing 9.2.x, I accidentally created an invalid remap.config file. In previous releases, ATS would fail to start if it loaded an invalid remap.config file and it would emit a FATAL log message. In 9.2.0 (not released yet), this is no longer the case: ATS starts, albeit with ERROR messages.
   
   This change looks intentional per the following PR: #7782
   
   However we might want to reconsider this because this is a pretty significant change in behavior that can lead to confusing 404 responses for the user. Consider the following possible scenario:
   
   1. An admin creates a problematic remap.config entry near the end of the file, maybe 95% down.
   2. They restart ATS. In 9.1, ATS would refuse to come up with a FATAL message. In 9.2, it now emits an ERROR but does start with the previous remap entries active in its running state.
   3. Since the majority of the remap.config entries were parsed, their smoke testing shows that the remap.config file seems to work. Remapping works fine in general, and unless they test entries at or after their corrupted remap.config entry, remapping will seem to work.
   4. This runs in prod for a while and the diags.log file is rotated.
   5. The admin gets reports about unexpected 404 errors due to the few entries near the bottom of the remap.config file.
   
   In this situation, he does not see diags.log errors anymore because they only happened after ATS restart. The corruption in the remap.config may not be obvious. In fact, particular entries may be fine with their only problem being that they come after the corrupted entry, which may be many lines before that for which the current 404 responses correspond. Thus for large remap.config files (ours are thousands of lines long), a corrupted entry may be almost impossible to detect visually.
   
   Perhaps it's preferable for reloads to be more lenient, while keeping initial remap.config loading strict?


-- 
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

[GitHub] [trafficserver] ezelkow1 commented on issue #8785: 9.2.x: invalid remap.config files are no longer FATAL

[GitBox <gi...@apache.org>]

ezelkow1 commented on issue #8785:
URL: https://github.com/apache/trafficserver/issues/8785#issuecomment-1095732704

   +1 on a soft fail option if the way it is working now is desired. For us we definitely would prefer the old behavior of hard fail on startup. Half-soft fail on bad reload where it continues using the old remap without killing ATS until it can do a full valid reload of the config file


-- 
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

[GitHub] [trafficserver] randall commented on issue #8785: 9.2.x: invalid remap.config files are no longer FATAL

[GitBox <gi...@apache.org>]

randall commented on issue #8785:
URL: https://github.com/apache/trafficserver/issues/8785#issuecomment-1095703850

   I'm +1 on fixing this.


-- 
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

[GitHub] [trafficserver] randall commented on issue #8785: 9.2.x: invalid remap.config files are no longer FATAL

[GitBox <gi...@apache.org>]

randall commented on issue #8785:
URL: https://github.com/apache/trafficserver/issues/8785#issuecomment-1097214904

   Ditto with everything @ezelkow1 said.


-- 
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

[GitHub] [trafficserver] randall commented on issue #8785: 9.2.x: invalid remap.config files are no longer FATAL

[GitBox <gi...@apache.org>]

randall commented on issue #8785:
URL: https://github.com/apache/trafficserver/issues/8785#issuecomment-1095713219

   If someone wants it to soft fail on startup, it should be opt in (like the ssl_multicert.config var https://docs.trafficserver.apache.org/admin-guide/files/records.config.en.html?highlight=proxy%20config%20ssl%20server%20multicert%20exit_on_load_fail#proxy-config-ssl-server-multicert-exit-on-load-fail)


-- 
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

[GitHub] [trafficserver] SolidWallOfCode closed issue #8785: 9.2.x: invalid remap.config files are no longer FATAL

[GitBox <gi...@apache.org>]

SolidWallOfCode closed issue #8785: 9.2.x: invalid remap.config files are no longer FATAL
URL: https://github.com/apache/trafficserver/issues/8785


-- 
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