Add aws-apn-id PRM tag to AWS EKS sample cluster configs#172
Conversation
Adds the `aws-apn-id` tag (value `pc: ajk5xy316takzneuu4ykhhj8c`) to all four AWS eksctl ClusterConfig samples, at both the cluster level (`metadata.tags`) and on every managed node group (`managedNodeGroups[].tags`). The per-node-group tags, combined with the existing `propagateASGTags: true`, ensure the tag reaches the EC2 instances; `metadata.tags` alone tags only the cluster/stack resources. This metadata-only tag identifies the deployment to AWS for Partner Relationship Management (PRM) attribution and has no cost or runtime effect. Each location carries a public-facing comment explaining its purpose, linking the AWS PRM onboarding docs, and noting it is highly recommended to leave in place. Scope is AWS-only: GCP, on-prem, Docker, Podman, and the Helm chart (values.yaml + templates) are untouched. Documented in the chart CHANGELOG (Unreleased) and samples/README.md.
Full-coverage follow-up to the cluster/node tagging. Adds the PRM tag to the AWS resources the chart can create at runtime, scoped so non-AWS deployments are completely unaffected: - Load balancers: add a commented `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags` annotation (aws-apn-id=pc: ajk5xy316takzneuu4ykhhj8c) to the `service.annotations` example in all four AWS sample values files (01, 05, 07, voice-agent/aws/self-hosted-llm). It rides along when a user uncomments `type: LoadBalancer`, tagging the provisioned NLB/ALB. - EBS / EFS: documented in samples/README.md (EBS via a StorageClass `tagSpecification`/CSI `--extra-tags`; EFS at filesystem creation), since EBS journals are a non-default path (EFS is the default) and the EFS filesystem is customer-created. No chart templates or the default values.yaml were changed, so GCP, on-premises, Docker, Podman, and generic Kubernetes deployments render identically and cannot fail. All additions live in AWS-only sample files (commented/uncommentable) plus the samples README and CHANGELOG.
|
@VWang1111 The intent of the PR is great. The validation is syntactic so far (YAML parse + presence). Can you also confirm (1) whether the value should carry the |
Per the AWS PRM manual tagging guide, the aws-apn-id value format is `pc:<product-code>` with no space (example `pc:5ugbbrmu7ud3u5hsipfzug61p`), and best practice is to "ensure 'pc:' prefix in value". The earlier value included a space after the colon (`pc: ajk5x...`), which was non-canonical and risked being mangled by the load balancer controller's tag parser. Updated all occurrences to `pc:ajk5xy316takzneuu4ykhhj8c` across the AWS cluster-config files, the load balancer annotation in the AWS values samples, the samples README, and the CHANGELOG. Ref: https://docs.aws.amazon.com/PRM/latest/aws-prm-onboarding-guide/manual-tagging.html
|
Confirmed the canonical value and validated end-to-end on a live EKS cluster. 1. 2. Does it survive the LB parser? Removing the space makes it unambiguous, and I verified it lands intact at runtime. I stood up an EKS cluster via Tag value observed on every resource type (verbatim, no mangling):
The NLB tag confirms the annotation value passes through the cloud provider's tag parser unmangled. Test cluster has been torn down. |
2 participants
Proposed changes
Tags AWS deployments with
aws-apn-id=pc:ajk5xy316takzneuu4ykhhj8cfor AWS Partner Relationship Management (PRM) attribution. The tag is metadata-only (no cost, no runtime effect) and is highly recommended to leave in place.The value follows the PRM manual-tagging canonical format
pc:<product-code>—pc:prefix, no space.AWS does not propagate tags across resource types, so the tag is applied at each layer that creates AWS resources — scoped entirely to AWS sample files so non-AWS deployments are unaffected:
*.cluster-config.yamlfiles atmetadata.tags(cluster + CloudFormation stacks) and on everymanagedNodeGroups[].tags(EKS nodegroup → ASG → EC2 instances, via the existingpropagateASGTags: true). Both levels are required:metadata.tagsalone does not reach the instances.*.values.yamlsamples include a commentedservice.annotationsexample withservice.beta.kubernetes.io/aws-load-balancer-additional-resource-tags; it rides along when a user uncommentstype: LoadBalancer, tagging the provisioned LB.billing.journal.aws.efs.enabled: false(EFS is the default, so no sample hits this path). Documented insamples/README.md: pointbilling.journal.storageClassat anebs.csi.aws.comStorageClass withparameters.tagSpecification_1, or set the EBS CSI driver--extra-tags.samples/README.md.Validation (live EKS cluster)
Beyond YAML/syntactic checks, I deployed a real cluster via
eksctlusing the same tagging mechanism as the samples, plus atype: LoadBalancerNLB Service carrying the sample's exact annotation, and confirmedaws-apn-id=pc:ajk5xy316takzneuu4ykhhj8clanded verbatim on every resource type:eks describe-clustercloudformation describe-stacksautoscaling describe-auto-scaling-groupsec2 describe-instanceselbv2 describe-tagsThe NLB result confirms the value passes through the cloud provider's tag parser unmangled (the no-space form removes the earlier ambiguity). Test cluster torn down after verification. See the comment thread for details.
Safety: non-AWS deployments are provably unaffected
No chart templates and not the default
charts/deepgram-self-hosted/values.yamlwere modified — every change lives in AWS-only sample files (commented/uncommentable),samples/README.md, andCHANGELOG.md. GCP (02), on-premises (03), aura-2 (04/06), Docker, and Podman deployments render byte-for-byte identically.Types of changes
Checklist
metadata.tags+managedNodeGroups[].tags+propagateASGTags, plus an NLB Service with the sample annotation. Verified theaws-apn-idtag landed verbatim on the cluster, both CloudFormation stacks, the ASG, the EC2 instance, and the NLB. Cluster torn down afterward.Further comments
Tag value confirmed canonical against the PRM manual-tagging guide:
pc:prefix, no space.