Hi Erich, Yes, I like the idea to save the configurator data in the mysql database (ODA). I think it won't be very difficult to implement it. But I would like to see how .configurator.values are created and as you suggested I would like to save the values directly to the database rather than store them by parsing an XML file(.configurator.values) containing the configurator data. I believe that it is also possible to parse the XML file and then save the output to the database, though. Since I have not successfully set up OSCAR via trunk, I have not seen that the XML file .configurator.values is created for each package and how it is crated. Probably I'd better try to install trunk on RHEL 4, which we believe is working fine with trunk tomorrow. Have anyone setup oscar (trunk) successfully on FC3 X86?
Regards, -- DongInn Erich Focht wrote: >Hi DongInn, > >do you think you could give this a try? I think the advantages of having >the configurator data in the mysql database are obvious, the implementation I >am proposing in the attached email could maybe be improved. So if anybody has >comments or can help with the implementation, please speak up. > >The short story: >when an OSCAR package is "configured", the values coming out of the >configurator form are stored in the package directory in an XML file called >.configurator.values. This is bad for several reasons: people might overlook >them when doing a backup of the OSCAR configuration, the values are not >accessible from client nodes, the XML files need XML parsers to be interpreted >on other nodes (XML parsers are usually not installed on the client nodes). > >My proposal is to replace the hidden .configurator.values files by a table in >the OSCAR mysql database which consists of name-value pairs. A record should >consist of following fields: > opkg_id : which OSCAR package does this record belong to > name : the configuration variable name > value : the configuration variable value > selector : a selector allowing to do selective configuration for > example for particular images or node groups (as required > by the ganglia package). >The table could simply be called "configurator" or "configuration". > >Thanks in advance for comments and improvement ideas! > >Regards, >Erich > > >On Tuesday 21 March 2006 00:29, Erich Focht wrote: > > >>On Monday 20 March 2006 22:59, DongInn Kim wrote: >> >> >>>Erich Focht wrote: >>> >>> >>>>* move configuration data to database: the configurator data living in some >>>> files is actually something that should have been cleaned up long ago. Can >>>> we simply read and write the configurator output directly to the database >>>> instead of keeping those secret files around? This way they would be >>>> accessible from client nodes, too (and enable us to make them much more >>>> useful) and the packages directories would be more or less read-only. >>>> Again: DongInn: is this doable? Any idea how this config data could be >>>> stored easilly? Should we parse it and store name-value pairs? Or store the >>>> XML file? Consider also storing per image or node-group configuration data >>>> (i.e. multiple configuration records per opkg). >>>> >>>> >>>> >>>> >>>I have no idea what the configuration data look like but if we can get >>>the name-value pairs of the output or >>>it can return the output as XML file, we can parse it to insert the data >>>into the database. >>>It should not be too difficult. >>>But I think it would be easier to parse the name-value pairs of the >>>output than the XML format. >>> >>> >>name-value pairs might be much easier to parse on client nodes, too. >>Currently we parse the form data and store something called >>.configurator.values. One of the complex ones is the one from ganglia: >><config> >> <cluster__name>Benchmark Cluster</cluster__name> >> <cluster__owner>NEC</cluster__owner> >> <gmond_per_image>YES</gmond_per_image> >> <gridname>Bench</gridname> >> <udp_recv_channel__mcast_if>eth0</udp_recv_channel__mcast_if> >> <udp_recv_channel__port>8649</udp_recv_channel__port> >> <udp_send_channel__mcast_if>eth0</udp_send_channel__mcast_if> >> <udp_send_channel__port>8649</udp_send_channel__port> >></config> >> >>So what if we store one a record for each name-value pair, the table could >>have the fields: opkg_id, name, value, selector. >>The "selector" field could differentiate between opkg-global config values (if >>undefined) and (right now) per-image values. Example: >> selector = "" : opkg global values (for master) >> selector = "image:oscarimage" : special values for image oscarimage >> selector = "group:oscar_clients" : particular node group >> >>Getting all config values for a particular package is simply a select >>statement collecting all name-value pairs attributed to that package with a >>particular (or empty) selector. XML parsing is then needed only once, when the >>stuff entered into the form is put into the database. >> >> >> >> >>>>* backup/restore OSCAR config: with the previous two points this would >>>>become >>>> a much simpler task and would basically require the backup of the ODA and >>>> the images. It would make it easier also to upgrade OSCAR or recreate a >>>> particular setup. >>>> >>>> >>>> >>>> >>>> >>>I have thought about this feature before. I would like to add this >>>feature to the OSCAR5 todo list too. >>>Please assign backup/restore of the ODA to me if we agree to do this. >>> >>> >>Cool! >> >>Regards, >>Erich >> ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
