-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[KEYCLOAK-19303] - Allow managing providers through CLI #328
base: main
Are you sure you want to change the base?
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: "to _un_install"
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -563,6 +563,89 @@ Examples of commands are: | |||
Commands may support additional options to change how they are executed and behavior. For that, commands should provide the | |||
help and usage messages to document how they can be used as well as the different options they support. | |||
|
|||
### 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.