Generate backendservice name if not specified in autoneg annotation

[fdfzcq]

Why

We (Fabric/Spotify) would like to use autoneg without specifying neg names and realized that the default values might be a bit simple and prone to name collisions. Currently the NEG name defaults to service name + port when using new autoneg annotation and service name when using old config, in this PR we propose to change it to generated name similar to how k8s-io/ingress-gce generates NEG names.

What

• Allows passing a NEG name template using --neg-name-template flag, and defaults to {name}-{port}
• If NEG name is not set in the new autoneg annotation, generate one using the given template
  • Generated name may contain namespace, name, port or the first 8 characters of a sha256 hash, separated with -. It has max length of 63 characters, the non-hash tags are truncated evenly if the full name is longer than that. The hash can be used to make sure truncated long names won't collide.
  • The name generation is only applied to the new neg annotation as port mapping is missing with the old annotation.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[fdfzcq]

Erik suggested that we could import k8s-io/ingress-gce and call Namer directly. I tried this at first and got this error, suggesting using k8s-io/ingress-gce as a dependency is discouraged. There is a workaround linked in the issue but it's neater to move the functionalities here.

[rosmo]

Hey @fdfzcq and thank you for the PR! I was wondering if this could be a bit more flexible and I had two ideas in mind:

• Allow passing a template to the controller via command line parameters (eg. {namespace}-{name}-{port}-{hash}), and/or:
• Allow setting/overriding the template via annotation on the namespace

I think the first one ought to be fairly trivial, so I'd probably go with that (would also allow to keep backwards compatibility, if the default template was {name}-{port}), second one I'm not so sure of (if it's even desirable). Wdyt?

[fdfzcq]

Thanks @rosmo
That sounds good, do you mean supporting something like --neg-name-template={name}-{port}-{hash} here ?

[rosmo]

@fdfzcq Yes, exactly there!

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[fdfzcq]

@rosmo I've added configurable template, could you take a look when you have time? Thanks! :)

[soellman]

Thanks Sophy! I'll review this tomorrow.

Question - would you also want a flag that disallows setting the service name? I could see how that might be desirable so that all users would have their service names automatically determined.

[fdfzcq]

@soellman Thank you Oliver, yes we think something to disallow setting the service name would be nice to have.

[soellman]

This is a solid and clear PR, thank you, this look great.

I have one request that will require some name changes: please let's change "neg name template" to "service name template" everywhere, as this better describes what we'll use the name to describe. We could also change the command line flag to "default-backendservice-name" as well.

If you like, you could also add a flag that disables the ability to specify a service name (something like --disable-supplied-service-names), or we can add this in a future PR.

Thanks!

[fdfzcq]

Thanks @soellman I've changed the flag to default-backendservice-name now and we can make another PR to add disable-service-name flag.

[fdfzcq]

@googlebot I signed it!

[soellman]

small typo

[fdfzcq]

oops thx, I forgot this :D

[soellman]

Looks great, thanks again for the contribution!