[tanka][ingress] optional ingress

[marcadamsge]

The idea is to have one generic ingress configuration per cloud/k8s distribution to get started. The configuration is done with one variable that would take values in gke, azure, aws or none to select the target cloud. For each cloud, there would be one object with custom variables:

gkeIngress: {
  ipName: 'VAR_GKE_IP_NAME',
},
azureIngress: {
  ...
}
awsIngress: {
  ...
}

[marcadamsge]

That's a breaking change though. I'm not sure if that's ok? @BenjaminPelletier @barroco If not I could try setting gke as the default cloud. I didn't do it there because I'm not sure if there's a nice way to set that ipName value from metadata.gateway.gkeIngress.ipName with a fallback on metadata.gateway.ipName and have the ipName: error 'must supply ip name', assertion at the same time

[marcadamsge]

I think breaking changes are ok as long as we can effectively communicate to users that they've happened. Is there a good, standard way to keep track of things that should go into the next release's changelog? Maybe some GitHub magic I don't know about currently?

If there isn't such a thing, we could bootstrap something by adding /build/changes.txt and add a "Changes since version 0.4.0" heading, and then we'd add a new heading each release.

A changelog is a good idea 👍 I'm unaware of such a github feature, I tried googling around but didn't find anything. I've just seen there's some kind of changelog standard https://keepachangelog.com/en/1.0.0/ and a tool for linting it https://github.com/brightcove/kacl . It might be a good idea to use these and add a linting step in the CICD, what do you think?

[BenjaminPelletier]

Starting a deployment changelog seems like a good idea, especially for the changes we have coming up. kacl seems abandoned though, and we may not need automated enforcement. If we can just write down specific expectations, I'll bet we can manage well manually.

[marcadamsge]

Starting a deployment changelog seems like a good idea, especially for the changes we have coming up. kacl seems abandoned though, and we may not need automated enforcement. If we can just write down specific expectations, I'll bet we can manage well manually.

I added a changelog here: https://github.com/interuss/dss/pull/854

[marcadamsge]

Waiting for release discussions on the infrastructure strategy before introducing breaking change 🙂

[barroco]

@marcadamsge, looking at the new approach, I am not sure we will need this as is. Since it is a breaking, let's park it for the moment. Let's keep the branch and reopen it when we add a new cloud if it is still relevant.