We’re pleased to discuss some of the upcoming changes and new features to Vagrant 3.0. Check out our blog for more details.
If you have comments or questions, please reply to this topic!
3 Likes
As a plugin maintainer (vagrant-libvirt) I’m curious to know more about a number of areas:
- Maintaining compatibility with multiple vagrant releases, e.g. How bring your own ruby will work for plugins looking to work with both vagrant 3.0 and previous releases as far back as the 2.2 stream? With that even be possible?
- Testing - vagrant-libvirt utilizes helpers from vagrant-spec to provide some isolated environment pieces to make it easier to unit test with vagrant to help avoid making assumptions about how vagrant behaves and instead just leverage it. How will this be supported in the future? Maybe this is related to the above, because it’s again about how to work across multiple releases of vagrant?
- Integrating with golang - will there be additional helpers around converting parts of plugins to golang and remaining working? Typically it appears that for ruby <–> golang it’s involves golang to C and a fair amount of tool chain support to make the installation slick. Basically how would plugins migrate over time to be pure golang as well? Or is the expectation that only the vagrant core needs to be golang and most external plugins (not builtin) are expected to remain ruby with mostly only new plugins being written in golang?
Hi! Sure, I’d be happy to provide a bit more information. I’ll keep my answers in the same order as your questions.
- For that range of compatibility in a single plugin implementation, the current Ruby based plugin API would be the ideal focus. At some point when pre-3.0 support is no longer required, it would be advantageous to move to the new API mainly because that is where we will be focusing adding new features and enhancements. However, we will be keeping the existing Ruby based plugins fully functional.
- At this point in time we have no plans on deprecating or replacing vagrant-spec. There will likely be some updates as we work through porting to keep things properly functional, but it will still be used for running high level acceptance tests. Since vagrant-spec cares mostly about a
vagrantexecutable which it runs tests on, there’s no reason pressing reason that we would need to replace it with something else. - The new plugin API is built around go-plugin. This is a golang library, but it does not require the plugins to be implemented in golang. There will not be any C bindings introduced to connect Ruby and Go. Instead, Vagrant will interact with plugins over GRPC. While there won’t be any helpers for converting parts of a plugin from one language to another, there is a plugin SDK that will be publicly available once we have shipped Vagrant 2.3.0. The plugin SDK is currently golang based (providing base GRPC server/client implementations, helpers, and interfaces) but it will also include a Ruby implementation as well. The Ruby implementation will also include some extras that the go-plugin library provides to make building plugins using the new API in Ruby easier.
We are planning on publishing a blog post along with the Vagrant 2.3.0 release that includes much of this more developer/maintainer focused content. It will provide more detailed explanations and examples than my somewhat summarized answers. Hope that helps, and if you have more questions, or need something expanded upon, just let me know.
Cheers!
Thanks, I’ll try to keep an eye out for when the new blog post lands. Finally got around to watching the recording of some of the details being shared at hashicorp europe.
Are there any plans around having a workshop on vagrant plugin dev using the new SDK at some of the conferences that hashicorp would have a presence once things are a little further along? Or maybe an online session specifically for this, as I’m thinking it that it might help disseminate knowledge through the community a little quicker. With advanced notice it might be easier for more plugin maintainers to attend, and ask many of the same questions in one go, especially if it involves travel and the plugin maintenance is outside of their day job.
I don’t have any definitive answers around anything that would be available at upcoming conferences. However, we will be generating lots of documentation around the new SDK, guides for building new plugins, and approaches for porting existing plugins.
The 2.3.0 release is when everything will be made available. I will be working with our developer advocacy team to schedule a “community office hours” (which have been happening for other HashiCorp products) to coincide close to the release with a focus on the new plugin SDK.
We also have a Build talk scheduled today which talks a bit about the new plugin architecture, and will be available for questions afterwards. (https://events.hashicorp.com/hashitalksbuild)
Very excited about this, but curious on the status.
Where is development taking place; in public or a private repo?
Do you have alphas or betas available for testing? I’d love to start testing something.
1 Like
I signed up and logged in to ask just these same questions. It’s been ~6 months and no response. That’s discouraging.
Would someone be so kind as to answer those questions? Like @mikeschinkel I am also very excited about this new development!
1 Like
I guess it’s internal. If you watch this video at this point in time: https://youtu.be/H6RRfhi3v0E?t=957, you can see there are Go modules referenced that do not exist publicly in Github. 
1 Like
I am also very excited about 3.0, but would also love to know a bit more about the current progress.
1 Like
I am curious how the port to Go is going, we’re big on Vagrant at our company and are very much looking forward to a ruby-less future with 3.0 
1 Like