[Freeipa-devel] Locations design v2: LDAP schema & user interface

Tue Feb 23 14:19:18 UTC 2016

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

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

[...]

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

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

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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York