Annotation nginx.org/(location|server)-snippets and configmap (location|server)-snippets coexist?

[kongdewen]

Is your feature request related to a problem? Please describe.

So we are currently working on on-boarding ingress on various applications. we want every team to be able to setup their ingress. but not everyone is familiar with nginx language and we will have a lot of common nginx annotation section in most ingresses. We wanna create various nginx variables(each variable will means one feature), the common operations regarding these variables will be added to configmap controlled by us. so for each team, they will just define these variables (simply as on/off). In this way, it will make their lives much easier. and for our team, we can take control of the each feature.

Describe the solution you'd like

Currently setting up Annotations(nginx.org/(location|server)-snippets) will overwrite configmap ((location|server)-snippets) section. Is there a way we can just add a 'switch' (an annotation ) so when we turn on the switch, we can merge snippets from both levels?

Describe alternatives you've considered

We also considered the new introduced custom templates, we just didn't feel like opening that gate because it might create a problem to maintain future new feature releases.

[isaachawley]

Hi @kongdewen,

That's an interesting feature idea. I see the benefit of merging snippets. Can you tell me more about what you're trying to accomplish? Will merging snippets do everything you want, or is it a workaround idea?

Is RBAC important? Are you using k8s RBAC to limit what the teams can configure by setting RBAC on the ConfigMaps?

I think you're right that you could accomplish this with custom templates, at least partially.

Thanks

[kongdewen]

Hey @isaachawley,

Our nginx ingress with global configmap is under a special namespace controlled by RBAC. Only handful people can update them. Now with each ingress source can be able to using annotation to overwrite our configmap, some enforced feature we added to configmap for servers and locations might get lost. with more and more applications we move to kubernetes, an easier way to maintain them becomes essential to us.

We will love to help to create the feature.

[pleshakov]

Hi @kongdewen

your usecase is quite interesting, especially considering that you have multiple teams sharing the Ingress Controller. Could you possibly answer the additional questions below? this will help to better design a feature for your requirements.

1. Except for the snippets annotations, do you use any other available annotations? As several annotations override configmap values, do you need to have control over any of them?

2. You mentioned that multiple teams are sharing the same Ingress Controller. Does every team have equal access to the Ingress Controller features? Are you planning to restrict some teams to use only a subset of features?

We wanna create various nginx variables(each variable will means one feature), the common operations regarding these variables will be added to configmap controlled by us. so for each team, they will just define these variables (simply as on/off). In this way, it will make their lives much easier. and for our team, we can take control of the each feature.

Could you possibly illustrate that with some example how that is implemented?

[kongdewen]

Hi @pleshakov
1.

for the snippets annotations, do you use any other available annotations? As several annotations override configmap values, do you need to have control over any of them?

Right now, we don't see a need to add control over them. as most of them is for http proxy module, dealing with connection between ingress and upstream. To us, each ingress should be able to adjust the values. as for location-snippets/server-snippets, they are pretty open for anything especially when you have lua support.

you mentioned that multiple teams are sharing the same Ingress Controller. Does every team have equal access to the Ingress Controller features? Are you planning to restrict some teams to use only a subset of features?

currently yes, we just on-boarded ingress. as everyone excited and eager to explore it, currently everyone has equal access. we do think about the restrictions once we get mature.

3,

Could you possibly illustrate that with some example how that is implemented?

Example,

we have been using nginx with lua support. certain features are written in Lua already. as we wanna migrate to k8s, we want people to be free testing the features with their applications.
so for our team,
we can add a default variable(switch off by default) using map to control the feature on/off.
we can deploy these features(lua block) with configmap. each will verify its own switch.

for user,
user can test their applications with these features by overwriting the variable later in their snippets (switch on)

[pleshakov]

@kongdewen
thanks for your answers. Could you possibly take a look at #359 proposal and see if that can address your problem?

[kongdewen]

@pleshakov that will definitely address the problem. Thank you!

[pleshakov]

@kongdewen great! we'll start working on the initial version of the feature. We'll publish it in a separate branch/PR. Would you be OK to test it for your requirements?

[kongdewen]

@pleshakov definitely. Thank you so much!

[pleshakov]

@kongdewen could you take a look at this PR #375 ? We'd like to hear your feedback.

We've implemented most of the proposal #359 Now it is possible to create custom annotations.

The only downside is that it is not possible to insert modified template as snippets - we need to modify the whole template. We discovered that during the implementation.

[pleshakov]

thanks, the feature was merged #375

It is available in the edge version now. See https://github.com/nginxinc/kubernetes-ingress/#nginx-ingress-controller-releases
It will be available in 1.4.0 release

[Dean-Coakley]

Closing, this feature now available in the latest stable release