Re: VCL block alloc, PERL module issue update
Hi Aaron, I hadn't noticed this specifically (was on CentOS 5.7), but I was hunting specifically for RPC-XML issues so I might've missed it. I can run another test install on a clean setup later this week with the updated install_perl_libs.pl. Mike On Fri, Feb 17, 2012 at 09:06, Aaron Peeler aaron_pee...@ncsu.edu wrote: Hi Mike, When you ran the latest install_perl_libs.pl. Did you see any errors in the CPAN section - should be toward the end of the output. That had: cpan tar: Options `-[0-7][lmh]' not supported by *this* tar I'm seeing an error related to config option for cpan that the verbosity level is set wrong on different linux OS versions. It's not consistent, so just checking to see if you had seen this. Thanks, Aaron On Mon, Feb 6, 2012 at 3:53 PM, Mike Haudenschild m...@longsight.com wrote: Hi Andy, I pulled down the updated install_perl_libs.pl and used alongside the 2.2.1 management node release. I did notice that libwww was installed to satisfy dependencies for perl-xml-simple. I didn't do any other tweaking -- just ran the script and otherwise followed the normal management node install procedure. A block allocation didn't work, however: |3394|blockrequest| CRITICAL |3394|blockrequest| 2012-02-06 15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object method type via package RPC::XML::Client::send_request: HTTP server error: you need (perhaps you forgot to load RPC::XML::Client::send_request: HTTP server error: you need?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. |3394|blockrequest| ( 0) vcld, die_handler (line: 636) |3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) |3394|blockrequest| (-3) blockrequest.pm, process (line: 193) |3394|blockrequest| (-4) vcld, make_new_child (line: 568) |3394|blockrequest| (-5) vcld, main (line: 448) On Mon, Feb 6, 2012 at 12:23, Andy Kurth andy_ku...@ncsu.edu wrote: I updated install_perl_libs.pl in the repository: https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl You should now be able to run it without having to perform any additional steps. Please give it a try. Thanks, Andy On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild m...@longsight.com wrote: All, I've managed to get around the CRITICAL error I was seeing in the vcld log during block allocations. perl-libwww-perl wasn't installed. *sigh* Installing that prior to running install_perl_libs.pl solved the problem (should that be added to the install_perl_libs script?). I noticed that there are two listings of PERL-related software required for the management node: https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation and https://cwiki.apache.org/confluence/display/VCL/Apache+VCL We might want to consolidate those. I was running from the install docs and didn't even think to check that perl-libwww-perl was installed. Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71 (which is NOT the most recent version) using the make method from the CPAN archive. Note that I'm on CentOS 5.7, clean install and fully updated prior to install VCL management node. There is no package perl-XML-RPC (called from the script) available from the repos (with EPEL enabled), and perl-libwww-perl wasn't installed by default. Here's the process I used... 1. Used the 2.2.1 release install_perl_libs.pl script 2. Commented out the line that tells install_perl_libs.pl to retrieve RPC::XML from CPAN (line 285) 3. Ran install_perl_libs.pl 4. Installed RPC-XML 0.71 from CPAN 5. Completed VCL management node install steps from the documentation I went with the lowest-versions of the various dependencies needed by RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate any feedback from the list on whether that may have unintended consequences... Here's the dependency tree with links: - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/) - libwww-perl (LWP) 5.801 ( https://metacpan.org/release/GAAS/libwww-perl-5.801) - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note that some tests FAILED - HTML-Parser 3.33 ( https://metacpan.org/release/GAAS/HTML-Parser-3.33) - HTML-Tagest 3.02 ( https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/) - XML-Parser 2.31 ( https://metacpan.org/release/COOPERCL/XML-Parser-2.31) Having the most recent perl-libwww-perl from CPAN yielded an install that didn't include LWP::Protocol::https (and the script is trying to make an HTTPS connection). Installing
Re: mailing list moderators
I'm not. Feel free to make me a moderator if no one else is. Aaron P. On Sun, Feb 19, 2012 at 11:29 AM, Alan D. Cabrera l...@toolazydogs.com wrote: Who of you are email list moderators for this project? I want to make sure it's not just the mentors. Regards, Alan -- Aaron Peeler Program Manager Virtual Computing Lab NC State University 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.
Re: VCL block alloc, PERL module issue update
I believe I fixed this in the commit on 2/6. There are a bunch of CPAN options which get configured in a hash in the configure_cpan subroutine. These options need to be configured so that CPAN module installs are non-interactive. I included all the options I could find in this hash to prevent CPAN from asking any questions. One of the options is tar_verbosity. It had previously been set to 0. It seems as though CPAN takes this parameter and adds -0 to the tar arguments. I changed it to a blank string and it seems to have solved the problem. -Andy On Fri, Feb 17, 2012 at 9:06 AM, Aaron Peeler aaron_pee...@ncsu.edu wrote: Hi Mike, When you ran the latest install_perl_libs.pl. Did you see any errors in the CPAN section - should be toward the end of the output. That had: cpan tar: Options `-[0-7][lmh]' not supported by *this* tar I'm seeing an error related to config option for cpan that the verbosity level is set wrong on different linux OS versions. It's not consistent, so just checking to see if you had seen this. Thanks, Aaron On Mon, Feb 6, 2012 at 3:53 PM, Mike Haudenschild m...@longsight.com wrote: Hi Andy, I pulled down the updated install_perl_libs.pl and used alongside the 2.2.1 management node release. I did notice that libwww was installed to satisfy dependencies for perl-xml-simple. I didn't do any other tweaking -- just ran the script and otherwise followed the normal management node install procedure. A block allocation didn't work, however: |3394|blockrequest| CRITICAL |3394|blockrequest| 2012-02-06 15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object method type via package RPC::XML::Client::send_request: HTTP server error: you need (perhaps you forgot to load RPC::XML::Client::send_request: HTTP server error: you need?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. |3394|blockrequest| ( 0) vcld, die_handler (line: 636) |3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) |3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) |3394|blockrequest| (-3) blockrequest.pm, process (line: 193) |3394|blockrequest| (-4) vcld, make_new_child (line: 568) |3394|blockrequest| (-5) vcld, main (line: 448) On Mon, Feb 6, 2012 at 12:23, Andy Kurth andy_ku...@ncsu.edu wrote: I updated install_perl_libs.pl in the repository: https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl You should now be able to run it without having to perform any additional steps. Please give it a try. Thanks, Andy On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild m...@longsight.com wrote: All, I've managed to get around the CRITICAL error I was seeing in the vcld log during block allocations. perl-libwww-perl wasn't installed. *sigh* Installing that prior to running install_perl_libs.pl solved the problem (should that be added to the install_perl_libs script?). I noticed that there are two listings of PERL-related software required for the management node: https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation and https://cwiki.apache.org/confluence/display/VCL/Apache+VCL We might want to consolidate those. I was running from the install docs and didn't even think to check that perl-libwww-perl was installed. Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71 (which is NOT the most recent version) using the make method from the CPAN archive. Note that I'm on CentOS 5.7, clean install and fully updated prior to install VCL management node. There is no package perl-XML-RPC (called from the script) available from the repos (with EPEL enabled), and perl-libwww-perl wasn't installed by default. Here's the process I used... 1. Used the 2.2.1 release install_perl_libs.pl script 2. Commented out the line that tells install_perl_libs.pl to retrieve RPC::XML from CPAN (line 285) 3. Ran install_perl_libs.pl 4. Installed RPC-XML 0.71 from CPAN 5. Completed VCL management node install steps from the documentation I went with the lowest-versions of the various dependencies needed by RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate any feedback from the list on whether that may have unintended consequences... Here's the dependency tree with links: - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/) - libwww-perl (LWP) 5.801 ( https://metacpan.org/release/GAAS/libwww-perl-5.801) - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note that some tests FAILED - HTML-Parser 3.33 ( https://metacpan.org/release/GAAS/HTML-Parser-3.33) - HTML-Tagest 3.02 ( https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/) - XML-Parser 2.31 ( https://metacpan.org/release/COOPERCL/XML-Parser-2.31)
Re: mailing list moderators
I'm not. Please add me. Thanks, Andy On Sun, Feb 19, 2012 at 11:29 AM, Alan D. Cabrera l...@toolazydogs.com wrote: Who of you are email list moderators for this project? I want to make sure it's not just the mentors. Regards, Alan
Re: mailing list moderators
Same for me. Josh On Monday 20 February 2012 9:37:55 AM Andy Kurth wrote: I'm not. Please add me. Thanks, Andy On Sun, Feb 19, 2012 at 11:29 AM, Alan D. Cabrera l...@toolazydogs.com wrote: Who of you are email list moderators for this project? I want to make sure it's not just the mentors. Regards, Alan -- --- Josh Thompson Systems Programmer Advanced Computing | VCL Developer North Carolina State University josh_thomp...@ncsu.edu 919-515-5323 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. signature.asc Description: This is a digitally signed message part.
Re: vcld test script
On Wed, Feb 1, 2012 at 10:54 AM, Aaron Coburn acob...@amherst.edu wrote: Has there been any thought about the installation procedure of the perl code for VCL? The current approach is to manually rename the management node directory to /usr/local/vcl Wouldn't it be better to use a standard Makefile.PL for this? This would allow the modules to avoid the 'use lib $FindBin::Bin/...' constructs, because the modules would be in perl's @INC path. Furthermore, there are a number of places where the installation directory is hard-coded (VCL::Module::OS::Windows) -- that could all be pushed to a configuration file, written by the Makefile.PL script. Is there something in the Windows.pm module or are you referring to the package structure in general? I did find /usr/local/vcl being hard-coded in the S99vcld.linux file. This should probably be improved. It would also allow the vcld script to be installed in a more standard location (e.g. /usr/local/bin) Plus, this would make the code consistent with other CPAN modules. If there was interest (some time in the future) to make these libraries available on CPAN, these changes would all be necessary. I thought about adding the VCL backend code to CPAN long ago before it was donated to the ASF. I don't know if this would be possible or advantageous now. I'm very used to developing and running vcld and the Perl modules from a single directory but I can see how using standard locations may make it more straightforward -- especially for Linux pros. Either way, I think an installation mechanism should allow the person installing it to override default locations and also provide additional information. I think a model similar to VMware's standard method of installing things under Linux would work best: -untar the installation files (doesn't matter where) -run vcld-install.pl -answer questions (or press enter to accept defaults) -when the script is done, vcld is up and running Furthermore, this would make it much easier to build and run a test suite for the perl code -- ExtUtils already has a structure for supporting this. I have attached a sample Makefile.PL I like the idea of anything that makes installation easier (and managing the installation scripts). I'll give your Makefile.PL a try. -Andy This is just a stub, but with a little more work, it could be used to configure /etc/vcl/vcld.conf and run the various tests that have been listed below. Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College (413) 542-5451 acob...@amherst.edu On Jan 13, 2012, at 11:41 AM, Andy Kurth wrote: I like the idea. Other tests which would be useful: -check VM host license expiration dates -check if the network names defined in the VM profile are available on the VM hosts -check amount of space available for VM host datastores, management node repository, and management node volume where vcld.log is being written -make sure required attributes are defined for VMs such as MAC addresses if they are not auto-generated -check if time is sychronized on VM hosts, management node, and the database server -send a test sysadmin email message The architecture of 'vcld -setup' hasn't been discussed on this list so now is a good time to begin. The idea is for vcld to handle all of the details so that any module just needs to implement a subroutine named 'setup' and it automatically gets added to the menu. This allows any module to contain options specific to itself but results in a somewhat clunky menu system. It would be good to have a single menu option where all of the tests appear yet still allow each module to implement it's own test code. In order to do this, the setup_management_node sub in vcld will need to be extended. I had thought about adding something like this in the past but never completed it. I was thinking of adding code to vcld to look for modules which implement a 'setup_check' subroutine (the same way it looks for 'setup') and then put all of these under a single menu option. There are a few bits and pieces to look at in the current code. There is a setup_check subroutine in Windows.pm. It simply gets called by Windows.pm::setup every time it is run. It only checks if product keys have been configured. The Module.pm::setup_test_rpc_xml subroutine would be another one that would be part of this. -Andy On Thu, Jan 12, 2012 at 9:45 AM, Aaron Coburn acob...@amherst.edu wrote: Hi, Guys, The web front-end to the VCL has a testsetup.php script that tests a variety of server settings so that the web code is easier to install. I am wondering if there might be interest in building a similar facility into the vcld -setup script. It seems that many of the questions posed on this (and the users') list relate to misconfigured networks and/or provisioning module components. Clearly, the vcld logfile captures all of
[jira] [Created] (VCL-556) edit schedule groups code not doing permissions correctly
edit schedule groups code not doing permissions correctly - Key: VCL-556 URL: https://issues.apache.org/jira/browse/VCL-556 Project: VCL Issue Type: Bug Components: web gui (frontend) Reporter: Josh Thompson Fix For: 2.3 viewSchedules and submitScheduleGroups do not build the list of schedules and schedule groups using the same permission set. viewSchedules has it correct. The calls to getUserResources in submitScheduleGroups need to be updated to match viewSchedules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VCL-557) xCAT2 reset node to boot state on DESTROY
xCAT2 reset node to boot state on DESTROY -- Key: VCL-557 URL: https://issues.apache.org/jira/browse/VCL-557 Project: VCL Issue Type: Improvement Reporter: Aaron Peeler Priority: Minor Fix For: 2.3 In xCAT2 provisioning module, when process is exiting set node to boot state. - create DESTROY routine - call nodeset $node boot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VCL-438) allow new users to be added to VCL when shibboleth authentication is used without LDAP
[ https://issues.apache.org/jira/browse/VCL-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson resolved VCL-438. --- Resolution: Fixed allow new users to be added to VCL when shibboleth authentication is used without LDAP -- Key: VCL-438 URL: https://issues.apache.org/jira/browse/VCL-438 Project: VCL Issue Type: Improvement Components: web gui (frontend) Reporter: Josh Thompson Assignee: Josh Thompson Fix For: 2.3 Attachments: add_shib_user.txt When using LDAP, users can be added to user groups even if they have not logged in to the site before because the userid can be validated using LDAP. This is not possible when Shibboleth is used without LDAP. It would be useful to go ahead and add the users to the database and set a flag that the user is not validated. Then, after some amount of time, if the user never logs in, the account can be expunged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VCL-313) need a way to set computers as vmhosts without a bare metal provisioning engine
[ https://issues.apache.org/jira/browse/VCL-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson resolved VCL-313. --- Resolution: Fixed need a way to set computers as vmhosts without a bare metal provisioning engine --- Key: VCL-313 URL: https://issues.apache.org/jira/browse/VCL-313 Project: VCL Issue Type: Improvement Components: vcld (backend), web gui (frontend) Reporter: Josh Thompson Assignee: Josh Thompson Fix For: 2.3 If there is no bare metal provisioning engine (i.e. xCAT), there needs to be a way to place computers in the vmhostinuse state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VCL-547) removing site maintenance entry from .ht-inc/maintenance directory doesn't fully remove site from maintenance
[ https://issues.apache.org/jira/browse/VCL-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Thompson resolved VCL-547. --- Resolution: Fixed removing site maintenance entry from .ht-inc/maintenance directory doesn't fully remove site from maintenance - Key: VCL-547 URL: https://issues.apache.org/jira/browse/VCL-547 Project: VCL Issue Type: Bug Components: web gui (frontend) Reporter: Josh Thompson Fix For: 2.3 The design of the site maintenance portion of the site included that removing a maintenance file from the maintenance directory would remove the site from maintenance. Removing a file allows the site to be displayed, but reservations cannot be made. Code should be added that sets the end time of any active site maintenance entries that don't have corresponding files in the maintenance directory to the current time. This allows the entry to stay there for archive purposes, but fully removes the site from the maintenance state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
