[Freeipa-devel] New/Updated FreeIPA design pages

[Martin Kosek]

On 12/17/2014 03:52 PM, Simo Sorce wrote:
> 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 ? :-)

No? :-) In meadiawiki, the highest headings you are supposed to use is "==" as
"=" generates <h1> header and there should be just one <h1> on the page - and
that is the page name.

> Why do you start at == level instead of = ?

See the note in
http://www.mediawiki.org/wiki/Help:Formatting#Level_2

This is the reason why I changed levels in the Feature template - to drive the
good mediawiki practices.

> Starting at == makes === almost disappear within the text and sections
> do not stand up anymore ...

Then the problem is not in levels, but in the CSS we use - this is something we
can fix.

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

I agree both on this comment and comment above. So you would like to push for
numeric levels which we would then map in documentation with FreeIPA versions,
right?

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

Ok, makes sense.

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