2022-10-19 Meeting notes

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll

Ingolf Kuss is next, followed by Maccabee Levine 

-TCR Board Review

All

No news.

-RFCsAll

No news.

1 minThings FOLIO could do betterAll


10-15 min

Technical Council Sub Groups Updates

All


Ingolf and Tod went over the Pain Points page and worked it into the Goals & Objectives page. Tod wants to wrap up this week.

Translation subgroup didn't meet.

Breaking Changes: Ankita started working on the RFC. Will send it by the end of next week.

New  subgroup "Improve the TCR process": Marc Johnson volunteers to participate.

5 minSpring Boot 3.0

All

  • Upgrade to Spring Boot v3.0 ?
    • There's a lengthy discussion in #folio-spring-base about this.  Here are some highlights:
      • Spring Boot 3.0 requires Java 17
        • Has implications for scratch envs – currently don't support Java 17
      • Spring Boot 2.7.* - OSS supported ends Nov 2023
      • Other related frameworks - OSS support ends May 2023.  See Nolana#Frameworks.1
      • FOLIO's Nolana support period ends around August 2023 assuming a similar cadence to previous FOLIO releases: FOLIO Support Policy
        This gap of at least three months (Jun, Jul, Aug) puts FOLIO implementers at risk because Spring versions that have reached their end of life are neither monitored for security issues nor get patches that fix vulnerabilities.
      • Spring Boot 3.0 isn't GA until Nov 2022...  from https://spring.io/blog/2022/05/24/preparing-for-spring-boot-3-0:
Although we don’t recommend it for production, you can try Spring Boot 3.0 milestones today to see how hard it will be to migrate your project.
  • Craig McNally advised that the release coordinator organized a meeting with with some of us.  The outcome being that we all felt that we need more information about the level of effort required to upgrade to Java 17/ Spring Boot 3.0 before making a decision.  As such, the plan is to upgrade for Orchid (team spring-force).  Then, once we have a better idea for the amount of effort required, the councils, cap planning, etc. can discuss how to proceed.  Options could be:
      • Adjust the support period for Nolana
      • Backport the Java 17/SB 3.0 upgrade to Nolana in a hot fix release.
  • Marc Johnson expressed surprise, as an active participant in previous conversations, about this meeting

Today:

Jeremy: It seem we have not come to a conclusion of this topic.

Marc: We have to signal that it is not our business right now. Let us wait for Craig. There is a technical decision. We could make that ... for any of the modules. ... It means that the TC does not need to have an official stance on it. We do not have policies in place. Vijay comes in here...  I find it mind-boggling how Spring Boot handles this. You have to upgrade a new version of this and that and to a major version of Spring itself which is not yet supported. This goes beyond my mind.

Jeremy: I can not follow this, either. It does seem like we can offer some specific guidance. 

We have to defer this discussion.

5-10 minTools/Dependencies Versions

Previous:


Today:

5 minRetrospective on the ADR Process

Notes:

There are some candidates on the Doodle Poll.


10-20 minOfficially Supported Technologies and Mod OA

A discussion, explored by Marc Johnson in this slack post (https://folio-project.slack.com/archives/C02HP10PPGB/p1665740976370339), should be had concerning the role of Officially Supported Technologies in our new module evaluation process. 


Notes:

Marc: Jeremy did a review of mod-oa. Zak did not understand the reasoning, because Groovy is not on the supported technology list.  Without changes in our policies, there will be no way to pass mod-oa to pass the acknowledgement process. Shall we stay with this policy ? The supported technologies list was written as a backend for the module acceptance criteria. Now we are talking about how to make changes to modules. So now it also applies to existing modules. There are numerous modules that are currently written and use technologies that are not on the supported technologies list. We do need to answer the "new modules" list. 

Jeremy: It is clearly a discrepancy.

If mod-oa would be submitted again based on the same technologies it would be rejected again. It would have to be completely rewritten.

Jeremy: mod-oa passed on the specific criteria; it did not fail the acceptance criteria because of the technology it uses. 

Technologie that we have experiences with are on this list. If you do implement a technology that is not on this list.,...This is intended to be a guideline.


Marc: Most folks are familiar with Java and Spring. ... Folks want to be at the Flower releases. ... Do we want to be so restrictive ? We can just add Groovy and Grails to the list. That would solve the issue immediately. But support and boot tooling issues are then unresolved. And: Where do we stop ? Do we add all new technologies in ?

Mikhail: My concern is the programming language. Maybe a beautiful new team comes to FOLIO and developers in Fortran. Then the new team disappears again. My opinion is we have to stay with Java. We could add Groovy to this list. But it would be beneficial not to make this list too long.

Jeremy: The process we have designed allows for people to make judgement calls. It is workable. That will potentially lead to some conflict at some time.  It will produce disagreement but I do not necessarily see this as a bad thing. 

Macabee: We need literal processes. Identify what are absoulzely core requirements.

Tod: Don't put the burden on the operations teams. On the other hand I do want there to be some flexibility. A nice compromise: Accept Java, Grails, NodeJS, Perl & Python (or something like that). 

Owen:  We should not discourage those who are already enthusiastic. ... We will have an issue of support. It is the number of people that we have. We have seen that multiple times.  A statement of a vision of the technical environment. Let us improve the overall situation of managing FOLIO. We always have bigger problems here. If we add one more technology, we will talk about this topic again.

Ingolf: I support Tod that we should ask the dev ops teams what burden that puts on them if we add a new technology. We should go step by step, for now only inquire about Groovy and Grails. In my opinion, adding these technologies does not put more work to the sys ops folks, because they are development tools.

Jeremy: Jason Root is very lassé faire about this. He just puts it in a container. And he does not think about compute costs. But a hosting provider will be very concerned on hosting costs. 

Marc: From a centralized build operation perspective: The dev ops folk did that years ago, there is nothing new to do. The other thing is the system operation. Some hosting containers build from source and do not use Docker containers. We need to make life easier for all of these people. 

Marc: We should add Groovy, it is a practical thing to do. There are at least two non-TC groups that are discussing this. How do we get more people willing to build things for FOLIO. There is another group from Julie Bickle. ... Some of the challenges will go away naturally. Then the project overall wins and the challenge goes away. Then we could be more lassé faire. But right now we don't have a way of distinguishing: must be in the middle of FOLIO, might be added later. It might take years to do this. But people know that right now it is not sustainable.


Form the chat:

Jakub: Why don’t we add Groovy/Grails to the allowed list?
Given that there are many modules using it

Owen: They were added to the project before the module acceptance criteria / process was in place
I think it is the case that we would see failures in a number of cases if we were to run the currently included modules through the same process as new modules
Not just on this basis

Owen: I think we tipped over from “recommending" to "requiring" when the TCR process was formulated but that change was perhaps slightly hidden by this fact
We should be so lucky
Marc :
If we choose to go that way, we should be explicit that evaluations are subjective and there isn’t a binary evaluation based upon the criteria  and we should acknowledge what that means for documentary power of these docs.

Ian : If we wanted FOLIO to be written in a single language, and present as a fully integrated system to users, we should just abandon the 'microservices' concept and embrace the monolith.

Tod: Those are two different concepts that do not need to be combined.

Marc: Ian, we effectively decided to go homogenous when we said all UIs must be stripes based and backend must be Java. As Tod says, the deployment strategy is related yet separate to that. I would like to emphasise that the group working on a desirable future state for FOLIO and the CC capacity challenges group both want to make it easier for system operators to customise and to shrink the centrally owned and strongly governed stuff.

Tod: ++Owen: How do we make FOLIO a success, given the context.

Owen: That's a sunk cost at this point because it already works. From Owen Stephens to Everyone. Unless you remove mod-agreement, mod-licenses as well.

Jakub: Grails is still JVM so purely from the operations point of view there is less risk. Assuming the modules are well documented and follow similar patterns in terms of access to infrastructure.

10:59:26 From Tod Olson to Everyone:

There's also different tooling that is needed for our QA processes.

11:00:26 From Owen Stephens to Everyone:

I want to add one other specific comment around the question of flexible interpretation of guidelines is that if we are going to have some degree of leeway to interpret the criteria then why not do this on the basis of exceptions for excluding things rather than including things - that is we should have a policy that assumes inclusion rather than exclusion

11:01:35 From Tod Olson to Everyone:

Nice framing, Owen.

11:04:05 From Owen Stephens to Everyone:

To just pick up on the point about the development language etc being independent to sys ops - I understand that, but if we can get away from the tyrany of the Flower release then we can worry less about some of the minutiae of modules as we don't have to 'accept' them

11:04:59 From Owen Stephens to Everyone:

And I think one of the reasons the Flower release is attractive because people want some 'easy' option for running Folio


Topic Backlog
20 min

Tech Council Charter

All



Previous Notes: TC charter has been updated recently, how would the TC like to review it?

Jeremy Huff Was it written by TC or by someone else? - Craig McNally It was written by TC?

Craig McNally Let's create a draft version, discuss it, communicate to other councils before publishing

Tod Olson A comment to Guiding Principles .... (smth that should be explicitly stated as a GP) - Tod will add a comment to the doc

Some conversation followed.. some comments were added to the doc itself

Review and comments from TC members are welcome

After review, what will our rewrite process be?

Suggestion: make a subgroup to handle the rewrite.

What's the value of continuing the review in TC as a whole? Would provide a general summary of feeling about the current charge. Useful onboarding, or better to onboard with a revised charge?

Seems like a subgroup has formed: those who have actually commented

Decision: will continue with review, try to be quick and then hand to a subgroup


Notes: 

Jeremy: This needs to be either a new subgroup or an individual charge. After we have identified what needs to change we need to ... (initiate actions). 

Marc: We need to continue to review.


Review

Guiding Principles:

Need some revision per above, make these clear as they are what we go to when we are uncertain.

Motivation review:

Much language needs to change: relationship with PC is different, TC does not do resourcing, "platform" is a dubious term now.

Structure and Composition:

Much of this is redundant with FOLIO Governance Model. Should refer to that document, and retain only those items that supplement that document.

Responsibilities:

What does "own architecture" mean? When we reviewed a year ago, concluded we were not doing this well. There are some abandoned blueprint documents.

Do we think we are still responsible for this? Yes. The purpose of TC is to set some constraints or shared agreements about how the platform develops. TC does not have many options for enforcement, want compliance. Might affect how we approach the architectural guidance.

Opposing view: approach as agreement and consent rather than enforcement and compliance.

Giving teeth or power to the councils balances the weight of more powerful community members, like a check and balance. One challenge for the councils is that some voices have made decisions and councils have to retroactively accept these decisions. This creates a disincentive to talk to the councils as they may disagree. So incentive is to do first and ask permission later.

Define processes, etc.: need to be clear about project requirements v dev team domain

Maintenance of Contributor licenses, etc., CoC, etc.: Many of these seem to be for CC

Out of Scope: need to update the audience for these bullet points, broader than PC.

Key deliverables:

Much language inconsistent and out of date, some things up in discussion and may change radically.

May need two phases: short term immediate changes, then long term after other discussions resolve.

Architectural blueprint - have provided but need to update the deliverable.

RFCs: need to add ADRs

20 min

WOLFcon Hot TopicsAll

An overview was provided of the "hot topics" at WOLFcon.  It seems clear that the TC ought to be involved in these discussions/efforts;  what is the best way to participate?

  • Platform minimal
  • Applications/bounded contexts & application management
  • Blue/green deployments
  • Kafka/messaging improvements
  • FOLIO governance
  • API technical debt
  • ???

Notes:


How can/should the TC weigh in on the architectural impact of new modules?

Introduce the topic

  • What do we want to get out of this conversation?
  • Does this require a subgroup or individual to generate a proposal?

Optimistic Locking interfering with batch update in inventory

Conversation started in slack:

The Data Migration subgroup of SysOps has been struggling with how optimistic locking has interfered with batch update in Inventory. They've asked me to bring it to TC to see if there's a way to push this forward. The current open ticket is MODINVSTOR-924 Batch update with optimistic locking disabled. (This was split off from MODINVSTOR-910.)

Topic has been addressed. Core team has agreed to implement as separate API that disables optimistic locking.

See also Bulk Operations redesign, different issue but seems related.


Ease of Installing FOLIO

All / Ian Walls 

From last week:

  • Ease of installing/deploying FOLIO - Ian Walls , Marc Johnson , Jeremy Huff
    •  Primary task the Tc would take on by making FOLIO easier to get up and running. Would also reduce AWS costs so that the money coming from Membership groups can be flowed to other aspects of FOLIO. Tc is the best equipped group to decide on how to make installing and deploying Folio easier and cheaper.
    • Craig McNally - Brainstorming open ended session with Ian Walls and then discuss further before or after WOLFcon depending on the brainstorming session. Ian Walls and Tod Olson to frame the topics of discussion for the brainstorming. 

Today:

  • Probably defer, but keep on the agenda so we don't lose track of this...

Revisiting FOLIO Governance

All / Ian Walls 

Slack discussion:  Revisiting FOLIO Governance 

    • Ian Walls - should be best discussed in cross council meeting possibly at WOLFcon. Idea to was bring this up at a high community level not necessarily the Pc or TC. Doesn't need to be on TC agenda next week. Aspects to be discussed at WOLFcon.
    • See also:  messages to PC and CC council channels

Action Items

  •  Craig McNally investigate a calendar to track long term TC responsibilities