Open 389-ds-bot opened 4 years ago
Comment from rmeggins (@richm) at 2017-02-11 23:04:17
Metadata Update from @richm:
Comment from mreynolds (@mreynolds389) at 2020-04-01 17:19:19
Metadata Update from @mreynolds389:
Comment from mreynolds (@mreynolds389) at 2020-04-22 16:29:50
Metadata Update from @mreynolds389:
Comment from firstyear (@Firstyear) at 2020-04-23 02:07:27
I think this doesn't apply now given we have the system schema dirs?
Comment from tbordaz (@tbordaz) at 2020-04-23 10:00:56
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.
Comment from firstyear (@Firstyear) at 2020-04-24 01:42:54
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 ....
Comment from mhonek (@kenoh) at 2020-04-24 09:25:52
I might be missing something but wouldn't my suggestion at (#3515#comment-577304) fix this issue, too?
Comment from tbordaz (@tbordaz) at 2020-04-24 09:41:54
@kenoh I think your proposal would work but I would like to extend it. Not limiting it to the schema file name.
@Firstyear, @elkris made a proposal that could help for this ticket as well as the one referenced by @kenoh . 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
Comment from firstyear (@Firstyear) at 2020-04-27 02:21:33
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. #4098 this is where I want to start discussing the bigger schema issues we have.
Setting label to low priority.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/445
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