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

171–180 of 185 posts

Re: Otto, the successor to Vagrant

#171

Post by buster »

Walkman wrote: 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.

Which tells me that you never worked on a platform with multiple servers and complex network and storage situation. Atleast not for a few years when your infrastructure bitrots away and you're fighting to keep it all together most of the time. But by then you're used to the mess. No big deal.

Re: Otto, the successor to Vagrant

#172

Post by mhoad »

I almost feel like I am in the majority here but I am insanely excited for this.

It is precisely what I have wanted for a long time and the ability to customize and override defaults where wanted seems to handle most of the complaints that people in this thread are mentioning.

I don't think I can underestimate just how much I don't want to have to stay up to date with all the various best practices for deployments. I have zero interest in that and it is currently a fairly expensive problem to fix for many.

Re: Otto, the successor to Vagrant

#173

Post by jacques_chester »

cfthrowaway wrote: post #159
jacques_chester wrote: post #148

Earlier quoted context omitted.

I've worked on Cloud Foundry buildpacks team. Several of Cloud Foundry's default are downstream from Heroku (Ruby, Python, NodeJS) and several aren't (Java, Go, PHP). Heroku's buildpacks are open, but they build them for their own purposes. In particular a large part of my work involved recreating behaviours added to support this or that Heroku change (particularly STACK, god what a mess that was), dealing with binar…

It's interesting you say that, because Cloud Foundry recently built a requirement for the environment that runs in their Warden containers ( https://github.com/cloudfoundry/stacks ) into their buildpacks, which caused applications on CF distributions that used other stacks to break when using their buildpacks.

I was partly responsible for that work. We did it for the same reason as Heroku: Ubuntu 10.04 passed out of LTS.

CF buildpacks explicitly state which binaries should be used with which stack in the manifest.yml file. If you had a breakage, feel free to report it on the relevant github repo.

Re: Otto, the successor to Vagrant

#174

Post by stephenr »

parasubvert wrote: post #127
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…

'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 work…

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

Re: Otto, the successor to Vagrant

#176

Post by happywolf »

Real world has taught me 'magic' only works in some specific cases and mine usually isn't one of those. That is why anything that claims to be smart gets to my nerve. Instead, I prefer tools that are clearly scoped, do their own scope extremely well, and designed to complement each and work well together, AND with good documentations. Yes, Unix command line tools are good examples (except not all have good docs though)

There, I will vote for this option against any other tool that claims ability to do things automagically.

Re: Otto, the successor to Vagrant

#177

Post by timthelion »

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

Re: Otto, the successor to Vagrant

#178

Post by solusipse »

skorecky wrote: post #47
solusipse wrote: post #30

there is already go project named otto: https://github.com/robertkrimen/otto

Last commit a year ago. Unless you trademark a name or at least has active development I don't see anything wrong with using the name.

nothing wrong with one year last commit when project's pretty mature

Re: Otto, the successor to Vagrant

#180

Post by parasubvert »

stephenr wrote: post #174
parasubvert wrote: post #127

Earlier quoted context omitted.

'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 work…

> 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/ac…

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

Post reply on HN