On Tue, Jul 09, 2013 at 02:12:45PM +0200, Guido Trotter wrote: > On Mon, Jul 8, 2013 at 9:57 PM, Iustin Pop <[email protected]> wrote: > > Hi all! > > > > Last year on a vacation I scribbled down this idea in my phone's note > > taking app, and promptly forgot completely about it. Last week on > > another vacation I was bored and played with the phone and found it > > again, so here it is. As I haven't kept track with developments this > > year it could be completely obsolete, in which case sorry for the noise. > > Or maybe I already mentioned (and forgot that I did so). Anyway, here it > > is! > > > > This doesn't solve any big problem, but it might improve the interaction > > with the cluster for users of instances (and not for cluster admins). > > The problem is basically that it's not possible to query the cluster for > > VM-related data, such as: > > > > - on which node does this VM live? > > - what is the console information for this VM? > > - what are the master candidates? (this is more to cluster admins > > though) > > > > All these are possible via either Ganeti-specific protocols (confd) or > > open protocols (rapi), but they require sharing of passwords (in case of > > confd) or user/pw configuration (rapi). > > > > My idea is that, if the security policy allows this kind of information > > to be openly available, to expose this via a DNS server. The master node > > would be (either via confd or a new daemon) a NS (authoritative name > > server) for the cluster name itself, and would provide records such as > > follows (values in < > are variables): > > > > - primary.<vm>.instances.<cluster>: a CNAME to the primary node FQDN > > - secondary.<vm>.instance.<cluster>: a CNAME to the secondary (if only > > one) (per RFC 2181, section 10.1, there can't be multiple CNAMEs) > > - pip.primary.<vm>.instances.<cluster>: an A or AAAA to the primary ip > > of the primary; similar sip.primary, pip.secondary, sip.secondary > > - console.<vm>.instances.<cluster>: TXT record denoting console > > information > > - master-candidates.<cluster>: A/AAAA records to the primary IPs of > > master candidates > > - no wildcard queries would be supported, as to not leak too much > > information > > - all TTLs would be very small (~1 minute or so) > > > > The way this would be used is as follows (non-exhaustive examples): > > > > - as the console port is static once an instance is created, one could > > always connect to the console of the instance by VNC'ing into > > primary.<vm>.instances.<cluster> at the fixed port, without having to > > query the cluster for information > > - in order to monitor node performance/status for an instance, e.g. > > monitoring for VM could be silenced if primary.<vm>.… is unreachable, > > or connect to the ganeti-mond port on the same address for performance > > stats > > - for confd clients, instead of having to preseed the list of MCs, it > > would be enough to point the client to master-candidates.<cluster> > > - potentially other nice things (related to node groups? related to DRBD > > pairs maybe?) could be implemented, as this would be a live database > > and thus could serve instantaneous information, as opposed to delayed > > gathering via RAPI > > > > All this works as the master IP should be always reachable (if the > > cluster is healthy), so only this IP is needed in the recursive resolver > > as a delegation. > > > > So, not sure if this is really useful or not, but I thought to mention > > it. What do you think? > > Before changing confd clients I'd like the master self-healing to > work, and this protocol to be more resilient to master failure. Right > now we rely on external people/tools to fix the cluster, and we built > confd to have information available even when the master node is down: > relying on the master for confd clients would be a bit counter > productive.
Ack. What do you think about the VM-related stuff? > That said it's quite a good idea, and I'd love to see patches that > start implementing it, perhaps even as part of confd. Unfortunately we > don't have people who could work on it right now, but perhaps in the > future it would be possible, and it's good to keep it into account. Ack. It's too bad it stayed hidden in my phone for a year :( > Would you like to file a bug for it? (or I can, in case) Sure, will do! thanks, iustin
