Set special "header_placement" TargetGroupAttribute

[moensch]

Is your feature request related to a problem? Please describe.
We have a specific need to set a "special" (read: not publicly exposed) attribute on our NLB target groups. It is not commonly used, but we found this project to be the closest to a solution for us to set those attributes natively without having to run some external script to set those.

The specific key we have to set is proxy_protocol_v2.client_to_server.header_placement.

Describe the solution you'd like
Either introduce a new annotation to set this "header placement" attribute, or maybe even open this up to allow any arbitrary attribute to be set via annotation?
I know embedding JSON in attribute values can soon get ugly, but I've seen similar things on the ALB ingress controller.

Maybe an annotation like:

aws-nlb-helper.3scale.net/extra-annotations: '[{"Value": "on_first_ack", "Key": "proxy_protocol_v2.client_to_server.header_placement"}]'

We should be able to directly Unmarshal this into an []*elbv2.TargetGroupAttribute (hopefully) and log errors accordingly.

Describe alternatives you've considered
Write another operator that would do 99% of what this one does ;-)

Additional context
We are happy to contribute this, whichever way you prefer (specific annotation for this attribute or implement the "generic" annotation).

[raelga]

Welcome @moensch, thank you very much for the proposal!

Give me some days to play a bit with those extra attributes and get back to you as soon as posible.

:)

[moensch]

Keep in mind the specific attribute in question is undocumented and only available/usable after being specifically enabled for your account and region by AWS support upon request.

If we’re going with the “smaller” change (not the option to allow arbitrary attributes) I’m happy to start putting a PR together.

[raelga]

Hello @moensch, for the time being, we don't see that many settings can be tweak to go for the arbitrary attributes.

Having specific logic for the attributes, allows to add some validations on the operator side, makes it easier by setting specific annotations for each setting rather than messing with structured data in annotations. In case the number of options that can be tweak grows, probably going using a custom resource definition for NLB settings may be also a good option.

Feel free to start putting a PR if you like, and thanks for contributing! :)

The code is still in early stages, we will be working on improving the code and add testing asap.