-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, October 01, 2014 12:00:37 PM Andy Kurth wrote: > 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?
Correct - the 'optimized' version just crams all the needed Dojo files for a part of the site into a single file that has unnecessary whitespace removed and variable names set to things to minimize the characters used. Correct - extracting the stock release and running the copydojocss.sh script are all that is needed. A problem arises if you try to use an optimized version of Dojo from on old release. Then, the single vcl*.js files don't contain all the parts necessary for some of the newer code, and you get errors. > 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. This is correct. > > 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. Correct - the themes/<theme name>/css/dojo directory is the only thing created by the copydojocss.sh script. The script is explained here: https://vcl.apache.org/docs/themes.html > 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. Good points. > 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. This is a good idea. > 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 - -- - ------------------------------- Josh Thompson VCL Developer North Carolina State University my GPG/PGP key can be found at pgp.mit.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQsYT8ACgkQV/LQcNdtPQMH9wCfdcmCOQ8sbo/inoDDiBQqFdg4 nrEAn3a3RNQvb0BX3L1nuwu/YGqaDxFe =fNVc -----END PGP SIGNATURE-----
