Provider for Tart (VMs on Apple Silicon)

[fkorotkov]

We just open sourced Tart -- virtualization toolset to build, run and manage virtual machines on Apple Silicon. At the moment Tart only supports macOS VMs but soon we'll add Linux support as well.

Tart was designed to be integrated into CIs and other tools. We already have a Packer Builder Plugin. There is already an interest in Tart Vagrant Provider and we are willing to work/help to build it.

Creating this issue as an alternative/additional option of #12518.

[jottr]

@fkorotkov any updates?
Have you started working on a provider?

[fkorotkov]

@jottr, just a quick update that since macOS Ventura is in public beta and seems safer now to be installed, we'll start working on Linux support in Tart starting next week. Please follow cirruslabs/tart#62 for updates.

Getting Linux support in Tart is prerequisite to having a Vagrant provider. Once Linux support is there we can start looking at Vagrant provider. My understanding is that provider development is moving to Go but I haven't found much information beside the announcement post. Will appreciate any insights in that area. Will be cool to try out Go which I'm personally more familiar with than with Ruby. 😅

[jottr]

Will appreciate any insights in that area. Will be cool to try out Go which I'm personally more familiar with than with Ruby. 😅

@fkorotkov Let me know if you start working on this. I'm looking for an excuse to do more in golang and would be happy to help.

[fkorotkov]

@jottr good timing! We've just release initial support for Linux. I just created a repository for the plugin at https:/cirruslabs/vagrant-plugin-tart. Will try to put out some initial implementation this week hence there is now some documentation available.

Please keep an eye on the repository about development updates. Once there is something people can play with I'll post here an update.

[ringods]

@fkorotkov will this be a new Go based Vagrant plugin?

[fkorotkov]

Hope so! Have no desire to touch Ruby 😅

[fkorotkov]

So I did some investigation and it seems everything is doable... I was looking mostly into the Ruby plugin for Parallels and it seems one will need to implement all the actions but in the new Go world.

But I don't think it's reasonable for the Tart team to try to implement the integration on our own. We don't use Vagrant and are lacking the expertise on that end. Plus we have many other things on our plate to justify allocation resources.

We believe someone from Vagrant community or HashiCorp should champion the plugin development and we'll provide support from Tart side like we did with Linux support.

If anyone interested please ping and let's schedule a meeting to discuss the potential combined effort.

[soapy1]

First, it's very exciting to see projects like Tart for running Virtual Machine on M1/M2, and it's also very exciting to see folks hacking against the Go side of Vagrant! However, Vagrant-go is currently not super stable. So, while the provider plugin interface is available you may not want to dig into quite yet. In general, I would advise against writing Go provider plugins for right now (other plugin interfaces like for guest/host plugins are pretty stable at this point). We are actively working on making this better and will keep you updated!

[tomjn]

@fkorotkov I can't say I can build all of this out in to a full provider that does everything VirtualBox does, but I can help get a basic provider up and running.

I also see there's a golang provider plugin on the cirruslabs github org but it's undocumented and not clear how far along it is. I'd suggest building in Ruby, but I detail why below.

Tart Questions

Some basic needs and requirements, how do we do these things in Tart via CLI?

• on vagrant up
• off vagrant halt
• suspend and resume VM
• reload/restart/reboot
• run provisioner script vagrant provision/vagrant up --provision
• VMs
  • create named VMs
  • list VMs
  • destroy a VM
  • box format?
  • VM status
    • running,on,started
    • stopped,off,halted
    • provisioning
    • not created
• SSH/shell
• execute single command
• shared/mapped folders
  • local dir and virtual dir
  • user/group ownership and read/write/execute
• Networking
  • getting a VM's IP
  • specifying an IP for a VM on creation/start
• VM export
• VM import

In theory a basic provider could be built purely out of shell commands that call Tart.

Additional Questions

• Are you aware a Tart is slang for a prostitute or promiscuous woman in the UK? I think there being a tool named git means it won't be a shock but I see you're based in NYC so you might be unawares.
• There's no download page for Tart, just a link to the github homepage, are there any plans to put a nice user friendly page with a download button? Even if it leads ot the latest releases? I can see our users struggling to get Tart installed, not all of them will be happy to run a brew command or even know what that means.

General Recommendations

• Make MacOS Ventura a minimum requirement
• initial limited scope with a warning for not yet implemented features
• Build it as a Ruby plugin
  • rely on golang binaries to do all the actual work
  • minimal logic in the ruby plugin
  • vagrant go is not ready yet and lots of people won't be able to adopt it for some time
  • as many direct calls to Tart itself to do work will make a golang plugin simpler in the future, and the ruby code much faster to build and easier to maintain
• Settle on a box format as early as possible
  • if Bento boxes can be adapted it will provide a large number of useful options
    • both Intel and Arm64 boxes would help with greater adoption
• OS
  • Fail gracefully on linux/Windows ( vbguest will happily install on Apple Silicon then proceed to crash every vagrant instance )
  • Enforce Ventura as a minimum for mapped folders?

My Personal Stake:

• I'm project lead on VVV, a vagrant based local dev environment popular in the WordPress community
• Our primary provider at the moment is VirtualBox but:
  • the WordPress community wants a free open-source local dev environment, but currently docker is the closest they have and that's not free for all
  • Parallels costing money puts a lot of people off
• rolling our own basic provider with a simple VM from the examples adds a lot of maintenance burden unique to just our project
• A lot of our users aren't very technical, Parallels and VirtualBox aren't super reliable, we want to eliminate that for MacOS users, perhaps even bundle a provider directly with our project to simplify things

[tomjn]

Also it seems from what I can tell that you can start a Tart VM from CLI, but there are no stop commands, this is a problem as running vagrant up starts the VM in the background, once the VM has started you're able to run more commands. Tarts help documentation however implies this isn't a background task, but a blocking task, and that you halt the VM by either shutting it down from within, or ending the tart run task in the terminal.

There would need to be an asynchronous mechanism to start and stop named VMs independent of the current shell environment that currently does not exist.

[tomjn]

Additionally, a lot of Tart commands print out human friendly responses, but do not have machine friendly responses, a JSON/XML parameter for responses would be very helpful and avoid a lot of potential bugs when interacting with the Tart CLI

[tomjn]

I've created a number of tickets for things that would be very helpful for a vagrant Tart provider:

cirruslabs/tart#302 cirruslabs/tart#301 cirruslabs/tart#300 cirruslabs/tart#299 cirruslabs/tart#298 cirruslabs/tart#297 cirruslabs/tart#303 cirruslabs/tart#304

These would be invaluable and make Tart much more flexible, particularly for VM scripting and automation

[fkorotkov]

Hey @tomjn, thank you for the interest and a lot of questions/feature requests! I've commented on some of them and will try to answer other your questions inline below.

I also see there's a golang provider plugin on the cirruslabs github org but it's undocumented and not clear how far along it is.

https:/cirruslabs/vagrant-tart was created to just play around. As we learned that it's not advised to try to implement a provider in Go we put it on hold.

Are you aware a Tart is slang for a prostitute or promiscuous woman in the UK?

Heard of it a month after we launched Tart but still not sure how common this slang is. 🤷‍♂️ Name was chosen after Apple Tart desert aka Tartine in France. Plus tart is pretty easy to type. 😅

There's no download page for Tart, just a link to the github homepage, are there any plans to put a nice user friendly page with a download button? Even if it leads ot the latest releases? I can see our users struggling to get Tart installed, not all of them will be happy to run a brew command or even know what that means.

Interesting! Just bough https://tart.run domain that will redirect to the latest release for now. At some point we'll definitely have a dedicated site but it's not a priority now.

If you choose to bundle tart with VVV, then I guess you won't have the problem. But as part of cirruslabs/tart#305 we'll probably make the Desktop App self-updatable or even add it to App Store (for free of course).

Build it as a Ruby plugin

I'm a bit concerned about this part since our team has very limited experience with Ruby. I personally did some Ruby back in 206-2017 but I didn't like it at all.

I'm afraid choosing Ruby will limit our ability to help with the development. Also I'm still not quite understand the state of current vagrant and it's future after vagrant-go matures.

Do you maybe want to have a call to chat through some details? Email me at [email protected] in that case.

[tomjn]

Interesting! Just bough https://tart.run/ domain that will redirect to the latest release for now. At some point we'll definitely have a dedicated site but it's not a priority now.

Good to see!

I'm a bit concerned about this part since our team has very limited experience with Ruby. I personally did some Ruby back in 206-2017 but I didn't like it at all.

it has its quirks, Ruby isn't my primary language either. The biggest concern here is less Ruby and more Vagrants APIs. A golang plugin will only work with vagrant-go which isn't super stable right now and missing things. Maybe with vagrant 2.4 we could do things in golang and it might be ok. Ruby will work with all of it though.

In terms of what the ruby plugin will actually do? Not a lots, issue commands and then interpret the output and send vagrant what it needs. I doubt anybody expects to embark on a grand architectural adventure with a ruby plugin right now.

When vagrant-go is in more use and more mature we can think about a golang port, but it's not clear how a golang provider would work and if that'll still be the same in a years time right now.

Something else to keep in mind is that it's likely that a Tart provider will be used as a template for other Hyperkit based VMs

Do you maybe want to have a call to chat through some details? Email me at [email protected] in that case.

That sounds good, but for now I'd like to be sure everything is possible and noted down, and there are still things on my side I want to resolve first, vagrant related projects aren't my day job so I want to cordon off the time to sort this out properly uninterrupted, and make sure anybody who's interested has a framework to work within. I hope I've given you plenty of food for thought and tasks in the meantime :)

[tomjn]

@fkorotkov if it helps, I've a very primitive ruby provider that uses the same structure as VirtualBox, currently it only checks if Tart is installed.

However it's useful to know that:

• Vagrant specifies a box file should contain a metadata json with a minimal set of values, otherwise the rest of it can contain whatever we want, so whatever Tart prefers for exporting/importing VMs
• We can use the .vagrant folder however we please, including to track the VM's status, aka if it's running/starting/destroyed/etc. VMWare even uses the folder as a place to put the VM itself, but I gather from Tarts issues and code that there's a general Tart VM folder, much like how VirtualBox behaves, with a configurable environment variable to adjust it
• The actual provider itself is somewhat sensible
  • vagrant will trigger a handful of top level actions such as "up" "ssh" or "halt" etc, and we then build a series of actions and return them. In this case an "action" is like a wrapped piece of code, something that performs a single action, e.g. run a VBoxmanage command to set a value, start a process, etc
  • this means that if we know the Tart equivalents to classic vagrant commands such as vagrant up, each of those becomes an action
  • Providers have to opt in to things so if the user wants to do something Tart can't do then they'll be told no by vagrant without us having to do anything

I believe a decent amount of progress can be made based on the issues I raised in the Tart repo, the most pressing being that running the tart command is a blocking operation

[craighurley]

Are you aware a Tart is slang for a prostitute or promiscuous woman in the UK?

The primary use of the word tart in that region is for... tarts, as in things with pastry that you eat, like: apple tart, rhubarb tart, etc. 🙄

[tomjn]

@craighurley I grew up and live in that region :) It's used for both, just checking they were aware

[petemounce]

@craighurley I grew up and live in that region :) It's used for both, just checking they were aware

Same. Can confirm. 🤷‍♂️

[adrianteri]

What's the current state of this? Is there a 'vagrant-tart' plugin(ruby gem) in the works? If they is where is it(not public)? Accepting contributions and/or help?

[tomjn]

@adrianteri I have a WIP project but it's been slow going with work, the Tart devs have been very helpful and I've been able to figure out a lot of what needs to be done. My hope was to open the repo up once I could start a VM and run a basic provisioner from vagrant

[adrianteri]

the Tart devs have been very helpful and I've been able to figure out a lot of what needs to be done

Can you share? Hope you've documented this ...

[tomjn]

https:/tomjn/vagrant-tart-ruby

I've figured out what the box format is and settled on how to interact with Tart itself ( shell scripts similar to the Hyper-V providers powershell scripts, the next step is building a box file out of a VM, for which I installed Ubuntu 22 in a Tart VM then tried checking out the chef/bento box repo and running the scripts. Last I tried I ran them in the wrong order and messed the VM up though which is a bit silly of me.

[royteeuwen]

Is this still something that is actively maintained?

I am checking into replacing VMWare Fusion with something more lightweight / easier to use. We keep getting issues in using Vagrant + VMWare Fusion + Packer Built CentOS image on a macOS Apple Silicon. Not sure if this would be a good alternative

[tomjn]

Getting it up and running is more challenging than I had anticipated, and it's been a one man journey so far. The Tart devs have been helpful and made changes from their end so that end of things has been going very well, but the actual vagrant part is difficult, especially on my own.

As a result though I managed to figure out the box format and get things scaffolded, I haven't gotten to the point where I can start a VM with vagrant up yet, and I've had very limited time to look into this. The project i maintain that needed this has pivoted towards providing support for docker in the meantime to try and unblock ourselves.

I'm still very interested in getting this working though, but I don't think it'll be done in a timely manner if i'm the only one working on the vagrant side, it's the first vagrant plugin/provider I've ever built so there's a steep learning curve.

Suffice to say if I did get it running I'd be making a big song and dance about it here asking for fellow maintainers and testers to get new boxes setup

[tdesaules]

Thanks @tomjn trying to master that piece of cake !

I was initially searching for a replacement of Vagrant / VirtualBox on my Mac, searching around UTM I find Tart.
I will first have to discover Tart and how to handle images creation with Packer but my final goal is to find a way to combine it with Vagrant.

I hope the thread is not dead :)

[letiemble]

Hello,

I have managed to produce a usable provider (in Ruby), which supports most of the Vagrant commands: https://letiemble.github.io/vagrant-tart/. The Gem is available on RubyGems.

Feel free to test it and give some feedback.

[barkingfoodog]

@letiemble I gave your project a go today and it’s working great! We automate infrastructure testing using Test Kitchen which uses Vagrant to control VMs. We switched to CirrusCLI to use tart, which was fine, but missed some nice features that Test Kitchen offers. Thanks to your tool, I’m able to switch back to Test Kitchen!

There is a little bit of hassle getting Test Kitchen to set the name on the VM, but that’s not related to your work.

Thank you for putting this together!!

[codiophile]

Hello,

I have managed to produce a usable provider (in Ruby), which supports most of the Vagrant commands: https://letiemble.github.io/vagrant-tart/. The Gem is available on RubyGems.

Feel free to test it and give some feedback.

Thank you for this. If it is fully working, it seems like official recognition is all that is left, to be able to close this issue. Is that a simple matter of adding it to the list of providers here?

I've looked through the comments and it doesn't seem like any official member of the HashiCorp organization has commented on this issue. I'm not sure if there's something we need to do to get their attention.