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


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

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

[2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels

Freeipa-devel mailing list

Reply via email to