So this approach sounds good to me, but there are a few things that I want to know before I dive into this thing simply because I don't have enough time here this summer to be able to address all these issues:
Would this still work for the current GUI or are there going to be some major changes necessary to continue the current method of running things? Would we need to keep 2 versions of things for a while to get things running? Also, how would the database values get seeded in the database? I'm assuming that DongInn is creating the table where these things will go. They could be read in from files so that we would have a setup with a configurator.sql to initialize the values and configurator.xml to show the display formatting. Lastly, and I don't want to sound pressing again, is this something that would happen soon (as in the next couple of weeks) or take a while? I'd be happy to do the XML part of this but if noone else has time to get the database part done, I'm going to be hurting when it comes down to crunch time. Thanks again for your patience, Wesley On Wednesday 14 June 2006 10:19 am, Erich Focht wrote: > 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
