related to https://fedorahosted.org/389/ticket/444
There may be cases where you do not want to use the standard schema provided in /etc/dirsrv/schema - unfortunately the upgrade process will always attempt to re-copy schema files from /etc/dirsrv/schema to /etc/dirsrv/slapd-INST/schema - it would be nice to specify which schema files should never be upgraded
Metadata Update from @rmeggins: - Issue assigned to rmeggins - Issue set to the milestone: FUTURE
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue close_status updated to: None - Issue tagged with: Schema
Metadata Update from @mreynolds: - Assignee reset - Issue set to the milestone: 1.4.4 (was: FUTURE)
I think this doesn't apply now given we have the system schema dirs?
Let's assume we have a deployment with only standard schema definitions(/share/dirsrv). An upgrade will update those standards files. If I read correctly the request, the demand is to be able, during an upgrade, to not update a given set (blacklist) of those standard schema. IMHO the request still applies. It should not be too complex to do (but I am not upgrade script expert) . Also I do not know why it is needed.
Well, we can't use upgrade scripts either ... because of containers.
So really, we ned a way to say "don't load this schema file" or "don't load this schema element" if that's the case.
Honestly, I wonder if this is really just part of the bigger schema questions we have at the moment ....
I might be missing something but wouldn't my suggestion at (https://pagure.io/389-ds-base/issue/50457#comment-577304) fix this issue, too?
@mhonek I think your proposal would work but I would like to extend it. Not limiting it to the schema file name.
@firstyear, @lkrispen made a proposal that could help for this ticket as well as the one referenced by @mhonek . The idea was to have a reference repository (a file) containing the list of schema files (under /etc or /share or anywhere ?) to load. At startup, the reference repository is read and only schema files listed are loaded. I think it would address this ticket but also #50457
I think it gets a bit tricker because when you throw in schema replication, if you have mismatched server blacklists, you could have all kinds of weird things happens.
Right now, we have a weird mix of "schema is local" but also "schema is distributed", and we need to stop straddling that line and pick "one or the other" IMO. https://pagure.io/389-ds-base/issue/51045 this is where I want to start discussing the bigger schema issues we have.
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/445
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.