The way I am currently running a CoreOS cluster in a VMWare ESXi environment has been to use an ISO mounted in vCenter as described by this blog post...


However with that particular VMWare environment, I have to explicitly define my assigned IP address into a /etc/systemd/network/static.network service in the cloud config in a few places... so I have to create an ISO file for each CoreOS machine I want to run. This seems fine, but does not scale... and sometimes the IT admins unmount the ISO drive unintentionally.

The OEM distribution documentation (here) says that you can define a /usr/share/oem/cloud-config.yml file and that you should be able to "create additional units that process user-provided metadata, as described below."

Then the process for EC2 and Rackspace is illuminated, and the explanation just points you to their baked in code in CoreOS.

What I would like to do is create a CoreOS unit that pulls a cloud-config file via HTTP with a simple URL...something like http://server-ip/cloud-configs/specific-hostname and pull the YAML file from there at boot...

This would solve two issues: I wouldn't have to provide a separate ISO for each CoreOS machine and I wouldn't have to have the VMWare admins consistently managing an ISO for each CoreOS machine.

The docs are not really clear on the best way to accomplish that. It seems like Amazon/Rackspace works because they have code inside the OS. How does Joe Schmoe provide dynamic cloud config data outside of mounting an ISO?

The big disconnect is that I can write a unit that fetches the file via wget/curl (whatever is available) but how do I tell CoreOS to process the YAML after I've fetched it?

| improve this question | | | | |

So, I probably should have rummaged through some of the other cloud providers... like there is this 'exoscale' provider which provides a bash script and a unit to fire off that bash script...

  - name: exoscale-cloudinit.service
    command: restart
    runtime: yes
    content: |
      Description=Cloudinit from exoscale (cloudstack-style) metadata


...and the method of getting CoreOS to parse a cloud-config via URL...


. /usr/share/oem/bin/exoscale-dhcp


block-until-url "${USERDATA_URL}"
coreos-cloudinit --from-url="${USERDATA_URL}"

...but now I have a bit of a chicken/egg problem unless I have some method of getting a temporary IP address to perform the curl operation...

| improve this answer | | | | |
  • In theory, DHCP is what gives you the IP and you go from there.You could, again in theory, use link local addresses to talk to a server. – Randall Smith Oct 9 '14 at 19:46
  • Agreed, I just can not remember if the allocated DHCP address/subnet allowed access to the part of the network where the user-data server would be... – azurewraith Oct 9 '14 at 21:08
  • @azurewraith have you blogged about this? I'm looking to do the same thing and getting really stuck – xddsg May 29 '15 at 15:29
  • I was successful in getting my cloud-config to work, it ended up being very similar to the above snippets, the complicated part is making sure you are connected to the network at the point of executing coreos-cloudinit --from-url – azurewraith May 29 '15 at 19:00
  • One thing I forgot to mention -- if using VMWare / vSphere this article has some automation that can be applied during virtual machine creation: virtuallyghetto.com/2014/11/… – azurewraith Jun 1 '15 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.