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
