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.<p>I want to just give a few key notes, though many other folks around here are right.<p>* For Otto 0.1, we focused on developer experience. We don't recommend deploying for anything more than demos. Future versions of Otto _are_ going to make this production-ready though, and we already have plans in place to do so.<p>* As others have discovered, Otto is built on top of our other tools and executes them under the hood. We didn't reinvent the wheel, and this has huge benefits. We're dedicated to making all our tools better, and as we do, Otto naturally improves as well.<p>* Otto is a lot of magic, we're not trying to hide that. It is a magical tool. But we also give you access to the details (OS, memory, etc.) using "customizations." We'll improve customizations and increase the number of knobs over time.<p>* Vagrant development will continue, we have some major Vagrant releases planned. Please see this page for more info: <a href="https://ottoproject.io/intro/vagrant-successor.html" rel="nofollow">https://ottoproject.io/intro/vagrant-successor.html</a><p>* Remember that Otto is 0.1 today and Vagrant is 6 years old. We have a long way to go to reach the maturity and toughness of Vagrant. We're committed to make that happen, but it will take time.<p>Thanks everyone, sorry for not being able to be more active in here. Have a great day!
I'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.<p>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.<p>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.
Key takeaways for me:<p>- __Right now__, Otto appears to be Vagrant++. I wouldn't use this for prod, at least not for a while.<p>- Otto is written in Go. Source is here: <a href="https://github.com/hashicorp/otto" rel="nofollow">https://github.com/hashicorp/otto</a><p>- Otto uses a plugin model for different applications. Plugins aren't supported yet. <a href="https://ottoproject.io/docs/plugins/app.html" rel="nofollow">https://ottoproject.io/docs/plugins/app.html</a><p>- Built in plugins don't appear to be consuming a sane plugin interface. How the built-in plugins work is non-obvious.<p>- Under the hood, Otto appears to be using Packer, Terraform, and Vagrant.<p>- I would consider Otto, Nomad, and Terraform to all be "provisioner tools". They seem to be all directly related to tools such as Ansible provisioning, Chef provisioning, Fog, or other direct management tooling, like the AWS CLI or Powershell CLI for VMWare.<p>- Otto, Nomad, and Terraform all promise to solve the same problem in prod in different ways:<p>-- Otto is a one-off push to set up infrastructure and deploy to prod.<p>-- Nomad is for pushing jobs to help maintain long standing infrastructure in prod.<p>-- Terraform is for periodic pushes to prod to create idemopotent infrastructure.<p>In other words, from least to most robust IMO:<p>Least Robust -------> Most Robust<p>Otto --> Terraform --> Nomad
"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."<p>Sounds like a big bag of "nope."
I use Vagrant regularly for development work and it is a good tool, however, it does still have a <i>lot</i> of issues. I have also gotten the sense over the years that HashiCorp developers could have been more responsive to users and addressed more of the issues that mattered most to the user base.<p>And now, with a new, complex, and broad product introduced...I just don't have a lot of confidence that the quality is going to be there or that it will ever fulfill the very large goals that are outlined.<p>I would prefer they focused on Vagrant and made it a really outstanding, polished tool.
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"?<p>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 enough that it has become one of the two or three preferred tools for building local environments for developers.<p>AFAIK (anecdotal evidence here, to be sure), other HashiCorp tools are nowhere near as dominant. So is the tagline just to try to get more people interested in the tool?<p>It wouldn't sound as interesting to _me_ if it were "Otto, something like Heroku but a Go app that uses a bunch of HashiCorp products to deploy apps locally and in the cloud".
I'm kind of glad to see this, as I wrote <a href="https://github.com/mpdehaan/strider" rel="nofollow">https://github.com/mpdehaan/strider</a> for the reason that Packer and Vagrant used different config files.<p>This appears to address that.<p>OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like <a href="https://github.com/mitchellh/packer/issues/409" rel="nofollow">https://github.com/mitchellh/packer/issues/409</a>
) addressed more than I want glue on top.<p>Anyway, if people want to hack on Strider, pull requests are welcome.<p>I'm not using it actively (yet), but it's a very very tiny amount of code to supply both. All the work gets done by boto.<p>Back to otto - I am curious what otto means when it says it's going to start to talk to infrastructure and means that it's going ot be more of a workflow engine that can also invoke terraform or what.<p>The DSL changes appear to maybe be a step in that direction?<p>Would probably benefit from more than one liners on the homepage, to show what is really involved more quickly.
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.
<i>All Ruby development environments look alike, all PHP development environments look alike, etc.</i><p>Did they do any user research? Doesn't feel like it based on the above statement.
I think HashiCorp did themselves somewhat of a disservice by presenting Otto as a "successor" to Vagrant. Vagrant is a great technology that solves complex problems. Otto <i>uses</i> Vagrant to solve a different set of problems.<p>Otto is designed to automate the provisioning of local dev environments and production environments. While some use Vagrant to solve this problem, it's typically an un-standardized, home-grown solution. Otto is an attempt to standardize and automate the process.<p>FULL DISCLOSURE: I've been working on a project for the last year-ish that solves the exact same problems: Easily provisioning and configuring local dev environments and finding consistent parity between dev and production environments. I'm interested to really dig in and see the differences between Otto and the project I've been working on, Nanobox. Would love some outside feedback so feel free to take a look: <a href="https://nanobox.io" rel="nofollow">https://nanobox.io</a><p>But I digress. I think Otto is less a "successor" to Vagrant, and more of a natural offshoot that solves a different problem. I don't ever see it replacing Vagrant, especially since it uses Vagrant behind the scenes.
Looks really cool, excited to see some more detail on how it actually works!<p>Why the new custom config file format? I've mostly found that these homegrown formats (logstash? nginx?) suffer from inconsistency and lack of flexibility, and don't have any obvious benefits. Why not use one of the following like other Hashicorp tools?<p>- JSON/YAML, possibly with support for templating like Ansible<p>- A Ruby DSL<p>- A limited, but well-tested and understood format like .ini files
Fails on Windows:<p><pre><code> 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.</code></pre>
So the supported environments are available at <a href="https://www.ottoproject.io/docs/apps/index.html" rel="nofollow">https://www.ottoproject.io/docs/apps/index.html</a>, and they're Go, PHP, Node.JS, Ruby, and Docker.<p>I hope Python gets added to that list as a first class environment in the future.
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.
I love Vagrant. At this point, every repo I contribute to has a Vagrantfile. I've turned dozens of coworkers onto Vagrant. That said, I am not a fan of the full Hashicorp ecosystem. Reading through the Otto site, and comments on HN, my first reaction is that my favorite tool has been selected for planned obsolescence.
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.<p>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.<p>Anyway, this sounds like an awesome "UX" - let's see how it plays out in reality.
Does this use Heroku buildpacks or do they reinvent the wheel?<p>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 instance you can use them with docker via <a href="https://github.com/progrium/buildstep" rel="nofollow">https://github.com/progrium/buildstep</a><p>It seems crazy to me that Hashicorp would try and reinvent this wheel. It's a problem that's fairly easy to do as a proof of concept, but it's the niggling details and number of combinations that can really explode.
Why not choose a name that is not already used by other project?<p>There is already a pretty popular library for android named Otto <a href="http://square.github.io/otto/" rel="nofollow">http://square.github.io/otto/</a>
"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.
If 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.
> Vagrant is a mature, healthy project that is continuing to grow every day. We are committed to supporting Vagrant for the foreseeable future and will continue to release new versions. Otto is our vision for the next generation and will be developed alongside Vagrant.<p>Yeah I agree. That's why there will be a time gap between 5 years, until Otto becomes mainstream. The eco-system of vagrant is so good that I even got it supported in my IDE ( WebStorm ). I don't plan to use Otto, before I can enjoy all the benefits of Vagrant that exist today.
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)<p>There, I will vote for this option against any other tool that claims ability to do things automagically.
I almost feel like I am in the majority here but I am insanely excited for this.<p>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.<p>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.
Otto looks great, and is probably a substantial improvement over Vagrant.<p>My biggest concern is that it still relies on VirtualBox for local dev. VirtualBox is unreliable and slow, especially its file mounting driver.<p>I'd love to see this evolve to use a different virtualization solution, maybe something based on the OS X Hypervisor Framework (ala <a href="https://github.com/mist64/xhyve" rel="nofollow">https://github.com/mist64/xhyve</a>)
If Otto's Appfile mimics Heroku's app.json file (<a href="https://devcenter.heroku.com/articles/heroku-button#creating-the-app-json-file" rel="nofollow">https://devcenter.heroku.com/articles/heroku-button#creating...</a>), that'd be a huge win to me in having more sustainable Rails open source projects.
Seems like a good start to a useful project! I'm a bit turned off by the lack of customisation options for the servers though. I would like a bit more options in terms of what gets installed and what not (I don't need Bazaar, Mercurial _AND_ git installed f.e. and I'd like nginx i.o. Apache).<p>I'll definitely be keeping an eye on the project!
Heads up blank page for docs on custom types: <a href="https://ottoproject.io/docs/apps/custom-plugin" rel="nofollow">https://ottoproject.io/docs/apps/custom-plugin</a><p>Eagerly waiting to see what goes there eventually - very exciting!<p>Also, will there be a way to create custom Infra Types?
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.
Maybe Vagrant with Docker as backend will get some love now? That is native Docker (ie on a linux host) not just a separate vm to host Docker. The fact that one can't set static ip-address using the Vagrantfile is annoying.
One thing Vagrant does right is to use a DSL. I have no idea why this has been abandoned in favor of the common error of inventing Yet Another XML/JSON/YAML/TOML/INI.
there is already go project named otto: <a href="https://github.com/robertkrimen/otto" rel="nofollow">https://github.com/robertkrimen/otto</a>
I think I'll stick with Vagrant and Ansible.<p>I'm not going to trade it for magic to be honest. Unless there is a compelling reason to do so that I'm not seeing/reading.
Wonder if this attempt will work properly with windows unlike packer and vagrant. Path issues, unreliable builds, ugh. This isn't the portability promise I expected.
It seems that my ISP is poisoning my Internet connection once again :(<p><pre><code> Error building dev environment: Get https://checkpoint-api.hashicorp
.com/v1/check/vagrant?arch=amd64&os=linux&signature=&version=: x509:
certificate is valid for www.example.com, not checkpoint-api.hashicorp.com
https://checkpoint-api.hashicorp.com/v1/check/packer
?arch=amd64&os=linux&signature=&version=</code></pre>
"The creators of Otto are also the creators of Vagrant. After working on Vagrant for over six years, we've learned a lot and we believe Otto is a superior tool for development plus so much more." - another successful project written on Go! Nice!