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

Wed Apr 6 08:50:12 UTC 2016

On 4.4.2016 13:51, Petr Spacek wrote:
> On 4.4.2016 13:39, Martin Basti wrote:
>>
>>
>> On 31.03.2016 09:58, Petr Spacek wrote:
>>> 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.
>>
>> Design review:
>>
>> 1)
>> You missed warning when there is no backup DNS server in location
>
> Thanks, added.
>
>
>> 2)
>> "Number of IPA DNS servers <= number of configured IPA locations" I dont
>> understand
>>
>> You need at least one DNS server per location, thus  DNS servers >= locations
>
> Good catch, fixed.
>
>
>> 3)
>> Design (Version 1: DNAME per client)  Link to design doesn't work for me
>
> Oh, my wiki-fu was weak. Fixed.
>
>
>> CLI looks good to me. Maybe we should explicitly write in design that
>> priorities of the SRV records will be set statically (What values? 0 - servers
>> in location, 100 - backup?)
>
> I've added a note about static priorities. Particular values are just an
> implementation detail so I would not clutter feature management section with that.

If server can be only in one location, why bother with 
location-{add,mod,remove}-member and not use server-mod:

     server-mod <FQDN> --location=<NAME> [--location-weight=0..65535]

? This is the natural way to model one-to-many relationships in the API, 
consistent with existing stuff.

-- 
Jan Cholasta