2024-12-18 Eureka Adoption

Date

18 Dec 2024

Attendees

Discussion items

Time	Item	Who	Notes
_{Credit: IrisImages}
1 min	Scribe	All	Julian Ladisch is next, followed by Maccabee Levine Reminder: Please copy/paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits.

	Quesnelia	Ramsons	Sunflower	Trillium
EBSCO Primary development platform	Okapi	Okapi	Eureka	Eureka
EBSCO Bugfixing for	Okapi and Eureka	Okapi and Eureka	Eureka	Eureka
Community Bugfixing for	Okapi and Eureka	Okapi and Eureka	Eureka	Eureka
Community Testing (bugfest) - EBSCO hosted	Okapi and Eureka	Okapi and Eureka	Eureka	Eureka
Community Testing (bugfest) - Community	X	X	X	X
Support for CSPs (critical issues only)	Quesnelia/Okapi Quesnelia/Eureka Poppy/Okapi	Ramsons/Okapi Ramsons/Eureka Quesnelia/Okapi Quesnelia/Eureka	Sunflower/Eureka Ramsons/Okapi Ramsons/Eureka	Trillium/Eureka Sunflower/Eureka
Option			Running Sunflower modules under Ramsons Okapi is possible but not officially supported. Ramsons and Okapi support ends on Trillium GA.

Time	Item	Who	Notes
60 min	Eureka Adoption	All	Report of a possible timeline and reasoning for presentation at the January tri-council meeting Report: Introduction to Eureka Benefits What can be deprecated Does the community accept Eureka? Does the community accept the Sunflower timeline? Timeline information The EBSCO timeline: Chart Craig presented of EBSCO's plan Potential implications of community not adopting for Sunflower No alternative has been presented Community support for Okapi past Sunflower into Trillium? What arguments against adopting for Sunflower? Uncertainty of non-FSE providers ability to adopt for Sunflower Potential lack of information Sunflower - late springish/ early summer 2025 Sunflower modules can run on Ramsons Okapi Info from Index Data ID might have thoughts about reallocating hours, too early to draw conclusions We just don't know yet! Inventory of current documentation/efforts links from Julian Possible next steps Community dev ops Early adopter activities won't fully cover this Build on work Kitfox has done but a large amount of analysis needs to be done What does the community want and how do they want it? Recent convo about Vagrant boxes A lot of retooling - FOLIO devops team preparing to take on but not currently underway Analysis is being done Community environments currently most like a set of Docker containers, some of the existing documentation may help Tool for getting local dev env running exists FSE has set of bash scripts EBSCO Early adopter activities German libraries The GBV early adopters program starts officially at mid of January. We just do some pre-work now. It will hopefully be finished 4-6 weeks later. Won't answer all the questions here Can community dev ops be involved in this Is there a formal early adopters program? Craig McNally will get info to Wayne Schneider or Mike Gorrell that has been shared with GBV Program with EBSCO hosted libraries focused on end users Need to understand changes needed for community run environments- gap analysis Rancher tooling and FSE don't involve wider community, there is some documentation Eureka/Kitfox are running in both Rancher and Production environments Governance Tech council Special approval track for Eureka modules Product council Carry forward oversight of application formalization Community council Definition of community run environments Flower release and snapshot reference environments
	Notes		Previous Notes Notes: Craig McNally recap from last meeting suggested transition table: Jenn Colt: Community will not be able to run a bugfest Marc Johnson: bugfests need capacity for people to do the testing, and this would cause double work Wayne Schneider: do we already have bugfests for the two platforms Craig McNally: yes Jenn Colt: bugfixing has to done for the two platforms, and do functional tests have to be done in both platforms? Ingolf Kuss: do we have resources for two platforms in devops/bugfest? Craig McNally: CSPs documentation says, that bugs shall be fixed in current and the 2 releases before Marc Johnson: in reality: the last two generally available releases. Wayne Schneider: is this document (table above) a proposal the TC wants to decide to? Craig McNally / Marc Johnson: Just a idea to start discussion Jenn Colt: Is this Ebscos timeline Craig McNally: will check Ingolf Kuss: Difference between CSP and bugfixes Jenn Colt and Marc Johnson: Does the community commit to support Okapi or will the community switch to Eureka due to lack of possibility to support Okapi further? Marc Johnson: Will bug reports will be accepted, if the reproduction is only done in one of the platforms? Marc Johnson: Developers and implementers need to get kickstarted for Eureka Craig McNally: Early adopters already committed - knowledge spreads Wayne Schneider: different people and groups are trying to get involved with Eureka already Marc Johnson: what information does the community need for a decision in the tri-council in january to be able to commit to the plan to be Eureca-centric for sunflower. Jenn Colt: If something goes wrong and Eureka will not work, then the decision has to be rethinked. Craig McNally: How could proposals for decisions look at? Jenn Colt: All energy goes to Eureka or we try to support both for a transition time. Mark Veksler: Community could help enhancing development documentation Marc Johnson: Investment will be lower when we only have to support one platform Craig McNally: Benefits also from external managed parts like keycloak and kong Mark Veksler: Do we all agree, that Eureka is the right way, and are we talking about timing? And can Maccabee Levine or others help on developer documentation? Craig McNally and Jenn Colt will outline a proposal - we will need another discussion. Wayne Schneider: do we need CSPs or do we provide CSPs for Sunflower with Okapi? _____ Craig: What happens if the adoption gets pushed further to another FOLIO release? List of modules for an RFC? - impressive list Julian: 2 decisions here: Do we adopt for Sunflower even though it's technically past that deadline? The approved technology stack is already approved for Sunflower. Is there an overlap period for supporting both Okapi/Eureka? SSO/login modules have completely changed in Eureka. Marc Johnson: Does the community approve adopting Eureka in the first place? Do we have a special process for this? Points out Ebsco is a large contributor to the community technically The assumption - At some point if Eureka is adopted by the community at large, is it a given that Okapi envs will stop being supported by the community at large? There are a set of decisions that need to be made - Community support? Adoption? Need a transition plan? How do we structure these decisions? Multiple options on the table: Support Eureka and Eureka only from Sunflower. Combined support from Sunflower until a future release. Support Okapi for more long term with transition plan Next steps? Experience in early adopter program? Craig: There are cost implications for supporting both Okapi/Eureka. Several back-end modules for login no longer needed in Eureka. Over time less code that needs to be maintained, management users and tokens handled at a higher level. Concrete action items for next meeting? Jen: Isn't the community technically supporting both platforms at the moment? We are making a decision for the whole community here.. Is it true that development is supported with Okapi on Sunflower? Or after? Is the early adopter program an actual program? Vince: Lots of effort to test both environments. Development could shift to primarily Eureka environments in Rancher. New modules have a different workflows, and a different permissions model on the management level. New development is being done on Eureka, if it needs to be tested on Okapi - but who would be addressing these issues? Another way is not to do that, and support the other way around. Jason: Putting the cart before the horse - still need to vote on adoption or not. Asks about what development resources would be shifted or different with Okapi vs Eureka. We need to decide if there's a transition plan, because some have stated you can just run on Okapi as a fall-back? Who in the community would support this? Not many outside of Ebsco who have exp. with running the platform right now.. Kristin: Needs to be able to organize their platform upgrades/transitions. Points out that this platform is currently only running on AWS infra - no other "local" or "non-AWS" examples out there. Will Eureka be supported for local installations? Adoption needs to be planned securely and sustainably. Needs to be vetted for local installations by the community. Mark V: The more people that start getting involved in the early adoption, the better off we'll be. ... (More notes to come after I review the recording, hard to keep up with the convo...) Overall chicken in egg scenario: Community is blocked on adoption until TC agrees, but community doesn't have experience to help in deciding to adopt or to support. Craig, Mark and Vince will come up with narrowed options based on discussion. Today: Follow up on action items from last week... Craig: A list of new components has been added to the Eureka RFC. See 0010-eureka#New-Components Jenn: Draft of the proposal? Marc: Fill in notes from meeting recording Adopting Eureka for Sunflower means that the new Eureka modules get accepted even if the there's not enuogh time for the module acceptance workflow. Adopting Eureka means that platform-complete is not longer needed and gets replaced by application descriptors. The folio-keycloak is based on the keycloak docker images and adds customization for FOLIO; the same for folio-kong. Where is documentation for https://github.com/folio-org/mod-scheduler ? Technical dept OpenAPI documentation: https://github.com/folio-org/mod-scheduler/tree/master/src/main/resources/swagger.api A complete documentation won't be in place for Sunflower, but this is acceptable for adoption of Eureka. The RFC lists all new modules needed for Eureka. Regarding the Tri-Council-Meeting: The chairs will meet a week before and plan how the meeting will run. Draft report on adoption and timeline of the Eureka platform The shift from Okapi to Eureka is probably the most important decision for FOLIO (apart from human readable IDs). The report should be less opiniated than the RFC but can link to the RFC for details. What is needed to make the Eureka decision? What is needed after the decision? Support for hosting (operational support) and for development teams. The Christmas break doesn't allow to get substantial additional information before the decision in the tri-council meeting. Jenn will expand the report.
	Background		Slack conversations: expectations around Eureka modules and the TCR process... Is the expectation that we should submit all of these for inclusion into Sunflower? Is it too soon, given where we stand with the RFC process? There's a lot here, so I think we'd want to get started sooner than later so we don't wind up with a huge backlog of these things closer to the deadline. https://folio-project.slack.com/archives/C02HP10PPGB/p1730467357615359 I request that we put the 0010-eureka RFC into the next status stage on Monday. Implementers need a decision now whether the community adopts Eureka for Sunflower or not so that they can plan their work. https://folio-project.slack.com/archives/C02HP10PPGB/p1731076265224589 RFC in preparation: 0010-eureka Relevant dates: Sunflower OST acceptance: Sept 27, 2024 Sunflower scope deadline: Sept 27, 2024 January tri-council meeting: Jan 13, 2025 Sunflower API freeze? Jan 24 2025 Sunflower module acceptance deadline: Jan 24, 2025 FOLIO support period is the next release (currently in development) and the two latest GA (General availability) releases: PC Supports long-term release and regular release recommendations RFC public review timebox: 1 month
-	Zoom Chat		17:04:27 Jenn Colt: https://folio-org.atlassian.net/wiki/spaces/TC/pages/676855870/Draft+report+on+adoption+and+timeline+of+the+Eureka+platform 17:09:43 Wayne Schneider: platform-complete is also technically a yarn platform and performs the function of a reference UI build platform. 17:10:05 Wayne Schneider: Oh, I see, platform-lsp fills that? 17:16:46 Julian Ladisch: OpenAPI documentation: https://github.com/folio-org/mod-scheduler/tree/master/src/main/resources/swagger.api 17:17:09 Wayne Schneider: Actually the Okapi timer is a little more flexible than that FWIW (doesn't really matter at this point) 17:20:28 Tod Olson: I think useful to include the non-code repositories for completeness, even if there's an explicit statement that we don't need formal review for those. 17:20:39 Craig McNally: Reacted to "OpenAPI documentatio..." with 👍 17:21:26 Marc Johnson: Reacted to "I think useful to in…" with 👍 17:22:09 Ingolf Kuss: Reacted to "I think useful to in..." with 👍 17:23:20 Day, Kevin: I agree with Marc's statement about referencing the ~OKAPI~ Eureka functionality. 17:29:40 Tod Olson: Agreed w/ @Craig McNally , the other councils are looking to TC for guidance on Eureka. 17:34:00 Craig McNally: No, that would be human readable IDs 17:34:04 Craig McNally: ;) 17:34:14 Tod Olson: Reacted to "No, that would be hu..." with 😆 17:37:27 Wayne Schneider: FWIW regarding community devop -- not sure more information will be available by early January. We have internally addressed next steps and are planning to engage Eureka pretty deeply in the new year. 17:52:26 Tod Olson: Also hard to quantify say "reduced" in this context without measurements to refer to.