2025-06-04 Kong/Keycloak and flower releases

1 min

Scribe

All

@Jenn Colt is next, followed by @Marc Johnson

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.

*

Kong/Keycloak and flower releases

Craig

• FOLIO specific Kong that adds in a little bit - start up scripts, config, etc. Pretty static. Similar for Keycloak - add in some UI, simple plugin for SSO, also pretty static.

• Should these be released like modules or like infrastructure?

  • complicating factor - shorter support periods than FOLIO. so might need to upgrade before a flower release goes out of support, especially with longer FOLIO release cycles

  • Backwards compatibility in Keycloak releases

• these are FOLIO specific packages of Kong/Keycloak

  • https://github.com/folio-org/folio-keycloak
    https://github.com/folio-org/folio-kong

• Because we’re using community version only most recent releases are in support

• https://github.com/Kong/kong/discussions/13418

• Position: treat like modules because they have custom code specific to FOLIO and may require backporting

• Position: treat like Kafka, postgres, etc.

  • Right now not too worried about backward compatibility because using very standard stuff that doesn’t change much - very unlikely to have breaking changes. CI helps prevent breaking changes

  • Because the changes are so minor it might be okay to update mid-flower release

  • Right now our K/K releases are not bound to flower releases

• Sysops perspective: more complicated if you have to upgrade for each flower, better to have it independent

• Does seem to resemble infrastructure more than module

• Wonder if any guidelines should be set around the features we use to make sure we don’t adopt anything that is more likely to not be backwards compatible?

  • If someone would want to use an advanced feature, could hosts do that on their own? Not sure

• Can also be revisited if needed

  • Start with infrastructure approach but note in OST to review how it has gone?

• Do we want sysops to upgrade K/K separately from the flower release and more frequently? Yes that is the advice, esp for security reasons

• How does being independent work with the OST?

  • Might need a different policy/category since they change version more frequently than the other infrastructure

  • Policy something like: Sysops should upgrade to new version when those releases are public

• Tell sysops what versions are compatible with a given flower release?

• Would have to do a csp for each new release?

• When a new version comes out do we deploy to bugfest?

• Do we want to tie it to the csp process at all?

  • Doesn’t really seem right for csp

• Faster moving than most other infra

• We haven’t previously asked sysops to upgrade in this way

• Easiest might be to go ahead with new section in OST and include statement that sysops should keep them updated

• Action item: update OST to include the new section and the policy that hosts are encouraged to stay on the latest version. Keep text regarding support policies and release predictions - first draft done

• Action item: Release management needs to be made aware @Jakub Skoczen

• Should we indicate versions that have been tested? (also for other infra like Kafka)

• New releases of these should go on snapshot and bugfest - devops should be made aware @Jason Root

• @Craig McNally will talk with @Oleksii Petrenko again

-

Zoom Chat