While Otto may be replacing Vagrant as the preferred directly-used tool for most users, its a higher level tool where Vagrant still exists and is used under the covers.
Since Vagrant still exists and is maintained and is used by Otto (as well as being usable independently), it would be extremely confusing if Otto was called Vagrant 2.0.
> Its confusing to be "abandoning" Vagrant for a new system "Otto" when really all that is happening is that Otto is fixing issues that have come up over time with Vagrant.
The main issue Otto seems to be fixing with Vagrant is that Vagrant, alone, isn't a complete solution, a suite of other tools are needed by typical teams; Otto incorporates Vagrant and those other tools, puts an abstraction layer over them, and lets you use them together.
But that is the closest thing anyone thinks of when you say "successor." Then having to explain that it's not a successor, well, you've done it yourself.
Ruby on Rails, for instance, is a beautiful example of an internal DSL, but the Vagrant DSL is awful, you could write a much easier to read/use internal DSL in Java.
Then there is the issue that Packer and Vagrant are two different tools. Why should you need to change anything about your provisioners AT ALL when you are trying to burn an image? Doesn't that just defeat the whole point of devops?
And then there is the issue that when Vagrant can't talk to the mothership, it doesn't work right.
It goes on and on. People are screaming out today that "devops is a big waste of time" and I think 80% of that is that Packer and Vagrant are so awful and putting another layer is going to make it 95% awfulness from Hashicorp.
> devops is a big waste of time
Devops is about culture, not about tooling.
Software managers all the time are bitching that their developers get it into their heads that they need a reproducible build environments and then the three of them go screw off for two weeks trying to get Vagrant to work 100% right.
I can't help but think that what the DevOps world really needs isn't another thin layer of magic trying to shellac over the issues of everything below it, but rather to have a hard think and rebuild everything from the ground up with more appropriate primitives. Sort of like what NixOS is trying to do (haven't used it, so can't attest to how successful it has been).
That's my two cents.
Sometimes as I am working with boto (Python SDK for AWS), I wish I have the time to write some of the boto modules myself, because they were inconsistent and harder to use than other modules. I can easily create many AWS services with Ansible modules, but I find it easier to hack and integrate more tightly with my environment by writing my own Python code using boto directly. What's inside the machine remains to be Ansible because it does a really good job.
Another classic example is logstash and AWS logs like cloudtrail, flow log and alarams. I can easily write a parser in Python or in C and get my job done, and overtime the code can be reusable. But with logstash I can't guarantee that existing filters and plugins will always work and they get really really messy no matter how good you are with logstash. And that's a layer I have to reinvent because of simplicity and total control.
I'd rather pipe to Elasticsearch myself than relying on logstash in cases like that.
Awful compared to what?
'And then there is the issue that when Vagrant can't talk to the mothership, it doesn't work right. It goes on and on.'
I'm curious, which package management tool have you seen that works when it can't talk to the mothership?
Hashicorp has a particular philosophy of how it builds and ships its ecosystem: small, standalone, composed tools. That leads to some overlap and inconsistent quality, as they evolve independently. Atlas is supposed to smooth over the overall experience, but, software is hard.
Alternative ecosystems tend to be large pills to swallow (i.e. PaaS), though they might have a better overall experience.
I'm going to assume this is about not being able to detect/handle version upgrades of base boxes if they're not in Atlas (or if you're offline).
This is my issue with this ecosystem too - Atlas is a "free" service but to use/run an alternative "Atlas" would mean reverse engineering it (if there is a spec detailing the endpoints, calls, payloads expected/accepted I'd love to hear about it!).
As for "which package manager works it can't talk to the mothership":
Debian's Apt/Dpkg can work from a purely offline mirror on the local disk if you want. RPM can too. But more likely you'll want to use your own private repo. Possibly just a mirror of the upstream repo. Maybe your own packages. Maybe a mix of both.
No official spec to my knowledge, but there are a couple of attempts at this https://github.com/hollodotme/Helpers/blob/master/Tutorials/... https://www.nopsec.com/news-and-resources/blog/2015/3/27/pri...
"Debian's Apt/Dpkg can work from a purely offline mirror on the local disk if you want"
Okay, but Vagrant caches boxes on the local disk too.... if one runs "box update --box --provider" in a scheduled job.
Thanks for the references - I did find a reference to an environment variable in the vagrant source somewhere so maybe it can work reasonably well with a private reverse engineered "atlas"
These people have obviously never managed fleets of servers pre-devops. Forgive me if the opinions of some devs who have never managed a server in their lives ranks lower than those who have been in the trenches for a while now.
Anyway, in a more typical software development environment you'd provide such transition tools and carry your users along, so that the next version already starts with a huge base of users. Rather than throw out the old way and come in with a new completely incompatible way to do things.
Very confusing.
They still work at different levels, with Otto more likely trying to satisfy needs for things like "Ruby" and "Redis" while Vagrant is still more explicit.