On Wednesday 14 June 2006 14:33, Wesley Bland wrote: > Continuing the discussion about Configurator: > > What is your idea about moving the configurator stuff to the ODA? I'm not > opposed to the idea as it would probably make things simpler for me, but the > problem that I run into is that I only have 6 1/2 weeks left here and if we > decide to go with the database option, I'm afraid that it wouldn't be ready > to go in time with all the current effort being poured into 5.0. The other > problem that you run in to when moving stuff into the database is that while > it's easy to look up and modify the keys and their values, you will also need > some fields to keep track of a few other things related to that key such as a > description and possibly a type (if you wanted to use things like radio > buttons or check boxes) to know how to group things.
All the applications need for configuration are the variables, maybe the context. So the minimalistic approach is: Table : Configurator Fields : opkg, name, value, context "context" is reserved for per-image configuration, for example. So: opkg=ganglia name=gmond_port value=8649 context="global" (or "" empty string) would be a valid entry for one variable of the global ganglia configuration. context="image:myimage" would specify that the configuration variable is valid only for the image myimage, but not globally. This allows us to access the configuration variables easilly, even from the client nodes or from chroot inside an image. Reconfiguring something will be easier and backing up the configuration will also be much easier (as all relevant info lives in the OSCAR database). The method how we get these variables into the database, how they are displayed, in which form (html? anything else?) they are collected, should be unrelated to the way the variables are stored. Actually the variable collection method should be decoupled from its storage. So why not describe the collection method in an html or xml file? With the current configurator.html files this would already work fine (I know this is a problem for CLI) and be a pretty limited effort. If you can move one step up and describe the input forms in XML, why not? The XML file can state that a variable will be collected by clicking a radio-button or selecting something from a pop-up menu, in the end the variable will have exactly one value and this is what we'd like to find in ODA. So I'm an adept of what you call hybrid method. It is because an XML file can later be easilly integrated into a web gui, but no matter how fancy you make the GUI, it will not change the way how the variables are stored in the database. Best regards, Erich _______________________________________________ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
