Really nice to see it. Me and my co-worker had this feeling of needing something like OTTO when first using vagrant... I remember saying that it should definitely be a product. We ended up writing a python script for our user case that makes life really easy for new developers joining us.
Otto, the successor to Vagrant
81–90 of 185 posts
Re: Otto, the successor to Vagrant
#82So the supported environments are available at https://www.ottoproject.io/docs/apps/index.html, and they're Go, PHP, Node.JS, Ruby, and Docker.
I hope Python gets added to that list as a first class environment in the future.
Re: Otto, the successor to Vagrant
#83Hello 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'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 provisioners AT ALL when you are trying to burn an image? Doesn't that just defeat the whole point of devops?
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. 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.
Re: Otto, the successor to Vagrant
#84I'm not sure if I find it astonishing or expected that somebody finds all that magic good enough to both build that tool and to be thrilled about somebody did. I, for one, find it absolutely unacceptable. The whole point of virtual containers is to have development environment closely resembling production one (not entirely possible, but better than nothing). Your promise that your tool gives me "best possible environment for Python web-app" isn't enough for me, not even close. In fact, I don't really care what you consider "best possible environment", because I already know that there isn't one and I have experienced multiple times these unpleasant moments when you find out that for your app it actually matters if you use Amazon S3 or GlusterFS on real hardware, how many nodes there are, what are exact settings in php.ini or something else you'd be glad not to care for, but you suddenly do care. I don't need magic software, I don't want magic software, I don't like magic software, I'm afraid of it. I really struggle to imagine somebody who isn't a total newcomer and feels otherwise, but apparently there are such people.
What I ideally want is virtual machine based (like vagrant), immutable configuration (like NixOS) approach, with reasonably simple configuration (like docker+fig) and file-based settings (as opposed to docker, where your image is pretty much separate from Dockerfile) with 1 common repo for your "best possible environment" config examples, where every somewhat important decision is explicitly listed and can be changed by user. So something similar (in some sense) to vim-pathogen: git clone, maybe run some other magic command and your env is up and running in several minutes. If contents of config get changed, so does virtual machine.
I understand that what I'd like to have is a bit utopical in today's reality. But nevertheless, Otto is pretty much opposite of what I consider perfect — I cannot imagine anything farther from desirable than that.
Re: Otto, the successor to Vagrant
#85Never used Vagrant that much. How does Vagrant/Otto compare to Docker/Docker Compose/Docker Swarm?
Re: Otto, the successor to Vagrant
#86If I understand correctly, this is actually a bridge between several existing Hashicorp tools like Vagrant, Terraform and Consul (as hinted in "What is Otto?") integrated into a one-stop solution.
Its an abstraction layer that uses them behind the scenes. If it can avoid being a leaky abstraction, it could move away from the current underlying tools to future tools and built-in functionality in the future.
Re: Otto, the successor to Vagrant
#87"Notice that the Appfile makes no mention of OS, memory, disk space, etc. Otto has built-in knowledge of best practices and picks smart defaults for you." Sounds like a big bag of "nope."
Note that it appears that the Appfile can (or will be able to before a 1.0 release, at any rate; the documentation is incomplete and not entirely consistent and its not clear if how to do this is just not documented or not yet present) specify these things, but the intent to is to provide basic defaults so that the "get something minimally working" workflow is as simple as possible.
Re: Otto, the successor to Vagrant
#88Earlier 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?
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…
> Doesn't that just defeat the whole point of devops?
> devops is a big waste of time
Devops is about culture, not about tooling.
Re: Otto, the successor to Vagrant
#89Fails on Windows:
the following errors and try again:
vm:
* The host path of the shared folder is missing: C:Projectsotto-playground
* The host path of the shared folder is missing: C:Projectsotto-playground.ottompiledppoundation-consulpp-dev
Error building dev environment: Error executing Vagrant: exit status 1
The error messages from Vagrant are usually very informative.
Please read it carefully and fix any issues it mentions. If
the message isn't clear, please report this to the Otto project.Re: Otto, the successor to Vagrant
#90yezsutexryckjg