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. -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- Petr^2 Spacek -- 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
