389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 90 forks source link

create schema upgrade blacklist #445

Open 389-ds-bot opened 4 years ago

389-ds-bot commented 4 years ago

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

389-ds-bot commented 4 years ago

Comment from rmeggins (@richm) at 2017-02-11 23:04:17

Metadata Update from @richm:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-04-01 17:19:19

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-04-22 16:29:50

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

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?

389-ds-bot commented 4 years ago

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.

389-ds-bot commented 4 years ago

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 ....

389-ds-bot commented 4 years ago

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?

389-ds-bot commented 4 years ago

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

389-ds-bot commented 4 years ago

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.

jchapma commented 2 years ago

Setting label to low priority.