Re: [Oscar-devel] Configurator values - ODA
Title: Re: [Oscar-devel] Configurator values - ODA
With the recent fixes by
Erich, this is now confirmed to be working.
Cheers,
Bernard
From: [EMAIL PROTECTED]
on behalf of Bernard LiSent: Sat 01/07/2006 18:25To:
[EMAIL PROTECTED]; oscar-devel@lists.sourceforge.netSubject: Re:
[Oscar-devel] Configurator values - ODA
Hi Erich:
I just tried a fresh install
with FC5 x86, and the issue is still present. Here's the content of
/etc/gmetad.conf:gridname "gridname"data_source
"cluster__name" fc5-x86.ocg.org
The relevant bits from
/etc/gmond.conf looks like:cluster { name =
"unspecified" owner = "unspecified" latlong =
"unspecified" url = ""}
I also ran the steps you
outlined manually, nothing changed. This was tested with
r5092.
And I think it's a good idea
to put the default values into ODA - this way, things are consistent no matter
whether you configure the package, or not.
Thanks,
Bernard
From: Erich Focht
[mailto:[EMAIL PROTECTED]Sent: Sat 01/07/2006 13:32To:
oscar-devel@lists.sourceforge.netCc: Bernard LiSubject:
Re: [Oscar-devel] Configurator values - ODA
Hi Bernard,I fixed one thing and then tried
callingcd $OSCAR_HOME/packages/gangliaenv
OSCAR_PACKAGE_HOME=`pwd` scripts/edit_ganglia_conf --gmetad
--verbosewhile the ODA table Packages_conf was empty. /etc/gmetad.conf
looked goodafterwards. But I didn't try a clean fresh install.We can
of course add a step for presetting the configurator values in thedatabase
to reasonable values (read out of the configurator.html
files).Regards,ErichOn Friday 30 June 2006 07:33,
Bernard Li wrote: Hi Erich: This seems to work
okay if you actually go through the "Configure Selected OSCAR Packages..." step,
however, if you bypass it (using default values), then it did not work. I
was testing Ganglia package... the resulting /etc/gmetad.conf looks
like: gridname "gridname" data_source
"cluster__name" fc4-x86.oscar.gsc Looks like the
key and the value got switched around? BTW, would it be
possible to use sed or regex to update the configuration instead of throwing the
modified bits at the bottom of the configuration file? To a new user who
doesn't know anything about Ganglia, the configuration option is now out of
context with the nice comments which describe what the options are
for... Thanks,
Bernard
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Oscar-devel mailing list
Oscar-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator values - ODA
Hi Bernard, I fixed one thing and then tried calling cd $OSCAR_HOME/packages/ganglia env OSCAR_PACKAGE_HOME=`pwd` scripts/edit_ganglia_conf --gmetad --verbose while the ODA table Packages_conf was empty. /etc/gmetad.conf looked good afterwards. But I didn't try a clean fresh install. We can of course add a step for presetting the configurator values in the database to reasonable values (read out of the configurator.html files). Regards, Erich On Friday 30 June 2006 07:33, Bernard Li wrote: Hi Erich: This seems to work okay if you actually go through the Configure Selected OSCAR Packages... step, however, if you bypass it (using default values), then it did not work. I was testing Ganglia package... the resulting /etc/gmetad.conf looks like: gridname gridname data_source cluster__name fc4-x86.oscar.gsc Looks like the key and the value got switched around? BTW, would it be possible to use sed or regex to update the configuration instead of throwing the modified bits at the bottom of the configuration file? To a new user who doesn't know anything about Ganglia, the configuration option is now out of context with the nice comments which describe what the options are for... Thanks, Bernard Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator values - ODA
Title: Re: [Oscar-devel] Configurator values - ODA
Hi Erich:
I just tried a fresh install
with FC5 x86, and the issue is still present. Here's the content of
/etc/gmetad.conf:gridname "gridname"data_source
"cluster__name" fc5-x86.ocg.org
The relevant bits from
/etc/gmond.conf looks like:cluster { name =
"unspecified" owner = "unspecified" latlong =
"unspecified" url = ""}
I also ran the steps you
outlined manually, nothing changed. This was tested with
r5092.
And I think it's a good idea
to put the default values into ODA - this way, things are consistent no matter
whether you configure the package, or not.
Thanks,
Bernard
From: Erich Focht
[mailto:[EMAIL PROTECTED]Sent: Sat 01/07/2006 13:32To:
oscar-devel@lists.sourceforge.netCc: Bernard LiSubject:
Re: [Oscar-devel] Configurator values - ODA
Hi Bernard,I fixed one thing and then tried
callingcd $OSCAR_HOME/packages/gangliaenv
OSCAR_PACKAGE_HOME=`pwd` scripts/edit_ganglia_conf --gmetad
--verbosewhile the ODA table Packages_conf was empty. /etc/gmetad.conf
looked goodafterwards. But I didn't try a clean fresh install.We can
of course add a step for presetting the configurator values in thedatabase
to reasonable values (read out of the configurator.html
files).Regards,ErichOn Friday 30 June 2006 07:33,
Bernard Li wrote: Hi Erich: This seems to work
okay if you actually go through the "Configure Selected OSCAR Packages..." step,
however, if you bypass it (using default values), then it did not work. I
was testing Ganglia package... the resulting /etc/gmetad.conf looks
like: gridname "gridname" data_source
"cluster__name" fc4-x86.oscar.gsc Looks like the
key and the value got switched around? BTW, would it be
possible to use sed or regex to update the configuration instead of throwing the
modified bits at the bottom of the configuration file? To a new user who
doesn't know anything about Ganglia, the configuration option is now out of
context with the nice comments which describe what the options are
for... Thanks,
Bernard
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Oscar-devel mailing list
Oscar-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oscar-devel
[Oscar-devel] Configurator values - ODA
Hi Erich: This seems to work okay if you actually go through the "Configure Selected OSCAR Packages..." step, however, if you bypass it (using default values), then it did not work. I was testing Ganglia package... the resulting /etc/gmetad.conf looks like:gridname "gridname"data_source "cluster__name" fc4-x86.oscar.gsc Looks like the key and the value got switched around? BTW, would it be possible to use sed or regex to update the configuration instead of throwing the modified bits at the bottom of the configuration file? To a new user who doesn't know anything about Ganglia, the configuration option is now out of context with the nice comments which describe what the options are for... Thanks, BernardUsing Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
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
Re: [Oscar-devel] Configurator
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
Re: [Oscar-devel] Configurator
Hi Wesley, I'd propose to do it in some steps: 1. add the table (doesn't hurt) 2. prepare routines for reading/writing values from/to database (given opkg, context) 3. prepare a routine to parse the configurator.values and feed the database with them (doesn't hurt, yet, as it leaves the old thing in place) 4. work on the XML part: - can you build the configurator.html out of xmls? - can we initialize the database with the XML values? - ... lots of things I didn't think about ... 5. switch over all the routines reading the configurator.values xml to read the database. Steps 2,3,4 can be done in parallel and can be properly tested before switching over. Step 4 seems to be your main focus, most of it is what you wanted to do anyway. We can move along without seriously hurting the existing system and you'd be doing what you had to do anyway. Of course we need to take care that steps 1, 2, 3 proceed well. There appear to be some natural assignements to the tasks, but we should discuss this in a call, I guess... Regards, Erich On Wednesday 14 June 2006 17:28, Wesley Bland wrote: 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
[Oscar-devel] Configurator
As you may have seen this summer I'm working on making a CLI for the OSCAR Installer. As I have moved into the configurator step (Step 2), I have run into a major problem. HTML is very difficult to parse into a command line format. Essentially what I have to do is write my own HTML browser to print the HTML and get responses from the users when there is an INPUT tag. Already this is a huge pain, but it gets worse as I start to try to parse the INPUT tags to create prompts. For example, logically, to use a radio button, a label is necessary. However, in HTML there is no way to connect a label to a button because the label could be to the left, right, above, or below the button. Other problems arise when trying to connect things like checkboxes, which have no way to be tied together. What I ask from you guys is to consider the possibility of converting the Configurator to use XML input files instead of HTML, i.e., configurator.xml instead of configurator.html. Using XML would make solving all these problems much easier and allow me to get this CLI going by the end of the summer. For the moment, the HTML (used by GUI) and XML (used by CLI) versions could coexist until a better solution (converting the GUI to XML, etc.) is realized. I am told that these configurator files do not change very often, and it would not be a huge pain to maintain an HTML and XML version for a while especially since they are not very complex pages. Please send me any input you have and keep an eye on the wiki page to keep up with progress on the CLI. Thanks, Wesley -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
On Thu, Jun 08, 2006 at 09:02:36AM -0400, Wesley Bland wrote: As you may have seen this summer I'm working on making a CLI for the OSCAR Installer. As I have moved into the configurator step (Step 2), I have run into a major problem. HTML is very difficult to parse into a command line format. [...] The configurator I'm familiar with uses a graphics toolkit rather than HTML, so this is necessarily just a general comment on HTML (which I'm very familiar with). For example, logically, to use a radio button, a label is necessary. However, in HTML there is no way to connect a label to a button because the label could be to the left, right, above, or below the button. Physical location on the web page is not an issue. If the page is done right, the label will have a for attribute that matches the radio button's id attribute. Other problems arise when trying to connect things like checkboxes, which have no way to be tied together. Yes they do, the fieldset and legend tags. Again, this is a general comment on HTML, prompted by the assertion in HTML there is no way. In your specific case, you are at the mercy of the code that generates the web page, which may or may not link and group things properly. But in HTML there _is_ a way, and the author of the web page(s) in question should be using it. For further information, see: HTML XHTML: The Definitive Guide Chuck Musciano Bill Kennedy O'REILLY Chapter 9: Forms Section 9.10: Labeling and Grouping Form Elements I'm still using the fourth edition, from 2000, so the chapter and section numbering may be different now. -- Ted Powell [EMAIL PROTECTED] http://psg.com/~ted/ If you don't look, you don't know. Dr. Sam Ting, Nobel laureate experimental physicist. ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
You're right. I'll admit that I am by no means an HTML expert and that many of the things I described here can probably be done as long as you are looking for output for an HTML browser. My problem is that I'm not trying to use the HTML code as a browser would, but instead parse it to display on the command line in the fashion that I am looking for (not the same as what lynx would do). Feel free to take a look at the wiki to see more details of the CLI project. Wesley On Thursday 08 June 2006 10:54 am, Ted Powell wrote: On Thu, Jun 08, 2006 at 09:02:36AM -0400, Wesley Bland wrote: As you may have seen this summer I'm working on making a CLI for the OSCAR Installer. As I have moved into the configurator step (Step 2), I have run into a major problem. HTML is very difficult to parse into a command line format. [...] The configurator I'm familiar with uses a graphics toolkit rather than HTML, so this is necessarily just a general comment on HTML (which I'm very familiar with). For example, logically, to use a radio button, a label is necessary. However, in HTML there is no way to connect a label to a button because the label could be to the left, right, above, or below the button. Physical location on the web page is not an issue. If the page is done right, the label will have a for attribute that matches the radio button's id attribute. Other problems arise when trying to connect things like checkboxes, which have no way to be tied together. Yes they do, the fieldset and legend tags. Again, this is a general comment on HTML, prompted by the assertion in HTML there is no way. In your specific case, you are at the mercy of the code that generates the web page, which may or may not link and group things properly. But in HTML there _is_ a way, and the author of the web page(s) in question should be using it. For further information, see: HTML XHTML: The Definitive Guide Chuck Musciano Bill Kennedy O'REILLY Chapter 9: Forms Section 9.10: Labeling and Grouping Form Elements I'm still using the fourth edition, from 2000, so the chapter and section numbering may be different now. -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
On Thu, Jun 08, 2006 at 09:02:36AM -0400, Wesley Bland wrote: [...] Please send me any input you have and keep an eye on the wiki page to keep up with progress on the CLI. On Thu, Jun 08, 2006 at 11:06:27AM -0400, Wesley Bland wrote: [...] would do). Feel free to take a look at the wiki to see more details of the CLI project. Am I suffering from a mental blind spot, or have you failed to give a URL for this wiki? I've looked in a few obvious places on the web, but without success. -- Ted Powell [EMAIL PROTECTED] http://psg.com/~ted/ If you don't look, you don't know. Dr. Sam Ting, Nobel laureate experimental physicist. ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
Sorry about that, here's the URL: https://svn.oscar.openclustergroup.org/trac/oscar/wiki/DevelDocs My stuff is under Command Line Interface. Wesley On Thursday 08 June 2006 12:07 pm, Ted Powell wrote: On Thu, Jun 08, 2006 at 09:02:36AM -0400, Wesley Bland wrote: [...] Please send me any input you have and keep an eye on the wiki page to keep up with progress on the CLI. On Thu, Jun 08, 2006 at 11:06:27AM -0400, Wesley Bland wrote: [...] would do). Feel free to take a look at the wiki to see more details of the CLI project. Am I suffering from a mental blind spot, or have you failed to give a URL for this wiki? I've looked in a few obvious places on the web, but without success. -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
I guess my big question after looking at your wiki is Why reinvent functionality that works beter in the GUI?. I understand the need for automated installs and the need for some sort of CLI interface, but I am not really understanding the need for a fully featured text mode installer which has similar functionality as the GUI itself. On 6/8/06, Wesley Bland [EMAIL PROTECTED] wrote: Sorry about that, here's the URL: https://svn.oscar.openclustergroup.org/trac/oscar/wiki/DevelDocs My stuff is under Command Line Interface. Wesley On Thursday 08 June 2006 12:07 pm, Ted Powell wrote: On Thu, Jun 08, 2006 at 09:02:36AM -0400, Wesley Bland wrote: [...] Please send me any input you have and keep an eye on the wiki page to keep up with progress on the CLI. On Thu, Jun 08, 2006 at 11:06:27AM -0400, Wesley Bland wrote: [...] would do). Feel free to take a look at the wiki to see more details of the CLI project. Am I suffering from a mental blind spot, or have you failed to give a URL for this wiki? I've looked in a few obvious places on the web, but without success. -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
Hi Wesley: First of all welcome (but I think I have already said that in the conference call before) and I'm glad that you're getting us involved in your summer project. Anyways, I have been meaning to contact you regarding your work. About your problems with parsing the HTML - how about just use a text web browser? I guess that may not really help you with automatic installs, but at least it allows a user to remotely ssh into the headnode and configure some stuff. Some commonly good text web browsers are w3m, lynx, etc. Just some suggestions. Cheers, Bernard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wesley Bland Sent: Thursday, June 08, 2006 6:03 To: oscar-devel@lists.sourceforge.net Subject: [Oscar-devel] Configurator As you may have seen this summer I'm working on making a CLI for the OSCAR Installer. As I have moved into the configurator step (Step 2), I have run into a major problem. HTML is very difficult to parse into a command line format. Essentially what I have to do is write my own HTML browser to print the HTML and get responses from the users when there is an INPUT tag. Already this is a huge pain, but it gets worse as I start to try to parse the INPUT tags to create prompts. For example, logically, to use a radio button, a label is necessary. However, in HTML there is no way to connect a label to a button because the label could be to the left, right, above, or below the button. Other problems arise when trying to connect things like checkboxes, which have no way to be tied together. What I ask from you guys is to consider the possibility of converting the Configurator to use XML input files instead of HTML, i.e., configurator.xml instead of configurator.html. Using XML would make solving all these problems much easier and allow me to get this CLI going by the end of the summer. For the moment, the HTML (used by GUI) and XML (used by CLI) versions could coexist until a better solution (converting the GUI to XML, etc.) is realized. I am told that these configurator files do not change very often, and it would not be a huge pain to maintain an HTML and XML version for a while especially since they are not very complex pages. Please send me any input you have and keep an eye on the wiki page to keep up with progress on the CLI. Thanks, Wesley -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
The probelm with using lynx is that I can't control the input and output in the way that I need, and I really do need the automation as that is the whole premise of my work. Wesley On Thursday 08 June 2006 1:21 pm, Bernard Li wrote: Hi Wesley: First of all welcome (but I think I have already said that in the conference call before) and I'm glad that you're getting us involved in your summer project. Anyways, I have been meaning to contact you regarding your work. About your problems with parsing the HTML - how about just use a text web browser? I guess that may not really help you with automatic installs, but at least it allows a user to remotely ssh into the headnode and configure some stuff. Some commonly good text web browsers are w3m, lynx, etc. Just some suggestions. Cheers, Bernard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wesley Bland Sent: Thursday, June 08, 2006 6:03 To: oscar-devel@lists.sourceforge.net Subject: [Oscar-devel] Configurator As you may have seen this summer I'm working on making a CLI for the OSCAR Installer. As I have moved into the configurator step (Step 2), I have run into a major problem. HTML is very difficult to parse into a command line format. Essentially what I have to do is write my own HTML browser to print the HTML and get responses from the users when there is an INPUT tag. Already this is a huge pain, but it gets worse as I start to try to parse the INPUT tags to create prompts. For example, logically, to use a radio button, a label is necessary. However, in HTML there is no way to connect a label to a button because the label could be to the left, right, above, or below the button. Other problems arise when trying to connect things like checkboxes, which have no way to be tied together. What I ask from you guys is to consider the possibility of converting the Configurator to use XML input files instead of HTML, i.e., configurator.xml instead of configurator.html. Using XML would make solving all these problems much easier and allow me to get this CLI going by the end of the summer. For the moment, the HTML (used by GUI) and XML (used by CLI) versions could coexist until a better solution (converting the GUI to XML, etc.) is realized. I am told that these configurator files do not change very often, and it would not be a huge pain to maintain an HTML and XML version for a while especially since they are not very complex pages. Please send me any input you have and keep an eye on the wiki page to keep up with progress on the CLI. Thanks, Wesley -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator
Is the html vs xml a problem for the automated installs also? On 6/8/06, Wesley Bland [EMAIL PROTECTED] wrote: The probelm with using lynx is that I can't control the input and output in the way that I need, and I really do need the automation as that is the whole premise of my work. Wesley On Thursday 08 June 2006 1:21 pm, Bernard Li wrote: Hi Wesley: First of all welcome (but I think I have already said that in the conference call before) and I'm glad that you're getting us involved in your summer project. Anyways, I have been meaning to contact you regarding your work. About your problems with parsing the HTML - how about just use a text web browser? I guess that may not really help you with automatic installs, but at least it allows a user to remotely ssh into the headnode and configure some stuff. Some commonly good text web browsers are w3m, lynx, etc. Just some suggestions. Cheers, Bernard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wesley Bland Sent: Thursday, June 08, 2006 6:03 To: oscar-devel@lists.sourceforge.net Subject: [Oscar-devel] Configurator As you may have seen this summer I'm working on making a CLI for the OSCAR Installer. As I have moved into the configurator step (Step 2), I have run into a major problem. HTML is very difficult to parse into a command line format. Essentially what I have to do is write my own HTML browser to print the HTML and get responses from the users when there is an INPUT tag. Already this is a huge pain, but it gets worse as I start to try to parse the INPUT tags to create prompts. For example, logically, to use a radio button, a label is necessary. However, in HTML there is no way to connect a label to a button because the label could be to the left, right, above, or below the button. Other problems arise when trying to connect things like checkboxes, which have no way to be tied together. What I ask from you guys is to consider the possibility of converting the Configurator to use XML input files instead of HTML, i.e., configurator.xml instead of configurator.html. Using XML would make solving all these problems much easier and allow me to get this CLI going by the end of the summer. For the moment, the HTML (used by GUI) and XML (used by CLI) versions could coexist until a better solution (converting the GUI to XML, etc.) is realized. I am told that these configurator files do not change very often, and it would not be a huge pain to maintain an HTML and XML version for a while especially since they are not very complex pages. Please send me any input you have and keep an eye on the wiki page to keep up with progress on the CLI. Thanks, Wesley -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
[Oscar-devel] Configurator schema
I just wanted to let everyone know that I posted a schema for the XML input for configurator on the OSCAR wiki: https://svn.oscar.openclustergroup.org/trac/oscar/wiki/ConfigSchema Feel free to give me some feedback on it. If I don't hear anything by the end of the call on Tuesday, I'm gonna go ahead and begin writing the configurator with the specifications I've put on the wiki. -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator schema
Hi Wesley: You won't be modifying the behaviour of the GUI Configurator though, right? i.e. it will still use HTML as opposed to XML Cheers, Bernard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wesley Bland Sent: Thursday, June 08, 2006 12:48 To: oscar-devel@lists.sourceforge.net Subject: [Oscar-devel] Configurator schema I just wanted to let everyone know that I posted a schema for the XML input for configurator on the OSCAR wiki: https://svn.oscar.openclustergroup.org/trac/oscar/wiki/ConfigSchema Feel free to give me some feedback on it. If I don't hear anything by the end of the call on Tuesday, I'm gonna go ahead and begin writing the configurator with the specifications I've put on the wiki. -- Wesley Bland 576-5508 [EMAIL PROTECTED] ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator schema
On Thu, Jun 08, 2006 at 12:54:47PM -0700, Bernard Li wrote: Hi Wesley: You won't be modifying the behaviour of the GUI Configurator though, right? i.e. it will still use HTML as opposed to XML The GUI Configurator I'm (sort of) familiar with is the one at: trunk/lib/OSCAR/Configurator.pm which uses the Tk GUI tookit, not HTML. Is there another one? Where can I find it? -- Ted Powell [EMAIL PROTECTED] http://psg.com/~ted/ If you don't look, you don't know. Dr. Sam Ting, Nobel laureate experimental physicist. ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
Re: [Oscar-devel] Configurator schema
Hi Ted: Wesley is talking about the configurator.html in various packages: $ find . -name configurator.html ./torque/configurator.html ./ntpconfig/configurator.html ./ganglia/configurator.html ./sge/configurator.html These are used in Step 2: Configure Selected OSCAR Packages... Cheers, Bernard -Original Message- From: Ted Powell [mailto:[EMAIL PROTECTED] On Behalf Of Ted Powell Sent: Thursday, June 08, 2006 15:23 To: Bernard Li Cc: Wesley Bland; oscar-devel@lists.sourceforge.net Subject: Re: [Oscar-devel] Configurator schema On Thu, Jun 08, 2006 at 12:54:47PM -0700, Bernard Li wrote: Hi Wesley: You won't be modifying the behaviour of the GUI Configurator though, right? i.e. it will still use HTML as opposed to XML The GUI Configurator I'm (sort of) familiar with is the one at: trunk/lib/OSCAR/Configurator.pm which uses the Tk GUI tookit, not HTML. Is there another one? Where can I find it? -- Ted Powell [EMAIL PROTECTED] http://psg.com/~ted/ If you don't look, you don't know. Dr. Sam Ting, Nobel laureate experimental physicist. ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oscar-devel
[Oscar-devel] configurator values to ODA
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__nameBenchmark Cluster/cluster__name cluster__ownerNEC/cluster__owner gmond_per_imageYES/gmond_per_image gridnameBench/gridname udp_recv_channel__mcast_ifeth0/udp_recv_channel__mcast_if udp_recv_channel__port8649/udp_recv_channel__port udp_send_channel__mcast_ifeth0/udp_send_channel__mcast_if udp_send_channel__port8649/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=lnkkid=110944bid=241720dat=121642 ___ Oscar-devel mailing list Oscar-devel@lists.sourceforge.net
