On 18.4.2016 17:44, Petr Spacek wrote: > On 18.4.2016 16:42, Martin Basti wrote: >> >> >> On 18.04.2016 15:22, Petr Spacek wrote: >>> On 6.4.2016 10:57, Petr Spacek wrote: >>>> 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. >>> Honza and me are playing with idea that Server Roles can be re-used for >>> Locations, too. >>> >>> The rough idea is that 'the advertising' server will have a role like 'DNS >>> Location XYZ DNS server' and that the member server will have role like 'IPA >>> master in location XYZ'. >>> >>> (Pick your own names, these are just examples.) >>> >>> Obvious advantage is consistency in the user interface, which is something >>> we >>> really need. >>> >>> The question is how where to put equivalent of --weight option. >>> >>> This would make location-add-member command unnecessary. >>> >> Today I found out that I misunderstood how non-IPA SRV records will work with >> the DNS locations feature. >> >> I expected that other SRV record stored in IPA domain will be copied >> unchanged >> to locations, only for IPA services SRV records will be altered with >> priorities. >> >> However, DNS locations *will not* handle other SRV than IPA ones, what >> effectively means that custom user SRV records will disappear on hosts thats >> belong to a location. > > Yes, thank you for pointing this out explicitly. > > I've tried to capture all I know about this to the design page: > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_2:_DNAME_per_sub-tree.29 > > Copy follows so we can discuss it quickly: > > === Interaction with hand-made records === > Side-effect of DNAME-redirecting <tt>_udp</tt> and <tt>_tcp</tt> subdomains is > that all original names under these subdomains will become occluded/invisible > to clients (see [https://tools.ietf.org/html/rfc6672#section-2.4 RFC 6672 > section 2.4]). > > This effectively means that hand-made records in the IPA DNS domain will > become invisible. E.g. following record will disappear when DNS locations are > configured and enabled on IPA domain <tt>ipa.example</tt>: > > _userservice._udp.ipa.example. SRV record: 0 100 123 > own-server.somewhere.example > > This behavior is in fact necessary for seamless upgrade of replicas which do > not understand the new template LDAP entries in DNS tree. Old replicas will > ignore the template entries and use original sub-tree (and ignore > <tt>_locations</tt> sub-tree). New replicas will understand the entry, > generate DNAME records and thus occlude old names and use only new ones (in > <tt>_locations</tt> sub-tree). > > Note: This would be unnecessary if IPA used standard DNS update protocol > against standard DNS server with non-replicated zones because we would not > need to play DNAME tricks. In that case we could instead update records on > each server separately. With current LDAP schema we cannot do that without > adding non-replicated part of LDAP tree to each DNS server. > * If we added non-replicated sub-tree to each IPA DNS server we would have > another set of problems because hand-made entries would not be replicated > among IPA servers. > > Handling of hand-made records adds some interesting questions: > * How to find hand-made records? > ** Blacklist on name-level or record-data level? What record fields should we > compare? > * How to handle collisions with IPA-generated records? > ** Ignore hand-made records? > ** Add hand-made records? > ** Replace IPA generated ones with hand-made ones? > * What triggers hand-made record synchronization? > ** Should the user or IPA framework call ''ipa dnslocation-fix-records'' after > each hand-made change to DNS records? > ** How is this synchronization supposed to work with DNS update protocol? > Currently we do not have means to trigger an action when a records is changed > in LDAP. > * How it affects interaction with older IPA DNS servers (see above)? > > There are several options: > {{clarify|reason=What to do with hand-made records?}} > * For first version, document that enabling DNS location will hide hand-made > records in IPA domain. > * Add non-replicated sub-trees for IPA records and somehow solve replication > of hand-made records. > ** What is the proper granularity? Create 20 backends so we can filter on > name-level? > * Do 'something' which prevents replication of IPA-generated DNS records among > servers while still using one LDAP suffix. > ** With this in place we can mark IPA-generated records as non-replicable > while still replicating hand-made records as usual. (An object class like > <tt>idnsRecordDoNotReplicate</tt>?) This would mean that we can drop whole > <tt>_locations</tt> sub-tree and each server will hold only its own copy of > DNS records. > * Find, filter and copy hand-made records from main tree into the > <tt>_locations</tt> sub-trees. This means that every hand-made record needs to > be copied and synchronized N-times where N = number of IPA locations. > > > My favorite option for the first version is 'document that enabling DNS > location will hide hand-made records in IPA domain.' > > The feature is disabled by default and needs additional configuration anyway > so simply upgrading should not break anything. > > > I'm eager to hear opinions and answers to questions above.
Yet another option: Replace DNAME with CNAMEs on *each* IPA-managed named. This would mean some changes in https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator In particular idnsTemplateObject would have to somehow replace all other attributes on given entry (as CNAME cannot coexist with anything else) + we would have to somehow solve the problem with servers where template is present but substitution is not configured. I will dream about that over night. Petr^2 Spacek > > Petr^2 Spacek > > >> Example: >> domain: ipa.test >> server: server.ipa.test >> custom SRV record in IPA domain: _userservice._udp SRV record: 0 100 123 >> server.ipa.test. >> >> The record above will not be accessible from clients that connect to server >> with enabled locations. I think that users may have own services on IPA >> server >> with custom SRV records, and I don't consider this behavior as user-friendly >> and blocker for deployment of this feature. >> >> NACK to design from me. We should fix 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
