Improved configuration validation for running configuration changes

[shaun-nx]

Overview

As a user of NGINX Ingress Controller, I would like have the confidence that NGINX itself will never be given an invalid configuration so that I can always be confident that my applications will serve traffic undisrupted

Functional Requirements

• Ensure all configuration is pre-validated before it is written to disk and NGINX is reloaded.

Example: In the presence of an invalid Snippet, either in an Ingress Resource or a VirtualServer resource, ensure the snippet is validated to prevent this invalid configuration from being applied to the NGINX pod

Definition of Done

Development

• Unit tests are written to cover functionality delivered in the story.
• Make sure that the unit test passes before creating a pull request.
• Make sure that the test coverage stays optimal.
• Run make lint locally before creating a PR.

Testing

• Automated tests are written as part of the story.
• Run “make lint-python“ from root
• Acceptance criteria are met.
• Stories are demonstrated to the team.
• Product Manager accepts the story as done.
• If a feature requires changes/extensions of the Helm chart, those shall be done as part of the story.

Release Notes & Documentation

• PR is labeled appropriately so they display in GitHub release notes.
• Create/update documentation related to the user story.
• Create/update the example in our codebase when applicable.

[github-actions]

Hi @shaun-nx thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!

[hostalp]

I recently raised a similar question #8075 as this is also something that bothers us.
It's especially a problem in larger environments with multiple teams operating independently, where one can now easily affect others via invalid ingress configuration.
I noticed that some ingress controllers make use of validating webhooks for validating the ingress resource to be applied and rejecting it if not passing the validation.
Another option would be to at least make the Nginx server skip (and output some warning about it) the invalid conf file which would break the functionality only for the invalid Ingress here.