US1094711:- Add httpMethods field to L7Api PortalMeta for per-API HTTP method restriction

[ksaladi]

What

Adds an httpMethods field to PortalMeta on the L7Api CRD so Portal API authors can
restrict which HTTP verbs a published API accepts (e.g. GET only), instead of the Gateway
unconditionally allowing all 7 verbs.

Changes

• api/v1alpha1/l7api_types.go: new HttpMethod enum type (8 consts) + HttpMethods []HttpMethod
  on PortalMeta.
• internal/templategen/templategen.go: mirrored HttpMethods []string on PortalAPI (required
  for the PortalMeta → PortalAPI JSON round-trip in deployL7ApiToGateway).
• internal/templategen/portal-api-restman-template.qtpl (+ regenerated .qtpl.go): <l7:Verbs>
  now emits from HttpMethods when set, falling back to the existing hardcoded 7-verb list when
  unset — fully backward compatible.
• CRD schema regenerated in all 3 locations (config/crd/bases/, bundle/manifests/,
  charts/layer7-operator/crds/).
• Added a test case covering the restricted-methods path in templategen_test.go.

Enforcement itself is native to the Gateway via Graphman's WebApiServiceInput.MethodsAllowed —
no new assertion logic.

Testing

• go build, go vet, go test ./internal/templategen/... — all pass.
• Verified live on a kind cluster: patched an L7Api CR with httpMethods: ["GET"], confirmed
  via the Gateway's Graphman API that methodsAllowed matched, and confirmed POST/DELETE
  are rejected with "HTTP method ... not allowed" while GET passes through to policy.

[jb683638]

[Nit] ❌ gofmt reports this block as misformatted: running gofmt -l internal/templategen/templategen.go on this branch flags this file. The struct-tag column padding on PublishedTs/CreateTs/ModifyTs/SsgServiceType doesn't match what gofmt would produce after adding the HttpMethods field.

✅ Run gofmt -w internal/templategen/templategen.go (or make lint-fix) before merge so CI's fmt check doesn't drift.

[ksaladi]

Fixed — ran gofmt -w.

[jb683638]

[Suggestion] ❌ No +kubebuilder:validation:Enum marker on HttpMethods []HttpMethod, even though HttpMethod is defined as a closed enum type below with 8 named consts. As generated, the CRD schema only enforces type: array of type: string (see httpMethods: in config/crd/bases/security.brcmlabs.com_l7apis.yaml) — any string value passes admission and flows straight into the Graphman bundle's <l7:Verb> elements via the qtpl template.

✅ Consider adding // +kubebuilder:validation:Enum=GET;POST;PUT;PATCH;DELETE;HEAD;OPTIONS;OTHER above the field so the API server rejects typos/invalid verbs at admission time rather than letting them reach the Gateway.

(Noting the rest of this file doesn't use Enum markers elsewhere, so this is a suggestion rather than a blocking pattern violation.)

[ksaladi]

Intentional — mirrors StateStoreType/RedisType in l7statestore_types.go, which also has no enum marker.

[jb683638]

[Question] ❓ HttpMethodOther = "OTHER" isn't a real HTTP verb. If a caller sets httpMethods: ["OTHER"], the template will render <l7:Verb>OTHER</l7:Verb> into the Graphman bundle for the l7:HttpMapping. What's the intended use case for this constant? If it's meant as a catch-all for arbitrary/custom verbs, is <l7:Verb>OTHER</l7:Verb> actually meaningful to the Gateway/Graphman schema, or should it be dropped until there's a concrete use for it?

[ksaladi]

OTHER is a Gateway-native value (see the HttpMethod enum's doc comment in generated-modified.go), not invented here — Portal is just mirroring what the Gateway already exposes.