Finish and cloud-init script support

I did small review today and this is the list of providers and their support:

Finish script support:

  • bare metal
  • openstack
  • amazon ec2
  • rackspace
  • gce

Cloud-init script support:

  • ovirt/rhev
  • vmware (*)
  • openstack
  • amazon ec2
  • rackspace

(*) VMWare has actually special cloud-init limited scope support, it
does not pass the cloud-init into the image as-is, but rather converts
it into individual actions referred as Custom Spec in VMWare docs.
Only some fields are converted, the rest is unused. It does not accept
"call home" wget/curl call therefore VMWare VMs initialized with
cloud-init stays in build mode forever. This is known limitation.

https://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.vm.customization.Specification.html

Any comments on that? We often get questions on this topic, I plan to
put this into docs.

ยทยทยท -- Later, Lukas @lzap Zapletal
1 Like

Is there any guide/page on writing a compute resource plugin that supports
cloud init? I'm contemplating working with xen-orchestra, and writing a
plugin to interface with that (as it provides cloudinit for xenserver)

ยทยทยท On Mar 28, 2017 07:29, "Lukas Zapletal" wrote:

I did small review today and this is the list of providers and their
support:

Finish script support:

  • bare metal
  • openstack
  • amazon ec2
  • rackspace
  • gce

Cloud-init script support:

  • ovirt/rhev
  • vmware (*)
  • openstack
  • amazon ec2
  • rackspace

(*) VMWare has actually special cloud-init limited scope support, it
does not pass the cloud-init into the image as-is, but rather converts
it into individual actions referred as Custom Spec in VMWare docs.
Only some fields are converted, the rest is unused. It does not accept
"call home" wget/curl call therefore VMWare VMs initialized with
cloud-init stays in build mode forever. This is known limitation.

https://github.com/fog/fog-vsphere/blob/master/lib/fog/
vsphere/requests/compute/cloudinit_to_customspec.rb

https://pubs.vmware.com/vsphere-55/index.jsp#com.
vmware.wssdk.apiref.doc/vim.vm.customization.Specification.html

Any comments on that? We often get questions on this topic, I plan to
put this into docs.

โ€“
Later,
Lukas @lzap Zapletal

โ€“
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

IIRC we just fire it at Fog at then let Fog handle it, there's very little on
our side. The assumption is that user-data will do a phone home, so there's
really little more to do than render a template and add it to the cerate_vm
hash. I can look up code examples if it helps :wink:

Greg

ยทยทยท On Tuesday, 28 March 2017 12:35:41 BST Neil Hanlon wrote: > Is there any guide/page on writing a compute resource plugin that supports > cloud init? I'm contemplating working with xen-orchestra, and writing a > plugin to interface with that (as it provides cloudinit for xenserver)

You can get a Windows VM built in VMware to call home by using a run once
script and having powershell hit the build URL. Unfortunately, VMware does
not support run once commands for Linux guests in their customization
objects.

ยทยทยท On Tuesday, March 28, 2017 at 7:36:13 AM UTC-5, Greg Sutcliffe wrote: > > On Tuesday, 28 March 2017 12:35:41 BST Neil Hanlon wrote: > > Is there any guide/page on writing a compute resource plugin that > supports > > cloud init? I'm contemplating working with xen-orchestra, and writing a > > plugin to interface with that (as it provides cloudinit for xenserver) > > IIRC we just fire it at Fog at then let Fog handle it, there's very little > on > our side. The assumption is that user-data will do a phone home, so > there's > really little more to do than render a template and add it to the > cerate_vm > hash. I can look up code examples if it helps ;) > > Greg >

Wow, that is an excellent idea. xen-orchestra is still very active, and might be the solution to our xenserver/xcp-ng compatibility.