Comment by mitchellh | Hacker News Reader

Comment by mitchellh | Hacker News Reader

Hello everyone! I just wanted to note that I'm running around at HashiConf and likely won't be around to answer as many questions or comments as I'd like. But thank you for all the activity around this and we're excited to show this to you today.

I want to just give a few key notes, though many other folks around here are right.

* For Otto 0.1, we focused on developer experience. We don't recommend deploying for anything more than demos. Future versions of Otto _are_ going to make this production-ready though, and we already have plans in place to do so.

* As others have discovered, Otto is built on top of our other tools and executes them under the hood. We didn't reinvent the wheel, and this has huge benefits. We're dedicated to making all our tools better, and as we do, Otto naturally improves as well.

* Otto is a lot of magic, we're not trying to hide that. It is a magical tool. But we also give you access to the details (OS, memory, etc.) using "customizations." We'll improve customizations and increase the number of knobs over time.

* Vagrant development will continue, we have some major Vagrant releases planned. Please see this page for more info: https://ottoproject.io/intro/vagrant-successor.html

* Remember that Otto is 0.1 today and Vagrant is 6 years old. We have a long way to go to reach the maturity and toughness of Vagrant. We're committed to make that happen, but it will take time.

Thanks everyone, sorry for not being able to be more active in here. Have a great day!

Why isn't Otto named Vagrant 2.0 or something? 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. Why not a migration strategy, some backwards compatibility during the translation, and then move into the future?

Otto uses Vagrant under the hood.

Indeed, which makes the tagline "successor to Vagrant" a dubious choice. It would be like referring to fleet as the successor to systemd. They're stacked layers driving existing utilities.

That makes sense, the announcement seems to imply that really the problem was that Vagrantfiles were too restrictive, so make a Vagrant 2.0 that can read the old files (and will whine) and it uses the new super "Appfile" format as its native format. Maybe there is a tool to convert a Vagrantfile to an Appfile automatically (as Appfiles are supposed to be able to do everything Vagrant can do and more)

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.

I think the idea is that Otto is the (new) interface and Vagrant is a potential implementation. A 2.0 would hide this distinction.

It sounds more like a new product, new direction than Vagrant 2.0....

My take: I think the notion is, it will make sense to use Otto directly from the git-go the way it was for Vagrant in the past.

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.

> Why isn't Otto named Vagrant 2.0 or something?

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.

I commonly use Ansible with Vagrant: the two play very well together. Otto seems to be an alternative to Ansible.

> it would be extremely confusing if Otto was called Vagrant 2.0

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.

Windows was the successor to DOS, built on DOS. Maybe this is like that?!

It's pretty depressing to see Hashicorp adding more layers to a system that already has way too much accidental complexity.

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.

> Doesn't that just defeat the whole point of devops?

> devops is a big waste of time

Devops is about culture, not about tooling.

Culture and tooling go together.

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 don't agree with everything you've said, but I do feel like otto is in danger of being another teetering piece on top of the base-os/virtualbox-os/vagrant(+ansible/chef/puppet)/guest-application tower, which are all leaky abstractions and all cause problems in practice and make debugging complicated. "Accidental complexity" is the right phrase.

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).

Replace DevOps with "web technologies" in general and your statement rings even more true.

I think the difference is that in the case of web technologies there are a huge number of competing products: we've had everything from CGI to ColdFusion to PHP to Ruby on Rails to Node.js and we are always learning from what people got right and wrong in the past.

By "web technologies" do you mean all the abstractions away from pages using HTML, CSS and JavaScript if requried?

IMO, DevOps should not be afraid of reinventing their own wheels. The closer you are to the service layer you don't actually manage, the better. i.e. if you use public cloud you should really make use of the APIs and build your own wheels. But of course, use existing tools to do your job first, and slowly create your new wheels. Overtime, the new wheels will function better because they can fit your ever-changing requirements.

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.

I played with logstash for a day or two, and it looked quite neat, but again, nothing that couldn't be accomplished in a small Perl script.

It is nice to the point you have really sit down sweat through the filters and plugins. The documentation is really horrible. A lot of Internet digging and GitHub source code digging...

'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.'

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.

> Vagrant can't talk to the mothership, it doesn't work right

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.

"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!)."

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.

Re: apt, I meant there are well documented ways to host a complete apt repo either on your own server or even offline (eg the Debian cd/dvd images are the same structure)

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"

> People are screaming out today that "devops is a big waste of time"

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.

http://xkcd.com/1579/

Given how different Otto and Vagrant are, and that Vagrant development will continue independently of Otto, I think it would be very confusing to name them the same thing.

It is bad to name different products using the same name. See gnome2 vs 3. Few would be hating on gnome3 if it wasn't named gnome.

What does Otto do that Vagrant doesn't? I mean, Vagrant is pretty good! What do I need Otto for that I can't do with Vagrant and a few scripts (that I'm likely to have to write anyway)?

Otto lets you create infra and deploy to it. So it covers production, not just development. On top of that it offers default stacks for PHP/Ruby/etc that will be maintained by the community. From what I understand, if you're demands aren't too specific, you'll profit from infra/os/apps all set up as a foundation for you app. It detects what app you have and hence you can even have an empty Appfile (similar to Vagrantfile, does more, requires less, hence the magic)

I dunno, I have yet to find a real-world situation where the demands/requirements aren't "too specific". There are always obnoxious little kinks unless you are using some tool from scratch as the basis of your entire operation. Particularly in production!

And I don't see why we need default stacks, don't we already have that with Vagrant? Isn't that the entire point of the Vagrant file and the setup file? You grab an image, you grab the post-setup file, and off you go? Is it really that much work to write a post-setup script to run apt-get and do some config work?

It just seems like we're reinventing the wheel, again. And again, and again. And we invent all these new tools just to go through and spend another 6 years fixing them, improving them, debugging them, cajoling others into using them, etc., instead of just improving the tools we already have.

Or perhaps I'm just in a shitty mood, I dunno. All I know is that the only reason I can use Vagrant in my professional life is PRECISELY because it's not for production deployment, and that's awesome, because it fills a very specific and needful spot that was vacant before. Why do we always have to keep expanding, cannot we not be happy with just really good tools for a really good specific purpose?

P.S. Thanks for the info.

"Why do we always have to keep expanding, cannot we not be happy with just really good tools for a really good specific purpose?"

Because that tool, along with the beer in their fridge, is for paid by VC money, who needs to recoup their investment. $99 Vagrant licenses for use with VMware isn't going to cut it.

True, but to be clear, Vagrant can also cover production.

https://docs.vagrantup.com/v2/push

The project's Getting Started guide does a really good job at answering that question: https://ottoproject.io/intro/getting-started/install.html

ftrtggt4

Reply on news.ycombinator.com