We have, at last count, 335 questions tagged vagrant.
As far as I know, for the most part this is a tool used by developers to create developer environments, and not something that is useful in creating production environments. (I could be wrong about this, though.)
Should Server Fault accept questions about Vagrant?
I would say yes. Systems administrators can also use vagrant for testing our own environments. Say you want to test your puppet manifests against a known standard configuration - you could vagrant up an entire testing system environment.
Additionally, part of a systems administrators job is supporting the systems that the staff use. Vagrant still falls within this scope.
So a blanket ban on vagrant is not a good idea. As with most things, looking at the question in-context before making a decisions is the way to go.
As per our very own on-topic FAQ:
If your question is about:
- managing the hardware or software of servers, workstations, storage or networks
- tools used for administering, monitoring, or automating these
- deployment to and management of third-party provided information technology platforms
I believe that Vagrant fits these three requirements. It's software for workstations, it's a tool for automation, and it's about deployment and management of third party technology platforms!
and is not about:
- consumer workstations or networking (which belong on our sister site, Super User)
- working with a service provider's management interface, such as cPanel
- product, service, or learning material recommendations product licensing inquiries or legal advice
- career, salary, personnel, employment, or formal education
- unauthorized use or misuse of IT systems
It is none of those things either.
As with most things, looking at the question in-context before making a decisions is the way to go. - I don't support a blanket ban, but I also do not support making anything vagrant on-topic
Commented
Sep 23, 2015 at 17:36
This is a topic I've been mulling over for quite some time, and I'm not sure I have a good answer.
Nonetheless...
The vast majority of vagrant usage is by developers, orchestrating development environments or to otherwise automate the handling of VirtualBox VMs. Yes, vagrant can be used with vSphere or any number of other public clouds, but as womble mentioned, it fails on many accounts to provide meaningful functionality in those environments outside of development.
That said, just because a tool is used predominantly by developers doesn't mean that it should be thrown out the window altogether. There are indeed uses for vagrant that IMHO fit right in Server Fault's wheelhouse. Some examples of these uses are:
Vagrant can be used for all of these, and can accomplish the tasks in a 100% programmatic and repeatable manner, which is where the value comes from.
To sum up my views on this, it would be silly to take a black-and-white stance on this. Like so many topics on Serverfault determining topicality requires a bit of nuance. We need to examine whether or not the OP is using vagrant for appropriate purposes as part of their professional systems/network administration job. If so, and if it's a good question, then I will welcome it.
It's kind of the same as VirtualBox or *AMPP. If you are preparing/deploying for other people then yes, on topic. Otherwise you are running close to development and SO is likely a better place. It's not like they don't have a body of vagrant knowledge, they have 4000+ questions tagged as such.
Sure we can and do use vagrant for a variety of sysadmin tasks but the majority of questions we see clearly don't fall into that category.
I haven't reviewed all the questions, but I think one of the issue is in this:
If a SysAdmin has a question regarding Vagrant, it will probably be on-topic. Like Mark Henderson states, it may be used by Sysadmin to test a configuration management and many more scenarios.
However, if a end-user comes and ask a question, then he thinks SF is his SysAdmin and he is asking a user question to a SysAdmin group hoping some sysadmin will kindly do the missing job in his business. Or his question is more pertinent to other developers to answer.
So I think it comes down to the usage scenario, not the particular software/tool.
If I ask a grep question, is it on topic? Or I can't figure out why my awk script isn't processing the syslog entry correctly... But if I say "I am writing a wrapper around grep to make it easier to use by housewifes", then that's off-topic...
I've tossed enough comments in so I thought I'd summarize my arguments in one place.
Pro argument: Vagrant is an admin tool for managing environments
My response
Pro argument: Questions should be handled case by case
To be completely clear vagrant, as a product, I do not see as an issue per se. I do see the larger question of "what's the difference between SF and other sites". If you start taking questions about non "admin in the enterprise" solutions/products then we've gone off target
I say this as a frequent user of Vagrant, and as someone who develops Vagrant-based (dev) systems for others to use: I think Vagrant, in general, isn't on-topic for SF. It really isn't a systems management tool. I've seen a few people try to use Vagrant as their "cloud orchestration platform"; it goes about as well as you'd think... that is to say, not at all.
It's true that it can be used by sysadmins to create ops testing (and training) environments, but just because a sysadmin uses it doesn't make it a suitable topic for SF (otherwise whiskey would be a top-voted tag, no doubt).
Also, I really think that "support the systems that the staff use" is a bad criteria. Sysadmins have to deal with all sorts of end-user applications, and if questions about using Visual Studio are off-topic, Vagrant is equally off-topic. The day clippy shows up will be a sad day for us all...
Generally:
A topic of an useful, healthy, friendly site should be interpreted as wide as possible, and should always contain what is the "common sense".
It is because new people won't know all of the relevant meta posts about the site topic, years retroactively. In most cases, they don't even know that a meta site exists.
And closing - destructing their content isn't a happy first experience. With their loss, the site loses all of the content as well, what they could have constructed later.
The content of the site should be filtered by quality, and not by an irrationally narrowed topic.
It is especially bad thing to use rules retroactively, it is the worst of all worst. Going years back on the site and deleting hundreds of questions on newly invented rules, it is simply... sulphuric, on my opinion. Instead of it, if such an intent comes forth, first it should be discussed, what is the real reason.
It is highly unrealistic, that something were about professional system administration years ago, and now it isn't. If you now want to kill year-old content, then something is nearly surely not okay.
Second important thing, that for such cases there is a healthier solution: using a tag with "historical" or similar name, to differentiate the old, but once allowed content.
Specifically to Vagrant:
First, constructing environments by Vagrant is a border case between the development and the administration. It shouldn't be offtopic, especially not on SO and SF, it should be ontopic on both sites. I don't think that a little bit of overlap with the SO would be a problem or even harmful.
There is a lot of cases where professional software developers need to work in environments constructed by system administrators for them. The difference between our common skills and viewpoints, it is big and highly visible. And, honestly, it is not always a good experience if both of us need to maximize our work quality, but on different measurements. Having "vagrant" content on the SF would be a help to build a bridge between the worlds.
But, if the vagrant content should be exterminated, it should be done on such a way:
On my opinion, this is what should be done, but unfortunately the well-known, SE-wide disdain of the mods from the question migrations probably avoids the migration part.
But destroying content retroactively, it is always bad and it could be avoided.
I say we answer them.
I use Vagrant for testing my config management and other automation tooling all the time.
I use it to provide a prod-like environment on which the dev teams can test their code so I don't have to hear "it works on my machine".
I use it to evaluate new tools without having to install it on the shared-infrastructure (which - depending on your environment - may incur additional work or cost).
I use it to run services that I may want to have around, but don't necessarily want running all the time, and may not want on shared infrastructure (short lived or seldom-used webserver or database instances, for example.)
If you don't want to answer them, then dont. If you don't want to see them, add a filter.
By default, filtered tags are greyed out. If you don't want to see them at all...
ignore tags and hide-ignored tags features. @Iain