I did not test this yet, but this behavior is consistent with a lot of other features. That means config reload is not triggered on the events that you listed.

I don't think a behavior change can be implemented in the near future so you are better off doing a manual reload or deploying the changes during initial controller installation.

/remove-kind bug
/kind feature
/triage accepted

@longwuyuan are you sure this is a consistent behavior, because for example configuration snippets work out of the box. Basically every feature I used which is set per ingress works when it's applied to ingress. I understand that features itself should be enabled and configured before you can use them and the controller reload is needed. With the current implementation updates of ingresses are not possible, only the recreation or some workarounds like setting wrong configmap. If setting wrong configmap and then fixing it triggers the reload, the reload should also be triggered on any changes

@PavelGloba your expectation is correct and fair. Your expectation is the desired way such config changes should work.

The "proxy_set_header" directive is the configuration that is the result of adding a custom header. While there seems to be a watch/loop type of design for server_blocks & location blocks, the proxy_set_header is in the global config. And the global config seems to get its nginx.conf directives only at the time of creating a new pod or some other specific event like recovering from a broken controller config.

More importantly, there is a acute shortage of resources and there is a required direction that the development activities of the ingress-nginx controller must and absolutely must take. Because of these reasons it will not be possible to work on changing the controller's behavior to reload and live update nginx.conf for adding the proxy_set_header directive in the global context of nginx.conf .

I understand this is not your desired result or the desired result of any other user who has to make changes to environments that are not offering downtime. But I thought that you should be well informed to make required decisions. If its possible for someone to work on this change, they will comment here, but I think it is not likely.

Please wait for comments from others.

@longwuyuan the fix for this problem doesn't seem to be a complex one.
The function func (l1 *Location) Equal(l2 *Location) bool in the file pkg/apis/ingress/types_equals.go is missing an equals check for the customheaders.Config type.
Maybe with some support I can start a pull request for this issue?

@jgoelen I am not a developer so I can not comment effectively.

What I do not know is if that check you mention is unique to just one annotation or if that code-path is shared by other annotations. I also don't know if the e2e tests will cause a false positive. What I do know is that in the past this may seem trivial for one annotation but there is a need for developers to comment on this. So I will wait for a developer to comment.

On the other hand its a great help to get contributions as its the priceless value to K8S projects. Hence waiting for comments from others.

You can message in the Kubernetes slack in the channel ingress-nginx-dev

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.