[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon




On Fri, 21 Jan 2005, Andrew Warfield wrote:

> > 1) Change xcs to use unix domain sockets.
> 
> The original thought behind using ip sockets behind xcs was in
> planning for cluster management.  Obviously there are other ways to
> map this in, I'm not terribly fussy on this point.

how will this work if we run a 256-node xen cluster (which we will be
doing here for testing)? Wouldn't we want the IP socket?

> I would much rather see xcs only handle control messages, and see the
> console stuff broken off onto a seperate split driver.  ptys/ip
> sockets/whatever can then be mapped in at the backend independent of how
> the control plane works.  I just chatted with keir about this, and he
> agrees that pulling console messages off onto their own rings and
> providing a separate backend for them would be a good thing.

make sense to me, again I sure hope we can keep things so that we can put 
lightweight xend's on bproc slave nodes (i.e. in the end we'd like to be 
python-free) and control from a single front-end node via tcp.

I think python-free is beyond the scope of this discussion, just thought 
I'd mention it -- it's a real problem to run python tools in bproc 
clusters.

ron


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.