There are all sorts of open cloud standards emerging, overlapping, sometimes contradictory, and at this point developed by the big boys without much community participation. One such standards body with relevant to this particular topic interests that comes to mind is Distributed Management Task Force.
In my opinion, we should focus on individual instance or cluster configuration first, as opposed to trying to solve the global distributed configuration management problem. It will be very easy to dig ourselves in a hole, if we aggressively take an ad hoc path and just throw a bunch of centralized configuration components in there. I will give you the following example. Consider a Drizzle instance deployed in a virtual machine. Suppose this virtual machine is relocated from one private, hybrid, or public cloud to another. How do you reflect in your Drizzle instance configuration all the conditions, sizing options, logging parameters, etc and what interface will you provide to a hypervisor or to a cloud management tool? I apologize for describing this rather awkwardly; the problem space itself is very much undefined and vague; people are still debating cloud and cloud interoperability definitions and concepts. Just an opinion. Regards, Alex Esterkin On Tue, Apr 28, 2009 at 8:38 PM, Francesco Riosa <[email protected]>wrote: > In data Wednesday 29 April 2009 01:29:40, Ronald Bradford ha scritto: > : > Just to throw some more open thoughts into the config discussion. > > > > > Why should a config file be restricted to one server. If we do want to > > move toward a cloud like deployment, being for example to pull one config > > file from a central location to support multiple servers may be seen as > an > > advantage, if it can handle small variants (I use the referenced thread > > example skip-slave-start, not an ideal one) > > > > Is there merit in enabling config files to have the standard > configuration > > and then also server-centric configuration settings by a given name. > > > > That said, can we replace server-id (which is old replication) with a > > better server-identifier Something obviously unique within your topology, > > but a description, not a number. > > > kioslaves from kde are a good example of how it should be managed central > configuration files: > the server should see files and only files, filtered by an abstraction > layer that can access everithing from local file to plan9 resources, also > trasformation from say xml to winini should be done the same way. > > > Then remember to give each config file a strict order and priority, MySQL > messed up with that a pair of times and was a sad time. > > > > > _______________________________________________ > Mailing list: > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > Post to : [email protected] > Unsubscribe : > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
