Conversation
filippomc
left a comment
There was a problem hiding this comment.
The scope of this PR is unclear. I suspect it's a fix for cached users within kafka listener workflows but not so sure, as I'd expect a fix for Kafka listeners to circumvent cache by construction instead of invalidating the cache.
|
|
||
| ## Configuration | ||
|
|
||
| Add the following to your `settings.py` after importing the CloudHarness settings: |
There was a problem hiding this comment.
I'd mention that the preferred way to get started is to use harness-application
| ## Installation | ||
|
|
||
| ```bash | ||
| pip install cloudharness-django |
There was a problem hiding this comment.
This might confuse and make the reader expect that cloudharness-django is on pip
| Add the library's settings module to the **top** of your `settings.py`: | ||
|
|
||
| ```python | ||
| PROJECT_NAME = "my-app" # must be set before the import |
There was a problem hiding this comment.
Not an issue with this specific PR, but having a name that's unrelated from the cloudharness configuration for the application can be confusing. get_current_configuration().name would be more consistent IMO
| Run migrations once after installation: | ||
|
|
||
| ```bash | ||
| python manage.py migrate |
There was a problem hiding this comment.
We should probably suggest the preferred way to run migrations (the init container with the lock, now in templates)
| init_listener_in_background() | ||
| ``` | ||
|
|
||
| If Keycloak may not be reachable immediately (e.g. during container startup), use the background variant for services as well: |
|
|
||
| ### Cache invalidation | ||
|
|
||
| When a user is deleted or deactivated in Keycloak the Kafka event handler calls `invalidate_user_cache()` to remove the stale cache entry before syncing. You can also call it directly: |
There was a problem hiding this comment.
Is this relevant for the user of the library or more interesting for the library developer? Also this is the first time the kafka event handler is mentioned
|
|
||
| ## Event-driven synchronisation | ||
|
|
||
| `KeycloakMessageService` consumes the `keycloak.fct.admin` Kafka topic. On each Keycloak admin event it dispatches to the appropriate sync method: |
There was a problem hiding this comment.
This deserves more context. The event based sync adds real time update of user properties, but it's not necessary for the users sync functionality to work in general
| init_services() | ||
|
|
||
| # Start the Kafka consumer in a background thread | ||
| init_listener_in_background() |
There was a problem hiding this comment.
Optional, and requires harness.dependencies.soft += events
Implemented solution
Use contextvars and invalidate user cache (on delete/update user event from KC)
Also added a README about how this Django app works and how to use it
Breaking changes (select one):
breaking-changeand the migration procedure is well described abovePossible deployment updates issues (select one):
alert:deploymentDocumentation (select one):