6:01 a.m.
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-devel(a)lists.fedorahosted.or
> > > g
> > > To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorah
> > > oste
> > > d.org
> >
> > _______________________________________________
> > FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahos
> > ted.org
>
>