Re: [Discuss] VCL 2.3 release date

2012-02-21 Thread Andy Kurth
See comments below:

On Thu, Feb 16, 2012 at 10:39 AM, Aaron Coburn acob...@amherst.edu wrote:
 Aaron,
 My comment relates to module design rather than the mechanics of SVN.

 The basic issue is that I have a module that works great in our VCL 
 infrastructure, but there are ways in which it could more easily integrate 
 into the overall design of the VMware provisioning module. To describe in 
 brief, the vCenter module is implemented as a subclass of the vSphere_SDK 
 module. Since the VMware module doesn't know a priori which API object to 
 use, it iteratively attempts to connect to a vm host using various existing 
 APIs. When I wrote the vCenter module for our system, I tried to touch the 
 VMware module as little as possible, so I ended up subclassing VMware.pm and 
 modifying the definition of $VSPHERE_SDK_PACKAGE (defined, instead, to load 
 VCL::Module::Provisioning::VMware::vCenter).

 The better approach, though, (and I would appreciate some feedback on this) 
 would be to add an additional class variable (e.g. $VCENTER_PACKAGE) and 
 modify the initialize subroutine in VMware such that if the vSphere module 
 did not connect, it would try connecting with the vCenter module. If that 
 attempt succeeds, the api object would proceed to use the vCenter module. 
 Does that sound like a reasonable approach?

Sounds fine to me but I think it's best to keep the technical details
in the VMware provisioning module for vCenter clusters thread.  See
the reply I just sent.

 This would assume that the username and password used to access vCenter were 
 not the same as the credentials used to access individual esx hosts. That is 
 true for our setup, but is that something we could reliably trust to be the 
 case in other vm host infrastructures?

I'm not sure if I understand the issue.  Couldn't you create different
VM profiles for hosts controlled by vCenter and ones controlled
individually?  After some testing with vCenter, there may be a use to
store vCenter credentials as well as hosts controlled by vCenter
because of the CopyVirtualDisk issue.  I'm wondering if vCenter could
be used to control most things, then switch to controlling a host
individually to copy a vmdk.


 Also, there are some aspects of the vSphere_SDK module that do not rely on 
 VMware's vSphere API -- notably in how the *.vmx files are generated. The 
 vCenter module follows this approach, since when I wrote the module, I chose 
 to reimplement only what was absolutely necessary to make it work. There has 
 been some discussion on this list on precisely this point. I am certainly 
 interested in moving the vCenter code in that direction, but if the hope is 
 to put the vCenter code into the 2.3 release (i.e. by March), it seems more 
 reasonable to use the code that has over six months of testing time in a 
 production environment. I would be concerned about making significant code 
 changes and adding them to a VCL release without allowing much time to 
 evaluate the changes.

I agree.  I don't think the issues discussed related to vmx generation
should be done prior to 2.3.  This would involve a fair amount of
work.

-Andy

 Aaron


 On Feb 16, 2012, at 9:41 AM, Aaron Peeler wrote:

 Cool, Thanks Jim and Aaron.

 Aaron,
 On packaging it up - not sure I follow.  Unless I'm misunderstanding -
 you just need to commit the modules to the repo. Did you confirm you
 had svn access? If not we missed a step in creating your account.

 Josh is the release manager and will do the release candidate the code
 is ready.


 Andy, Josh, others, when you get a chance also chime in on any
 thoughts about the 2.3 release timeline, features, etc.

 Thanks,
 Aaron P.




 On Wed, Feb 15, 2012 at 3:33 PM, Aaron Coburn acob...@amherst.edu wrote:
 I think a March timeframe sounds reasonable for the vCenter module.

 I do have a few questions about how best to package it up; I will be in 
 touch about that shortly.

 Aaron


 On Feb 15, 2012, at 11:55 AM, James O'Dell wrote:

 Hi,

 I've been running the OSX provisioning code for about 6 months, and
 really haven't had much trouble with it.

 I'm not sure how well it will run under KVM, though.
 Getting the EFI bios under KVM is something that I haven't had time to
 work out, ... yet :)

 __Jim

 On 2/15/2012 7:22 AM, Aaron Peeler wrote:
 Hi Guys,

 I'd like for us to set a plan/goal for the 2.3 release.

 How does end of March sound?

 My thoughts are we identify which features and jira issues need to be
 completed and start the process.

 Features to include:
 * I think we want to include Aaron C's work on the vcenter modules.
 Aaron how do you feel on this?
 * The kvm work Andy has added
 * vote on putting back in the esxthin.pm module - one of our community
 members was using this heavily but we have no way to test it.
 * access methods
 * server loads - base line code, more improvements would be developed
 this Spr/Sum
 * Jim O'Dells work on OSX provisioning. I've looked through the code
 and it 

Re: [Discuss] VCL 2.3 release date

2012-02-17 Thread Josh Thompson
I agree that we need to set a date to work toward to get a release out.  I 
really don't like that it has been so long since our last release.  Let's go 
ahead and shoot for a March release.  However, I have to say I'm concerned 
that I won't have the time required to get stuff finished on the frontend by 
then.  Even with that concern, let's go ahead and shoot for the end of March.

Josh

On Thursday 16 February 2012 9:41:08 AM Aaron Peeler wrote:
 Cool, Thanks Jim and Aaron.
 
 Aaron,
 On packaging it up - not sure I follow.  Unless I'm misunderstanding -
 you just need to commit the modules to the repo. Did you confirm you
 had svn access? If not we missed a step in creating your account.
 
 Josh is the release manager and will do the release candidate the code
 is ready.
 
 
 Andy, Josh, others, when you get a chance also chime in on any
 thoughts about the 2.3 release timeline, features, etc.
 
 Thanks,
 Aaron P.
 
 On Wed, Feb 15, 2012 at 3:33 PM, Aaron Coburn acob...@amherst.edu wrote:
  I think a March timeframe sounds reasonable for the vCenter module.
  
  I do have a few questions about how best to package it up; I will be in
  touch about that shortly.
  
  Aaron
  
  On Feb 15, 2012, at 11:55 AM, James O'Dell wrote:
  Hi,
  
  I've been running the OSX provisioning code for about 6 months, and
  really haven't had much trouble with it.
  
  I'm not sure how well it will run under KVM, though.
  Getting the EFI bios under KVM is something that I haven't had time to
  work out, ... yet :)
  
  __Jim
  
  On 2/15/2012 7:22 AM, Aaron Peeler wrote:
   Hi Guys,
   
   I'd like for us to set a plan/goal for the 2.3 release.
   
   How does end of March sound?
   
   My thoughts are we identify which features and jira issues need to
   be
   completed and start the process.
   
   Features to include:
   * I think we want to include Aaron C's work on the vcenter
   modules.
   Aaron how do you feel on this?
   * The kvm work Andy has added
   * vote on putting back in the esxthin.pm module - one of our
   community
   members was using this heavily but we have no way to test it.
   * access methods
   * server loads - base line code, more improvements would be
   developed
   this Spr/Sum
   * Jim O'Dells work on OSX provisioning. I've looked through the
   code
   and it looks good, but I didn't have a way to test it yet. - Jim
   your
   thoughts?
   
   
   Things we exclude:
   - cluster reservations improvements.
   - jira issues that require large amounts of work at this time
   
   
   Thoughts?
   Aaron
  
  - --
  Jim O'Dell
  Network Analyst
  California State University Fullerton
  Email: jod...@fullerton.edu
  Phone: (657) 278-2256
-- 
---
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: [Discuss] VCL 2.3 release date

2012-02-16 Thread Aaron Peeler
Cool, Thanks Jim and Aaron.

Aaron,
On packaging it up - not sure I follow.  Unless I'm misunderstanding -
you just need to commit the modules to the repo. Did you confirm you
had svn access? If not we missed a step in creating your account.

Josh is the release manager and will do the release candidate the code
is ready.


Andy, Josh, others, when you get a chance also chime in on any
thoughts about the 2.3 release timeline, features, etc.

Thanks,
Aaron P.




On Wed, Feb 15, 2012 at 3:33 PM, Aaron Coburn acob...@amherst.edu wrote:
 I think a March timeframe sounds reasonable for the vCenter module.

 I do have a few questions about how best to package it up; I will be in touch 
 about that shortly.

 Aaron


 On Feb 15, 2012, at 11:55 AM, James O'Dell wrote:

 Hi,

 I've been running the OSX provisioning code for about 6 months, and
 really haven't had much trouble with it.

 I'm not sure how well it will run under KVM, though.
 Getting the EFI bios under KVM is something that I haven't had time to
 work out, ... yet :)

 __Jim

 On 2/15/2012 7:22 AM, Aaron Peeler wrote:
  Hi Guys,
 
  I'd like for us to set a plan/goal for the 2.3 release.
 
  How does end of March sound?
 
  My thoughts are we identify which features and jira issues need to be
  completed and start the process.
 
  Features to include:
  * I think we want to include Aaron C's work on the vcenter modules.
  Aaron how do you feel on this?
  * The kvm work Andy has added
  * vote on putting back in the esxthin.pm module - one of our community
  members was using this heavily but we have no way to test it.
  * access methods
  * server loads - base line code, more improvements would be developed
  this Spr/Sum
  * Jim O'Dells work on OSX provisioning. I've looked through the code
  and it looks good, but I didn't have a way to test it yet. - Jim your
  thoughts?
 
 
  Things we exclude:
  - cluster reservations improvements.
  - jira issues that require large amounts of work at this time
 
 
  Thoughts?
  Aaron
 


 - --
 Jim O'Dell
 Network Analyst
 California State University Fullerton
 Email: jod...@fullerton.edu
 Phone: (657) 278-2256




-- 
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: [Discuss] VCL 2.3 release date

2012-02-16 Thread Aaron Coburn
Aaron,
My comment relates to module design rather than the mechanics of SVN.

The basic issue is that I have a module that works great in our VCL 
infrastructure, but there are ways in which it could more easily integrate into 
the overall design of the VMware provisioning module. To describe in brief, the 
vCenter module is implemented as a subclass of the vSphere_SDK module. Since 
the VMware module doesn't know a priori which API object to use, it iteratively 
attempts to connect to a vm host using various existing APIs. When I wrote the 
vCenter module for our system, I tried to touch the VMware module as little as 
possible, so I ended up subclassing VMware.pm and modifying the definition of 
$VSPHERE_SDK_PACKAGE (defined, instead, to load 
VCL::Module::Provisioning::VMware::vCenter).

The better approach, though, (and I would appreciate some feedback on this) 
would be to add an additional class variable (e.g. $VCENTER_PACKAGE) and modify 
the initialize subroutine in VMware such that if the vSphere module did not 
connect, it would try connecting with the vCenter module. If that attempt 
succeeds, the api object would proceed to use the vCenter module. Does that 
sound like a reasonable approach? This would assume that the username and 
password used to access vCenter were not the same as the credentials used to 
access individual esx hosts. That is true for our setup, but is that something 
we could reliably trust to be the case in other vm host infrastructures?

Also, there are some aspects of the vSphere_SDK module that do not rely on 
VMware's vSphere API -- notably in how the *.vmx files are generated. The 
vCenter module follows this approach, since when I wrote the module, I chose to 
reimplement only what was absolutely necessary to make it work. There has been 
some discussion on this list on precisely this point. I am certainly interested 
in moving the vCenter code in that direction, but if the hope is to put the 
vCenter code into the 2.3 release (i.e. by March), it seems more reasonable to 
use the code that has over six months of testing time in a production 
environment. I would be concerned about making significant code changes and 
adding them to a VCL release without allowing much time to evaluate the 
changes. 

Aaron


On Feb 16, 2012, at 9:41 AM, Aaron Peeler wrote:

 Cool, Thanks Jim and Aaron.
 
 Aaron,
 On packaging it up - not sure I follow.  Unless I'm misunderstanding -
 you just need to commit the modules to the repo. Did you confirm you
 had svn access? If not we missed a step in creating your account.
 
 Josh is the release manager and will do the release candidate the code
 is ready.
 
 
 Andy, Josh, others, when you get a chance also chime in on any
 thoughts about the 2.3 release timeline, features, etc.
 
 Thanks,
 Aaron P.
 
 
 
 
 On Wed, Feb 15, 2012 at 3:33 PM, Aaron Coburn acob...@amherst.edu wrote:
 I think a March timeframe sounds reasonable for the vCenter module.
 
 I do have a few questions about how best to package it up; I will be in 
 touch about that shortly.
 
 Aaron
 
 
 On Feb 15, 2012, at 11:55 AM, James O'Dell wrote:
 
 Hi,
 
 I've been running the OSX provisioning code for about 6 months, and
 really haven't had much trouble with it.
 
 I'm not sure how well it will run under KVM, though.
 Getting the EFI bios under KVM is something that I haven't had time to
 work out, ... yet :)
 
 __Jim
 
 On 2/15/2012 7:22 AM, Aaron Peeler wrote:
 Hi Guys,
 
 I'd like for us to set a plan/goal for the 2.3 release.
 
 How does end of March sound?
 
 My thoughts are we identify which features and jira issues need to be
 completed and start the process.
 
 Features to include:
 * I think we want to include Aaron C's work on the vcenter modules.
 Aaron how do you feel on this?
 * The kvm work Andy has added
 * vote on putting back in the esxthin.pm module - one of our community
 members was using this heavily but we have no way to test it.
 * access methods
 * server loads - base line code, more improvements would be developed
 this Spr/Sum
 * Jim O'Dells work on OSX provisioning. I've looked through the code
 and it looks good, but I didn't have a way to test it yet. - Jim your
 thoughts?
 
 
 Things we exclude:
 - cluster reservations improvements.
 - jira issues that require large amounts of work at this time
 
 
 Thoughts?
 Aaron
 
 
 
 - --
 Jim O'Dell
 Network Analyst
 California State University Fullerton
 Email: jod...@fullerton.edu
 Phone: (657) 278-2256
 
 
 
 
 -- 
 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: [Discuss] VCL 2.3 release date

2012-02-16 Thread Aaron Peeler
ok gotcha. Thanks for the additional details.

Yes, It sounds like a reasonable approach to me, but Andy would need
to comment more when he can. I only have the basic understanding of
that flow in the how/when the objects are created.

-A


On Thu, Feb 16, 2012 at 10:39 AM, Aaron Coburn acob...@amherst.edu wrote:
 Aaron,
 My comment relates to module design rather than the mechanics of SVN.

 The basic issue is that I have a module that works great in our VCL 
 infrastructure, but there are ways in which it could more easily integrate 
 into the overall design of the VMware provisioning module. To describe in 
 brief, the vCenter module is implemented as a subclass of the vSphere_SDK 
 module. Since the VMware module doesn't know a priori which API object to 
 use, it iteratively attempts to connect to a vm host using various existing 
 APIs. When I wrote the vCenter module for our system, I tried to touch the 
 VMware module as little as possible, so I ended up subclassing VMware.pm and 
 modifying the definition of $VSPHERE_SDK_PACKAGE (defined, instead, to load 
 VCL::Module::Provisioning::VMware::vCenter).

 The better approach, though, (and I would appreciate some feedback on this) 
 would be to add an additional class variable (e.g. $VCENTER_PACKAGE) and 
 modify the initialize subroutine in VMware such that if the vSphere module 
 did not connect, it would try connecting with the vCenter module. If that 
 attempt succeeds, the api object would proceed to use the vCenter module. 
 Does that sound like a reasonable approach? This would assume that the 
 username and password used to access vCenter were not the same as the 
 credentials used to access individual esx hosts. That is true for our setup, 
 but is that something we could reliably trust to be the case in other vm host 
 infrastructures?

 Also, there are some aspects of the vSphere_SDK module that do not rely on 
 VMware's vSphere API -- notably in how the *.vmx files are generated. The 
 vCenter module follows this approach, since when I wrote the module, I chose 
 to reimplement only what was absolutely necessary to make it work. There has 
 been some discussion on this list on precisely this point. I am certainly 
 interested in moving the vCenter code in that direction, but if the hope is 
 to put the vCenter code into the 2.3 release (i.e. by March), it seems more 
 reasonable to use the code that has over six months of testing time in a 
 production environment. I would be concerned about making significant code 
 changes and adding them to a VCL release without allowing much time to 
 evaluate the changes.

 Aaron


 On Feb 16, 2012, at 9:41 AM, Aaron Peeler wrote:

 Cool, Thanks Jim and Aaron.

 Aaron,
 On packaging it up - not sure I follow.  Unless I'm misunderstanding -
 you just need to commit the modules to the repo. Did you confirm you
 had svn access? If not we missed a step in creating your account.

 Josh is the release manager and will do the release candidate the code
 is ready.


 Andy, Josh, others, when you get a chance also chime in on any
 thoughts about the 2.3 release timeline, features, etc.

 Thanks,
 Aaron P.




 On Wed, Feb 15, 2012 at 3:33 PM, Aaron Coburn acob...@amherst.edu wrote:
 I think a March timeframe sounds reasonable for the vCenter module.

 I do have a few questions about how best to package it up; I will be in 
 touch about that shortly.

 Aaron


 On Feb 15, 2012, at 11:55 AM, James O'Dell wrote:

 Hi,

 I've been running the OSX provisioning code for about 6 months, and
 really haven't had much trouble with it.

 I'm not sure how well it will run under KVM, though.
 Getting the EFI bios under KVM is something that I haven't had time to
 work out, ... yet :)

 __Jim

 On 2/15/2012 7:22 AM, Aaron Peeler wrote:
 Hi Guys,

 I'd like for us to set a plan/goal for the 2.3 release.

 How does end of March sound?

 My thoughts are we identify which features and jira issues need to be
 completed and start the process.

 Features to include:
 * I think we want to include Aaron C's work on the vcenter modules.
 Aaron how do you feel on this?
 * The kvm work Andy has added
 * vote on putting back in the esxthin.pm module - one of our community
 members was using this heavily but we have no way to test it.
 * access methods
 * server loads - base line code, more improvements would be developed
 this Spr/Sum
 * Jim O'Dells work on OSX provisioning. I've looked through the code
 and it looks good, but I didn't have a way to test it yet. - Jim your
 thoughts?


 Things we exclude:
 - cluster reservations improvements.
 - jira issues that require large amounts of work at this time


 Thoughts?
 Aaron



 - --
 Jim O'Dell
 Network Analyst
 California State University Fullerton
 Email: jod...@fullerton.edu
 Phone: (657) 278-2256




 --
 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