What do you think about making changes to Vagrant?

[Dennis Chang]

Hi all,

This is part question and part request for comment.

I've become more familiar with Docker and I'd like Vagrant to be patterned similarly.

E.g.

docker images

produces a list of images.

vagrant box list

produces a list of boxes. This is good.

However,

docker ps -a

produces a listing of containers,

whereas

vagrant global-status

produces a list of "machines". This is fine.

My question is:

Why do I need to have an environment tied to a directory/folder?

What I'd like to do is:  vagrant up --provision-from-box "some/box" --name "some-new-machine-name"

Instead of having to rely on a Vagrantfile to define a "machine".

Plus, when I do want to use a Vagrantfile, I'd like to do the following: vagrant up -f Vagrantfile.mymachine

In other words, is it really necessary to have one Vagrantfile per directory? to define an environment for a machine?

[Alvaro Miranda Aguilera]

whats the problem on using docker for all your needs?

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/fa49f073-fa4c-4aef-bad9-7544ddd23778%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alvaro

[Dennis Chang]

I’m trying to run very old Linux versions, ie Slackware, within Docker. I get a Bash shell but every binary I execute, eg. ls, results in exit or Bash: out of virtual memory.

So I know I can do it within Vagrant.

Ideally I can do,

vagrant ssh [machine] ‘sh -c some-build-script’

Etc.

[Dennis Chang]

So apparently

vagrant ssh [machine_id] -c "some build command"

does work.

So I only have a few complaints:

1. to create a new machine I need to be in a directory with a Vagrantfile, I cannot do vagrant up --box abcd  and a new box should spin up

2. the name (in global-status) of "default" I'm guessing means default provider, in my case virtualbox, which seems meaningless to me

I've used qemu for creating VM but I don't get a shared folder (which really helps in having files available in the VM).

Anyway, Vagrant is only Ruby so it might not be too bad in implementing my changes.

[Dennis Chang]

I submitted an enhancement request. Let’s see what they say.

[Jim McGinness]

Sorry, but your requested enhancements seem a bit incoherent to me. What is the overall goal you are trying to achieve and what properties of vagrant were causing you to be interested in applying it to that goal?

The "default" is a machine name; One vagrantfile can specify a number of machines, each with their own name, built from different prepared boxes. When no names are specified, you get "default".

As it is currently implemented, vagrant creates a .vagrant folder containing files related to the machine associated with the corresponding Vagrantfile. While "vagrant init" can produce a minimal Vagrantfile, most of the time users need to add more configuration details to the Vagrantfile to get what they want rather than a generic box. There's a trade-off between the generic-ness of the base boxes and the added complexity of the Vagrantfile specifications vs using a more specialized box as the base where the customization has been already carried out. This all means that the location of the Vagrantfile (you could specify VAGRANT_HOME as an environment variable to have it be a different location than the current directory) is a locus for per-machine information about the vagrant guest machine, a locus that can be independent of the many different providers.

While there may be some similarities between docker and vagrant, there are also a lot of differences, especially in the suitability for use in various environments.

I suspect that with Slackware on qemu you could still do an NFS-based shared folder. It's not as slick as a provider-supported shared folder, but could support your use case. Of course, that's one of the configuration statements that you'd need to put in a Vagrantfile.

As for your build commands, it sounds like you might want to try using the "shell" provisioner.

[Dennis Chang]

Hi Jim,

What I would like is a command-line process whereby I control the life-cycle of the machine (without having to jump to specific directories).

vagrant up --box bento/ubuntu14.04 --name myvm   (why should a machine name be only "default"?)

vagrant halt --name myvm

vagrant start --name myvm

vagrant destroy --name myvm

vagrant ssh --name myvm -c "run a build script to build linux kernel 2.2.0"

vagrant up -f Vagrantfile.X (I still want a Vagrantfile, but I don't want it limited to a particular directory, and I don't want it limited to *only* named "Vagrantfile").

Hence, my enhancement request.

1. an additional option (-f) to allow users to create vagrantfiles without having to name it Vagrantfile relieves an unnecessary restriction (one machine per directory)

2. adding an option '--box' to specify a box to create a new machine

3. option '--name' to allow users to name their machines

These changes would make Vagrant more flexible.

[Dennis Chang]

For 3. looks like we can name our machines

https://stackoverflow.com/questions/17845637/how-to-change-vagrant-default-machine-name

but we can't do it from the command-line (it has to be a Vagrantfile).

[Dennis Chang]

To answer your question about my goals (it's more like a wish, I can't see how I have the time to do all of this):

Basically, Linux from scratch, from Slack 3.2, .. onward.

I'd like to chain these "environments", by sharing virtual disks, whereby, one environment, is building the subsequent environment.

What's the point? 

I learned a lot from LFS.

I learned a lot from Slackware (early kernels).

Ideally, on my Mac, I create a qcow2 file. Use Docker container, mount the disk image, extract Slackware files, and then use Slackware floppy disks, or qemu -kernel to boot the environment. Then, I would create a new disk image, mount that (from the build environment), and build the next environment.

Ultimately, I've heard of kernel developers or device driver developers whom have a test-harness (of cross-compilation toolchains and environments) where they test their code. It would be nice if I can ssh into any kernel version I want.

[Alvaro Miranda Aguilera]

what tools those developers with crosstooling use?

maybe not vagrant.

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/1d4af4db-602c-4eb3-822b-1a310aa79b9f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alvaro

[Dennis Chang]

You’re probably correct, not Vagrant. And I don’t know what they use. So I’m just using the tools I know.

I work with Jenkins in my day job (I’m new to it, so I’m no expert). And we create build agents (java agents) which build artifacts.

So imagine that a vagrant machine to be a build agent. I want to build artifacts (old software artifacts). I need an environment (old kernel), build tools (old gcc, binutils, linker).

Now, if you extrapolate, I want to do this not in just one environment, but in multiple environments. So I need a tool to “chain” these together (in some way). My request regarding vagrant, is just to make this a little easier.

The way I see Vagrant, is that it’s a very nice “front-end” to providers like Virtualbox or Hyperkit, et al. If I can use it, I will. Thanks.

[Jim McGinness]

Part of your objection to the way Vagrant works appears to be due to a misunderstanding. One directory, one Vagrantfile, can serve as a home for as many machines as you would care to name. The "up", "halt" etc subcommands will take a machine name as a parameter. The Vagrantfile can refer to your own personal "box" files, not just to the published ones (but you may need to become familiar with the "packer" command to properly set up your own box files so they will work properly with Vagrant).

Whether this current implementation will serve all of your purposes, I can't say. It's certainly possible to use Docker images as a way to deploy a packaged cross-compilation environment; it's not likely to support very many aspects of kernel development simultaneously with providing the cross-compilation environment. It _is_ one way to answer the "hell" of conflicting library versions, since a container does not necessarily require all its libraries to be at the same version as every other container it communicates with. I would like to think that it's possible to sequence up the compilation environment of old versions of Linux separately from sequencing up the kernels. Both qemu and virtualbox, last I knew, can successfully run DOS or FreeDOS, as well as very old Linux kernels. Once you figure out the "glue" steps needed to get from one artifact to its successor, you should be on your way.

[Dennis Chang]

Hi Jim,

Thanks for your response, BUT can you provide an example. Because your response may be clear to you, but it's not clear to me.

How can a directory serve as a home for many machines? Is this what you mean?

E.g.

~/Vagrant/Vagrantfile.1  (where vm.define = machine1)

~/Vagrant/Vagrantfile.2  (where vm.define = machine2)

~/Vagrant/Vagrantfile.3  (where vm.define = machine3)

and then

vagrant up machine1   (will instantiate a new machine)?

Thanks

[Dennis Chang]

I got a response from the enhancement request,

Vagrantfile is a project file. You can define multiple machines per project.

https://www.vagrantup.com/docs/multi-machine/

One project file per directory. My misunderstanding was that I assumed

one Vagrantfile per machine.

So that means a '-f Vagrantfile.X' isn't really required.

You can name your machines within the Vagrantfile.

And thus, 'vagrant up [machine_name]' can instantiate a machine,

if VAGRANT_VAGRANTFILE is defined for a directory/file.

Thanks for everyones response here.

[Jim McGinness]

I'm glad you got that clarifying response, since producing the requested example would likely have exceeded my current Vagrant abilities. I'm still on the early part of the learning curve, just taking a very different path than you.

[Dennis Chang]

Thanks Jim! I got the help I needed. I appreciate it. :)