[keycloak-dev] Versioning - Keycloak Operator

Wed Nov 6 12:27:18 EST 2019

>
> 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
>>>
>>