/
Eureka environments deployment known issues - AI generated KB for RAG purpose - 2026.

Eureka environments deployment known issues - AI generated KB for RAG purpose - 2026.

Eureka Environments Deployment: Known Issues & Resolutions (2026)

1. 🚨 Tenant Settings Not Showing in UI — hasAllPerms Set to false in stripes.config.js

  • Issue: The Tenant Settings section is not visible in the FOLIO Eureka UI even after assigning all relevant capability sets (e.g., ui-tenant-settings_settings_*) to the user role.

  • Symptoms:

    • Settings tab or Tenant Settings sub-section is missing from the UI

    • All granular capability sets are assigned to the role

    • No errors reported in module logs

  • Root Cause: The hasAllPerms setting in stripes.config.js is set to false. In the Eureka platform, this value controls whether Stripes grants the UI access to render settings sections. When set to false, the UI hides settings (including Tenant Settings) regardless of assigned capabilities.

  • Resolution:

    1. Locate your stripes.config.js file (typically at platform-complete/eureka-tpl/stripes.config.js or your custom fork).

    2. Ensure the following value is set: hasAllPerms: true

    3. Rebuild and redeploy the UI bundle. See: Build/Deploy UI for Eureka environment

  • Additional Context:

(Source: Early Adopters Slack Community, Apr 2026 | Added to KB: 2026-04-19)

2. 🗄️ Cannot Create Instance or Holdings (5xx Error) After Environment Recreation — DB Table Permission Issue on mod-inventory-storage

  • Issue: After environment recreation, it is not possible to create Instance or Holdings records — a 5xx response is received due to a permission issue at the DB table level.

  • ⚠️ Important: This fix addresses the 5xx creation error only. It does NOT fix the absence of metadata on existing Instance records — metadata absence is a separate dataset-level issue (the dataset used for environment recreation does not contain metadata).

  • Affected Environments: Any Rancher environment recreated from a DB snapshot (non-ECS and ECS). Confirmed on etesting-sprint and eperf-corsair.

  • Symptoms:

    • Creating a new Instance or Holdings record returns a 5xx HTTP error

    • Permission denied error on statistical table access in mod-inventory-storage logs

    • Issue reproduces for all users including admin (folio) user

    • Instance records may also display "Unknown" in the Administrative data → Metadata section (separate dataset issue — not resolved by this fix)

    • Bulk Edit failures and OAI-PMH degradation may also be observed (related to metadata absence)

  • Root Cause (RANCHER-2944): The tenant+module DB user (e.g., fs09000000_mod_inventory_storage) has no permissions assigned after environment recreation. The DB user lacks the required grants on the statistical table, preventing any write operations (instance/holdings creation).

  • ✅ Resolution for 5xx / Permission Error (Verified by Kitfox team):

    1. Assign missing DB permissions via pgAdmin:

      • Navigate to the environment's pgAdmin URL (see Namespace useful info & tools for pgAdmin URL and credentials)

      • Locate the fs09000000_mod_inventory_storage DB user (or equivalent tenant-prefixed user)

      • Assign the required permissions to this user on the relevant schemas/tables (especially the statistical table)

    2. Reinstall mod-inventory-storage on the tenant (if permissions assignment alone is insufficient):

      • Use the reinstallModule Jenkins pipeline

      • Parameters: CLUSTER, NAMESPACE, MODULE=mod-inventory-storage, TENANT

    3. Verify fix: Attempt to create a new Instance record — it should now succeed (2xx response).

  • ❌ Metadata Absence — Separate Issue (Not Fixed by Above):

    • The absence of metadata in existing Instance records is caused by the dataset itself not containing metadata — this is a data preparation issue, not a permissions issue

    • Fixing DB permissions will not restore metadata on pre-existing records

    • This is a known data quality issue for sprint testing and perf datasets

  • ⚠️ Important Notes:

    • This permission issue recurs on every environment recreation

    • The workaround must be applied to all affected tenants (both ECS and non-ECS)

    • For perf/eperf environments (e.g., eperf-corsair): use env's pgAdmin for self-service fix ✅

    • For etesting environments: contact Kitfox team via #folio-rancher-support

  • Related Tickets:

    • RANCHER-2944 — Metadata is absent for most Instance records on Sprint testing environment (Closed)

    • MODINVSTOR-1402 — OAI-PMH behavior for Instances without metadata

  • Useful Links:

(Source: RANCHER-2944, Slack thread #folio-rancher-support, Kitfox Team Investigation | Corrected: 2026-05-25)

3. 📦 mod-inventory-update — loadSample=true Behavior on folio-etesting-snapshot Environments

  • Question: Can mod-inventory-update be installed with tenant init parameter loadSample=true in folio-etesting-snapshot and folio-etesting-snapshot-2?

  • Answer: ✅ No action required. For snapshot environments, loadSample=true (and all sample data parameters) are set to true by default in the daily snapshot rebuild pipeline. Sample data is automatically loaded for all modules that support it — including mod-inventory-update.

  • Verification: Confirmed by the Kitfox team. Sample data presence on folio-etesting-snapshot was verified directly by the requesting team.

  • Self-Service Options: If you experience any issues with sample data or module state in snapshot environments, you can use the following self-service Jenkins pipelines:

  • ⚠️ Important Restrictions:

    • Manual updates to folio-etesting-snapshot environments are strictly prohibited.

    • These environments are managed exclusively by the Kitfox team via a daily automated rebuild pipeline (runs at 23:00 UTC).

    • Any configuration change requests must be raised via Jira (RANCHER project) for the Kitfox team to implement in the pipeline.

    • No ticket is required just to enable sample data — it is already active by default.

  • Related Slack thread: #folio-rancher-support thread

(Source: Kitfox Team confirmation, Slack thread #folio-rancher-support | Added to KB: 2026-06-15)

4. 🐳 Custom Keycloak/Kong Images from platform-lsp — Now Supported ✅

  • Update: As of June 2026, custom Keycloak and Kong images sourced from a custom platform-lsp branch are fully supported in the createNamespaceFromBranch pipeline.

  • Background: Previously, the FOLIO_KEYCLOAK_VERSION and FOLIO_KONG_VERSION Jenkins job parameters were deprecated and ignored in the Eureka flow. The pipeline always resolved Keycloak/Kong images from folioci Docker Hub, making it impossible to use custom images built from feature branches and published to AWS ECR.

  • Previous Limitation:

    • Custom Keycloak/Kong images built via buildAndPushModule were published to AWS ECR, not to folioci

    • The pipeline had no dynamic registry detection logic — it always pulled from folioci

    • Attempting to use a custom ECR image tag in platform-lsp descriptor resulted in a namespace creation failure (image not found)

    • Related Jira ticket: RANCHER-3001 — Dynamic Registry Determination for Custom Image of Keycloak/Kong

  • ✅ Solution (Implemented):

    • A permanent fix was implemented via pipelines-shared-library PR #1317

    • The pipeline now supports dynamic registry determination — it can correctly resolve and use Keycloak/Kong images from both folioci (Docker Hub) and AWS ECR

  • How to Use Custom Keycloak/Kong Images:

    1. Build your custom Keycloak or Kong image using the buildAndPushModule Jenkins pipeline from your feature branch

    2. Note the resulting image tag (e.g., 26.6.0-SNAPSHOT.94aa737)

    3. Create a custom branch in platform-lsp (based off the snapshot branch)

    4. Update the folio-keycloak or folio-kong version in the branch descriptor to match your custom image tag

    5. Run createNamespaceFromBranch using your custom platform-lsp branch — the pipeline will now correctly resolve the image from ECR

  • ⚠️ Notes:

    • The FOLIO_KEYCLOAK_VERSION and FOLIO_KONG_VERSION Jenkins job parameters remain deprecated and are not used in the Eureka flow — custom versions must be set via the platform-lsp branch descriptor

    • Custom images built by buildAndPushModule are published to AWS ECR (not folioci)

  • Related Slack thread: #folio-rancher-support thread (Jun 2026)

  • Related Jira: RANCHER-3001

  • Fix PR: pipelines-shared-library PR #1317

(Source: Kitfox Team, Slack thread #folio-rancher-support, pipelines-shared-library PR #1317 | Added to KB: 2026-06-26)