Ability to configure annotation defaults

[bbrewer-forge]

How open would this project be to a PR adding support for configurable annotation defaults/fallbacks?

For instance, I'm on a project where we create several ingresses across many repositories that all share the same Ingress annotations values for a variety of things: cert-arn, security-groups, subnets, etc.

I think this could be accomplished by any of the following:

• Config file/flags sent to the controller on deployment manifest
• Global ConfigMap reference by the controller with settings for each annotation
• Individual ConfigMap references set in individual annotations, like suggested here Ingress ConfigMap #109

Anyways, I would be willing to work on/contribute something like this, just want to get a feel for how welcome it would be and which option people might like more.

[M00nF1sh]

Yeah, PRs are super welcome 😄

from my own point of view, both flag and configMap works.(though i prefers flags since i don't see the need to change these default settings at runtime, also the implementation is simpler if using style like --annotation-defaults=annotation1=xxx,annotation2=xxx,annotation3=xxx)

[rodlogic]

@bbrewer-pillar Did you end up making any progress on this?

[bbrewer-forge]

@rodlogic I've been dragging my feet as my team is using a workaround via terraform state sharing for this (it's not great, but it works for now).

[rodlogic]

@bbrewer-pillar No worries.

I am coming to the conclusion that it doesn't make sense to have many of these annotations at the Service/Ingress level. In fact it just added complexity (e.g. manifest templatization, dependencies on additional infrastructure configuration items, etc) and potential instability. It looks good for a demo or potentially for very large organizations, which may need DNS names, certificates, ALBs created dynamically.

Ideally, I want a solid infrastructure with all these components already provisioned (and pre-wired and just rely on the controller attaching/detaching targetGroups instead.

[bbrewer-forge]

@rodlogic I tend to agree. Another path we had thought might work was the single ALB approach, which I think this project has been working on. That might solve at least a few issues related to "set-once" configuration

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[caiconkhicon]

@bbrewer-papa-x , @rodlogic : Is there any of you still working on this? Because I have a case where I want to enable access log for all ALB, and I want the Controller does it for me, not setting Ingress one by one.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.