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

151–160 of 185 posts

Re: Otto, the successor to Vagrant

#151

Post by r0s »

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.

You mean like an in-house metal server? Well because I need to adjust resources on the fly sometimes, or experiment with different configurations, or test upgrades on my own.

That's why you use a virtual machine.

If you're wondering why to use a scripted provisioning system, it's to have that code under version control and shared between developers.

Re: Otto, the successor to Vagrant

#152

Post by akurtzhs »

andybak wrote: post #138
XorNot wrote: post #123

Earlier quoted context omitted.

Actually I'd love to be able to drop down to Python in my ansible playbooks/configs but ansible modules are very different to yaml/template files for the effort.

I have some misgivings about Ansible's fundamental design choices. It's main claim to fame seems to be that it sucks less than Puppet and Chef. I used to really enjoy using Fabric. I only ever tolerated Ansible. I wonder if building on Fabric might have resulted in a better devops tool than Ansible provides.

For smaller setups, I've been very happy with Fabric and the declarative configuration addon Fabtools - https://github.com/ronnix/fabtools

Re: Otto, the successor to Vagrant

#153

Post by randx838 »

dragonwriter wrote: post #73
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?

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

Re: Otto, the successor to Vagrant

#154

Post by nacho2sweet »

"If your application depends on other services (such as a database), it'll automatically configure and start those services in your development environment for you." -- Can you guys setup some tutorials that show this? Like you have a set of instructions for a Rails AWS deploy, but it would be nice to see like how to setup postgres etc with the dependencies.

Re: Otto, the successor to Vagrant

#155

Post by geerlingguy »

Cacti wrote: post #126
geerlingguy wrote: post #80

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…

I think you've pointed out exactly the reason why this product exists.

Yes, but I was making the point that the tagline under which this news story was released ("Otto, the successor to Vagrant") makes it sound as if Vagrant is no longer going to be supported, or as if Otto will focus on local development environments, something like that.

In reality, it seems the "successor to Vagrant" line is more to attract attention, as it's not at all a _replacement_ for Vagrant, just a tool you can glom on top of Vagrant and a bunch of other HashiCorp tools.

Re: Otto, the successor to Vagrant

#156

Post by lazzlazzlazz »

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?

Given how different Otto and Vagrant are, and that Vagrant development will continue independently of Otto, I think it would be very confusing to name them the same thing.

Re: Otto, the successor to Vagrant

#159

Post by cfthrowaway »

jacques_chester wrote: post #148
bryanlarsen wrote: post #8

Does this use Heroku buildpacks or do they reinvent the wheel? Edit: Otto appears to do a lot of things. But the part that everybody's complaining about is the "magic" part, the part that sets up a system automatically based on the language of the app. Heroku buildpacks also perform this magic, and have been open sourced and have a large community that helps maintain them. They're useful outside of Heroku -- for inst…

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.

Re: Otto, the successor to Vagrant

#160

Post by [deleted] »

jacques_chester wrote: post #148
bryanlarsen wrote: post #8

Does this use Heroku buildpacks or do they reinvent the wheel? Edit: Otto appears to do a lot of things. But the part that everybody's complaining about is the "magic" part, the part that sets up a system automatically based on the language of the app. Heroku buildpacks also perform this magic, and have been open sourced and have a large community that helps maintain them. They're useful outside of Heroku -- for inst…

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…

[deleted]
Post reply on HN