Versions Compared

Version Old Version 4 New Version Current
Changes made by

Jenn Colt

Jenn Colt

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Time

Item

Who

Notes

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?

  • these are FOLIO specific packages of Kong/Keycloak

  • 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