Live data from Hacker News

Otto, the successor to Vagrant

hashicorp.com

91–100 of 185 posts

Re: Otto, the successor to Vagrant

#92

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 anyt…

ftrtggt4

Re: Otto, the successor to Vagrant

#93

Fails on Windows: the following errors and try again: vm: * The host path of the shared folder is missing: C:Projectsotto-playground * The host path of the shared folder is missing: C:Projectsotto-playground.ottompiledppoundation-consulpp-dev Error building dev environment: Error executing Vagrant: exit status 1 The error messages from Vagrant are usually very informative. Please read it carefully and fix any issues…

Easy to reproduce, latest everything: otto, Vagrant, VirtualBox

Re: Otto, the successor to Vagrant

#94
I don't understand why so many people are so scared/not interested/afraid of system administration. It's not that hard. Why does it have to be abstracted? Bringing more and more layers makes everything slower, more complex for sure. The only thing is really hard is configuring and managing an email server.

Re: Otto, the successor to Vagrant

#95

Earlier quoted context omitted.

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 provisi…

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

Re: Otto, the successor to Vagrant

#96
I love Vagrant. At this point, every repo I contribute to has a Vagrantfile. I've turned dozens of coworkers onto Vagrant. That said, I am not a fan of the full Hashicorp ecosystem. Reading through the Otto site, and comments on HN, my first reaction is that my favorite tool has been selected for planned obsolescence.

Re: Otto, the successor to Vagrant

#97

Earlier quoted context omitted.

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?

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 provisi…

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

Re: Otto, the successor to Vagrant

#98

Key takeaways for me: - __Right now__, Otto appears to be Vagrant++. I wouldn't use this for prod, at least not for a while. - Otto is written in Go. Source is here: https://github.com/hashicorp/otto - Otto uses a plugin model for different applications. Plugins aren't supported yet. https://ottoproject.io/docs/plugins/app.html - Built in plugins don't appear to be consuming a sane plugin interface. How the built-in…

I think the Terraform/Nomad/Otto hierarchy is supposed to be like this:

  - Terraform defines that you have X servers with certain specs.    
  - Otto defines that those servers are running Docker or whatever.    
  - Nomad defines that your application is running in X containers in your infrastructure.
So, it's a layered approach (Infrastructure -> System -> Application), akin to the layers of your network. Each one is isolated enough to not worry about the others. At least, that's how I'm hoping this all shakes out :)

Re: Otto, the successor to Vagrant

#99
It seems that my ISP is poisoning my Internet connection once again :(

    Error building dev environment: Get https://checkpoint-api.hashicorp
    .com/v1/check/vagrant?arch=amd64&os=linux&signature=&version=: x509:
    certificate is valid for www.example.com, not checkpoint-api.hashicorp.com
    https://checkpoint-api.hashicorp.com/v1/check/packer
    ?arch=amd64&os=linux&signature=&version=

Re: Otto, the successor to Vagrant

#100
post #94

I don't understand why so many people are so scared/not interested/afraid of system administration. It's not that hard. Why does it have to be abstracted? Bringing more and more layers makes everything slower, more complex for sure. The only thing is really hard is configuring and managing an email server.

I agree, in spirit. Setting up an app server, a web server, a MySQL database, or a cron job is pretty easy once you get the hang of it. There are a lot of complex sysadmin tasks -- running a BIND server, an email server, a Cassandra cluster, etc. -- but that's not what the majority of developers are doing.
Post reply on HN