[Freeipa-devel] New/Updated FreeIPA design pages

[Simo Sorce]

On Wed, 17 Dec 2014 13:56:24 +0100
Ludwig Krispenz <lkrispen at redhat.com> wrote:

> 
> On 12/17/2014 12:59 PM, Martin Kosek wrote:
> > On 12/15/2014 11:01 PM, Simo Sorce wrote:
> >> Hello fellow developers, I added this new design:
> >> http://www.freeipa.org/page/V4/Domain_Levels
> >>
> >> It is a prerequisite for both the Replica Promotion design:
> >> http://www.freeipa.org/page/V4/Replica_Promotion
> >> and the Topology plugins design:
> >> http://www.freeipa.org/page/V4/Manage_replication_topology
> >> (Ludwig will change this to include the changes we have discussed
> >> in a previous phone call, and which involve mostly Domain
> >> Level/Domain Upgrades/migrations issues)
> >>
> >> As usual feel free to add as needed or comments and ask questions.
> >>
> >> Simo.
> >>
> > Thanks! For starters, please follow
> >
> > http://www.freeipa.org/page/Feature_template
> >
> > next time :-) Don't worry, I updated current proposal to follow it.
> >
> > On top of what was already said, I have couple comments:
> >
> >
> > 1) Relation between domain levels and FreeIPA versions
> >
> > It is now proposed as "numbers", how do we define the relation? Did
> > you want to create new domain level on needed basis? So we would
> > have mapping like
> >
> > Domain level 0 --> FreeIPA 4.1 or older
> > Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology
> > plugin user life cycle
> > Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client
> > Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts
> >
> > ? Would it be more transparent to simply use versions as AD does
> > [1] and always define which features require it? I.e.:
> >
> > Domain level "4.2"
> > Domain level "4.3" --> thin API client
> > Domain level "4.4" --> no changes
> > Domain level "5.0" --> IPA-IPA trusts
> >
> >
> > 2) Backporting features
> > Long standing problem with API version was if for example
> > RHEL/CentOS 6.6 does not rebase, but only backports selected
> > patches/features from higher versions. Should it bump the
> > API/supported Domain Level?
> >
> > Or should it only bump Domain Level if and only if it backports
> > *all* features for the respective domain level?
> which function would detect if "all" features are backported, and
> which function would bump the server level ?

A function implemented by the framework.

> maybe Simo's original proposal could be useful: each feature
> registers its feature level in the server entry, eg "topology/1.0",
> so all baclported features would be visible

we can retain the publishing of the individual features, but we
probably want to use only the coarse grained domain level range
indicator to make a decision.

Which means that if you lie because you backport some features and
raise the level, but you do not backport them all, then the admin would
be able to flip the switch to raise the level and then he may
experience issues as the domain is not fully functional ...

Simo.

> >
> > 3) Storing server and global domain level in LDAP
> > I added [2].
> >
> >
> > [1]
> > http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx
> > [2]
> > http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels
> >
> > _______________________________________________
> > Freeipa-devel mailing list
> > Freeipa-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-devel
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel



-- 
Simo Sorce * Red Hat, Inc * New York