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

Wed Apr 6 08:57:42 UTC 2016

On 6.4.2016 10:50, Jan Cholasta wrote:
> 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.

I originally wanted to have location-add-member command so (external) DNS
servers and IPA servers can be assigned to a location using the same command:
location-add-member 	LOCATION_NAME --ipa-server=<FQDN>
location-add-member 	LOCATION_NAME --advertising-server=<server/view ID>

Should I split this between
server-mod <FQDN> --location=<NAME> [--location-weight=0..65535]
and
dnsserver-mod <server/view ID> --type=external --advertise-location=...

I do not like splitting server-to-location assignment management between two
commands very much. Current proposal in design page was inspired by
group-add-member command which has --users and --groups options which seemed
philosophically similar to me.

Anyway, I'm open to suggestions how to handle this.

-- 
Petr^2 Spacek