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

Reply via email to