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. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
