[KEYCLOAK-19303] - Allow managing providers through CLI#328
[KEYCLOAK-19303] - Allow managing providers through CLI#328pedroigor wants to merge 1 commit intokeycloak:mainfrom
Conversation
bec4bf6 to
ee451fe
Compare
ee451fe to
56ffa79
Compare
| * `enable`, to enabled providers | ||
| * `disable`, to disabled providers | ||
| * 'install', to install a provider | ||
| * 'uninstall', to install a provider |
| Default: default | ||
| Provider (name: default, factory: class org.keycloak.locale.DefaultLocaleUpdaterProviderFactory) | ||
|
|
||
| To get more information, including the complete list of providers for a SPI, append `--full` to your command line. |
There was a problem hiding this comment.
maybe "...including a complete list of available providers..." is more concise here? Also: What does "all installed" mean. All "used at the moment", or "all which are installed in general for Keycloak.X" - from the result I think it's the former, which I'd also prefer. Just want to double-check.
There was a problem hiding this comment.
Installed means those Keycloak is using, those you have at runtime. The available providers (even those not installed) should be there when using --all.
| To get more information about each SPI, it should be possible to run `kc.[sh|bat] list-spi`: | ||
|
|
||
| ``` | ||
| Listing available SPI (see --help for more options) |
There was a problem hiding this comment.
I'm not sure if this makes sense at all without the information provided by --full. Can you clarify the use case of just running kc.sh list-spi?
There was a problem hiding this comment.
Yeah, it kinds of lacks some value. But the design is based on incremental steps:
- What are the SPI offered by Keycloak that I can customize? Run
list-spi. - How can I customize that SPI? Run with
--full. - What are all the SPI offered by Keycloak even those I'm not supposed to customize? Run
-all.
Note that regardless of the approach, the value-added is still not great. IMO, the reasons are:
- Although Keycloak is very often customized, most of the SPI people use is marked as internal. That is kind of contradictory. Most of our SPIs are marked as private and never managed to get as public.
- We lack a description and documentation for most SPIs. It would be nice if we could show to people at least a description and give them a link to our doc about how to use an SPI (e.g.: https://www.keycloak.org/docs/latest/server_development/)
- One of the improvements we discussed to Developer Experience is abstract the complexities of our SPIs and allow people to write extensions based on CDI and Annotations. Possibly using archetypes for creating projects with some example code. Showing interfaces you can use is not so user-friendly.
I'm also not sure about list-spi. If you guys think we can live without it, I'm fine to removing it.
|
|
||
| ### The `provider` command | ||
|
|
||
| The `provider` command provides utilities to query, (un)install, and enable/disable providers. The usage of this command is the following: |
There was a problem hiding this comment.
Does provider install command allow to add custom provider implementation with java classes in some jar file or source repo into the KC image?
There was a problem hiding this comment.
Yeah, that is the idea. It would be a more clean alternative to deploying jars directly into the providers directory.
We could also:
- Support fetching providers via HTTP (e.g.: maven artifact)
- Provide some nice repository for oficial extensions (similar to what quarkus does) and use this repository for listing and installing additional features
But initially, I'm not sure if it makes sense to provide the installation commands. But focus on troubleshooting and querying the distribution for details about what is installed.
stianst
left a comment
There was a problem hiding this comment.
As an extension often comes in the form of implementing more than a single provider I would like to introduce a concept that can wrap multiple providers into an extension, and have the option to manage extensions, rather than just individual providers.
No description provided.