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

61–70 of 185 posts

Re: Otto, the successor to Vagrant

#61

Post by ichilton »

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?

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

Re: Otto, the successor to Vagrant

#62

Post by endriju »

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.

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

Re: Otto, the successor to Vagrant

#64

Post by coldtea »

beberlei wrote: post #44
brudgers wrote: post #17

Earlier quoted context omitted.

Mitchell Hashimoto has been supporting Vagrant users for several years now. I wouldn't be surprised if that experience has led him to such a conclusion in regards to the use of Vagrant, e.g. all uses have dependency on a version of Ruby/PHP and some versions of some number of libraries and so on. The same abstractions allow control despite differences at a finer grain.

The number of variations on PHP applications are infinite: 1. Apache or Nginx+PHP-FPM 2. INI Configuration 3. PHP Extensions and their INI configuration 4. Vhost Configuration, especially rewriting rules 5. Docroot in app root, or dedicated directory This cant possible be defined in a common/generic way and supporting more than 50% of the use-cases. There is a reason why complex click to configure interfaces exist fo…

Doesn't matter. There's always the 80/20 rule. It doesn't have to catter to any and all exotic need. One could always customize further (even script that) after Otto's initialization.

Besides a lot of this variety is because people don't follow best practices, and instead have a hodgepodge of this and that technologies, with this and that settings.

Re: Otto, the successor to Vagrant

#65

Post by justizin »

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.

This addresses a bigger picture that some folks have been (ab)using vagrant to accomplish and requesting features that belonged in a new project, rather than on top of vagrant.

Re: Otto, the successor to Vagrant

#67

Post by discordianfish »

I love the idea in general and especially using git urls as dependencies and use the Appfile from their repos to bring those services (and their dependencies). That keeps ownership to the people best know about it (the developers of a given service) instead of have that centralized. But all this sounds very ambious.

I'm especially curious how to configure dependencies. You might need to creating tables in a database which is setup as a dependencies, but also need to support restoring from backups or setting up replication. Beside that, some of this configuration should belong to the owner of the service using the db (db names etc), other to the owner of the db (global server settings, limits etc). To add to that, some configuration needs to happen at runtime, so you can't just update the Appfile.

Anyway, this sounds like an awesome "UX" - let's see how it plays out in reality.

Re: Otto, the successor to Vagrant

#68

Post by joesmo »

huslage wrote: post #45

Otto is adding stupid to stupid. Vagrant is a pile of garbage and Otto is adding more junk to that garbage. Who cares.

I agree. Last time I used it in mid 2014, it was unusable. I spent more time trying to fix and work around its bugs than I would have building a VM from scratch, so eventually I gave up and went back to my plain VM. It's great for trying stuff out, but anything that needs to work for more than one session was extremely problematic with a lot of networking problems that required destroying the VM and rebuilding it constantly.

Re: Otto, the successor to Vagrant

#70

Post by antod »

mpdehaan2 wrote: post #23

I'm kind of glad to see this, as I wrote https://github.com/mpdehaan/strider for the reason that Packer and Vagrant used different config files. This appears to address that. OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like https://github.com/mitchellh/packer/issues/409 ) addressed more than I want glue on top. Anyway, if people want to hac…

> OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like https://github.com/mitchellh/packer/issues/409 ) addressed more than I want glue on top.

Ahhhh that Packer issue. I have been following that one for what seems like years too.

Post reply on HN