After merging lib389 and 389-ds-base, I think, we can improve our sample entries class.
We have - https://pagure.io/389-ds-base/blob/master/f/ldap/ldif/Example.ldif I think we can use it (parse it, take only what we need or everything, importLDIF can help too). So we won't need to care about versions because we will have it in sync with DS.
https://pagure.io/lib389/blob/master/f/lib389/configurations/sample.py https://pagure.io/lib389/blob/master/f/lib389/configurations/config_001003006.py
What do you think? Please, share your thoughts on this idea.
okay, so there is a reason I didn't use the ldif here and made them python modules.
The first is that in tests we can specify "hey we want this version" of the example entries, because I plan to change these for 1.3.7 / 1.4.x. This won't be a small change either, I want to completely rework our aci's and example layout.
So as a result, I want tests to say "I want this version of the server config".
The second reason was to allow "updating" of these values when the server upgradse, but with containers we can't do this in lib389 so I scrapped that idea.
I'd rather have these in the python than try to manage ldifs now.
Metadata Update from @firstyear: - Custom field Origin adjusted to None - Custom field Review Status adjusted to None
Ok, make sense. I agree.
Then we need to make some adjustment to the 'default' version for sample entries. Because we often will have backends created with some sample entries (most of the tests will require just the entries, and they wouldn't care about versioning). So after we merge lib389 and 389-ds-base, we will need to make sample entries according to the version we run it from. For instance, we can adjust backend.py for that, or make some change in the sample entries module. We can decide later, after the merge.
Login to comment on this ticket.