Bug 52672 - [O365]: Prepare UDM extensions for UCS 5.0 update
[O365]: Prepare UDM extensions for UCS 5.0 update
Status: NEW
Product: UCS
Classification: Unclassified
Component: Office 365
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-7-errata
Assigned To: Mail maintainers
Mail maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-01-20 20:51 CET by Arvid Requate
Modified: 2021-01-21 09:26 CET (History)
1 user (show)

See Also:
What kind of report is it?: Development Internal
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): API change
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2021-01-20 20:51:32 CET
The Joinscript 40univention-office365.inst contains calls of `ucs_registerLDAPExtension` which don't specify a `--ucsversionstart'/'--ucsversionend' yet. When a UCS primary DC gets updated to UCS 5.0, the postup.sh will resync the listener module udm_extension (and ldap_extension) and the adjustment for Bug #51622 then causes all modules to get removed from LDAP that don't flag their Python compatibility status at all. Additionally the assiciated files will get removed from the filesystem (Bug #51531).

So, in order to keep the UDM extensions active and installed on UCS 4.4 systems, we need to at least specify "--ucsversionend 4.99-0", to signal that the Module has been checked for Python compatibility and that it is not yet Python3 compatible. That way, the UDM extension will only be available on the UCS 4.4 Systems but the primary directory node and other systems running UCS 5.0 will not commit the files to the filesystem, so the UDM on those Systems cannot use them. At least this needs to be done before the release of UCS 5.0.

A better option would be to make the UDM extension also available on UCS 5.0 systems.
For this, the registered python code needs to be checked and migrated to Python3. If it is possible to keep the module compatible to both Python versions, then it would be best to do that and signal this fact by passing the options:
  --ucsversionstart 4.4-0 --ucsversionend 5.99-0

In the rare event that the code cannot be kept compatible to both Python versions, there is another option (see Bug #52433) outlined in the concept paper.