[Freeipa-devel] New/Updated FreeIPA design pages

[Simo Sorce]

On Wed, 17 Dec 2014 12:59:56 +0100
Martin Kosek <mkosek at redhat.com> 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.

Ah you mean you broke and moved down one notch all the headings that I
changed one level up because the default ones are ugly ? :-)

Why do you start at == level instead of = ?
Starting at == makes === almost disappear within the text and sections
do not stand up anymore ...

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

It is totally on a need to change 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

NO.
We change Domain Level only when there is a well defined *need*.

If we change something that absolutely requires all of the servers to
have it/update it then we have a candidate reason for a level change.
Otherwise not.

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

Certainly we'll need to document what Domain level a feature needs to
be activated, it will be necessary because said feature will have to
deactivate itself both in the CLI and UI if the domain level is not
high enough, and appropriate error messages need to be returned.

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

If you create a frankenstein you need to make sure you backport all the
features necessary to interoperate at a specific domain level, or you
do not get to claim support for that level.

> Or should it only bump Domain Level if and only if it backports *all*
> features for the respective domain level?

Exactly, you have to be consistent.

> 3) Storing server and global domain level in LDAP
> I added [2].

Thanks, although I think we'll need to store the domain level in it's
own object. The reason is that plugins may end up listening in to see
if it change and we do not want to have all of them parse every change
that goes into cn=ipaConfig all the time.

So I will change the container name.

Simo.

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



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