Re: [Discuss] Graduation ? next steps
Hi, Aaron et al. -- I'm heavily invested in VCL for two large production projects. I'm not a developer, but I have extensive experience writing documentation and would be happy to help in that regard. Most of my recent technical writing is proprietary, but a couple years ago I wrote a Moodle install doc that you could review here: http://mhauden.com/moodle Regards, Mike -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Mon, Jan 30, 2012 at 13:52, Aaron Peeler wrote: > Hi Folks, > > We are getting close to being able to ask for graduation. Based on the > checklist: > http://incubator.apache.org/guides/graduation.html#checklist > > We've meet many of the goals: > - the community is growing > - cut official releases, soon to be another one > - good communication on user/dev mailing lists and irc channel. > - more diversity in committers, hopefully over next month or so we can > bring one or two more. > > Our current active committers are: > Andy kurth - NCSU > Josh Thompson - NCSU > David Hutchins - Not-NCSU > Aaron Coburn - Not-NCSU > myself(Aaron Peeler) - NCSU > > Part of our challenge in not graduating yet has been the diversity > among our committers. It is/was heavily weighted with NCSU only > committers. In order to move quicker to graduation, it would be great > to attract one more committer. Which means being active on the list > and submitting code for review. Other areas to be a committer can be > with the web site or documentation, in case you are not comfortable > with writing code. > > Mentors, Can you advise on other areas or issues that your think we > need to address before we apply for graduation? > > Best Regards, > Aaron > > > -- > 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. >
Incubator PMC/Board report for Feb 2012 ([ppmc])
Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 15 February 2012, 10:00:00 PST. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, Feb 1st). Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/February2012 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC
Re: vcld test script
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.
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.
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
use warnings;
use strict;
use ExtUtils::MakeMaker;
my @prog = qw/vcld gen-node-key.sh/;
WriteMakefile(
NAME => 'VCL',
ABSTRACT => 'Virtual Computing Lab',
LICENSE => 'Apache',
EXE_FILES=> [ map "bin/$_", @prog ],
VERSION_FROM => 'lib/VCL/utils.pm',
PREREQ_PM=> { 'Digest::SHA1' => 0,
'DBI' => 0,
'File::Temp' => 0,
'Getopt::Long' => 0,
'HTTP::Headers' => 0,
'IO::File' => 0,
'List::Util' => 0,
'Mail::Mailer' => 0,
'Net::Ping' => 0,
'Object::InsideOut' => 0,
'RPC::XML::Client' => 0,
'Shell' => 0,
'Storable' => 0,
'Text::Wrap' => 0,
'Time::Local' => 0,
'YAML' => 0 },
MIN_PERL_VERSION => 5.008000,
META_MERGE => {
recommends => { 'VMware' => 0 },
resources => {
repository => 'https://svn.apache.org/repos/asf/incubator/vcl',
MailingList => 'mailto:vcl-dev@incubator.apache.org'
}
},
AUTHOR => 'Virtual Computing Lab',
clean => { FILES => join(" ", map "bin/$_", grep /^[A-Z\.]+$/, @prog) }
);
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 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 s
Re: VMware provisioning module for vCenter clusters
Regarding image/file naming:
I foresaw issues like this when writing VMware.pm. That's why all of
the naming logic is funneled through the various get_vmdk_* and
get_vmx_* subroutines. Changes to naming conventions or where files
are saved should (~theoretically~) only involve changing 1 or 2 of
these subroutines. All of the code in VMware.pm and the API modules
should rely on the get_* subroutines and not try to construct paths.
If vCenter for example goes and renames a vmdk, a small amount of code
could be added to VMware.pm::get_vmdk_file_path():
if ($self->api->can('get_mangled_vmdk_file_path')) {
$vmdk_file_path = $self->api->get_mangled_vmdk_file_path();
}
This would allow all of the other code to still rely on
get_vmdk_file_path() for returning the correct path.
It shouldn't really matter what you name the image or files. I wasn't
aware of the character limit. During image capture, the backend code
could rename the image in the database to something like
vmwarewinxp-82-v3 if necessary. I'm currently working on the KVM code
to do something like this. The issue I ran into has to do with the
KVM code being able to load VMware images and then capture new images
or update revisions. As a result, the updated image shouldn't be
named "vmware-". I was thinking the backend code could possibly
rename imagerevision.imagename via a update_image_name subroutine.
There may be some gotchas with the web code if you change the format.
Will have to test this.
Linked clones:
Already committed. I mentioned this earlier in this thread on 8/17.
Yes, there are added dangers with snapshots. I have added some safety
checks into the code. A snapshot is taken after a VM is registered
but before it is powered on. If the snapshot fails, the VM is
immediately deleted to prevent someone from powering it on. You have
to be very careful when working with the vSphere Client. If you
delete a linked clone VM it may delete the backing file.
prepare_vmx:
The current VMware code writes the vmx file out and then copies it to
the host for a few reasons:
- This is similar to how the old vmware.pm module did things. It was
never changed to be purely done through the vSphere SDK/vim-cmd
because it was working.
- I'm not sure if every vmx setting is configurable via the vSphere
SDK/vim-cmd. There are many undocumented vmx options which can be
useful.
That said, I have nothing against changing anything. I would like to
keep all of the logic in VMware.pm. The idea is that the API modules
are basically utility modules which expose functionality. The
different API modules should be able to be used interchangeably with
the resulting VMs constructed very similarly. Each subroutine in the
API modules should do a single simple task. The register_vm
subroutine should do only that, not actually define/construct the VM,
add devices, or other operations.
I'd prefer to add subroutines to the API modules to add devices or
make other VM configuration changes, replacing the vmx file generation
tasks done by prepare_vmx. There could either be granular subroutines
for the different device types or a single subroutine named something
like 'vmx_add_device' which accepts somewhat elaborate arguments. It
could be called from a new define_vm subroutine in VMware.pm similar
to:
if ($self->api->can('vmx_add_device')) {
$self->api->vmx_add_device('virtual_disk' => {
'vmdk_file_path' => $self->get_vmdk_file_path(),
'adapter_type' => $self->get_vm_disk_adapter_type()
}
);
# Add other devices...
}
else {
$self->prepare_vmx().
}
I'm not at all familiar with what needs to be done for vCenter. Do
you think this would work?
Also, I haven't had a chance to dig through all of vCenter.pm but
there appears to be some duplicated code. Was everything from
vSphere.pm copied into vCenter.pm or are all of the subroutines in
vCenter.pm ones which you had to modify? What are the main things you
had to change which didn't work in vSphere.pm? I'd like to push the
general changes into vSphere.pm and try to keep vCenter.pm small if
possible.
Thanks,
Andy
On Tue, Jan 31, 2012 at 10:14 AM, Aaron Coburn wrote:
>
> On Jan 31, 2012, at 9:31 AM, Sean Dilda wrote:
>
> On 1/31/12 8:46 AM, Aaron Coburn wrote:
>
> Sean,
>
>
> You can use the vsphere api to get the file names if you really need
>
> them.
>
>
> This is true, and that may very well be the better approach. I am not
>
> entirely happy with the method I described earlier, which relies on my
>
> own observation of an apparently undocumented behavior of VMware. There
>
> is, for instance, no guarantee that VMware won't start truncating
>
> virtual disk filenames at 28 characters at some point in the future.
>
>
> On the other hand, if VMware is allowed to (arbitrarily?) truncate
>
> values that follow an otherwise fairly strict VCL naming convention,
>
> there could be negative implications for subsequent revisions of a given
>
> image. Imagine, for instance,
Re: VCL block alloc, PERL module issue update
You shouldn't have to install anything manually. It looks like there
are some problems with the current install_perl_libs.pl script. There
is a CPAN "notest" option which I added to make the script run a lot
faster. Apparently this option isn't always available. Try editing
install_perl_libs.pl and then run it again. Swap the comment from the
"install" line to the "notest" line, change:
eval { CPAN::Shell->notest("install", $perl_module) };
#eval { CPAN::Shell->install($perl_module) };
-to-
#eval { CPAN::Shell->notest("install", $perl_module) };
eval { CPAN::Shell->install($perl_module) };
Also, was epel successfully installed? Run 'yum repolist'. Do you
see epel listed? If not, check the install_perl_libs.pl output for
errors when it tries to install it.
-Andy
On Tue, Jan 31, 2012 at 6:07 PM, Mike Haudenschild wrote:
> Here's the output:
>
> @
> XML::LibXML not found
>
> You may ignore the warnings about XML::LibXML not being present, if
> you plan only to use the XML::Parser-based parsing engine. The use
> of XML::LibXML is completely optional.
> @
>
> WARNING: MIN_PERL_VERSION is not a known parameter.
> WARNING: META_MERGE is not a known parameter.
> WARNING: LICENSE is not a known parameter.
> Warning: prerequisite LWP 5.834 not found. We have 5.805.
> Warning: prerequisite Test::More 0.94 not found. We have 0.62.
> 'LICENSE' is not a known MakeMaker parameter name.
> 'META_MERGE' is not a known MakeMaker parameter name.
> 'MIN_PERL_VERSION' is not a known MakeMaker parameter name.
> Writing Makefile for RPC::XML
>
>
>
> On Tue, Jan 31, 2012 at 17:52, Mike Haudenschild wrote:
>
>> Hi Aaron,
>>
>> You're right, RPC-XML wasn't installed, although perl-libwww-perl is
>> installed and updated.
>>
>> Should I install RPC-XML AFTER I run install_perl_libs.pl? (I get errors
>> when I run Makefile about various missing prerequisites on a clean CentOS
>> install.)
>>
>> Thanks,
>> Mike
>>
>> On Tue, Jan 31, 2012 at 16:49, Aaron Coburn wrote:
>>
>>> Oh. It looks like RPC-XML is not installed.
>>>
>>> You can verify that by using this command:
>>>
>>> perl -MRPC::XML -e "print 'have a nice day'"
>>>
>>> If you get errors, the module isn't installed. If the script seems
>>> friendly, then the module is installed.
>>>
>>> If the module is not installed, download it from here:
>>> http://search.cpan.org/dist/RPC-XML/
>>>
>>> unpack it and install it like so:
>>>
>>> perl Makefile.PL
>>> make && make test
>>> sudo make install
>>>
>>> Then try the command again that I listed above.
>>>
>>>
>>>
>>> On Jan 31, 2012, at 4:42 PM, Mike Haudenschild wrote:
>>>
>>> > Hi Aaron,
>>> >
>>> > I get the following errors running install_perl_libs from trunk, on
>>> CentOS
>>> > 5.7 fully updated:
>>> >
>>> > *No package perl-CPAN available.*
>>> > *WARNING: unexpected output returned while installing Linux package:
>>> > 'perl-CPAN'*
>>> > *this has happened since my first install, but doesn't seem to be a
>>> problem
>>> > since cpan is already installed in CentOS base
>>> >
>>> > *No package perl-RPC-XML available.*
>>> > *WARNING: unexpected output returned while installing Linux package:
>>> > 'perl-RPC-XML'*
>>> > *this has also happened since my first install, but I've never been
>>> able to
>>> > resolve this. I thought perhaps the CPAN commands issued at the end of
>>> the
>>> > install script installed RPC::XML from CPAN...?
>>> >
>>> > All of the PERL module installs throw:
>>> > *Unknown command 'notest'. Type ? for help.*
>>> >
>>> > Two PERL modules fail to install:
>>> >
>>> > *Attempting to install Perl module using CPAN: 'Object::InsideOut'*
>>> > *Unknown command 'notest'. Type ? for help.*
>>> > *checking if Object::InsideOut Perl module is installed...*
>>> > *Perl module Object::InsideOut appears to be installed but the version
>>> > could not be determined*
>>> > *command: perl -e "eval \"use Object::InsideOut\"; print
>>> > \$Object::InsideOut::VERSION" 2>&1*
>>> > *output:*
>>> > *ERROR: failed to install Perl module: 'Object::InsideOut'*
>>> >
>>> >
>>> > *Attempting to install Perl module using CPAN: 'RPC::XML'*
>>> > *Unknown command 'notest'. Type ? for help.*
>>> > *checking if RPC::XML Perl module is installed...*
>>> > *Perl module RPC::XML appears to be installed but the version could not
>>> be
>>> > determined*
>>> > *command: perl -e "eval \"use RPC::XML\"; print \$RPC::XML::VERSION"
>>> 2>&1*
>>> > *output:*
>>> > *ERROR: failed to install Perl module: 'RPC::XML'*
>>> >
>>> > Thanks!!
>>> > Mike
>>> >
>>> > --
>>> > *Mike Haudenschild*
>>> > Education Systems Manager
>>> > Longsight Group
>>> > (740) 599-5005 x809
>>> > m...@longsight.com
>>> > www.longsight.com
>>> >
>>> >
>>> >
>>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler
>>> wrote:
>>> >
>>> >> Hi Mike,
>>> >>
>>> >> Apologies for not responding on this.
>>> >>
>>> >> Are you still seeing this issue with your block allocations?
>>> >>
>>> >> If so you could try to use the latest
Re: remove me
If you'd like to unsubscribe, send an email to vcl-dev-unsubscr...@incubator.apache.org If that doesn't work, send an email to the list. --kevan
Re: VCL block alloc, PERL module issue update
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 LWP-Protocol-https doesn't solve the problem
because of stricter SSL certification requirements and hostname
verification (
http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm
).
Many thanks,
Mike
On Wed, Feb 1, 2012 at 11:44, Andy Kurth wrote:
> You shouldn't have to install anything manually. It looks like there
> are some problems with the current install_perl_libs.pl script. There
> is a CPAN "notest" option which I added to make the script run a lot
> faster. Apparently this option isn't always available. Try editing
> install_perl_libs.pl and then run it again. Swap the comment from the
> "install" line to the "notest" line, change:
>
> eval { CPAN::Shell->notest("install", $perl_module) };
> #eval { CPAN::Shell->install($perl_module) };
>
> -to-
>
> #eval { CPAN::Shell->notest("install", $perl_module) };
> eval { CPAN::Shell->install($perl_module) };
>
>
> Also, was epel successfully installed? Run 'yum repolist'. Do you
> see epel listed? If not, check the install_perl_libs.pl output for
> errors when it tries to install it.
>
> -Andy
>
>
> On Tue, Jan 31, 2012 at 6:07 PM, Mike Haudenschild
> wrote:
> > Here's the output:
> >
> > @
> >XML::LibXML not found
> >
> >You may ignore the warnings about XML::LibXML not being present,
> if
> >you plan only to use the XML::Parser-based parsing engine. The use
> >of XML::LibXML is completely optional.
> > @
> >
> > WARNING: MIN_PERL_VERSION is not a known parameter.
> > WARNING: META_MERGE is not a known parameter.
> > WARNING: LICENSE is not a known parameter.
> > Warning: prerequisite LWP 5.834 not found. We have 5.805.
> > Warning: prerequisite Test::More 0.94 not found. We have 0.62.
> > 'LICENSE' is not a known MakeMaker parameter name.
> > 'META_MERGE' is not a known MakeMaker parameter name.
> > 'MIN_PERL_VERSION' is not a known MakeMaker parameter name.
> > Writing Makefile for RPC::XML
> >
> >
> >
> > On Tue, Jan 31, 2012 at 17:52, Mike Haudenschild
> wrote:
> >
> >> Hi Aaron,
> >>
> >> You're right, RPC-XML wasn't installed, although perl-libwww-perl is
> >> installed and updated.
> >>
> >> Should I install RPC-XML AFTER I run install_perl_libs.pl? (I get
> errors
> >> when I run Makefile about various missing prerequisites on a clean
> CentOS
> >> install.)
> >>
> >> Thanks,
> >> Mike
> >>
> >> On Tue, Jan 31, 2012 at 16:49, Aaron Coburn
> wrote:
> >>
> >>> Oh. It looks like RPC-XML is not installed.
> >>>
> >>> You can verify that by using this command:
> >>>
> >>> perl -MRPC::XML -e "print 'have a
Re: [Discuss] Graduation ? next steps
On Feb 1, 2012, at 9:36 AM, Mike Haudenschild wrote: > Hi, Aaron et al. -- > > I'm heavily invested in VCL for two large production projects. I'm not a > developer, but I have extensive experience writing documentation and would > be happy to help in that regard. > > Most of my recent technical writing is proprietary, but a couple years ago > I wrote a Moodle install doc that you could review here: > > http://mhauden.com/moodle Cool! Your contributions would be most welcome. I multiple Apache projects with committers who have earned their commit karma via documentation contributions (not code). --kevan
Re: We have an Incubator report for February 2012 due
On Jan 31, 2012, at 2:21 PM, Aaron Peeler wrote: > 2012-02 Board Report posted. > > http://wiki.apache.org/incubator/February2012 > > And here for our records: > https://cwiki.apache.org/confluence/display/VCL/2012-02+Incubator+VCL+Report > > Let me know if you see anything that needs to be changed. Looked good to me. Thanks Aaron! --kevan
Re: [Discuss] Graduation ? next steps
I'm all about good karma. I owe the VCL guys. Besides, I'm one of the sick ones that actually ENJOY writing documentation. Don't judge me! -- *Mike Haudenschild* Education Systems Manager Longsight Group (740) 599-5005 x809 m...@longsight.com www.longsight.com On Wed, Feb 1, 2012 at 14:30, Kevan Miller wrote: > > On Feb 1, 2012, at 9:36 AM, Mike Haudenschild wrote: > > > Hi, Aaron et al. -- > > > > I'm heavily invested in VCL for two large production projects. I'm not a > > developer, but I have extensive experience writing documentation and > would > > be happy to help in that regard. > > > > Most of my recent technical writing is proprietary, but a couple years > ago > > I wrote a Moodle install doc that you could review here: > > > > http://mhauden.com/moodle > > Cool! Your contributions would be most welcome. I multiple Apache projects > with committers who have earned their commit karma via documentation > contributions (not code). > > --kevan
