Eureka Sunflower Plans and Expectations
Overview
This document aims to provide an overview of Eureka’s plans for Sunflower, as well as expectations. The intended audience is Folio community product owners. The goal is to share this information in order to align expectations between the Eureka team and others.
Expectations
The following are activities which other Folio development teams should be aware of, and/or expected to perform. Hopefully this doesn’t require too much time/effort from teams. Of course Eureka team will do whatever we can to ease the transition and reduce the burden placed on other teams.
In addition to verifying work on the standard snapshot/dev environments, please start also using snapshot/rancher environments running Eureka. This will help provide clarity on whether an issue is platform specific.
List of public Eureka-based environments: Reference environments
Ensure you’ve fully adopted Refresh Token Rotation (RTR). We’ve run into cases where bugs have been filed against Eureka because modules are still calling the legacy login endpoint which returns non-expiring tokens. The Technical Council determined last year that the transition plan for RTR is to deprecate these legacy endpoints in Poppy, and remove them altogether in Ramsons.
Technical Council meeting notes where this plan was agreed upon: 2023-10-02 Meeting notes
Incorporate the module descriptor validator maven plugin into your builds (local and otherwise) to identify any existing or new permission naming/use violations.
See FOLIO-4044: Ramsons 2024 R2 - Review and cleanup Module Descriptors for community modulesIn Progress
List of issues as of Sept 20: Permissions violations
Maven plugin repo w/ instructions: https://github.com/folio-org/folio-module-descriptor-validator
Try setting up a local dev environment based on Eureka. As this gets exercised, we will most likely find issues with the process as documented, and can make necessary improvements. This will also help developers become more familiar and comfortable with setting up and working with Eureka.
With Eureka, it’s important that interface dependency declarations are both accurate and complete. Please pay extra close attention to this as you implement new features. If you’re adding an API call, please check if your module already has a dependency on the interface which provides that API, and make any necessary adjustments to your module descriptor.
Please give extra thought to dependencies and coupling between modules in general. The multitude of interdependencies between our modules is a known (and systemic) problem preventing us from achieving the optimal composition of applications. While exact details of that composition are still TBD, it’s never too soon to start thinking about whether a given dependency is really required, or if it could possibly be relaxed to optional. UI modules have a mechanism to help deal with this (IfInterface). Unfortunately we don’t have clearly defined guidelines or advice for how to implement optional dependencies on the backend. We plan to generate such documentation soon.
Thunderjet team has offered to help be a pilot for this in Sunflower. They will work with Eureka and Solution Architects to identify one or more candidates, choose an approach, implement the changes, and help generate/update documentation describing techniques for reducing coupling between modules.
Introducing new modules? Please consider also creating an application for them as opposed to lumping them into the existing “mega” applications which we need to split up. The Eureka team can help provide advice and examples.
https://github.com/folio-org/application-builder (UI tool to facilitate application descriptor creation)
https://github.com/folio-org/folio-application-generator (maven plugin to help with generating snapshot versions of application descriptors)
Existing applications:
There’s also this monolith application currently being used by Kitfox for snapshot rancher envs: https://github.com/folio-org/app-platform-full
Feature Scope
Eureka’s exact release scope is still in flux, but the following features are being considered for inclusion in Sunflower. As noted, some of these still need to be cleaned up, split, re-estimated, etc. The purpose is to identify things which could have an impact on other teams so they can plan accordingly.
JIRA | Notes / Impact on other teams |
---|---|
Should only impact Thunderjet who will be working on policy mgmt for consortiums | |
Various groups across the rest of the community should benefit from the generated documentation | |
Having formalized platform descriptors should help DevOps/SysOps, but should not impact development teams or end users. | |
Shouldn’t require effort from other teams | |
Shouldn’t require effort from other teams | |
Needs to be split. For Sunflower we’re planning to only target the adoption of declarative user specification in edge API module descriptors. It would be helpful if teams responsible for these edge modules could help with this, but it’s not expected to be much effort anyway. | |
Needs refinement. Only mgr-* flows which cannot be exercised via the UI would be in scope for Sunflower | |
Shouldn’t require effort from other teams | |
Should not affect other teams, this is essentially addressing technical debt. | |
An incremental step toward the ability to manage direct capability/capabilitySet assignment to users in the UI (Read-only for now, Assign/manager later). Unlikely to impact other teams beyond requests for PR reviews in ui-users. | |
Needs to be split and re-estimated. The one story in scope here will benefit those working with the application generator tool. | |
Only the reliability/stability tasks are in scope for Sunflower. SysOps will benefit from this, but other teams should not be impacted. | |
Not likely to impact other teams | |
Will likely be included in Sunflower mostly as a placeholder, where we allocate time to work on enhancements to role management based on anticipated feedback following real-world use of this functionality. QAs and end users will be the benefactors of this work. Dev teams may also see benefits, but aside from Thunderjet who is working on roles management in the context of consortia, teams should not be impacted. | |
Spikes, investigations and designs - should not impact other teams | |
Bug fixes, dependency upgrades, tech debt, etc. Shouldn’t require effort from other teams, but they might benefit from this work. |