Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Otto, the successor to Vagrant

hashicorp.com

Post reply on HN
Print view View original

71–80 of 185 posts

Re: Otto, the successor to Vagrant

#71

Post by ChuckMcM »

divan wrote: post #57
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?

Otto uses Vagrant under the hood.

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.

Re: Otto, the successor to Vagrant

#73

Post by dragonwriter »

ChuckMcM wrote: post #56
mitchellh wrote: post #43

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…

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?

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

Re: Otto, the successor to Vagrant

#74

Post by Revell »

Seems like a good start to a useful project! I'm a bit turned off by the lack of customisation options for the servers though. I would like a bit more options in terms of what gets installed and what not (I don't need Bazaar, Mercurial _AND_ git installed f.e. and I'd like nginx i.o. Apache).

I'll definitely be keeping an eye on the project!

Re: Otto, the successor to Vagrant

#75

Post by scoates »

kaonashi wrote: post #55
abrahamepton wrote: post #48

Earlier quoted context omitted.

I think that's why they're defaults? Not hardcoded unchangeable values?

Everything having a default is sometimes not sensible. In such cases, explicit and declarative is much better than implicit and hidden.

Indeed. Sometimes it's worth making people do a little bit of extra work so that they can actually start to grok a system.

A little (but not quite) like this: https://github.com/eggheads/eggdrop-1.8/blob/master/eggdrop....

Re: Otto, the successor to Vagrant

#76

Post by verbin217 »

ChuckMcM wrote: post #71
divan wrote: post #57

Earlier quoted context omitted.

Otto uses Vagrant under the hood.

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

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

Re: Otto, the successor to Vagrant

#77

Post by dragonwriter »

wesleytodd wrote: post #18

So I feel like the reason I like Vagrant is because it does it's one job well, then gets out of my way. Doesn't sound like this shares that philosophy.

> So I feel like the reason I like Vagrant is because it does it's one job well, then gets out of my way. Doesn't sound like this shares that philosophy.

Seems to me it might, if you view its "one job" as coordinating a bunch of lower level tools that each do their own "one job".

Well, and assuming it does it well.

Re: Otto, the successor to Vagrant

#78

Post by skorecky »

endriju wrote: post #62
skorecky wrote: post #51

Earlier quoted context omitted.

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.

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.

Re: Otto, the successor to Vagrant

#79

Post by sanderjd »

skorecky wrote: post #50
whalesalad wrote: post #42

Earlier quoted context omitted.

Have you ever dealt with a large app deployment on Heroku? Unless you're willing to throw money at the problem it sucks.

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 the easy-start and but-scales-as-needed stories, and inevitably find people saying it's actually one or the other.

Re: Otto, the successor to Vagrant

#80

Post by geerlingguy »

Seeing that it uses Vagrant behind the scenes, and other HashiCorp tools as well (meaning it does things beyond just local development environment configuration... which is what 99% of people use Vagrant for), how is Otto "the successor to Vagrant"?

To me, it seems like it's just a bit of word play to try to get more interest in a product that is less interesting to some people. Vagrant is generic enough and helpful enough that it has become one of the two or three preferred tools for building local environments for developers.

AFAIK (anecdotal evidence here, to be sure), other HashiCorp tools are nowhere near as dominant. So is the tagline just to try to get more people interested in the tool?

It wouldn't sound as interesting to _me_ if it were "Otto, something like Heroku but a Go app that uses a bunch of HashiCorp products to deploy apps locally and in the cloud".

Post reply on HN