Otto, the successor to Vagrant • Hacker News Board

Re: Otto, the successor to Vagrant

#161

Post by dlandis » Tue, Sep 29, 2015, 4:39 AM UTC

kbenson wrote: post #131

dlandis wrote: post #122

I use Vagrant regularly for development work and it is a good tool, however, it does still have a lot of issues. I have also gotten the sense over the years that HashiCorp developers could have been more responsive to users and addressed more of the issues that mattered most to the user base. And now, with a new, complex, and broad product introduced...I just don't have a lot of confidence that the quality is going t…

Maybe they thought the best path to a really outstanding, polished tool was to approach the problem slightly differently and Otto is their solution? If that's the case (I really have no idea), maybe rather than devoting too much time to fixing vagrant they decided to limit the time spent on that to further what they thought is a better overall solution?

Yeah unfortunately I think it's more about tackling entirely new problems in addition to the problems Vagrant already solves.

Re: Otto, the successor to Vagrant

#162

Post by rubiquity » Tue, Sep 29, 2015, 5:14 AM UTC

huslage wrote: post #147

rubiquity wrote: post #49

Earlier quoted context omitted.

Do you mind backing up your opinions? Vagrant is a very widely used and beloved tool. edit: I just noticed your profile indicates that you work at Docker, Inc. I'm trying to figure out whether I feel that plays into your opinion or not but I would expect a bit more professionalism at least.

No this isn't Docker speaking. This is me. I've always felt that Vagrant was a solution in search of a problem and no being at Docker hasn't changed that either way. I have colleagues that love Vagrant and they are certainly entitled to that opinion, as much as I'm entitled to think that it's horrible. I honestly haven't seen any value brought from Vagrant or its ilk to anyone. There is temporary relief from some ver…

> Configuration files as infrastructure aren't particularly interesting to me.

How is this any different than a Dockerfile? Vagrantfile is certainly more abstract I guess.

Re: Otto, the successor to Vagrant

#163

Post by pron » Tue, Sep 29, 2015, 5:19 AM UTC

PaulHoule wrote: post #83

ChuckMcM wrote: post #56

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…

http://xkcd.com/1579/

Re: Otto, the successor to Vagrant

#164

Post by buffoon » Tue, Sep 29, 2015, 5:58 AM UTC

tomswartz07 wrote: post #19

buffoon wrote: post #13

Wonder if this attempt will work properly with windows unlike packer and vagrant. Path issues, unreliable builds, ugh. This isn't the portability promise I expected.

Strange. What issues were you having? We've been using Packer and Vagrant with Windows builds for the better part of a year now and it's been rock solid. We actually leverage it into our Windows Deployment Server to create automatically updated OS Images to be deployed to production machines.

WinRM dropouts when building images in packer, random failures that are unexplained, network not coming up in vagrant, consistency.

I've partially written my own version of it in powershell and Hyper-V now.

Re: Otto, the successor to Vagrant

#165

Post by yeukhon » Tue, Sep 29, 2015, 6:49 AM UTC

kcorbitt wrote: post #97

PaulHoule wrote: post #83

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…

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

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.

Re: Otto, the successor to Vagrant

#166

Post by tachion » Tue, Sep 29, 2015, 7:16 AM UTC

skorecky wrote: post #78

endriju wrote: post #62

Earlier quoted context omitted.

Did you try http://www.openshift.org ? The self-hosted version is basically what you described, at least for the JVM languages.

I have tried it, but just don't hold up as well as Heroku. I still use and love Heroku, but would be nice to have a similar option I could host anywhere on my terms.

So you seem to actually worry about hosting and servers, despite you saying you do not ;)

Re: Otto, the successor to Vagrant

#167

Post by vruiz » Tue, Sep 29, 2015, 7:31 AM UTC

skorecky wrote: post #51

vinceguidry wrote: post #25

Earlier quoted context omitted.

Sure, but could I compete with free?

If you or someone created something that was basically Heroku in a box that could then be hosted anywhere. I would be interested. I want to build apps, not worry about hosting and servers.

If you are talking single server solutions, then https://github.com/progrium/dokku

Re: Otto, the successor to Vagrant

#168

Post by stephenr » Tue, Sep 29, 2015, 7:49 AM UTC

corndoge wrote: post #102

kcorbitt wrote: post #97

Earlier quoted context omitted.

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

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

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

Re: Otto, the successor to Vagrant

#169

Post by derefr » Tue, Sep 29, 2015, 8:13 AM UTC

krick wrote: post #84

I'm not sure if I find it astonishing or expected that somebody finds all that magic good enough to both build that tool and to be thrilled about somebody did. I, for one, find it absolutely unacceptable. The whole point of virtual containers is to have development environment closely resembling production one (not entirely possible, but better than nothing). Your promise that your tool gives me "best possible enviro…

> it actually matters if you use Amazon S3 or GlusterFS on real hardware, how many nodes there are, what are exact settings in php.ini or something else you'd be glad not to care for, but you suddenly do care

It actually matters... at scale. No project starts at scale. Most projects never need to scale; most projects die before they scale.

Magic software is for prototyping. Sensible defaults and convention-over-configuration mean trying (and failing, and trying again), quicker. Even though I have software in production with a million users, I still code new my new experimental projects on Heroku, because relying on "magic software" is one barrier less in the way of getting to work. (Not a technical barrier, mind you; a barrier of choice paralysis about what my architecture is going to look like.)

At scale, meanwhile, you have a separate thing, a magic piece of strong-AI-equivalent software called a "dedicated ops team." When you get there, the task of refactoring your idiotic prototyping decisions becomes their (hopefully-well-paid) problem.

Re: Otto, the successor to Vagrant

#170

Post by derefr » Tue, Sep 29, 2015, 8:20 AM UTC

sanderjd wrote: post #79

skorecky wrote: post #50

Earlier quoted context omitted.

Yes and if you're a small team with limited resources and you don't have an operations person/team throwing money at the problem works. There will come a time when you will need to setup a more customized hosting solution but hopefully by then you can hire someone to do operations that knows what they are doing. I don't think Heroku or Otto are designed for big projects anyways, they're a great way to get up and runn…

> I don't think Heroku or Otto are designed for big projects anyways. If you're right about that in Otto's case, that's a bummer. It's frustrating that there is this seemingly intractable divide between things that are great to start with for a new project (Heroku, etc.) and things that scale well as a project grows huge (Kubernetes, etc.). Every time a devops tool comes out, I read about it in hopes that it has both…

A Heroku-like PaaS layer that serves as a manager for—but crucially, doesn't attempt to abstract away—a set of IaaS components would be interesting. Sort of a convention-over-configuration CLI tool for interacting with some CloudFormation-like API.

The "non-abstraction" part doesn't seem to be in any cloud provider's interest to sell, though; even with AWS, when you allocate a database, it doesn't result in a new EC2 instance for the DB being dropped into your bag of instances, such that you just get charged instance fees for the instance. Instead, it all gets packaged up so that you can be charged higher, separate, value-based database fees. It's a bit ridiculous.