On Sun, 2009-01-25 at 18:11 +0100, Alberto Caso wrote: > El sáb, 24-01-2009 a las 11:37 +0100, Alvaro Lopez Ortega escribió: > > By the way, the delegation of configuration pieces is a topic > > currently being discussed. > > Providing some kind of web services from cherokee-admin (or a new > specialized daemon) to give access to Cherokee configuration would > probably make it easy to integrate Cherokee into a hosting control panel > and could also be the foundations of a distributed configuration system > (ie. to manage a cluster of Cherokee instances from a central point). >
We are currently looking at that with GNUPanel, we're going to be using a slightly modified (stripped down) version of Cherokee to serve the control panel itself .. making a production version available to users is something we want to investigate. For shared hosting its really not up to the customer, but for VPS/VDS services, we hope to allow the customer to select what web server they wish to use. The problem is going to be locking , for instance if two people are logged in and want to modify the configuration at the same time. For this reason, we're likely going to store the entire configuration in our database and push writes to slave servers via our own methods, locking is handled on our end. In our scenario, five or six configuration modifications would need to be seen as one atomic update to watchers, so some sort of transaction system has to be in play that obtains an exclusive lock at the end. If facilities emerged to let Cherokee do this on its own, we probably would not use them for that reason alone. This is especially true when a human user races a billing/automation API user in a shared hosting setting. Such a feature would be useful in Cherokee, but I don't think really useful for hosting automation. Cheers, --Tim _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
