2024-04-24 - Architectural PoC

Enter questions here:

Big picture

• What is the concrete motivation for any of this? What problems does it solve? Why can they not be solved within the existing architecture?
• Is the main driver a rework of authentication/authorization? Do we have benefits in this rework?

Authorization

• How do existing permissions defined by modules work with Eureka architecture (Kong, keycloak, sidecars etc) e.g. what checks that a client can make a request to a module? (MJ)
• Many universities and libraries use SAML/Shibboleth, advanced (!) LDAP, and/or OpenID Connect (OIDC) for authentication. The respective Kong plugins are not OSS but require a monthly payment: https://docs.konghq.com/hub/?category=authentication What effort is needed to support these authentication methods without these plugins but with OSS software? (JC/ML/JL/Sysops)
• Mutual TLS (mTLS) is a state-of-the-art authentication method available for more than 20 years that at least some universities/libraries need to use to protect their systems against attacks in the next years, for example for machine-to-machine communication. However, Kong's mTLS plugin is not OSS: https://docs.konghq.com/hub/kong-inc/mtls-auth/ How can a FOLIO system that uses Kong can support mTLS without paying for that plugin, what effort is needed? (JL)
• The permissions set up in Eureka seems really different from the permissions set up in current FOLIO, will modules be able to handle both without changes? (JC)

Development

• Do module to module requests go direct (using sidecars, rather than via okapi) when Eureka architecture is used? (MJ)
• How do applications work with Okapi (instead of Eureka architecture)? (MJ)
• What fulfils the role of the Okapi APIs e.g. to install / upgrade modules in Eureka (when okapi is no longer present) (MJ)
• Will it be possible to document for all dev teams (including current teams not involved in Eureka and future teams) ways to include any environmental switches needed to have their app run in both a Eureka platform and non-Eureka platform? (JC)
• Is there anything that needs to change in modules to be able to run on both okapi and Eureka that can't be handled by environmental variables? Every place where it says Okapi in the code can you just point that at Kong instead without changing the module? (JC)
• Will everything on a Eureka platform need to be an application? If a team develops primarily for a non-Eureka audience, will those on a Eureka platform be able to figure out how to write an application descriptor for those modules without help from the team? Should the community provide either descriptors or guidance for doing this? (JC)
• What will be the impact of Kong on locally developed integrations that currently call Okapi? What will level the of change be (like find replace okapi/kong or more)? (JC)

Today's notes:

• Motivation here - to a large extent about authentication. Different version of core platform needed for higher security environments. For ex, need end to end encryption, touches how we do authorization.  Partly revamping some of the things we did in the past with more modern choices, as happens with software dev
• Slide illustrating Kong flow
  • A lot questions about Kong. Kong is just an API gateway, Okapi extends beyond that. Kong only does the gateway, Keycloak takes on the authentication.
• Separation of authorization from the gateway. Authorization barrier is located in the sidecars.
• Kong isn't responsible for auth, therefore the Kong auth plugins aren't needed, Keycloak with the sidecar handles the auth.
• Kong won't handle the Kafka interaction
• What is a sidecar? Is it a kubernetes sidecar? No not specific to kubernetes. Additional container that runs along the module container. Enforce authorization, tenant enablement checks. What ensures the module communicates via the sidecar?
  • Quarkus is what we use for the sidecars
• Slide of Eureka based authorization
  • Kong registers the URL for the sidecar so that is how the request is routed, Kong doesn't know about the module, just the sidecar
  • Sidecar performs auth with keycloak then passes request to module then returns response
• What keeps modules from communicating directly?
  • We don't prevent it but want the requests to go through the sidecars. One module's sidecar communicates to the other module's sidecar
  • In Okapi there is an x-okapi-url header. In new platform put the sidecar to populate that header with its own host, its own x-okapi-url. The sidecar knows how to proxy that call
• Keycloak provides login page in new. platform, can make it look like the old login page. Some adjustments in stripes, a branch with minor changes. Instead of local login, use keycloak page, keycloak interacts with mod-login keycloak, gets token for stripes
• Authentication keycloak, authorization side cars. side cars have user and request contexts, sends to keycloak.
• How much code is involved in  the sidecars? Is it mostly configuration? where do the sidecars live? in module repo? central repo?
  • Quarkus sidecars
  • One generic sidecar codebase, develop once and reuse over and over
• Are Kong and Keycloak interchangeable with other products? Are there generic protocols in these products to allow them to be switched out by sysops?
  • At run time OpenID connect is used. Challenge would be when configuring/during deployment. Applications need to be registered which gets into specific models provide by keycloak for instance. Do need some alignment between FOLIO and inner workings.
  • For Kong at least at runtime there's nothing specific to Kong, it proxies request appropriately, manager services and Kong creates routes and services, you'd have to make adjustments in the manager services to use a different gateway. Not plug and play. Same for Keycloak but more work involved to use something else because there are more interactions. Would require code changes.
• Can you run sidecar centrally instead of on every module so you could save some resources? In theory possible but haven't really considered. Might have to do additional things to account for that. Want to position this platform to work with the 'application' future we have envisioned with FOLIO. There's some close relationship between the module and the sidecar.
• Keycloak and Okta? - not so much replacing Keycloak but if using Okta, Okta would be an identity provider
• A lot of the motivation is about authentication/authorization, being able to support multiple providers. Keycloak can support multiple IDPs in a single tenant installation
• As you enable. applications the manager services set up the routes. Use Kong api to configure  the routes. Could add an abstraction later at some point if needed, haven't considered yet. Tried to keep this generic and tied to specific container management technology. Tried to touch as little folio code as possible.  Can you run outside of kubernetes? It would be hard to manage. Will be twice as many containers as today. Seems like even today need container management system. Running on a single server hard now. Being more specific to a certain platform might make things easier.
• How are these part of application formalization? Why have both of these conversations at the same time? Could do app form without these changes? These might be good changes to but why not handle them separately?
  • They are somewhat separate. This is an effort around authentication and using mature components.
  • While doing this assume application formalization is coming so that's why put application manager and put applications in there
  • Haven't formalized any applications really yet. Adoption of application formalization is sort of separate, but this platform will be ready for it
• Kong enterprise - we don't need it because we aren't using anything that doesn't exist in the community version, don't need the plugins
  • Haven't run into anything that was a show stopper that required the non-free versions, would have dropped if they did encounter that
• Is the plan to have Kong/Keycloak/Eureka run side by side and then customers have a choice?
  • Right now have two working platforms that use the same applications, modules and so forth
  • Would like the community to accept it and adopt it, but doesn't need to be pushed in urgent manner into Ransoms
• If this will live alongside current toolset will modules be able to be maintained as they are today without needing special work to have modules work in both platforms
  • Eureka introduces things, sidecars being one. Development would need to happen. Shouldn't be incompatible, some development would need to be done
  • If FOLIO classic wanted to use application manager, they would need work
• Backend modules worked out of the box as is in Eureka. If following usual FOLIO guidelines should be all set
• Eureka Core platform has to be compatible with existing modules in FOLIO
• Will there be overlap time where you could run current FOLIO release in both ways?
  • Wouldn't see modules developed specifically for this platform
  • Will there be a Kong release and a Okapi/classic release?
    • Community will have to figure out if have two platforms supported
    • Especially with potential for smaller application. releases
• None of the backend modules had to be changed. Front end? Did need branch of stripes with some differences for Keycloak for instance. Stripes core and also UI-users, introduced some "if interface" so you get the roles from Keycloak if that is what you are running. Made some modifications to the versions page so it has hierarchical layout with the application. Changes were made to take advantage of architecture
• Integration - have lots of things that integrate with Okapi. What sorts of changes will integrations need to make? 
  • APIs proxied by Okapi shouldn't matter, Kong will just send the request to the right module, shouldn't need changes. External should be unaware of the different
  • Won't integrations need to change their auth calls? Think we have tried to maintain the same endpoints with the different flavors to maintain the apis, still can use refresh token rotation.
  • mod-login-keycloak: alternative implementation, drop in replacement for mod-login
  • tried to make as backward compatible and easy to adopt as possible
• APIs for new tenant management application and it doesn't look like have reimplemented okapi so things done for registering modules would have to be redone?
  • Okapi apis not directly applicable because of working with applications, not modules.
  • Tried to value add: tenant attributes to store more metadata about tenants as example
  • Understand handful of places in FOLIO like dev tools in the UI that make calls to internal APIs to check various things, to support that looking at creating Okapi facade component which may be helpful for this, not sure. Depends on how extensive facade is and what the tooling does
  • Just flagging won't be impactless on hosting providers
  • Not being prescriptive about drop dead date, up to providers if they want to adopt this and what their timeline would be
• Is okapi gone?
  • Yes
  • How is versioning and module compatibility handled?
    • Application manager registers application
    • Tenant manager manages tenants
    • Tenant entitlement brings them together and that has a lot of the dependency checks
    • Happens at the application level, will check to see if at interface level as well,  maybe bit of both
• Would like to do another session. Thanks  to Craig and Vince.

11:02:04 From Mike Taylor to Everyone:
No response to The Cake Is A Lie?
11:02:11 From Mike Taylor to Everyone:
No culture in the this group!
11:02:12 From Maccabee Levine to Everyone:
Replying to "No response to The C..."

Love Portal
11:02:18 From Brooks Travis to Everyone:
Glados would be proud
11:02:19 From Tara Barnett (Index Data) to Everyone:
Replying to "No response to The C..."

Favorite game
11:02:23 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "Love Portal" with ➕
11:02:25 From Felix Hemme to Everyone:
Reacted to "Love Portal" with ➕
11:02:34 From Felix Hemme to Everyone:
Reacted to "Glados would be prou..." with 😂
11:02:36 From René Lange / ZDV Tübingen to Everyone:
Reacted to "Love Portal" with ➕
11:02:40 From René Lange / ZDV Tübingen to Everyone:
Reacted to "Glados would be pr..." with 😂
11:02:44 From Tara Barnett (Index Data) to Everyone:
Reacted to "Love Portal" with ➕
11:02:50 From Root, Jason M to Everyone:
Reacted to "Love Portal" with ➕
11:02:55 From Root, Jason M to Everyone:
Reacted to "Glados would be prou..." with 😂
11:03:02 From Root, Jason M to Everyone:
Reacted to "No culture in the th..." with 😂
11:03:38 From Mike Taylor to Everyone:
Replying to "No response to The C..."

I do think Portal 2 is the single best fusion of storytelling, voice-acting and gameplay I’ve come across.
11:03:54 From Tara Barnett (Index Data) to Everyone:
Reacted to "I do think Portal 2 ..." with ❤️
11:04:49 From Mike Taylor to Everyone:
The underlying technical question that I would love to see addressed as the architecture is presented is this: what actual problems does it solve? I would appreciate it if all the presenters could have this in mind.
11:05:33 From Lynne Fors to Everyone:
Meeting notes: https://folio-org.atlassian.net/wiki/spaces/TC/pages/158236674/2024-04-24+-+Architectural+PoC
11:05:52 From Charlotte Whitt to Everyone:
Reacted to "Meeting notes: https..." with 🙏🏻
11:06:37 From Mike Taylor to Everyone:
Why do we need to encrypt beneath Okapi? We run in configurations where all that stuff is firewall off, right?
11:06:58 From Wayne Schneider to Everyone:
Note to all please mute if you are not speak (he said after double-checking himself :-) )
11:07:08 From Huff, Jeremy T to Everyone:
Reacted to "Note to all please m..." with 😃
11:07:20 From Root, Jason M to Everyone:
@Mike, end-to-end is becoming more and more of a requirement in Fed and State agencies. I know in the EU it’s also taking off.
11:07:29 From Root, Jason M to Everyone:
Reacted to "Note to all please m..." with 😃
11:07:41 From Craig McNally to Everyone:
I grabbed host so I can mute people if needed, which has already been helpful :)
11:07:52 From Matt Weaver to Everyone:
Reacted to "I grabbed host so I ..." with ❤️
11:07:52 From Root, Jason M to Everyone:
Reacted to "I grabbed host so I ..." with 👍
11:07:55 From Lynne Fors to Everyone:
Reacted to "I grabbed host so I ..." with ❤️
11:07:58 From Ingolf Kuss to Everyone:
Reacted to "Why do we need to en..." with 👍
11:08:05 From Huff, Jeremy T to Everyone:
Reacted to "I grabbed host so I ..." with 👍
11:08:09 From Mike Taylor to Everyone:
@Root, Jason M Thanks, Jason. So this is more of a bureaucratic requirement than one that has a solid technical motivation?
11:09:21 From Root, Jason M to Everyone:
Well, yeah it’s more complicated in microservices-land. But the technical motivation here is better operational security.
11:09:29 From Mike Taylor to Everyone:
Reacted to "Well, yeah it’s more..." with 👍
11:09:58 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "@Mike, end-to-end is..." with 👍
11:10:18 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "I grabbed host so I ..." with 👍
11:10:34 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "Well, yeah it’s more..." with 👍
11:10:38 From Wayne Schneider to Everyone:
@Mike Taylor a reasonable technical motivation is that given the number of applications running in separate containers on the internal network there is quite a lot of unencrypted traffic running around, so if a container is compromised it may be possible to sniff traffic that should not be sniffed.
11:11:00 From Craig McNally to Everyone:
End-to-end encryption in transit is just one example... There are a bunch of other security-related requirements. To list a few: support for multiple identity providers, support for standard auth protocols (e.g. OIDC), multi-factor authentication, etc.
11:11:09 From Root, Jason M to Everyone:
Reacted to "@Mike Taylor a reaso..." with 👍
11:11:23 From Root, Jason M to Everyone:
Reacted to "End-to-end encryptio..." with 👍
11:11:58 From Ingolf Kuss to Everyone:
How do the Manager Services interact with the rest of FOLIO (if not via Kong or Sidecars, according to the slide) ?
11:12:51 From Jakub Skoczen to Everyone:
Are these “sidecars” Kuibernetes sidecards?
11:13:17 From Craig McNally to Everyone:
All calls to modules pass through the sidecars, regardless of the client... a manager component, another module, the UI via Kong.
11:13:17 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Containers, if I understood correctly.
11:13:22 From Mike Taylor to Everyone:
Is it the intention that Kong will never communicate directly with modules, only with sidecars?
11:13:40 From Craig McNally to Everyone:
Replying to "Is it the intention ..."

only via sidecars
11:13:44 From Mike Taylor to Everyone:
Replying to "Is it the intention ..."

Thanks.
11:13:50 From Ingolf Kuss to Everyone:
Reacted to "All calls to modules..." with 👌
11:14:00 From Mike Taylor to Everyone:
Replying to "Is it the intention ..."

Craig, it might be best if you MC the questions in chat, bringing them to Vince?
11:14:00 From Ingolf Kuss to Everyone:
Reacted to "Containers, if I und..." with 👍
11:14:05 From Mark Veksler to Everyone:
Reacted to "@Mike Taylor a reaso..." with 👍
11:14:09 From Mark Veksler to Everyone:
Reacted to "Well, yeah it’s more..." with 👍
11:14:14 From Mark Veksler to Everyone:
Reacted to "End-to-end encryptio..." with 👍
11:14:29 From Craig McNally to Everyone:
Replying to "Are these “sidecars”..."

not specific to kubernetes. These are containers which run alongside module containers
11:15:50 From Mike Taylor to Everyone:
I’m not understanding that “separation of concerns” argument for these changes. In the present FOLIO architecture, modules (mod_authentication, mod_authtoken, mod_permissions) handle the authn/authz issues — not Okapi itself. IIRC Okapi has *no* code to do with auth/authz, and only invokes the relevant modules as part of its general pipeline handling.
11:17:00 From Craig McNally to Everyone:
Replying to "I’m not understandin..."

OKAPI does the orchestration. IIRC there's a "special" filter for auth which OKAPI automatically uses if the authtoken interface is available
11:18:07 From Wayne Schneider to Everyone:
Are inter-module API calls made through Kong, then?
11:18:20 From Mike Taylor to Everyone:
Replying to "I’m not understandin..."

@Craig McNally I am not at all sure that’s correct. (I would need to re-read the Okapi Guide to be 100% sure.)
11:18:21 From Huff, Jeremy T to Everyone:
Replying to "Are inter-module API..."

Sounds like no
11:19:31 From Charlotte Whitt to Everyone:
Will there be a ’sidecar’ for each bundle of apps/modules?
11:20:01 From Huff, Jeremy T to Everyone:
Replying to "Will there be a ’sid..."

It looks like one per backend module
11:20:11 From Charlotte Whitt to Everyone:
Reacted to "It looks like one pe..." with 👌🏻
11:20:27 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "It looks like one pe..." with ➕
11:21:13 From Wayne Schneider to Everyone:
Replying to "Will there be a ’sid..."

Typically in a Kubernetes environment you would bundle a microservice with a sidecar in a single pod for ease of management
11:21:55 From Charlotte Whitt to Everyone:
Replying to "Will there be a ’sid..."

Just for me to understand: a different sidecar for mod-sender, another sidecar for mod-notice, … etc
11:22:01 From Wayne Schneider to Everyone:
Replying to "Will there be a ’sid..."

Presumably this common architecture would be workable
11:22:02 From Mike Taylor to Everyone:
Replying to "Will there be a ’sid..."

(Dumbass question: is a “pod” in Kubernetes like a “container” in Docker?)
11:22:11 From Wayne Schneider to Everyone:
Replying to "Will there be a ’sid..."

(not exactly)
11:22:16 From Pampell, Stephen M to Everyone:
If this model is adopted, is there a plan to re-evaluate the platform’s security posture with a third-party audit?
11:23:30 From Craig McNally to Everyone:
Replying to "Are inter-module API..."

they are not
11:23:43 From Olamide to Everyone:
Reacted to "OKAPI does the orche..." with 👍
11:23:44 From Tod Olson to Everyone:
Quarkus sidecars
11:23:46 From Craig McNally to Everyone:
Replying to "Are inter-module API..."

note the arrows directly from sidecar to sidecar in the diagram on screen ATM
11:24:24 From Uwe Reh to Everyone:
Replying to "Will there be a ’sid..."

a pod is one ore more 'regular' containers plus one special kubernetes container
11:25:35 From Craig McNally to Everyone:
Replying to "Will there be a ’sid..."

There's a single generic sidecar codebase see folio-org/folio-module-sidecar
11:25:40 From Mike Taylor to Everyone:
It sounds like sidecars are proxies that impose an auth barrier. Is that correct?
11:25:46 From Craig McNally to Everyone:
Reacted to "Quarkus sidecars" with 👍
11:25:49 From Thomas Trutt to Everyone:
https://quarkus.io/ <_ is the the correct url
11:26:27 From Jakub Skoczen to Everyone:
Or, on other words, was there any customisation done to Kong? E.g via a custom plugin?
11:26:37 From Jakub Skoczen to Everyone:
Could it be replaced with just standard NGINX?
11:28:28 From Pampell, Stephen M to Everyone:
Replying to "https://quarkus.io/ ..."

Quarkus is indeed a Kubernetes native framework. https://quarkus.io/kubernetes-native/
11:28:59 From Pampell, Stephen M to Everyone:
Replying to "https://quarkus.io/ ..."

So you would need to run these sidecars (and the platform) in Kubernetes (based on my understanding)
11:29:19 From Ingolf Kuss to Everyone:
Replying to "https://quarkus.io/ ..."

No, you can also run them in plain docker.
11:29:34 From Pampell, Stephen M to Everyone:
Reacted to "No, you can also run..." with 👍
11:29:55 From Wayne Schneider to Everyone:
Replying to "https://quarkus.io/ ..."

The administrative overhead would be higher with other container orchestration frameworks
11:30:00 From Mike Taylor to Everyone:
(Re-upping this.) It sounds like sidecars are proxies that impose an auth barrier. Is that correct?
11:31:35 From minus (liu) to Everyone:
Would the sidecars double the number of containers needed to run folio?
11:32:26 From Huff, Jeremy T to Everyone:
Replying to "Would the sidecars d..."

I feel like the answer has to be yes
11:33:34 From Root, Jason M to Everyone:
Just some general tech info about sidecars in a K8s distributed services model: https://www.techtarget.com/searchapparchitecture/tip/The-reasons-to-use-or-not-use-sidecars-in-Kubernetes
11:34:00 From Root, Jason M to Everyone:
Replying to "Would the sidecars d..."

Yes, though they tend to be smaller in resource requirement, and usually pull a common image.
11:34:22 From Wayne Schneider to Everyone:
How does horizontal scaling work with sidecars?
11:35:05 From Pampell, Stephen M to Everyone:
Replying to "How does horizontal ..."

https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/
11:35:54 From Root, Jason M to Everyone:
Replying to "How does horizontal ..."

The sidecar would, in general, scale with the primary pod.
11:37:06 From Maccabee Levine to Everyone:
I use the vagrant boxes
11:37:21 From Ingolf Kuss to Everyone:
I use plain docker. It works fine!
11:37:30 From Charlotte Whitt to Everyone:
Reacted to "I use the vagrant bo..." with 🌸
11:37:33 From Charlotte Whitt to Everyone:
Reacted to "I use plain docker. ..." with 🌸
11:37:39 From Maccabee Levine to Everyone:
Using vagrant for the backend is still the recommended (i.e. documented) method for ui module development.
11:37:47 From Ingolf Kuss to Everyone:
Reacted to "I feel like the answ..." with 👍
11:37:53 From Welling, William Stanley to Everyone:
https://konghq.com/products/kong-gateway

If expanding sections, there is a lot of red check marks on the Open Source offering. What costs are there with Enterprise and Konnect? Is there any likelihood where the Enterprise or Konnect becomes a sucscription cost for implimenting institutions?
11:38:13 From minus (liu) to Everyone:
Linköping University runs folio in podman on one one server (except edge modules)
11:38:35 From Charlotte Whitt to Everyone:
Reacted to "Linköping University..." with 🌸
11:39:00 From Kirstin Kemner-Heek to Everyone:
Reacted to "Linköping University..." with 🌸
11:39:01 From Kirstin Kemner-Heek to Everyone:
Removed a 🌸 reaction from "Linköping University..."
11:39:11 From Andreas Mace to Everyone:
Reacted to "Linköping University..." with 👍
11:40:39 From Peter Murray to Everyone:
Reacted to "Linköping University..." with 👏
11:40:48 From Ingolf Kuss to Everyone:
Reacted to "Linköping University..." with 👏
11:41:11 From Tod Olson to Everyone:
We have only 20 minutes left, so want to use the time wisely.
11:41:52 From Root, Jason M to Everyone:
Reacted to "We have only 20 minu..." with 👍
11:42:06 From Welling, William Stanley to Everyone:
Replying to "https://konghq.com/p..."

implementing
11:42:21 From Marc Johnson to Everyone:
Can applications / application manager be used with the current architecture (no kong, keycloak or side cars)?

I’m not sure if this question has been answered already (as I came late)
11:42:29 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "I use the vagrant bo..." with ➕
11:42:33 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "I use plain docker. ..." with ➕
11:42:53 From Mike Taylor to Everyone:
THat’s good to hear, @vbar. To me, adopting non-open source code into FOLIO would be a desecration.
11:42:54 From Thomas Trutt to Everyone:
I think that is the risk with any external project.. at anytime it may become paid, the community would have to pivit at that point.. IMO
11:43:01 From Huff, Jeremy T to Everyone:
Replying to "Can applications / a..."

This was what I was trying to ask a moment ago. I feel like the answer was that yes, the application formalization can be implemented without these changes.
11:43:12 From Mike Taylor to Everyone:
Replying to "I think that is the ..."

Or fork and maintain.
11:43:20 From Thomas Trutt to Everyone:
Reacted to "Or fork and maintain..." with 💯
11:43:26 From Huff, Jeremy T to Everyone:
Reacted to "THat’s good to hear,..." with 👍
11:43:39 From Marc Johnson to Everyone:
Replying to "Can applications / a…"
My interpretation of the answer was not the same as you

I thought folks said eureka had to come first
11:43:41 From Welling, William Stanley to Everyone:
Has there been any discussion on developer representation with these open source solutions?

https://github.com/quarkusio/quarkus/graphs/contributors
https://github.com/quarkusio/quarkus/graphs/contributors
https://github.com/keycloak/keycloak/graphs/contributors
11:43:54 From Welling, William Stanley to Everyone:
Replying to "Has there been any d..."

https://github.com/Kong/kong/graphs/contributors
11:44:05 From Root, Jason M to Everyone:
Reacted to "Or fork and maintain..." with 💯
11:44:07 From Huff, Jeremy T to Everyone:
Will these changes be a part of an RFC?
11:44:12 From Peter Murray to Everyone:
Replying to "I think that is the ..."

Is it something that, if forked, we could reasonably maintain? (Or equivalent/better than our Okapi maintenance today?)
11:44:46 From Marc Johnson to Everyone:
Replying to "I think that is the …"
Forking it might undermine the benefits of this being something we leverage and don’t need to maintain
11:45:01 From Ingolf Kuss to Everyone:
Reacted to "I think that is the ..." with 💯
11:45:29 From Ingolf Kuss to Everyone:
Reacted to "Or fork and maintain..." with 👌
11:45:33 From Julian Ladisch to Everyone:
Can mTLS been used for edge-modules without using the paid Kong mTLS plugin?
11:45:38 From Peter Murray to Everyone:
Replying to "I think that is the ..."

Forking, for me, assumes a worst case scenario -- we don't want to do it, but if we had to, could we realistically maintain the fork ask well as Okapi maintenance is now?
11:47:19 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Just an FYI regarding the discussion about the operation of FOLIO. We are still in the process of switching to Kubernetes orchestration, as we need to experiment with the integration of the technical infrastructure as part of our evaluation, also to get to know the possibilities and exploit the potential of our hardware. Vagrant just as plain docker-compose were and are our first steps.
11:48:00 From Peter Murray to Everyone:
It is refreshing to hear that sites are doing FOLIO with Docker Compose and Podman!
11:48:17 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "Linköping University..." with 👍
11:48:18 From Tobias Stumpp (ZDV/BSZ) to Everyone:
Reacted to "Linköping University..." with 👏
11:48:37 From Marc Johnson to Everyone:
I don’t think we know what the transition plan is yet
11:48:47 From Mike Taylor to Everyone:
Replying to "I think that is the ..."

Not really, as we don’t know the code. But it could be done.
11:49:21 From Root, Jason M to Everyone:
Reacted to "I don’t think we kno..." with 👍
11:52:40 From Peter Murray to Everyone:
Reflecting on this graphic, I'm not sure how I feel about modules talking to each other without going through the application gateway. Yes, it would be faster by microseconds, but do we lose visibility over what is happening on the system overall by not having the application gateway in the absolute center?
11:52:46 From Brooks Travis to Everyone:
Integrations that don’t call the /_/ APIs don’t change
11:52:59 From Zak Burke to Everyone:
Confirming: the only UI-side changes were to stripes-core and ui-users, i.e. to the places that directly interact with authn/authz.
11:53:10 From Peter Murray to Everyone:
Reacted to "Confirming: the only..." with 👏
11:53:13 From Craig McNally to Everyone:
Replying to "Can mTLS been used f..."

Presently the Edge APIs are still being hosted outside of the system, so Kong is not proxying requests to edge APIs, it's the other way around.
11:53:17 From Mike Taylor to Everyone:
Reacted to "Confirming: the only..." with 👏
11:53:19 From Jakub Skoczen to Everyone:
@Peter Murray the idea, nominally, is that you use a service mesh
11:53:33 From Marc Johnson to Everyone:
Will external integrations need to use keycloak for auth / getting a token?
11:53:37 From Craig McNally to Everyone:
Reacted to "Confirming: the only..." with 👍
11:54:07 From Ingolf Kuss to Everyone:
Reacted to "Confirming: the only..." with 👏
11:54:16 From Kristin Martin to Everyone:
Sorry, have to go - thanks for the conversation!
11:54:24 From Peter Murray to Everyone:
Replying to "@Peter Murray the id..."

/me probably needs to research what a service mesh means overall to this kind of installation.
11:54:54 From Shelley Doljack to Everyone:
Does this peg folio deployment to Kubernetes? My limited understanding is that sidecars is a Kubernetes object. If so, what does that mean in terms of hosting folio?
11:55:42 From Mike Gorrell to Everyone:
Replying to "Does this peg folio ..."

Craig said this was not tied to Kubernetes. It’s “just a container”
11:55:44 From Brooks Travis to Everyone:
There were minimal changes I had to make to the FolioClient python library to support a Eureka-base system.
11:55:56 From Huff, Jeremy T to Everyone:
Reacted to "There were minimal c..." with 👍
11:55:59 From Ingolf Kuss to Everyone:
Reacted to "Craig said this was ..." with 👍
11:56:05 From Andreas Mace to Everyone:
Reacted to "There were minimal c..." with 👍
11:56:16 From Mike Taylor to Everyone:
Replying to "There were minimal c..."

This is important! What were they?
11:56:19 From Ingolf Kuss to Everyone:
Reacted to "There were minimal c..." with 👍
11:56:45 From Marc Johnson to Everyone:
@Craig McNally if there is a compatible version of login, why did stripes need to change for keycloak?

Was it only for SSO?
11:56:51 From Brooks Travis to Everyone:
Replying to "There were minimal c..."

Things that call /_/ APIs
11:56:57 From Mike Taylor to Everyone:
Replying to "There were minimal c..."

I thought as much!
11:57:10 From Olamide to Everyone:
Reacted to "Craig said this was ..." with 👍
11:57:39 From Matt Weaver to Everyone:
Does this require any special setup for local development? For example, I tend to run a single module locally and point to an Okapi instance running elsewhere. Will I need to star a sidecar process for local dev?
11:57:47 From Mike Taylor to Everyone:
+100 for the Okapi Facade API!!
11:57:56 From Jakub Skoczen to Everyone:
It will be tricky to effectively (and securely) use an architecture that heavily relies on sidecar containers without a container management platform like Kubernetes, plus a Service Mesh that gives you observability and control plane for all containers. Not to say that this isn’t the case already with FOLIO
11:57:56 From Huff, Jeremy T to Everyone:
Reacted to "+100 for the Okapi F..." with 👍
11:58:02 From Thomas Trutt to Everyone:
Reacted to "+100 for the Okapi F..." with 👍
11:59:52 From Wayne Schneider to Everyone:
Reacted to "It will be tricky to..." with ➕
12:00:08 From Mike Taylor to Everyone:
@vbar @Craig McNally Gotta say, I feel A LOT happier about all this than I did before the meeting. Thank you for the presentation and Q&As.
12:00:21 From Ingolf Kuss to Everyone:
Reacted to "@vbar @Craig McNally..." with 👍
12:00:24 From Andreas Mace to Everyone:
Reacted to "@vbar @Craig McNally..." with 👍
12:00:33 From Mike Taylor to Everyone:
I think the big missing part for me at this point is the Okapi Facade API. I hope that’s under rapid development!
12:00:39 From Brooks Travis to Everyone:
Replying to "There were minimal c..."

The big one, so far, is the facility that library provides to get module versions. It now supports both.
12:00:47 From Thomas Trutt to Everyone:
Reacted to "@vbar @Craig McNally..." with 👍
12:00:52 From Julian Ladisch to Everyone:
Reacted to "@vbar @Craig McNally..." with 👍
12:01:05 From Brooks Travis to Everyone:
Replying to "There were minimal c..."

(Or will once I can do a new release, there’s an RC that has the changes now)
12:01:53 From Marc Johnson to Everyone:
I’d like us to have another meeting
12:02:02 From Tod Olson to Everyone:
Reacted to "I’d like us to have ..." with 👍