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

[Petr Spacek]

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

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.

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.


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

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.


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

-- 
Petr^2 Spacek