On Mon, 2017-07-10 at 12:44 +0200, Tomas Krizek wrote: > On 07/10/2017 12:16 PM, Simo Sorce via FreeIPA-devel wrote: > > Hi Fraser, > > I think you put on a reasonable proposal, however If I had to > > design > > this right now and had the freedom to change dogtag and the rest of > > freeipa to cope I would do the following: > > > > - Change the LDAP profile storage to have versioned subtrees for > > "system" profiles, and have a "custom" subtree for user profiles. > > > > - In the base tree have a version attribute that set what version > > dogtag should use, if absent dogtag will assume its current > > hardcoded > > default version. Profiles are never updated per se, a new version > > is > > installed and the version is upped. > > > > - On upgrade a modified profile is moved to the "custom" tree and > > the > > original version of the profile is stored in the system tree. This > > is > > assuming this does not cause older versions of dogtag to misbehave, > > otherwise we keep the modified version and make sure not to raise > > the > > version to use. We also find a way to notify the admin he should > > move > > customized profiles in the correct new section and leave system > > profiles alone. > > > > - Potentially if a dogtag server does not understand a new version, > > it > > keeps using an older version (perhaps we can have a "mandatory > > version > > attribute" to cause older versions to return an error instead. (see > > also previous case) > > > > The reason for this is that having a complex check on ipa versions > > is > > potentially fragile as well it adds yet another dimension to the > > things > > an admin need to know about to figure out why its domain is not > > using > > the "right" profiles. > > And I think in some cases there is no "conflict" between version > > profiles only new "optional" attributes you may want to > > add/support. > > > > The other option is to tie the dogtag profiles version to the > > domain > > level as well, and only ever use new ones when the whole domain > > level > > is upped. This is conditional on newer versions of dogtag being > > able to > > use older profile versions without modification in LDAP. > > I'd rather avoid any domain level bumps unless there is serious > justification for it. Additional domain levels introduce big testing > overhead.
That is the problem with domain levels, you do not introduce a whole new domain level for one feature. It means piling up (and keeping disabled) features until you have enough to justify a domain level bump. So that means, if that is the only option, the feature needs to be delayed until there are enough. Simo. > > HTH, > > Simo. > > > > > > On Sat, 2017-07-08 at 15:24 +1000, Fraser Tweedale via FreeIPA- > > devel > > wrote: > > > Hi all, > > > > > > I've published a draft design for the profile update mechanism. > > > This feature is to ensure that we can safely update included > > > profiles even when we use Dogtag profile components only > > > available > > > in new versions. > > > > > > https://www.freeipa.org/page/V4/Certificate_profile_update_mechan > > > ism > > > > > > Interested persons, please review the design. In particular > > > there > > > are two main questions I would like to discuss: > > > > > > 1. We need to store the IPA version in IPA master entries. What > > > should be the schema? > > > > > > https://www.freeipa.org/page/V4/Certificate_profile_update_mec > > > hani > > > sm#IPA_master_entries > > > > > > 2. How should we deal with customised versions of included > > > profiles? > > > There is a big tradeoff here, of complexity + flexibility vs. > > > simplicitity + reverting customisations to included profiles > > > (and > > > preventing them in future). > > > > > > https://www.freeipa.org/page/V4/Certificate_profile_update_mec > > > hani > > > sm#Dealing_with_modified_profiles > > I'm in favor of not supporting customized versions. I'm not sure how > common it is to customize these profiles among users. Unless it is > very > common, I wouldn't support them to avoid the additional complexity. > The > users always have the option to automate these customizations after > every server upgrade, if they really require them. > > > > > > Thanks, > > > Fraser > > > _______________________________________________ > > > FreeIPA-devel mailing list -- freeipa-de...@lists.fedorahosted.or > > > g > > > To unsubscribe send an email to freeipa-devel-leave@lists.fedorah > > > oste > > > d.org > > > > _______________________________________________ > > FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org > > To unsubscribe send an email to freeipa-devel-leave@lists.fedorahos > > ted.org > > _______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
