api version being appended to ambassador id for v3alpha1 mapping resources

[bigdave777]

Describe the bug Hi, I've been following the emissary quickstart guide and have some ambiguity around what the apiVersion should be for the mapping resource. https://www.getambassador.io/docs/edge-stack/latest/tutorials/getting-started

Having followed the steps in the guide, upon applying the mapping resource I end up with a yaml like this `- apiVersion: getambassador.io/v2 kind: Mapping spec: ambassador_id:

• --apiVersion-v3alpha1-only--default`

My (limited) understanding has me thinking the mapping resource should be using the v3alpha1 apiVersion, similarly to the Listener resource that is created - apiVersion: getambassador.io/v3alpha1 kind: Listener

I'm mainly curious if this is expected behavior as I'm under the impression the ambassador id's should match across resources with the same purpose.

I've recently started using the Host resource too and appear to have the same behavior there as well.

To Reproduce Steps to reproduce the behavior: ❯ k version Client Version: v1.28.0 Server Version: v1.25.0 With the following k8s versions, follow the quick start guide linked above. If you execute kubectl get mapping -o yaml, the api version is returning apiVersion: getambassador.io/v2

Expected behavior I would expect the apiVersion for mapping resources to be getambassador.io/v3alpha1 and the ambassador id to be 'default'

Versions (please complete the following information):

• Emissary: 3.9.1
• Kubernetes environment - EKS
• Version 0 v1.25.0
• Emissary Helm chart 8.9.1

Additional context Add any other context about the problem here.

[cindymullins-dw]

Hi @bigdave777 , yes I think that's expected because, per Kubernetes, we're only allowed one storage version and we've selected v2 (to accommodate users who are still in process of upgrading). Emissary's api extension (apiext) converts the v3alpha1 API resources to v2 and back.

If you applied your Mapping/etc. as v3alpha1 it should look like this:

apiVersion: getambassador.io/v2 kind: Mapping metadata: name: grafana namespace: defaulta spec: ambassador_id:

• --apiVersion-v3alpha1-only--default prefix: /grafana/ service: grafana

With the --apiVersion-v3alpha1-only being automatically added whenever the CRD is being retrieved in v2 format like above.

If you do a k get [mappings.v3alpha1.getambassador.io](http://mappings.v3alpha1.getambassador.io/) grafana -o yaml to ask the API server for the v3alpha1 version of the above CRD (it has to convert it up from v2 since that is how it is stored), then you can see it automatically notices the --apiVersion-v3alpha1-only and removes it.

apiVersion: getambassador.io/v3alpha1 kind: Mapping metadata: name: grafana namespace: default spec: ambassador_id:

• default hostname: '*' prefix: /grafana/ service: grafana (edited)

If you applied the CRD as a v2 then it won't have the apiVersion-v3alpha1 in the Ambassador ID.