Deployment record cannot express bundles (bundle-fetch); chart ignores ingress.sessionAffinity; registryInstanceId never rendered — blocks partnerre-test's record-driven Rolls
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 20/100
Research direction
Start in HelmValues (MeshWeaver.Plugins): IngressValues and Render, plus CatalogValues, which should emit pluginCatalog.instanceId from DeploymentContent.registryInstanceId. Then check deploy/helm/templates/memex-portal/ingress.yaml, which currently emits only ingress.annotations and ignores ingress.sessionAffinity. Done means a rendered record includes the bundles block, the affinity annotations and instanceId, with tests covering each. The bundles schema and the selfUpdate registry fix are design work for maintainers.
Written by the indexing model from the issue text.
Description
Symptom
Every record-driven Roll of PartnerRe's partnerre-test (Systemorph/PartnerRe.Memex, mesh/Deployments/partnerre-test.json) is refused by hosting-deploy's drop guard (aks-ops run 38732526946: "this upgrade would DROP 72 value(s) …"). Most of the 72 paths are sample values from deploy/aks/values.aks.yaml that the config repository's helm-release lane layers under its overlay; those are being retired on the record (HOSTING_RETIRE_VALUES, Systemorph/PartnerRe.Memex). Four of them carry live behaviour that a Deployment record cannot express today, so the Roll cannot be made to pass without silently losing them:
| Live values path | What it does on partnerre-test | Why the record cannot say it |
|---|---|---|
bundles.registry, bundles.sources, bundles.identity |
renders the bundle-identity + bundle-fetch init containers that pull the sealed NodeType publications (plugins, reinsurance) from cr.meshweaver.cloud into /data/prebuilt-bundles (PartnerRe.Memex docs/shipped-nodetype-bundles.md: without it every pod compiles NodeTypes itself and types fail to load on the other pod) |
DeploymentContent has no bundles field and HelmValues.Render (MeshWeaver.Plugins) renders no bundles section |
selfUpdate.registry |
SelfUpdate__Registry = memexaksacr43rzd6faaix36.azurecr.io — the self-updater lists the estate's OWN ACR mirror |
the Plugins renderer suppresses every ACR host (fix in flight in MeshWeaver.Plugins — HelmValues.SelfUpdateRegistry to follow core's DeploymentPortalConfig.SelfUpdateRegistry) |
Two related gaps found while classifying, both worked around on the record for now:
- The chart never reads
ingress.sessionAffinity.HelmValues.IngressValuesrenders the record's typedingress.sessionAffinity.nginxAnnotationsintoingress.sessionAffinity.*, butdeploy/helm/templates/memex-portal/ingress.yamlonly emitsingress.annotations(+ the issuer). A record-only render therefore drops cookie affinity (nginx.ingress.kubernetes.io/affinity,affinity-mode,session-cookie-*) from a 2–4 replica Blazor portal. PartnerRe states them iningress.annotationsas a workaround. registryInstanceIdnever reachespluginCatalog.instanceId. The record field documents itself as "the value itsPluginCatalog__InstanceIdcarries", butCatalogValuesrenders noinstanceId, so a record-driven deploy losesPluginCatalog__InstanceId(andPluginCatalog__HomeUrl) — thedeployment-config:{InstanceId}principal that authorizes named commercial packages. PartnerRe states both inextraPortalConfigas a workaround.
Ask
- A typed
bundlesblock onDeploymentContent(registry, sources, optional identity fallback) and its render inHelmValues(MeshWeaver.Plugins), so an estate outside Systemorph's subscription can declare its bundle source on the record. - Either the chart honours
ingress.sessionAffinity(mergingnginxAnnotationswhen enabled), or the renderer folds it intoingress.annotations. HelmValuesrenderspluginCatalog.instanceIdfromregistryInstanceIdwhen it is stated.
Until (1) lands, partnerre-test's Rolls stay refused on the bundles.* paths by design — retiring them would bring back the 2026-09-28 NodeType defect.
🤖 Generated with Claude Code
- Dominant language
- C#
- Stars
- 12
- Forks
- 5
- Avg merge
- 5h 57m
- Merged PRs (30d)
- 967
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Systemorph/MeshWeaver
-
bug sev:H
Difficulty 4/5 3-5 days Newbie friendliness 20/100
Systemorph/MeshWeaver#7018 · 1 comment ·
Maintainers usually reply within 1 day
-
bug sev:L
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Systemorph/MeshWeaver#7002 ·
Maintainers usually reply within 1 day
-
bug sev:L
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Systemorph/MeshWeaver#7003 ·
Maintainers usually reply within 1 day
-
Terminal NotFound NACK undeliverable to a portal hub whose pod-hub registration was already releasedOpenbug sev:L
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Systemorph/MeshWeaver#7001 ·
Maintainers usually reply within 1 day
-
bug sev:H
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Systemorph/MeshWeaver#6989 · 3 comments ·
Maintainers usually reply within 1 day
All issues in Systemorph/MeshWeaver
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
bug priority: P2
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
IridiumIO/CompactGUI#699 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
bitfoundation/bitplatform#14070 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day