[Freeipa-devel] Locations design v2: LDAP schema & user interface

Thu Mar 31 07:58:28 UTC 2016

On 26.2.2016 15:37, Petr Spacek wrote:
> On 25.2.2016 16:46, Simo Sorce wrote:
>> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote:
>>> On 25.2.2016 15:28, Simo Sorce wrote:
>>>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote:
>>>>> Variant C
>>>>> ---------
>>>>> An alternative is to be lazy and dumb. Maybe it would be enough for
>>>>> the first
>>>>> round ...
>>>>>
>>>>> We would retain
>>>>> [first step - no change from variant A]
>>>>> * create locations
>>>>> * assign 'main' (aka 'primary' aka 'home') servers to locations
>>>>> ++ specify weights for the 'main' servers in given location, i.e.
>>>>> manually
>>>>> input (server, weight) tuples
>>>>>
>>>>> Then, backups would be auto-generated set of all remaining servers
>>>>> from all
>>>>> other locations.
>>>>>
>>>>> Additional storage complexity: 0
>>>>>
>>>>> This covers the scenario "always prefer local servers and use remote
>>>>> only as
>>>>> fallback" easily. It does not cover any other scenario.
>>>>>
>>>>> This might be sufficient for the first run and would allow us to
>>>>> gather some
>>>>> feedback from the field.
>>>>>
>>>>> Now I'm inclined to this variant :-)
>>>>
>>>> To be honest, this is all I always had in mind, for the first step.
>>>>
>>>> To recap:
>>>> - define a location with the list of servers (perhaps location is a
>>>> property of server objects so you can have only one location per server,
>>>> and if you remove the server it is automatically removed from the
>>>> location w/o additional work or referential integrity necessary), if
>>>> weight is not defined (default) then they all have the same weight.
>>>
>>> Agreed.
>>>
>>>
>>>> - Allow to specify backup locations in the location object, priorities
>>>> are calculated automatically and all backup locations have same weight.
>>>
>>> Hmm, weights have to be inherited form the original location in all cases. Did
>>> you mean that all backup locations have the same *priority*?
>>
>> Yes, sorry.
>>
>>> Anyway, explicit configuration of backup locations is introducing API and
>>> schema for variant A and that is what I'm questioning above. It is hard to
>>> make it extensible so we do not have headache in future when somebody decides
>>> that more flexibility is needed OR that link-based approach is better.
>>
>> I think no matter we do we'll need to allow admins to override backup
>> locations, in future if we can calculate them automatically admins will
>> simply not set any backup location explicitly (or set some special value
>> like "autogenerate" and the system will do it for them.
>>
>> Forcing admins to mentally calculate weights to force the system to
>> autogenerate the configuration they want would be a bad experience, I
>> personally would find it very annoying.
>>
>>> In other words, for doing what you propose above we would have to design
>>> complete schema and API for variant A anyway to make sure we do not lock
>>> ourselves, so we are not getting any saving by doing so.
>>
>> A seemed much more complicated to me, as you wanted to define a ful
>> matrix for weights of servers when they are served as backups and all
>> that.
>>
>>>> - Define a *default* location, which is the backup for any other
>>>> location but always with lower priority to any other explicitly defined
>>>> backup locations.
>>>
>>> I would rather *always* use the default location as backup for all other
>>> locations. It does not require any API or schema (as it equals to "all
>>> servers" except "servers in this location" which can be easily calculated on fly).
>>
>> We can start with this, but it works well only in a stellar topology
>> where you have a central location all other location connect to.
>> As soon as you have a super-stellar topology where you have hub location
>> to which regional locations connect to, then this is wasteful.
>>
>>> This can be later on extended in whatever direction we want without any
>>> upgrade/migration problem.
>>>
>>> More importantly, all the schema and API will be common for all other variants
>>> anyway so we can start doing so and see how much time is left when it is done.
>>
>> I am ok with this for the first step.
>> After all location is mostly about the "normal" case where clients want
>> to reach the local servers, the backup part is only an additional
>> feature we can keep simple for now. It's a degraded mode of operation
>> anyway so it is probably ok to have just one default backup location as
>> a starting point.
> 
> Okay, now we are in agreement. I will think about minimal schema and API over
> the weekend.

Well, it took longer than one weekend.

There was couple of changes in the design document:
* ‎Feature Management: CLI proposal
* ‎Feature Management: web UI - idea with topology graph replaced original
complicated table
* Feature Management: described necessary configuration outside of IPA DNS
* Version 1 parts which were moved into separate document:
V4/DNS_Location_Mechanism_with_per_client_override
* ‎Assumptions: removed misleading reference to DHCP, clarified role of DNS views
* Assumptions: removed misleading mention of 'different networks' and added
summary explaining how Location is defined
* Implementation: high-level outline added

Current version:
http://www.freeipa.org/page/V4/DNS_Location_Mechanism

Full diff:
http://www.freeipa.org/index.php?title=V4%2FDNS_Location_Mechanism&diff=12603&oldid=12514

Practical usage is described in section How to test:
http://www.freeipa.org/page/V4/DNS_Location_Mechanism#How_to_Test

I will think about LDAP schema after we agree on CLI.

Petr^2 Spacek

> Petr^2 Spacek
> 
> 
>>>> - Weights for backup location servers are the same as the weight defined
>>>> within the backup location itself, so no additional weights are defined
>>>> for backups.
>>>
>>> Yes, that was somehow implied in the variant A. Sorry for not mentioning it.
>>> Weight is always relative number for servers inside one location.
>>
>> Ok it looked a lot more complex from your description.
>>
>> Simo.
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek
-- 
Petr^2 Spacek