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