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

[Petr Spacek]

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.

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.