Date
...
Discussion items
| Time | Item | Who | Notes | |
|---|---|---|---|---|
| 1 min | Scribe | All | Maccabee Levine is next 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. | |
...
| Time | Item | Who | Notes | ||
|---|---|---|---|---|---|
| 60 min | Eureka Adoption | All | Notes | | Expand | |
| 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...
| |||
| Notes | |||||
| Background | Slack conversations:
RFC in preparation: Relevant dates:
| ||||
| - | 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. |
...