On 6.4.2016 10:50, Jan Cholasta wrote: > On 4.4.2016 13:51, Petr Spacek wrote: >> 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. > > If server can be only in one location, why bother with > location-{add,mod,remove}-member and not use server-mod: > > server-mod <FQDN> --location=<NAME> [--location-weight=0..65535] > > ? This is the natural way to model one-to-many relationships in the API, > consistent with existing stuff.
I originally wanted to have location-add-member command so (external) DNS servers and IPA servers can be assigned to a location using the same command: location-add-member LOCATION_NAME --ipa-server=<FQDN> location-add-member LOCATION_NAME --advertising-server=<server/view ID> Should I split this between server-mod <FQDN> --location=<NAME> [--location-weight=0..65535] and dnsserver-mod <server/view ID> --type=external --advertise-location=... I do not like splitting server-to-location assignment management between two commands very much. Current proposal in design page was inspired by group-add-member command which has --users and --groups options which seemed philosophically similar to me. Anyway, I'm open to suggestions how to handle this. -- 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
