fix: Rename keda-http-add-on-interceptor-proxy to keda-add-ons-http-interceptor-proxy

[kahirokunn]

Renamed keda-http-add-on-interceptor-proxy to keda-add-ons-http-interceptor-proxy to align with naming conventions as referenced in the source: https://github.com/kedacore/charts/blob/main/http-add-on/Chart.yaml#L3

Checklist

• Commits are signed with Developer Certificate of Origin (DCO)
• Changelog has been updated and is aligned with our changelog requirements
• Any necessary documentation is added, such as:
  • README.md
  • The docs/ directory
  • The docs repo

Fixes #

[JorTurFer]

Thanks for the PR 😄

This behaviour is documented here: https://github.com/kedacore/http-add-on/blob/main/docs/walkthrough.md#routing-to-the-right-service

Personally I'd prefer to wait until going to GA, but maybe @zroubalik and @tomkerkhove have other opinion

[kahirokunn]

I was doing a TUTORIAL today and thought I couldn't connect, but now that you mention it I understand everything.

[tomkerkhove]

Should we abandon the PR then?

[kahirokunn]

I think users will be happier if it is merged because it doesn't actually work regardless of the warnings, but it depends on the project's policy, so if it is not acceptable, it can be discarded.

[zroubalik]

We should use one naming, regardles what was the installation method, but I would use keda-http-add-on-interceptor-proxy not ...add-ons... so we follow the name of the repo.

[kahirokunn]

@zroubalik Is this correct?
I would love to reduce the number of people who stumble across this wonderful add-on tutorial by one as soon as possible.

[wozniakjan]

thank you @kahirokunn, I like your PR very much!

tbh, I also got a bit confused initially by the discrepancy in naming. I accepted that as a quirky behaviour of the chart and accepted that as is, but unifying the names regardless of the installation method would make me happier :)

[zroubalik]

LGTM

[zroubalik]

We would also need to consolidate stuff in the Helm chart: https://github.com/kedacore/charts/tree/main/http-add-on

Let's see what @JorTurFer thinks

[kahirokunn]

Thank you LGTM!

[JorTurFer]

I see the benefit of unifying them, but I'm afraid about the impact.
Currently, that service is the touchpoint that users use for their ingresses and changing it will break all the integrations, IMHO we should wait until the going to GA change (which will include more breaking changes for sure) or at least until the dedicated ScalingSet are available (as the users can deploy a new ScalingSet with its own service that won't change).
If I'm the only one who see a problem with this, we can merge it and that's all, I can be overthinking xD

[zroubalik]

I see the benefit of unifying them, but I'm afraid about the impact. Currently, that service is the touchpoint that users use for their ingresses and changing it will break all the integrations, IMHO we should wait until the going to GA change (which will include more breaking changes for sure) or at least until the dedicated ScalingSet are available (as the users can deploy a new ScalingSet with its own service that won't change). If I'm the only one who see a problem with this, we can merge it and that's all, I can be overthinking xD

I see the point, but I think the sooner we do the change the lesser impact, also this is still in beta, so we can do any breaking changes. Users will just need to migrate to the new version.

[JorTurFer]

I see the point, but I think the sooner we do the change the lesser impact

Yes, totally. My point is that ScalingSet feature can offer an smooth migration path as they can just deploy their new ScalingSet and migrate the workloads to it as they can have both in parallel. Currently, they need to deploy another HTTP Add-on (all the components) temporally.
This have been as it is for a long, I think that a single extra version isn't a problem. Other option can be just maintaining the helm chart as it is (or even keeping both names) to not break integrations, deploy using make is something introduced as part of 0.6.0 IIRC and I don't think that it has a huge based of users

[zroubalik]

Yes, so that's another incetive for you to complete ScalingSets ASAP :)) So let's try to merge this once ScalingSets are completed. I think the benefits are clera, let's use same naming for all methods etc.

As I mentioned, I would prefer if we use keda-http-add-on-... prefix instead of the keda-add-ons-http-... so it is aligned with the repo name and also the plural in add-ons doesn't much make sense.

I would not keep both names in the charts, they would become too complex and confusing imho.

@JorTurFer how does that sound to you?

[JorTurFer]

Yes, so that's another incetive for you to complete ScalingSets ASAP :))

lol, no pressure xD

So let's try to merge this once ScalingSets are completed

My point is that ScalingSets feature has to be merged and released (so this PR can be merged for v0.10.0 or so)

As I mentioned, I would prefer if we use keda-http-add-on-... prefix instead of the keda-add-ons-http-... so it is aligned with the repo name and also the plural in add-ons doesn't much make sense.

I prefer this name too, I don't like the other naming at all, but 🤷 xD

[zroubalik]

Yes, so that's another incetive for you to complete ScalingSets ASAP :))

lol, no pressure xD

Are you sure? 😄

[kahirokunn]

Go Bold 👍