Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to append to default Vagrantfile #97

Closed
ghost opened this issue May 17, 2014 · 27 comments
Closed

Add ability to append to default Vagrantfile #97

ghost opened this issue May 17, 2014 · 27 comments

Comments

@ghost
Copy link

ghost commented May 17, 2014

I'm willing to implement this feature if there's value seen.

Users may be interested in making simple additions to the default Vagrantfile template, while avoiding having to track and reproduce all of its content or risk breaking functionality. I propose a config option to accept some arbitrary Vagrantfile keys and values that will be appropriately appended to the template, thus providing an additional degree of customization without a significant amount of complexity required.

@nelsonjchen
Copy link

It would be nice to re-add vagrant-cachier or some other things to this through this method.

@ifeltsweet
Copy link

+1

@ghost
Copy link
Author

ghost commented Jun 17, 2014

@fnichol Does this sound like a feature that you would be willing to merge in to master?

@colindean
Copy link

I would appreciate this feature for reasons stated in #100.

@tknerr
Copy link
Contributor

tknerr commented Jul 7, 2014

@colindean @nelsonjchen same issue here - also wanted to add vagrant-cachier. Got it successfully added via the global ~/.vagrant.d/Vagrantfile config, but it does not kick in for caching the omnibus installer yet, see test-kitchen/test-kitchen#440

I played around with creating my own Vagrantfile.erb, but that is doomed to fail once kitchen-vagrant makes changes to the default Vagrantfile.erb it ships with...

I'm 👍 for the possibility to append to the default Vagrantfile rather than copy / pasting the whole file (and all the future problems that this approach brings with)

@docwhat
Copy link

docwhat commented Jul 7, 2014

👍

@ghost
Copy link
Author

ghost commented Jul 8, 2014

For those interested, I have started working on a solution which I hope strikes a balance between being simple and extensible. I'll push the branch up soon.

@tknerr
Copy link
Contributor

tknerr commented Jul 15, 2014

@byggztryng cool stuff, let us know when there is something we can test

@ghost
Copy link
Author

ghost commented Jul 17, 2014

@fnichol @sethvargo is there any kind of vetted way that I could test my PR?

@ghost
Copy link
Author

ghost commented Jul 26, 2014

#111 is what I'm thinking. More robust symbol detection and replacement logic is needed, though, because Test Kitchen uses SafeYaml to load .kitchen.yml with the option to not deserialize any symbols.

@sethvargo
Copy link
Contributor

I did some research on this today. Could we leverage Vagrantfile merging and load order instead of appending? It seems like a more extensible solution. Then, instead of having this in your .kitchen.yml, you would have a real Vagrantfile that is merged with that of Kitchen

@ghost
Copy link
Author

ghost commented Jul 26, 2014

@sethvargo looks like it, so long as people are willing to package their own boxes with customized Vagrantfiles.

@sethvargo
Copy link
Contributor

@byggztryng why boxes? You could package it with a cookbook and you only need a partial vagrantfile, which seems to be what is requested here.

@ghost
Copy link
Author

ghost commented Jul 26, 2014

@sethvargo the documentation seems to suggest that the hooks for merging are strictly defined, but I think that packaging a Vagrantfile with a cookbook would require the ability to refer to it in addition to the Vagrantfile generated by kitchen-vagrant, which is sourced at level 3. Is that possible?

@sethvargo
Copy link
Contributor

You can change the starting directory where Vagrant looks for a Vagrantfile by setting the VAGRANT_CWD environmental variable to some other path.

@ghost
Copy link
Author

ghost commented Jul 26, 2014

Right, but I think that's still just for determining the sole Vagrantfile for level 3. Note that the lookup path logic states that it stops at the first Vagrantfile found, which I think would then block the kitchen-vagrant file.

@sethvargo
Copy link
Contributor

@mitchellh what would be a good pattern to follow here?

@mitchellh
Copy link

@sethvargo The best option would be to somehow require the Vagrantfiles from the source Vagrantfile (in VAGRANT_CWD). The merge logic will invoke.

@sethvargo
Copy link
Contributor

Okay. So the .kitchen/MACHINE/Vagrantfile could have something like:

require_relative '../../Vagrantfile' if File.exist?(File.expand_path('../../Vagrantfile', __FILE__))

@mitchellh
Copy link

Yep no problem. You might want to put that at the end if you want that contents to merge AFTER the Vagrant.configure in the Kitchen Vagrantfile.

@sethvargo
Copy link
Contributor

Awesome thanks!

@tknerr
Copy link
Contributor

tknerr commented Jul 27, 2014

@sethvargo @byggztryng +1 for using Vagrantfile merging + load order.

The name of the Vagrantfile should be configurable though instead of assuming "../../Vagrantfile" (which might be used for something else).

Or default to something more explicit like "../../.kitchen.Vagrantfile"?

@ghost
Copy link
Author

ghost commented Jul 28, 2014

@tknerr I think that entire path could probably be exposed to .kitchen.yml, so that the Vagrantfile could be included in the cookbook files, as suggested by @sethvargo.

@sethvargo, I'll take this advice and create a new PR.

@ghost
Copy link
Author

ghost commented Jul 29, 2014

#112 uses the Vagrantfile merging

@sethvargo
Copy link
Contributor

@byggztryng do you still need this now that we have user Vagrantfiles?

@ghost
Copy link
Author

ghost commented Nov 10, 2014

@sethvargo personally, no; I've moved on to using docker.

@sethvargo
Copy link
Contributor

Cool, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants