Keycloak.X: New store #9861

stianst · 2022-01-28T11:59:39Z

stianst
Jan 28, 2022
Maintainer

Feedback and general discussions around the new store that is being built for Keycloak.X.

Other relevant discussions:

xgp · 2022-01-28T12:00:52Z

xgp
Jan 28, 2022

Can you please post the link to the example implementation based on ConcurrentHashMap?

1 reply

mhajas Jan 28, 2022

Sure, here is what we have so far:

andreaTP · 2022-01-28T13:18:37Z

andreaTP
Jan 28, 2022

I have just watched an awesome presentation regarding the new Store at DevCon.cz and I would be happy to understand a few additional details (please feel free to link me to other documents in case I'm missing those).

In the talk have been mentioned that version N and N+1 of the Store needs to be compatible for performing a zero downtime upgrade. This open a few questions:

How do you guarantee that upgrades will be always "sequential"? How would the new storage deal with "non-sequential" upgrades?
Reading this I assume that the schema upgrades will be checked to be compatible using Protobuf, one of the common pitfalls is the exponential growth and increase of complexity in the protocol to preserve the compatibility. Do you expect the schema to stay pretty much stable or do you have any guard from this risk?
Not being able to perform breaking changes(or introducing the need of an intermediate release to do so) can slow down quite significantly the development cycle, have we considered possible mitigation strategies to counterbalance this effect, or we simply consider it acceptable?

Thanks a lot!

1 reply

hmlnarik Feb 6, 2022

Thank you for the questions!

In the talk have been mentioned that version N and N+1 of the Store needs to be compatible for performing a zero downtime upgrade. This open a few questions:

How do you guarantee that upgrades will be always "sequential"? How would the new storage deal with "non-sequential" upgrades?

The proposal counts on arbitrary ordered sequences, please check here.

Reading this I assume that the schema upgrades will be checked to be compatible using Protobuf, one of the common pitfalls is the exponential growth and increase of complexity in the protocol to preserve the compatibility. Do you expect the schema to stay pretty much stable or do you have any guard from this risk?

We expect the schema to be pretty much stable, leveraging generic attributes as much as possible. Please note that the reference you have used refers to Hot Rod-specific implementation, and that protobuf does not necessarily apply to other storage technologies.

Not being able to perform breaking changes(or introducing the need of an intermediate release to do so) can slow down quite significantly the development cycle, have we considered possible mitigation strategies to counterbalance this effect, or we simply consider it acceptable?

The strategy is based on keeping the schema as stable as possible.

Navigation Menu

Repository navigation

Keycloak.X: New store #9861

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 2 comments 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Keycloak.X: New store #9861

Uh oh!

Uh oh!

stianst Jan 28, 2022 Maintainer

Replies: 2 comments · 2 replies

Uh oh!

xgp Jan 28, 2022

Uh oh!

mhajas Jan 28, 2022

Uh oh!

andreaTP Jan 28, 2022

Uh oh!

hmlnarik Feb 6, 2022

stianst
Jan 28, 2022
Maintainer

Replies: 2 comments 2 replies

xgp
Jan 28, 2022

andreaTP
Jan 28, 2022