Post-processor to upload VMware builder artifacts to vSphere Endpoints [RFC]

[jasonberanek]

Openning to determine whether it would be appropriate for something like this to be built within the core packer project, or should be maintained as a separate plugin.

The idea would be to have a post-processor for the VMware builder that can take the build artifacts and add them as a VM and/or template on a vSphere compatible endpoint (either vSphere or vCenter). This post-processor would simplify workflows building VMware VMs primarily for operations within a vSphere environment, including builds triggers by a CI pipeline.

[mitchellh]

Yep, I'd be happy to have this in core. I'm going to mark as an enhancement. I don't plan on working on this by myself, but if I see a PR I'll be happy.

[jasonberanek]

@mitchellh I was going to make an attempt, time permitting. Mainly wanted to know if you'd accept the PR or if I needed to make a standalone plugin. My hope is that this would make a sane workflow for CI pipeline for vSphere machines, considering vSphere 5.x has a number of issues with doing the ISO based builds itself (see various discussions on the attempt to add vSphere support to veewee at jedi4ever/veewee#504).

[mitchellh]

Yep that looks good to me. The main blocker I think will be that there is no vSphere/ESX API client for Go. But it is all HTTP (if I remember) so it might be easy to make a quick/crappy one just like we did for the DigitalOcean builder.

[jasonberanek]

I'm thinking it would be easier to leverage VMware's ovftool to implement this. The tool is likely to be installed with the VMware desktop environments targeted, and it provides a single command line API to integrate into Packer (rather than adapting two separate HTTP libraries, one of which depends on SOAP messaging and dynamic typing over XML). As a bonus, a driver for ovftool could be reused as part of an ovf/ova post-processor for VMware builder's artifacts.

Long term, we could look at adapting something like the trivial SOAP implementation in RbVmomi (http://github.com/vmware/rbvmomi), but if we are going to build some kind of simple SOAP implementation, it would probably be better to generalize that enough for the WinRM use case @mitchellh has been mentioning.

There are a few other items I want to address/review first, but will start looking at what the configuration API for this post-processor would look like and post it for comment here.

[mheidenr]

I built a post-processor for vm upload with ovftool https://github.com/mheidenr/packer-post-processor-ovftool. @mitchellh if you are interested, you can integrate this directly into packer. I am awaiting your comments

[jasonberanek]

@mheidenr Your plugin looks to be equivalent to what I was planning on doing for my initial implementation of this capability before October got away from me. If you want to incorporate it into Packer and issue a pull request, I'll support getting it tested on my side. A few items I'd want to look at/discuss as part of that process:

• Rename the post-processor to reflect its an export to a vSphere server, and not a general ovftool interface
  • When I think ovftool, I primarily think transforming a VM into a ovf/ova file
• Review through the configuration for the pluging to make some of the naming conventions consistent with other plugins (ex. your plugin uses pass instead of password or vsphere_password)

We can work through the above two points in discussion on the issue, and then that could avoid those as comments with the pull request, or defer to the pull request comment process. Your choice.

[mitchellh]

@mheidenr As @jasonberanek said, make a formal PR and I'd love to incorporate it. :)

[mitchellh]

This is done, or has been done

[jasonberanek]

Yeah, thought I'd already come back around to close it.

On Tuesday, December 10, 2013, Mitchell Hashimoto wrote:

This is done, or has been done

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/232#issuecomment-30285469
.