| Time | Item | Who | Notes |
|---|
| FOLIO-3500 | | Is "apk upgrade" a workaround that should be removed from Dockerfiles, or is it best practice that should be mentioned on https://dev.folio.org/guides/best-practices-dockerfiles/ ? - We discussed and agree that it makes sense to do this.
- Todo:
Update the folioci/alpine-jre-openjdk docker image (already done)- Update the documentation linked above.
|
| EDGCOMMON-47. |
| Mitigations are known and until edge modules are fixed a message should be posted A backport to Kiwi is not needed because of easy to implement mitigation options: - Use different credentials for each tenant. OR
- Remove the X-Okapi-Tenant HTTP header from requests to these edge modules.
- Julian Ladisch to announce that in the appropriate channels (#sys-ops, etc.)
Today: - no new news here - check in next week.
|
| mod-configuration - should it be deprecated or not? |
| mod-configuration has been discussed on the development channel recently. Developers like it because they can simply drop variables to the /configurations/entries API. Simply use the "configuration.*" permission shared by all modules and you are done. No need to add schema validation, no need to add dedicated permissions, no need to add a dedicated API.
Drawbacks: - A big institution need config write permissions with module granularity. One member of staff may be allowed to edit circulation config but not aquisition config.
- No validation. mod-configuration cannot validate a POST or PUT request because it doesn't know. Only the module it belong to knows this. Relevant use case: Using curl/wget/postman/...
- No documentation. mod-configuration has no documentation, one needs to search, maybe the module's README has some? A dedicated module API always publishes the API documentation at https://dev.folio.org/reference/api/
- Performance. Requests to mod-configuration result in latency. If the config API belongs to the module the module can cache it and can invalidate the cache if the config is changed. Caching requests to mod-configuration will always result in a time period with outdated values. In mod-inventory-storage we've combined fetching the HRID config and HRID generation into a single SQL query.
- Coupling. Modules should be loosely coupled and therefore each module should store its own configs.
It was requested that a formal RFC/Architecture Decision Record been created if mod-configuration should no longer been used for module-specific configurations.
Team decided we want to have this as a RFC. Target should be to have this implemented within Nolana. Could discuss in your meetings while the RFC process moves on.
Today: - no new news here - check in next week.
|
| Official security support policy on releases |
| Security team needs - How many releases from now has to be supported? (3-4 releases or less?)
- Priority/Risk will likely factor into this as well.
- Also a matter of capacity
- Should be raised to the PC → Axel can bring this with a paper/proposal to the PC - not yet.
- Probably want to bring this to the TC as well at some point, even if only for awareness.
- WOLFcon session?
- Axel will produce a paper that outlines that problem by next weeks meeting.
- Chris to ask his stakeholders about TAMU needs - not specifically, but has started to have some conversations
- https://docs.google.com/document/d/1Un5OlutEh7M2p3AzxE8g20NmdeEhrC0KCNkfd_QLkRw
- Continue discussion from slack... Spring Boot LTS
- We need to communicate the expectation better - e.g. add something to the platform release notes indicate how long P1 security issues will be backported to that release.
- As long as we upgrade to the latest LTS release of Spring Boot in each flower release, we should be in decent shape - only ~1 mo. where we're running a version of Spring boot that's no longer supported.
- Note that we're currently a bit behind with this, even if we upgrade edge modules, etc. in a Lotus HF, kiwi and Juniper will be running older, unsupported versions for some period of time. Going forward we'll need to be diligent about this to avoid getting into this situation again.
- Update? Have we added anything to the MG release notes?
- Not yet... Craig McNally will refresh his memory on what we agreed to at previous meetings and will send out a strawman message in the slack channel for review.
- Textproposal:
Morning Glory will receive security fixes for critical issues until Orchid is released (est. Spring 2023).
Detailed information on particular issues will be provided by the security team. With this release there will be no other security hotfixes on Kiwi.
- Put this text proposal for the release into a ADR to forward this to the TC
- Julian Ladisch to set up that ADR - This is done and has been reviewed by the TC
- The TC has discussed this, and feel uncomfortable to make the call on their own. They feel that the PC needs to be involved in the decision.
- The TC will revisit next week - stay tuned for next steps
- The TC advised that we need to do some information gathering, engage those that made the LTS recommendations how we should proceed, as well as look at existing processes and policies to see if they are sufficient and can be adopted by the security team, or if there are gaps.
Today: - This was discussed at recent TC and PC meetings and the determination was that the Security team should engage Release Management on a case-by-case basis.
- TC meeting notes
- There are two ways we go about making this clear in the Morning Glory release notes...
- Simply update the wiki page ourselves, based on what's in the LTS recommendations document... OR
- Type up a slack message indicating what we'd like to add to the release notes and get approval from the PC.
|
| 5-10 min | | Jira Legacy |
|---|
| server | System Jira |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODEXPW-67 |
|---|
|
/ | Jira Legacy |
|---|
| server | System Jira |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODEXPS-109 |
|---|
|
/ | Jira Legacy |
|---|
| server | System Jira |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | FOLIO-3448 |
|---|
|
/ | Jira Legacy |
|---|
| server | System Jira |
|---|
| columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | FOLSPRINGB-58 |
|---|
|
| Team | Has there been any progress here? Last week it was noted that there was a slack conversation started about this. Need to check in on Oleksandr Bozhko's progress (he's was investigating the problem. - no news in the last 7 days... Craig McNally to nudge him and see where this stands.
- Open PR on FOLIO-3448 (Documentation as a warning for developers)
- Craig McNally to check if a new Jira has to be created for that and push on that
- A helper has been developed by Julian to prevent this issue in new/changed code.
- Mikhail F arranged a meeting for this Friday in order to explain all the details to Epam Team leads.
- There's one aspect of this that's still deserves some discussion. It was identified by Julian Ladisch and raised to Mikhail. Presently awaiting a response/feedback.
- June 23: Regarding FolioExecutionContextSetter no response, neither on FOLIO-3448 nor on #folio-spring-base Slack channel.
Today: - The proposed breaking change will be postponed and will be made in Nolana.
- For MG, the temporary fix will be made.
|
| 5 min | edge-lti-courses | Team | edge-lti-courses has been unmaintained since July 2021. Open Jiras: | Jira Legacy |
|---|
| server | System Jira |
|---|
| columnIds | issuekey,summary,created,updated,assignee,priority,status |
|---|
| columns | key,summary,created,updated,assignee,priority,status |
|---|
| maximumIssues | 20 |
|---|
| jqlQuery | key in (MODCR-81, MODCR-80, MODCR-78) |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
|
Last updates: - No real news here... Erin N. mentioned that she'll raise this with the staff at Duke. Maybe someone there can support these modules.
- Let's give it another week and then we might consider to move this out of the folio repo since there is no maintainer
- We asked Erin N. if there anything new on that
- Still awaiting response from Duke (Erin).
- Charlotte Whitt changed MODCR-81 status to "In progress" on 13/Jun/22.
- No progress, not even for the "In progress" Jira MODCR-81 on June 23.
Today: - No new news on this. Revisit next week.
|
| Kafka security | Team | The topic of Kafka security was raised as part of a conversation at the TC yesterday. The Security Team should be aware of this and probably should weigh in on the topic, or even generate proposals if we have ideas for how to solve the problem. |
* | Review the Kanban board. | Team | - There are several JIRAs on our board that haven't moved in a long time (well over a year in some cases...)
- Do we want to possibly close these as won't do?
- Craig McNally did look into how we can sort the board within swimlanes and couldn't find a way to do that. However, it should be possible to create an additional filter that will match only JIRAs which haven't been updated in the last N months/days/etc.
- Craig McNally to create such a filter (not modified recently - e.g. 3 months)
|