Bug 50253 - Handle reloading of extended attributes better
Handle reloading of extended attributes better
Status: NEW
Product: UCS
Classification: Unclassified
Component: UDM - REST API
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UMC maintainers
UMC maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-23 18:03 CEST by Florian Best
Modified: 2020-07-01 12:21 CEST (History)
6 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2019-09-23 18:03:23 CEST
Currently extended attributes are only reloaded in certain requests like .../users/user/add.

We should add a mechanism which automatically reloads extended attributes and extended options when there are changes.

This can be achieved by:
* changes of extended-* objects can trigger the reload directly
* a listener can cause a "service ... reload" call.
* ...

There are several dis/advantages for each way. We should find a good combination which suits for most cases.
Comment 1 Ingo Steuwer univentionstaff 2019-11-26 14:49:55 CET
Proposition:

* UDM REST API implements a way to trigger a reload by a client (with sufficient priviledges)
* a listener plugin on systems where the UDM REST API is installed sends this trigger in case Extended Attribute objects in LDAP have been changed in a postrun method
Comment 2 Daniel Tröder univentionstaff 2020-01-14 08:48:23 CET
IMHO a change to any of the following modules require a restart of the UDM REST server:

* settings/extended_attribute
* settings/extended_options
* settings/udm_module
* settings/udm_syntax
Comment 3 Daniel Tröder univentionstaff 2020-01-14 08:54:58 CET
There should be a way for clients to know _when_ the UDM REST server has restarted the last time. That way they can wait for it.

Scenario:
1. create an object of one of the four above modules via join script
2. wait for UDM REST server to restart
3. use UDM REST server

An entry in the UDM REST APIs root or a dedicated resource could hold that kind of metadata information (and possibly other "about this system" data in the future like the UCS version, patch level etc).
Comment 4 Dirk Wiesenthal univentionstaff 2020-01-29 15:24:04 CET
I installed OX with its UDM modules, registered by registerLDAPExtension. While the UDM CLI worked, my REST API Python client did not.

I did not expect the service to be reloaded and had to search for the reason.

I second an automated solution for this.
Comment 5 Daniel Tröder univentionstaff 2020-07-01 12:21:08 CEST
I search one hour of DL (!) time yesterday in two apps that use the UDM REST API for strange errors, only to find out that I didn't restart the UDM REST API after creating a few extended attributes.