Vagrant support in fabfile

50 views
Skip to first unread message

Kent Hauser

unread,
May 13, 2013, 3:08:54 PM5/13/13
to mezzani...@googlegroups.com
I don't know if there's any interest, but I've got a patch which adds 'Vagrant' support to the Mezzanine fabfile.py. With this patch, 'fab all' creates a Vagrant instance & does it's business on the local machine in a virtualenv appliance.

To create the Vagrant instance, you need to add 'USE_VAGRANT' to the FABRIC dict in settings.py. This overrides USER/PASSWORD/HOSTS and manages the vagrant instance. By default, the Vagrant machine is reachable on ports 8080/8443.

To add Vagrant support to your machine, visit http://vagrantup.com. Once vagrant & virtualenv are installed, the Ubuntu basebox is also needed. Execute "vagrant box add precise32 http://files.vagrantup.com/precise32.box" to add it to your machine.

If there's any interest, I can clean up the patch & add user documentation.

The patch is on branch "vagrant" at git://github.com/kenthauser/mezzanine.git


Stephen McDonald

unread,
May 13, 2013, 5:16:45 PM5/13/13
to mezzani...@googlegroups.com
Hey Kent,

Thanks for sharing this, it's really cool. I'm not sure it belongs in Mezzanine though. Here's my thinking:

I actually developed the fabfile exclusively using vagrant. Beyond using vagrant up/ssh/halt/etc, I didn't need any integration with the fabfile itself. I think by keeping any vagrant related handling out of the fabfile, we'll ensure that people properly get to know what the two pieces of software are (fabric and vagrant), and how to use them correctly. What I mean by that is, when using vagrant, users will still need to define the FABRIC settings for their vagrant instance - they'll learn about the options such as FABRIC username, host etc. They'll also learn about defining these separately in a local_settings.py module. They'll be steered towards treating the vagrant instance just like any other host to deploy to - I think it's a valuable experience in getting prepared for production deploys.

Secondly there's the support overhead. If we introduce this, all of a sudden we need to support every person who comes along and has some possible issue with vagrant when using it to develop their Mezzanine project. Not that we wouldn't try to help people with this right now, but it's certainly extra overhead we'd like to avoid. There's also the notion that vagrant may change over time - it's one more piece of code we'd need to maintain.

Given all that, I don't think adding this just to save people learning a few vagrant commands is really worthwhile. Thank anyway though, it is quite cool all the same. Perhaps you could release it as a separate library people could use, called "mezzanine-vagrant" or something similar? Then we could add it to the list of third-party mezzanine libraries. I think some people would really find it useful.






--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Stephen McDonald
http://jupo.org

Kent Hauser

unread,
May 13, 2013, 5:33:48 PM5/13/13
to mezzani...@googlegroups.com, st...@jupo.org
Hey Stephen,

Excellent comments on the extra support and maintenance load. I agree that questions on Vagrant would add a load to the list that's not needed. I'll see if I can't refactor it up as a separate package.

I must say that you have a really well organized fabfile.py included with Mezzanine. There was only line of code changed (the test for empty HOSTS[]). The rest was just a decorator & some support routines. Clean code like yours sure makes Mezzanine a pleasure to use!

Thanks a bunch.


Reply all
Reply to author
Forward
0 new messages