Live data from Hacker News

Otto, the successor to Vagrant

hashicorp.com

181–185 of 185 posts

Re: Otto, the successor to Vagrant

#181

Earlier quoted context omitted.

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

Re: apt, I meant there are well documented ways to host a complete apt repo either on your own server or even offline (eg the Debian cd/dvd images are the same structure)

Thanks for the references - I did find a reference to an environment variable in the vagrant source somewhere so maybe it can work reasonably well with a private reverse engineered "atlas"

Re: Otto, the successor to Vagrant

#183

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…

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

I played with logstash for a day or two, and it looked quite neat, but again, nothing that couldn't be accomplished in a small Perl script.

Re: Otto, the successor to Vagrant

#184
post #183

Earlier quoted context omitted.

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

I played with logstash for a day or two, and it looked quite neat, but again, nothing that couldn't be accomplished in a small Perl script.

It is nice to the point you have really sit down sweat through the filters and plugins. The documentation is really horrible. A lot of Internet digging and GitHub source code digging...

Re: Otto, the successor to Vagrant

#185

Earlier quoted context omitted.

> 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 "abandonin…

> it would be extremely confusing if Otto was called Vagrant 2.0 But that is the closest thing anyone thinks of when you say "successor." Then having to explain that it's not a successor, well, you've done it yourself.

Windows was the successor to DOS, built on DOS. Maybe this is like that?!
Post reply on HN