ldap.conf on the cloudcontrol systems uses ldap-labs.eqiad.wikimedia.org as the LDAP server, which is a cname for seaborgium. If the outage is very short, this is no big deal, but if it could be quite long based on when Row D is changed, we may need to swap to serpens or something.
Besides that, check for LDAP issues postmortem.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | cmooney | T291627 Packet Drops on Eqiad ASW -> CR uplinks | |||
| Resolved | cmooney | T284592 Adjust egress buffer allocations on ToR switches | |||
| Resolved | None | T286065 Switch buffer re-partition - Eqiad Row C | |||
| Resolved | None | T286613 check for ldap issues regarding seaborgium network blip for row C configuration change |
The network interruption was practically unnoticeable, so I think we can just close this without doing anything?
Side question, what is the difference on ldap-labs. and ldap-ro. (used by VMs itself)? Wikitech seems out of date and doesn't properly explain the difference between ldap-labs and the replicas.
ldap-labs is a CNAME for seaborgium while ldap-ro is a read-only proxy (and I believe load balancer) for seaborgium and serpens.
Generally ldap-labs is connected to by hardware things with ldap-ro on the VMs since they don't require the ability to write.
For more context from back when that was put in place, we were troubleshooting ldap issues which came around to T217280: LDAP server running out of memory frequently and disrupting Cloud VPS clients