Replies: 2 comments 12 replies
-
|
Thanks a lot for opening this discussion! Regarding the implementation we have a few possible alternatives:
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I think that option 2 is the best. Although I wouldn't name it "unsupported". If you consider additional options for dev mode only, maybe use: spec:
devMode:
enabled: trueAnd for more options: spec:
devMode:
enabled: true
someExtraOption: "someExtraValue"That way one needs to explicitly enable it. It follows the idea of CRDs, is extensible, and reasonably easy to implement. And you can always claim that there is no support for this section of the CRD. Maybe even set a warning on the status section of the |
Beta Was this translation helpful? Give feedback.
-
|
@ctron Hi and thank you for raising this topic and your interest in the new Operator! I believe it really depends on the use-case of the Operator. As you correctly stated, the Operator currently targets only production-grade deployments. This is and always will be the main use-case. It is a good question whether the Operator should support other use-cases as well, as e.g. the stated dev mode. Could you please elaborate a little on what is your use-case for the dev mode? Why do you want to use the Operator in this scenario? Our current expectations for now have been that for dev purposes and playing around with the Keycloak container, users can use e.g. plain Docker. For development of the Operator as such, we usually just use our example K8s objects. |
Beta Was this translation helpful? Give feedback.
-
|
My honest feeling is that the setup for "development" is still too verbose to be "just documented", but happy to hear other opinions! |
Beta Was this translation helpful? Give feedback.
-
|
@andreaTP My thoughts were that since we're talking about development purposes (primarily of the Operator itself but possibly in more general, as stated by @ctron), and AFAICT we already have all the tools (disabling SSL/hostname), we could just create some hints for easier development in the README. Similarly to e.g. what the old Operator has. |
Beta Was this translation helpful? Give feedback.
-
|
@vmuzikar that would be one step for sure, I think that we can do a little more by enabling an "easier" path for developers "out-of-the-box" with one of the proposals made here. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a similar option to disable https also in v1alpha1 operator? Struggle to find it |
Beta Was this translation helpful? Give feedback.
-
|
@ADiTuri this discussion is regarding the new operator. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Assuming I am building some application, on top of the Keycloak operator, I might want to offer my users also a "developer" deployment. Something that doesn't require HTTPS and can run on e.g. Minikube.
However, I also want to re-use the Keycloak operator "as is", and not be required to manually install Keycloak in my developer deployment, just because the Keycloak operator only supports a production grade deployment.
Maybe that can be achieved but some global
.spec.developerMode: trueflag? Or by some other explicit configuration, acknowledging by the user that this might not be secure.In any case, I wouldn't prevent the user from doing this. As you might never know what the intent of the user was.
Beta Was this translation helpful? Give feedback.
All reactions