Vagrant hackery redux #568
Conversation
The old behavior of loading authorized_keys from /usr/share/oem is deprecated, so lets switch vagrant to the new config driven world. :)
This is the static piece of the Vagrantfile previously defined in scripts/build_library/virtualbox_ovf.sh. Moving it here so we can start maintaining the major Vagrant OEM pieces together.
Import override-plugin.rb and some VirtualBox fixups from our published Vagrantfile repo. The current Vagrant OEM depends on this code, making it impossible to boot without using our special Vagrantfile. Using the box as a stand-alone entity worked up until recently and is something users expect to work. Also bump the minimum Vagrant version to 1.5, matching our current documentation. Fixes coreos/bugs#5
There's no reason for handling vagrantfile-user-data in the Vagrant plugin, move it to the OEM cloud-config.yml along side the user-data handler. Use the generic user-config@ unit as well.
…ook. The old override-plugin.rb didn't actually properly monkey patch the change host name function because it was missing a requires line pointing to the file it is defined in upstream. To clarify things split the code into two files that match the upstream names. Additionally using this hook as it is intended means it works if a host name is defined but additional networks are not. As part of the split switch to starting the units directly. The indirection through a path unit just adds complexity.
- Only write configs for static networks, DHCP will work by default. - Match interfaces by MAC address if possible. - Use the configured netmask instead of always using a /24 - Define default addresses in /etc/environment based on the type of network. Now using both a private and a public network works!
The environment file will not be written if there are no public or private networks defined since the configure_networks hook is never run. Report an error after one minute to make this situation less confusing.
The file `base_mac.rb` will be re-written when packing this into a box.
This fixes compatibility with the existing Vagrantfile in coreos-vagrant which expected the plugin code to create this directory. Also, the units can be runtime since they are always written at boot.
|
If anyone else wants to test this new code use this: Use it with our current Vagrantfile in coreos-vagrant or start a minimal one with When using our current Vagrantfile there will be some ruby warnings due to the double monkey patch, those are harmless and will go away when this is released and we can delete the monkey patching from that repo. |
Fix some comments that were written for a previous iteration of code.
|
Similarly for VMware: |
|
Unintended but harmless. I'll update the coreos-setup-environment unit so Thanks for testing! On Tue, Apr 29, 2014 at 2:57 PM, YungSang notifications@github.com wrote:
|
As you may have already known, I investigated this issue. It seems that I guess that it is needed |
|
RemainAfterExit=yes is exactly the fix I'm going to add. I'll fix that and post new test images. I also need someone with VMware Fusion to look at this since I don't have the software to test that myself. @polvi, I forget who had Fusion, was that you? |
There is no reason for this to get re-executed if a service depending on it comes up some time after boot. This is usually the case with Vagrant. Noted in: coreos/coreos-overlay#568
|
@marineam lgtm if it works |
|
@marineam tested on vmware and it seems to work. |
|
@philips great, thanks! |
|
Looks good on vmware to me as well. |
|
did this make it to the beta release? |
|
I'm asking because I'm facing this same issue: https://groups.google.com/forum/#!topic/coreos-dev/vmHYaIrE92E |
|
@c4milo Yes, the beta release, 310.1.0, should have both this fix for Vagrant images and another fix for the vmware_insecure images that was in that email thread. |
|
great! thank you @marineam 💃 |
This achieves a few things: