Fix _helpers.tpl function for ambassador.name, issue #4282

[AshutoshNirkhe]

Description

A few sentences describing the overall goals of the pull request's commits.

Related Issues

List related issues.

Testing

A few sentences describing what testing you've done, e.g., manual tests, automated tests, deployed in production, etc.

I have updated the logic for "ambassador.name" definition in _helpers.tpl so as to fix the issue I raised yesterday #4282

I was able to successfully upgrade the helm chart (local updated copy) with release name 'ambassador-internal' from v6.9.4 to v7.4.1 after making these changes!

Checklist

• I made sure to update CHANGELOG.md.

  Remember, the CHANGELOG needs to mention:

  • Any new features
  • Any changes to our included version of Envoy
  • Any non-backward-compatible changes
  • Any deprecations

• This is unlikely to impact how Ambassador performs at scale.

  Remember, things that might have an impact at scale include:

  • Any significant changes in memory use that might require adjusting the memory limits
  • Any significant changes in CPU use that might require adjusting the CPU limits
  • Anything that might change how many replicas users should use
  • Changes that impact data-plane latency/scalability

• My change is adequately tested.

  Remember when considering testing:

  • Your change needs to be specifically covered by tests.
    • Tests need to cover all the states where your change is relevant: for example, if you add a behavior that can be enabled or disabled, you'll need tests that cover the enabled case and tests that cover the disabled case. It's not sufficient just to test with the behavior enabled.
  • You also need to make sure that the entire area being changed has adequate test coverage.
    • If existing tests don't actually cover the entire area being changed, add tests.
    • This applies even for aspects of the area that you're not changing – check the test coverage, and improve it if needed!
  • We should lean on the bulk of code being covered by unit tests, but...
  • ... an end-to-end test should cover the integration points

• I updated DEVELOPING.md with any any special dev tricks I had to use to work on this code efficiently.

• The changes in this PR have been reviewed for security concerns and adherence to security best practices.

[alexgervais]

Hi @AshutoshNirkhe, thanks for opening an issue and contributing to fixing it!

@AliceProxy, @LukeShu can you please take a look at this PR, and issue #4282 ? Thanks!

[AshutoshNirkhe]

Hi @AshutoshNirkhe, thanks for opening an issue and contributing to fixing it!

@AliceProxy, @LukeShu can you please take a look at this PR, and issue #4282 ? Thanks!

Hi @AliceProxy , @LukeShu could you please review the PR ? Thanks.

[AliceProxy]

Upgrading Emissary-ingress / Edge Stack in-place is deliberately not supported due to the numerous breaking changes between 1.x and 2.x not only in the image, but also in all of the resources that are during installation such as how the Deployment labels have changed, and those are immutable-after-creation, so even with this change I would not expect in-place-upgrades would work or be supported.

There are only two supported methods for migrating from Emissary 1.x to 2.x

1. Fully uninstall 1.x and its resources, then install 2.x
2. Install 2.x side-by side following our migration guide and then perform a cutover from 1.x to 2.x

A full list of the supported migration paths can be found here:
https://www.getambassador.io/docs/emissary/latest/topics/install/migration-matrix/