AppmodService naming inconsistency across sample apps (rust vs java)

[allamand]

Summary

The sample apps use inconsistent naming for the "same" application across object types and between apps (rust vs java). Surfaced while investigating an IAM PassRole failure (fixed generically in #816). Not a functional break today (see verification), but confusing for participants and it coupled IAM to a name substring.

Naming map (kro path, current feature/agent-platform)

Concern	rust	java
AppmodService / Service / Rollout	rust-microservice-<env>	java-webservice
-<environment> suffix	yes	no
type suffix	-microservice	-webservice
image_name	rust-microservice	java-app
serviceAccount	rust-service-account-<env>	java-service-account
KubeVela Application wrapper	rust-application	java-application
ingress path	/rust-app	/java-app
DynamoDB table	rust-app-table-<env>	(n/a, dynamodb disabled)
derived IAM role (${name}-role)	rust-microservice-<env>-role	(none)

So a single app appears under 3-4 different base identifiers (*-microservice/*-webservice, *-application, *-app), rust carries an -<env> suffix and java does not, and image_name diverges from the k8s name for java.

Verification (services are functionally consistent)

• services.yaml names match the AppmodService name and the Rollout stableService/canaryService refs (${name} / ${name}-preview) for both rust and java.
• The content instructions document cp services.yaml ... and use the same names (java-webservice, rust-microservice-<env>).
• ✅ No service-name mismatch code↔content. The E2E "service 'java-app' not found" came from naming the AppmodService java-app (a deviation from the templates), not from a code/content gap.

Why it still matters

• Clarity: participants see rust-app, rust-microservice, rust-application, rust-app-table for one app.
• IAM coupling (now mitigated): the ${PREFIX}-cluster-mgmt-eks eks-access-management PassRole only matched *-microservice-*, so any app not named *-microservice-* (e.g. java-webservice, or a participant-chosen rust-app) that enables DynamoDB would fail PassRole. fix(iam): allow cluster-mgmt-eks to PassRole any pod-identity app role #816 decouples this via a pod-identity iam:PassedToService condition.

Proposed convention (for discussion)

Pick one base name per app and use it everywhere (AppmodService, Service, Rollout, SA, image_name, KubeVela Application, ingress path, table prefix), with a consistent (or no) env suffix:

• Option 1: <app>-microservice for all (rust stays, java java-webservice -> java-microservice).
• Option 2: drop the type suffix -> <app> (rust, java), simplest.
• Standardize the -<env> suffix (apply to both or neither).
• Align image_name with the k8s name.

Scope of the alignment change

• applications/{rust,java,...}/deployment/templates/{kro,kubevela}/* (appmod-blueprints, target feature/agent-platform).
• Content repo platform-engineering-on-eks (all locales) — AppmodService manifests, service copy steps, ingress paths, Backstage/Kargo project names.
• Keep fix(iam): allow cluster-mgmt-eks to PassRole any pod-identity app role #816 regardless (removes the IAM name coupling).

[allamand]

Deeper scoping (before attempting a rename)

Two distinct deployment models — the env suffix is (partly) justified

• rust: env-templated (<environment> substituted → per-env manifests) and creates account-global resources (IAM role ${name}-role, DynamoDB table) → needs -<env> to avoid dev/prod collisions in the same account.
• java: manifest hardcoded to dev (clusterName: peeks-spoke-dev), promoted dev→prod by Kargo (same name, Kargo swaps the image), dynamodb: false → no account-global resource → correctly has no -<env> (adding one would break the Kargo single-name promotion model).

So the refined convention is: collapse the base name to <app> (rust, java), keep -<env> only where the model requires it (rust yes, java no).

The rename is NOT cosmetic-only — real reference surface (functional risk)

rust-microservice / java-webservice are embedded well beyond the app templates + content:

• applications/rust/Cargo.toml + Cargo.lock — rust-microservice is the Rust crate/binary name (rename ⇒ Cargo package + Dockerfile + image build).
• gitops/addons/charts/grafana-dashboards/templates/rust-dashboard.yaml — metric queries select on the workload name (rename ⇒ dashboards break).
• applications/java/ci/buildspec-java.yaml — CI build.
• scripts/validation/cleanup-modules-20-30.sh, docs.
• Kargo project/stages, gitops fleet/ArgoCD apps.
• Content repo: ~7 locales × multiple pages (manifests, service copy steps, ingress paths, expected outputs).

Recommendation

Execute as a reviewed refactor on feature/peeks-refactoring (not a rushed PR into the release-candidate feat/pr-409), with a full reference audit first (Cargo/Docker, Grafana dashboards, CI, Kargo, gitops, ArgoCD, all content locales). The IAM coupling that made this urgent is already fixed generically in #816, so there is no functional blocker forcing an immediate rename.