6:49 a.m.
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(a)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(a)redhat.com
On Wed, Nov 6, 2019 at 11:07 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>
>
> On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)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(a)redhat.com>
>> wrote:
>>
>>> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)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(a)redhat.com
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <
>>> slaskawi(a)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(a)redhat.com>
>>> >> wrote:
>>> >>
>>> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira
<bruno(a)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(a)lists.jboss.org
>>> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >> > >
>>> >> > _______________________________________________
>>> >> > keycloak-dev mailing list
>>> >> > keycloak-dev(a)lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >> >
>>> >> _______________________________________________
>>> >> keycloak-dev mailing list
>>> >> keycloak-dev(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>
>>> >
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>