[keycloak-dev] Versioning - Keycloak Operator

Thu Nov 7 07:49:36 EST 2019

Support is not the right word here. As that implies it is a tested and
documented combination.

Keycloak operator can not support RH-SSO, RH-SSO operator can not support
Keycloak. Otherwise, we would have to document and test the combinations,
which doesn't really make that much sense.

>From an implementation standpoint it's okay the code is there, but needs to
default to the correct images, and it shouldn't be documented/tested.

On Wed, 6 Nov 2019 at 18:27, David Ffrench <dffrench at redhat.com> wrote:

> There should be two separate versions of the operator. One community which
>> will have version based on Keycloak, and another one for product, which
>> should be based on RH-SSO versions. There is also a difference in
>> maintenance/support for the Keycloak and the RH-SSO operator. The Keycloak
>> operator will be released together with Keycloak, with no micro updates
>> (unless there are critical bugs or CVEs), while the RH-SSO release has
>> micro releases for roughly a year.
>
> Thanks, Stian. This seems to be where the confusion lies. The current
> operator allows you to create either a Keycloak or an RH-SSO instance based
> on a value in the CR spec. Since it supports both, I was finding it hard to
> understand which to map the version too. I would still be happy for the non
> productised operator to support both, with the version mapped to Keycloak.
> You can only create RH-SSO if you have a pull secret in the namespace for
> pulling those images. The productised operator can then be mapped to RH-SSO
> in the future and still support both also in my opinion but default to
> RH-SSO.
>
>
>
> DAVID FFRENCH
>
> Principal software engineer, CLOUD SERVICES
>
> Red Hat Waterford <https://www.redhat.com/>
>
> Communications House, Cork Road
>
> Waterford, Ireland
>
> dffrench at redhat.com
>
>
>
>
>
> On Wed, Nov 6, 2019 at 11:07 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun at redhat.com> wrote:
>>
>>> So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3 and
>>> RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our Operator on
>>> the Keycloak version (8.0.0) then the user wouldn't necessarily know what
>>> RH-SSO version they would get (the operator can also install RH-SSO).
>>>
>>
>> RH-SSO 7.4 will most likely be based on Keycloak 9.
>>
>>
>>>
>>> It sounds like we should base it on the RH-SSO version then, so the
>>> Operator would be v7.4.0 which tells the user that they can either get
>>> RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
>>>
>>> Does that make sense?
>>>
>>
>> There should be two separate versions of the operator. One community
>> which will have version based on Keycloak, and another one for product,
>> which should be based on RH-SSO versions. There is also a difference in
>> maintenance/support for the Keycloak and the RH-SSO operator. The Keycloak
>> operator will be released together with Keycloak, with no micro updates
>> (unless there are critical bugs or CVEs), while the RH-SSO release has
>> micro releases for roughly a year.
>>
>>
>>>
>>>
>>>
>>> On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench at redhat.com> wrote:
>>>>
>>>> > Hi Stian,
>>>> >
>>>> > I agree with your assessment since all other sub-components within
>>>> > Keycloak all use the same version. I would just like to clarify one
>>>> point.
>>>> >
>>>> > have the version identical to Keycloak upstream, and identical to
>>>> RH-SSO
>>>> >> downstream
>>>> >
>>>> > I was under the impression these were on different versions. Keycloak
>>>> > 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after Keycloak
>>>> 8.0.0
>>>> > is release does the next version of RH-SSO get released and will this
>>>> also
>>>> > be 8.0.0?
>>>> >
>>>>
>>>> Yes/no ;)
>>>>
>>>> RH-SSO has two versions. The product version (7.3.0.GA for example)
>>>> and the
>>>> underlying productized Keycloak version (4.8.3.Final-redhat-0001).
>>>> RH-SSO
>>>> 7.4.0.GA will be based on the latest Keycloak release at the time (this
>>>> will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO
>>>> micro
>>>> releases these are based on Keycloak micros (so RH-SSO 7.3.2 was
>>>> Keycloak
>>>> 4.8.12 or something like that, can't remember the exact one). As a
>>>> side-note we don't do micro releases of older Keycloak versions to the
>>>> community, so branches and releases of these are not available to the
>>>> public.
>>>>
>>>>
>>>> >
>>>> > Thanks
>>>> >
>>>> > DAVID FFRENCH
>>>> >
>>>> > Principal software engineer, CLOUD SERVICES
>>>> >
>>>> > Red Hat Waterford <https://www.redhat.com/>
>>>> >
>>>> > Communications House, Cork Road
>>>> >
>>>> > Waterford, Ireland
>>>> >
>>>> > dffrench at redhat.com
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <
>>>> slaskawi at redhat.com>
>>>> > wrote:
>>>> >
>>>> >> Ok, you convinced me guys. Let's align it with Keycloak.
>>>> >>
>>>> >> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky <jlieskov at redhat.com>
>>>> >> wrote:
>>>> >>
>>>> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <bruno at abstractj.org
>>>> >
>>>> >> wrote:
>>>> >> >
>>>> >> > > Good afternoon,
>>>> >> > >
>>>> >> > > During our stand-up meeting today we discussed the versioning of
>>>> the
>>>> >> > > new Keycloak Operator. In summary, if the versioning should
>>>> follow the
>>>> >> > > same scheme as semantic versioning, or follow our continuous
>>>> delivery
>>>> >> > > model[1].
>>>> >> > >
>>>> >> > > The "old" Operator is actually on 1.9.4 and the new version
>>>> should be
>>>> >> > > 2.0.0. But if we use our current versioning scheme, that means a
>>>> >> > > significant bump, for example, 8.0.0.
>>>> >> > >
>>>> >> >
>>>> >> > +1 for version of the operator being aligned with the version of
>>>> other
>>>> >> > components
>>>> >> > (server, adapters etc.), even if this will mean:
>>>> >> >
>>>> >> >    - Operator version will need initially to get bumped
>>>> substantially to
>>>> >> >    match the Keycloak server version,
>>>> >> >    - Operator would need to be released together with other
>>>> components
>>>> >> this
>>>> >> >    way (IOW any, even possible urgent Operator fixes would need to
>>>> wait
>>>> >> for
>>>> >> >    N+1 server release).
>>>> >> >
>>>> >> > This makes more sense / is more consistent IMHO, than keeping the
>>>> >> Operator
>>>> >> > version as a separate one.
>>>> >> > Besides that (as already mentioned) it removes the need in the
>>>> future
>>>> >> > (maybe often?) to clarify, which
>>>> >> > Operator version matches which Keycloak server version.
>>>> >> >
>>>> >> > Just my two cents.
>>>> >> >
>>>> >> >
>>>> >> > Thank you && Regards, Jan
>>>> >> > --
>>>> >> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > >
>>>> >> > > I kind of know the answer :) But the team wanted to ask.
>>>> >> > >
>>>> >> > > [1] - https://www.keycloak.org/2019/04/versioning.html
>>>> >> > >
>>>> >> > > --
>>>> >> > > - abstractj
>>>> >> > > _______________________________________________
>>>> >> > > keycloak-dev mailing list
>>>> >> > > keycloak-dev at lists.jboss.org
>>>> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >> > >
>>>> >> > _______________________________________________
>>>> >> > keycloak-dev mailing list
>>>> >> > keycloak-dev at lists.jboss.org
>>>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >> >
>>>> >> _______________________________________________
>>>> >> keycloak-dev mailing list
>>>> >> keycloak-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >>
>>>> >
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>