On 23.2.2016 15:19, Simo Sorce wrote: > On Tue, 2016-02-23 at 12:43 +0100, Petr Spacek wrote: >> On 23.2.2016 11:00, Jan Cholasta wrote: >>> Hi, >>> >>> On 19.2.2016 16:31, Simo Sorce wrote: >>>> On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote: >>>>> On 4.2.2016 18:21, Petr Spacek wrote: >>>>>> On 3.2.2016 18:41, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I've updated the design page >>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>> >>>>>>> Namely it now contains 'Version 2'. >>>>>> >>>>>> Okay, here is the idea how we can make it flexible: >>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation >>>>> >>>>> Hello, >>>>> >>>>> I'm thinking about LDAP schema for DNS locations. >>>>> >>>>> Purpose >>>>> ======= >>>>> * Allow admins to define any number of locations. >>>>> * 1 DNS server advertises at most 1 location. >>>>> * 1 location generally contains set of services with different priorities >>>>> and >>>>> weights (in DNS SRV terms). >>>>> * Express server & service priority for each defined location in a way >>>>> which >>>>> is granular and flexible and ad the same time easy to manage. >>>>> >>>>> >>>>> Proposal >>>>> ======== >>>>> a) Container for locations >>>>> -------------------------- >>>>> cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>>>> >>>>> >>>>> b) 1 location >>>>> ------------- >>>>> Attributes: >>>>> 2.16.840.1.113730.3.8.5.32 idnsLocationMember >>>>> Server/service assigned to a DNS Location. Usually used to define 'main' >>>>> servers for that location. Should it point to service DNs to be sure we >>>>> have >>>>> smooth upgrade to containers? >>> >>> Services always live on a host (call it server or not), so IMO it makes >>> sense >>> to point to servers. >> >> Fine with me. We just need something which will be able to accommodate >> containerization without upgrade headache. >> >> Do I undestand correctly that 1 container is going to have 1 host object with >> one service object inside it? >> >> Like: >> cn=container >> - cn=DNS, cn=container >> ? > > Do we think we will ever need to define different locations on a per > service basis ?
No, I hope that we will avoid this. I suppose that when we containerize IPA things will get 'more interesting', but hopefully not in direction 'location per service'. If we have the possibility to have 1 DNS container and 2 CA containers attached to 1 LDAP container things will be complicated ... I would expect that we will need some additional logic to ensure that one location advertises all the services (so e.g. LDAP is not missing in that particular location). I would not go beyond that. > We based or hypothesis on the fact we only have one location and at most > different weights per services ? > Is there anything in here that will make it hard for us should we change > our mind in future ? (I think the single _tcp DNAME may be an > architectural issue anyway, but that could be resolved perhaps by moving > the location DNAME on a per service basis in future should we need it ? Yes, that is a possible approach but I hope it will not be necessary. Hopefully the logic for assigning containers/server to locations can be made smart enough to guarantee that we do not need more layers of CNAME/DNAME hacks or so. The DNAME trick should be seen as a cheap way to emulate views without actually using views. If you want more fancy things, go and use views on full-featured DNS server ... >>>>> 2.16.840.1.113730.3.8.5.33 idnsBackupLocation >>>>> Pointer to another location. Sucks in all servers from that location as >>>>> one >>>>> group with the same priority. Easy to use with _default location where all >>>>> 'other' servers are used as backup. >>>>> >>>>> These two attributes use sub-type priority<number> and >>>>> relativeweight<number>. >>>>> This is the only way I could express all the information without need for >>>>> separate objects. >>> >>> I don't see the benefit here. What is wrong with separate objects? Why is it >>> necessary to reinvent the wheel and abuse attribute sub-types for this, >>> losing >>> schema integrity checks provided by DS and making the implementation more >>> complex along the way? >> >> AFAIK Simo did not like separate objects because we could not use referential >> integrity plugin to prune references to removed servers. >> >> This can surely be done in framework, I do not insist on subtypes. >> >> >> Talk is cheap, show me your schema :-) > > I had a preference, but I m ok also with multiplle objects one per > server/service if we think this will make things easier to handle. > > Given we are going to need a Server object in DNS anyway (so that things > are self contained for non IPA use cases) then I think the referential > integrity thing goes out the window. Back to the drawing board! :-) > [...] > >>>>> Attributes: >>>>> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation >>>>> Pointer to a idnsLocation object. On DNS service object / external server. >>>>> Single-valued. >>> >>> IMO this should be attribute of server rather than service, >>> given that >>> idnsLocationMember points to servers rather than services. >> >> The main reason is why idnsAdvertisedLocation is tied to DNS service is that >> a >> IPA server without a DNS server cannot advertise anything, so the attribute >> does not make sense on all server objects. >> >> Also, the attribute can be (in future) used on external DNS server. The >> external server is not going to be an IPA server, it will be just >> representation of a DNS endpoint. Likely this external DNS server is not >> going >> to reside in cn=masters at all. It might be in cn=dns so somewhere else. > > If possible I'd tie it to the DNS server's DNS object, or a new object > in the DNS hierarchy. > We may want to have locations for servers that are not IPA Server at > all, like the preferred local XMPP server or other things like that. Petr Vobornik mentioned an important question: Should we care about non-IPA services? IMHO it is a valid point. It complicates things a lot as soon as we start introducing 'locations per service'. It is certainly doable but I would like to avoid it. It seems easy enough to support custom services as long as there is only one set of locations (which match IPA locations). It would be a management nightmare to support N parallel locations for distinct sets of services. As far as I can tell, AD can live with only 1 set of locations and that sounds reasonable thing to support in the IPA management interface to me. >> So it seemed to me that it would be good to tie this to 'DNS endpoint' object >> instead of IPA server object. >> >> Anyway, I do not insist on this. It can be on the IPA server if you want, but >> we will need additional checks to make sure that DNS service is always >> present >> on the IPA server in question. Negotiate with Simo :-) >> >> An alternative is to add idnsAdvertisedLocation to location object but then >> we >> need extra search to find out which location is advertised by particular >> server (or use yet another instance of memberOf plugin ...). > > We can put this on the location object, but what object would it point > to ? To the DNS server object, so we know where to send generated records and configuration. > The search is relatively easy if we can use the dereference control, no > need for memberof tricks. > >>>> I am thinking about it, on the surface it all looks quite reasonable. >>>> I think the UI is alittle messy, I wonder if we want to expose lower >>>> level concepts as priority and groups, or if we just want to allow users >>>> to set an order in the UI and then let the framework come up with weight >>>> an priority numbers to assign. >>> >>> +1, it seems to me that locations are a rather standalone concept, so why >>> tie >>> them to DNS like this? >> >> I do not see the tie to DNS in the user interface except the terminology I >> used. >> >> Priority (grouping) and weights (load distribution inside one group) are not >> DNS things, these are fail-over and load balancing concepts. >> >> Look at manual for load balancers from F5 [1]: >> * term 'pool' = same thing as our 'priority groups', i.e. group of services >> with equal priority >> * term 'weight' (sometimes also 'ratio weight') = the exactly same sense >> >> I'm certainly open to terminological changes to make it more accessible, it >> would make sense to use the same terms as load balancer vendors. > > Ack, my concern was not with terminology though, but with exposing users > to the concept themselves, I was thinking we might want a simpler > interface for the UI with limited ability to just define pools by > default. However if we think that both pools and weights will be > necessary for common administration I am ok exposing them. > > >> [1] >> https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_pools.html >> >> >>>> Maybe have a way in the CLI to override the decisions of the framework >>>> and set explicit weights ? >> >> I was thinking about this as well. >> >> Speaking of weights, we can easily default to the same weight for all servers >> by default so admins do not need to bother unless they want/need. > > I was thinking that an UI that exposes ordering (by moving entries > around up and down a list) would make things simpler, the framework > would calculate a weight based on the order. > > However I am aware that a simple list cannot express concepts like 1 > server being equal weight as 2 others, so perhaps we shouldn't go down > this route ? Ordering can be used to express priority. Weight can default to the same values for all servers and can be tweaked per-server because there is no way how to find out how beefy (or loaded) the server should be, that is purely administrative decision. Weight can be expressed as % (relative to one group) so it should be easy to understand. >> Priority groups are harder because they express metric based on: >> * communication costs, >> * fail-over requirements, >> * other political requirements in given deployment. >> These are hard things to see from layer 7. >> >> Theoretically we can provide ipa-advise plugin to generate some initial set >> of >> groups but this is going to be complicated and error prone. >> >> E.g. we can use ICMP ping or LDAP base DN search timings and use some >> clustering algorithm to create priority groups using measured values. >> This could work if we use some smart-enough clustering algorithm (= AI >> library). And of course, we would have to do measurements from at least one >> server in each location to properly define groups for each location ... >> >> It is not that easy as it might seem and I do not see an easy solution. >> >> >> Maybe we should take evolutional approach: >> Implement this 'expert' UI which exposes groups & weights to the user first. >> (It will be necessary for special cases anyway.) When this is done, we can >> play with it, do some usability testing (we can ask RH IT to see if it makes >> sense to them, for example.) >> >> Later we can extend this with a 'simple' variant of UI based on feedback or >> add the generator). This does not even need to happen in the same release. >> >> IMHO it would be better to start with something and refine it later on >> because >> right now we are just hand-waving and have no idea what users actually do and >> want. > > As long as we establish a proper CLI I am ok with implementing a very > bare bone UI first and improving it only later. > > Btw we probably want to have this information reported by the topology > view, and used to automatically group servers there based on location, > so I CCed Petr to see if there is anything that would make that job > easier/harder. We were kicking ideas around the drawing board in the Brno office. Finally, after many iterations we arrived to this: Wouldn't it be easier to implement concept of sites and links between sites at the same time? (In the AD spirit.) If we knew the locations/sites and links between them, we could compute priority groups etc. algorithmicaly. Then only remaining thing is weight, which can have default and admin do not have to touch it if not necessary. Even better, this can be later used to generate optimal replication topology (possibly as recommendation). As far as I can see in AD 2012 they do this: * define which servers belong to which sites * define site-to-site communication costs If we had this information we could take suitable graph algorithm generate priority groups without admin's intervention. It seems that it would make the user interface easier to use and potentially even simplify the schema. IMHO it is worth exploring because especially with large topologies manual priority (and later replication) management will become burden. What do you think? -- 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
