Hi Bostjan, Thank you for the detailed analysis. A few comments and questions of my own inline below...
On Mon, Sep 29, 2014 at 10:32 AM, Bostjan Boric <[email protected]> wrote: > More issues: on a clean install (more or less :P I'm trying to get Young Oh's > OpenStack module up and running - I'm providing the changes made to > the database below but I doubt they are related) clicking either on Reservations > or the Dashboard button immediatelly pops up an error: "Error encountered: > Please try again later" (it doesn't get any more generic than this ;)). I traced > it back to an exception caught at web/js/code.js:78 when calling > dojo.fromJson(data), data actually includes the following string: > > <h2>Error: Invalid Input</h2><br> > You submitted expired data to this web site. Please restart the steps > you were following without using your browser's <strong>Back</strong> > button. > > Continuing up along the stack trace is virtually impossible though as > the previous function calls originate deep from within the minified dojo.js. > I was wondering - why exactly are we including an 'optimized' JS library > in a development build of VCL? My understanding is that using an 'optimized' copy of dojo is solely to improve performance when running VCL in production. For development and troubleshooting, it seems like it would be better to use a standard copy of dojo. If so and just to clarify for everyone (going back to the original reason for this thread), nothing needs to a stock dojo-release-1.6.2 other than extracting it and running './copydojocss.sh default', correct? When using stock dojo-release-1.6.2, I do get these errors in /var/log/httpd/ssl_error_log: [Wed Oct 01 11:10:26 2014] [error] [client 152.14.53.54] File does not exist: /var/www/html/vcltrunk/dojo/dojo/vclResources.js, referer: https://x.x.x.x/vcltrunk/index.php Josh works across the hall from me and I asked about this. So correct me if I'm paraphrasing wrong, but this error is OK. It is just attempting to retrieve the single "optimized" dojo/vcl*.js file. If this fails, it continues to download the numerous files the vcl*.js would have contained. > Another slight problem (this time really a feature and not a bug :)) - my > browser was logging failed GET requests for /default/css/dojo/default.css. > After digging around I found a copydojocss.sh script that Josh commited > over 5 years ago > ( http://mail-archives.apache.org/mod_mbox/incubator-vcl-commits/200904.mbox/%[email protected]%3E > ) > that copies the Dijit thundra theme css files from dojo/dijit/themes/tundra > to themes/$skin/css. Not sure I have seen this mentioned anywhere before > so for all the testers of the bleeding edge web code from Josh: cd-ing into > themes dir and running > ./copydojocss.sh default > should do the trick :). The current copydojocss.sh in trunk should work. I did notice, however, that the script has problems if you try to run it a 2nd time: # ./copydojocss.sh default mv: cannot stat `tundra.css': No such file or directory mv: cannot stat `tundra_rtl.css': No such file or directory Successfully copied dojo css to default Deleting the themes/default/css/dojo directory seems to solve this problem. It's easy to miss the copydojocss.sh step. I think we could extend testsetup.php to check if copydojocss.sh was run for all of the themes. I also noticed that testsetup.php isn't checking for the new Spyc requirement. This should also be added. As a side note, the paths in copydojocss.sh require you to run it from the themes directory. This isn't ideal since someone could try to run it from another directory using the absolute path of the script. This is particularly useful for anyone attempting to script parts of the VCL install. It saves a messy step of cd'ing to the directory, running the command, then possibly cd'ing back. It would be nice if the script were updated to allow it to be run from anywhere. If nobody else is interested, I could attempt to make the changes but this won't happen for a while since I have several higher-priority issues to work on. Side note 2 :), the same goes for genkeys.sh. And a friendly reminder and plea for help... The core committers are pretty busy these days trying to complete VCL 2.4. The improvements I mentioned above could be implemented by anyone in the VCL community, not just committers. The copydojocss.sh and genkeys.sh scripts are simple bash scripts. testsetup.php is fairly simple as well. Working on these would be a relatively easy way to get your feet wet and would benefit the project. If interested, please review: http://vcl.apache.org/comm/contribute-documentation.html > Now for the MySQL changes/additions I mentioned (btw, is there > a conceptual/logical ER model available? I reverse engineered the > physical data model from the vcl.sql script using MySQL Workbench and > the results are quite messy - the auto-arrange function that Workbench > provides fails miserably and I spent a couple of hours sorting out the > diagram with usually 4 to 5 entities overlapping each other, > not a pretty sight :). Short answer, no. I did create some UML models a while ago to describe the backend architecture but nothing for the database schema. ( https://cwiki.apache.org/confluence/display/VCL/Modularized+Architecture) I have used MySQL Workbench in the past and highly recommend it. As you've experienced, it's practically impossible to create an organized diagram with all of the tables in the database. I usually create smaller diagrams with a subset of closely related tables such as: -request, reservation, computer, vmhost, vmprofile -computer, image, managementnode, resource, resourcetype, resource, resourcegroup, resourcegroupmembers It would be great to improve the documentation and include such diagrams. Feel free to add to the wiki: https://cwiki.apache.org/confluence/display/VCL/Apache+VCL I planned to start a dedicated documentation planning thread for the upcoming release, and thereafter. This would be a great topic to include. > Also: are the current provisioning modules > hard-coded in the Add Computer dialog? Even after all the database > aditions shown below the Openstack provisioning option is missing, > but it can be selected via "Actions for selected computers > > Change Provisioning Engine" after a computer has already been > created?) This appears to be controlled by getProvisioningTypes in utils.php: if($row['type'] == 'kickstart' || $row['type'] == 'partimage') > $types['blade'][$row['id']] = $row['prettyname']; > if($row['type'] == 'none') > $types['lab'][$row['id']] = $row['prettyname']; > if($row['type'] == 'vbox' || $row['type'] == 'vmware') > $types['virtualmachine'][$row['id']] = $row['prettyname']; $row['type'] refers to OSinstalltype.name. The page won't display a provisioning option if a new OSinstalltype is added. The "Change Provisioning Engine" option is using getProvisioning in utils.pm, which returns all provisioning types. There is currently no way to narrow down computer to potential provisioning entries based on the schema. How about this: -Add a "computertype" table -Change computer.type to computer.typeid and have it point to this table -Add a "provisioningcomputertype" table which maps provisioning.id to computer.typeid -When someone selects "Computer Type" on the "Add Computer" page, it can then narrow down the potential provisioning types by only showing provisioning entries which map to the selected computer.type. I don't think this needs to be done for 2.4. For now we could simply extend the if statement in getProvisioningTypes to include Openstack and make sure any other provisioning entries included in the schema work as well. For additional osinstalltype entries developers may add, we do need to include a description of this issue and a workaround in the documentation. Regards, Andy
