Minutes of meeting re Discussion paper - 17th September 2014
The Development Meeting of 17th September 2014 discussed the
DICE client LDAP configuration discussion paper.
The decision of the meeting was:
- To accept the proposal to move to a distributed LDAP configuration for all DICE clients, and to
only revert from that decision if some major technical obstacle or blocking issue comes to light.
- To arrange this move at the time of the next DICE OS upgrade (i.e. the expected upgrade to SL7).
- To insist that client-side LDAP caching be implemented, with the clear expectation that this will be
A brief transcript of the main points made at the meeting follows:
Brief opening remarks:
- Project started ~18 months ago.
- Idea was to review the overall client configuration - arguably it's over-complex.
- Eventually became clear that a move to a 'standard' client/server config was one obvious proposal.
- The discussion document sets out risks/benefits of that proposal in a neutral way.
- Idea of this meeting is to decide yes or no on the proposal.
- In favour of the proposal.
- SL7 is the right time to change.
- We need caching => use of
sssd is a risk for us ...
- The transition should be staged in some way. A group of machines (e.g. a lab) at a time?
- We need load-testing in advance to avoid nasty surprises.
- Lab machines can probably be used for that.
- How do we find the max. load our LDAP servers can reasonably take? Needs testing.
- Why? What exact circumstances?
- We (COs) need to be sure that we don't create chicken-and-egg problems that stop us fixing things.
Caching might/might not help with that.
- KDCs and NetInf machines need to be truly standalone - so under the proposal will need to be
- Which servers/services might get confused/broken if LDAP drops out?
- Each server/service needs to be qualified/tested for its behaviour in the absence of LDAP.
- Lab exam machines? Are they going to work for outbound lookups? Will LDAP failover work?
What will the exam machine firewalling look like?
- If AT server room loses power, exams will break. (That's not the case in the current setup.)
- Could provide exam LDAP server machine in the same lab.
- Load-balancing needs testing. Need to avoid a cascading failure where e.g. server A breaks under load;
all clients switch to server B, which then breaks under load; etc.
Meeting_minutes_2014.09.17.html,v 1.12 2014/09/18 13:15:29 idurkacz Exp
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is
copyright The University of Edinburgh