12 ms·

Otto, the successor to Vagrant

772 points by agonzalezro 11y ago

bovermyer 11y ago
There's a lot of magic here. I'd love to know what's going on beneath the hood.
- davexunit 11y ago
  That magic will surely prove to be problematic. I see lots of potential issues. It automatically installs other Hashicorp tools, presumably outside of your system's package manager, which means that it is a package manager in addition to whatever else it does. Where does it install software? How does it verify integrity? Does it build from source or use pre-built binaries? If they are pre-built binaries, how do I get the corresponding source code and build scripts? Does it bundle all other dependencies? How do I make sure I get security patches for the whole dependency tree? I don't expect that Hashicorp would have satisfactory answers to all these questions. Furthermore, automatic dependency installation sounds like it will make reproducibility difficult, and I imagine automatic application type detection will fail in spectacular ways. What happens when the magic doesn't work? The Appfile looks like yet another ad-hoc domain specific language that you need to learn that has the usual major deficiencies compared with using an existing general purpose programming language.
vezzy-fnord 11y ago
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.
- dragonwriter 11y ago
  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.
vinceguidry 11y ago
Wow, there goes my business idea. Kudos.
- rco8786 11y ago
  Why? If someone else is doing it that probably means there is a market for it.
  - vinceguidry 11y ago
    Sure, but could I compete with free?
    - danesparza 11y ago
      Yes. Especially if you have a good tool that you pair with 'paid for' consulting. Consider RedHat or Canonical (among others).
    - skorecky 11y ago
      If you or someone created something that was basically Heroku in a box that could then be hosted anywhere. I would be interested. I want to build apps, not worry about hosting and servers.
      - endriju 11y ago
        Did you try http://www.openshift.org http://www.openshift.org? The self-hosted version is basically what you described, at least for the JVM languages.
        skorecky 11y ago
        I have tried it, but just don't hold up as well as Heroku. I still use and love Heroku, but would be nice to have a similar option I could host anywhere on my terms.
        11y ago
cyber1 11y ago
"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!
ldpg 11y ago
Heads up blank page for docs on custom types: https://ottoproject.io/docs/apps/custom-plugin https://ottoproject.io/docs/apps/custom-plugin Eagerly waiting to see what goes there eventually - very exciting! Also, will there be a way to create custom Infra Types?
bryanlarsen 11y ago
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 instance you can use them with docker via https://github.com/progrium/buildstep https://github.com/progrium/buildstep 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.
- ldpg 11y ago
  In that analogy Heroku buildpacks are more like the boot the police put on your car.
- jacques_chester 11y ago
  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 binaries being silently substituted, the messy statefulness of their staging architecture. Oh, and most importantly, we made it all work in a disconnected environment. Which Heroku never intended. Speaking individually, not as a Pivot, if you didn't have to, I wouldn't recommend starting with Heroku's buildpacks. They solve a lot of problems, but no small part is solving Heroku's problems.
  - cfthrowaway 11y ago
    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 https://github.com/cloudfoundry/stacks) into their buildpacks, which caused applications on CF distributions that used other stacks to break when using their buildpacks.
LukeB_UK 11y ago
All Ruby development environments look alike, all PHP development environments look alike, etc. Did they do any user research? Doesn't feel like it based on the above statement.
- Kiro 11y ago
  What do you mean? How is the statement false?
  - mrrsm 11y ago
    As far as looking alike goes I think it could end with uses Ruby or uses PHP. A lot of modules will differ for different use cases. I may not need any of the modules another user needs.
    - cleverjake 11y ago
      nothing about mentions installing modules for you. This is about the environment, not the actual project
      - Carrok 11y ago
        PHP/Apache modules, which are very much environment based.
  - vidarh 11y ago
    Ruby: MRI vs. REE vs jRuby vs Rubinius, for starters. And this choice is solved through a variety of mechanisms that people rely on for other parts of their infrastructure, and feel strongly about. For my part, this is also a solution that is way too late: We have Docker/Rocket and a range of similar tools. Why do it yet another way, when if you instead build a Docker image, you can take that Docker image and deploy it without having to translate your dependencies to a different format and re-test everything?
    - brudgers 11y ago
guelo 11y ago
Unfortunate name, there's a popular Java open source library called Otto.
- cleverjake 11y ago
  There are a lot of things called otto - https://github.com/search?q=otto&type=Repositories https://github.com/search?q=otto&type=Repositories doesn't mean its a bad name
  - mikehc 11y ago
    Yeah, but look at the number of stars and forks. Square's Otto is a pretty popular library. Side note: I don't know why someone is down voting people saying this. I mean yeah they will not change their name I guess but it should be bad for the next big project to choose a name that is not taken by a popular project already.
buffoon 11y ago
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.
- tomswartz07 11y ago
  Strange. What issues were you having? We've been using Packer and Vagrant with Windows builds for the better part of a year now and it's been rock solid. We actually leverage it into our Windows Deployment Server to create automatically updated OS Images to be deployed to production machines.
  - buffoon 11y ago
    WinRM dropouts when building images in packer, random failures that are unexplained, network not coming up in vagrant, consistency. I've partially written my own version of it in powershell and Hyper-V now.
wesleytodd 11y ago
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.
- justizin 11y ago
  This addresses a bigger picture that some folks have been (ab)using vagrant to accomplish and requesting features that belonged in a new project, rather than on top of vagrant.
  - thejerz 11y ago
    Such as?
    - mastazi 11y ago
      Such as provisioning and deployment I guess... I've seen those requests over and over.
- tptacek 11y ago
  Which is why this uses Vagrant and doesn't replace it.
- dragonwriter 11y ago
  > 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. Seems to me it might, if you view its "one job" as coordinating a bunch of lower level tools that each do their own "one job". Well, and assuming it does it well.
- Cacti 11y ago
  Probably because they did such a good job with Vagrant that they realized they were running out of things to do and decided, in the interests of job security, to ride the train a little longer by "pivoting." Then again, who am I to complain? Vagrant is a superb tool and the endless and pointless reinventing of standards every few years keeps like 70% of us employed.
robbles 11y ago
Looks really cool, excited to see some more detail on how it actually works! 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? - JSON/YAML, possibly with support for templating like Ansible - A Ruby DSL - A limited, but well-tested and understood format like .ini files
- deleted 11y ago
  [deleted]
- robbles 11y ago
  Answering my own question after looking at the code: https://github.com/hashicorp/hcl#why https://github.com/hashicorp/hcl#why It's JSON-compatible, at least (valid JSON is valid HCL).
- jweir 11y ago
  The config format looks like the same format as Terraform.
  - Perceptes 11y ago
    It's HCL. Same format used by Terraform and the just-announced Nomad.
- davexunit 11y ago
  > JSON/YAML, possibly with support for templating like Ansible When you are writing templates for your configuration files, what you've wanted all along was a real programming language.
  - acveilleux 11y ago
    Yes and no, a lot of the ops folks I know peter out at pretty basic scripting and find a templating system easier.
mpdehaan2 11y ago
I'm kind of glad to see this, as I wrote https://github.com/mpdehaan/strider https://github.com/mpdehaan/strider for the reason that Packer and Vagrant used different config files. This appears to address that. OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like https://github.com/mitchellh/packer/issues/409 https://github.com/mitchellh/packer/issues/409 ) addressed more than I want glue on top. Anyway, if people want to hack on Strider, pull requests are welcome. 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. 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. The DSL changes appear to maybe be a step in that direction? Would probably benefit from more than one liners on the homepage, to show what is really involved more quickly.
- antod 11y ago
  > OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like https://github.com/mitchellh/packer/issues/409 https://github.com/mitchellh/packer/issues/409 ) addressed more than I want glue on top. Ahhhh that Packer issue. I have been following that one for what seems like years too.
alrs 11y ago
"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."
- skorecky 11y ago
  Why? This is what I love about Heroku. I get to build the app I want without worrying about all the other aspects of hosting that make me want to never launch an app ever again. I love the idea of focusing on the development part and letting something / someone else worry about hosting.
  - whalesalad 11y ago
    Have you ever dealt with a large app deployment on Heroku? Unless you're willing to throw money at the problem it sucks.
    - skorecky 11y ago
      Yes and if you're a small team with limited resources and you don't have an operations person/team throwing money at the problem works. There will come a time when you will need to setup a more customized hosting solution but hopefully by then you can hire someone to do operations that knows what they are doing. I don't think Heroku or Otto are designed for big projects anyways, they're a great way to get up and running and help you grow without having to worry about infrastructure upfront or for a couple years.
      - sanderjd 11y ago
        > I don't think Heroku or Otto are designed for big projects anyways. If you're right about that in Otto's case, that's a bummer. It's frustrating that there is this seemingly intractable divide between things that are great to start with for a new project (Heroku, etc.) and things that scale well as a project grows huge (Kubernetes, etc.). Every time a devops tool comes out, I read about it in hopes that it has both the easy-start and but-scales-as-needed stories, and inevitably find people saying it's actually one or the other.
throwaway9851 11y ago
Key takeaways for me: - __Right now__, Otto appears to be Vagrant++. I wouldn't use this for prod, at least not for a while. - Otto is written in Go. Source is here: https://github.com/hashicorp/otto https://github.com/hashicorp/otto - Otto uses a plugin model for different applications. Plugins aren't supported yet. https://ottoproject.io/docs/plugins/app.html https://ottoproject.io/docs/plugins/app.html - Built in plugins don't appear to be consuming a sane plugin interface. How the built-in plugins work is non-obvious. - Under the hood, Otto appears to be using Packer, Terraform, and Vagrant. - 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. - Otto, Nomad, and Terraform all promise to solve the same problem in prod in different ways: -- Otto is a one-off push to set up infrastructure and deploy to prod. -- Nomad is for pushing jobs to help maintain long standing infrastructure in prod. -- Terraform is for periodic pushes to prod to create idemopotent infrastructure. In other words, from least to most robust IMO: Least Robust -------> Most Robust Otto --> Terraform --> Nomad
- timdorr 11y ago
  I think the Terraform/Nomad/Otto hierarchy is supposed to be like this: - Terraform defines that you have X servers with certain specs. - Otto defines that those servers are running Docker or whatever. - Nomad defines that your application is running in X containers in your infrastructure. So, it's a layered approach (Infrastructure -> System -> Application), akin to the layers of your network. Each one is isolated enough to not worry about the others. At least, that's how I'm hoping this all shakes out :)
solusipse 11y ago
there is already go project named otto: https://github.com/robertkrimen/otto https://github.com/robertkrimen/otto
- skorecky 11y ago
  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.
  - solusipse 11y ago
    nothing wrong with one year last commit when project's pretty mature
- makepanic 11y ago
  there's also an android event bus by square http://square.github.io/otto/ http://square.github.io/otto/
ajsharma 11y ago
If Otto's Appfile mimics Heroku's app.json file (https://devcenter.heroku.com/articles/heroku-button#creating-the-app-json-file https://devcenter.heroku.com/articles/heroku-button#creating...), that'd be a huge win to me in having more sustainable Rails open source projects.
mikehc 11y ago
Why not choose a name that is not already used by other project? There is already a pretty popular library for android named Otto http://square.github.io/otto/ http://square.github.io/otto/
- deleted 11y ago
  [deleted]
drinchev 11y ago
> 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. 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.
mitchellh 11y ago
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 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. * 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. * 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. * Vagrant development will continue, we have some major Vagrant releases planned. Please see this page for more info: https://ottoproject.io/intro/vagrant-successor.html https://ottoproject.io/intro/vagrant-successor.html * 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. Thanks everyone, sorry for not being able to be more active in here. Have a great day!
- ChuckMcM 11y ago
  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?
  - divan 11y ago
    Otto uses Vagrant under the hood.
    - vezzy-fnord 11y ago
      Indeed, which makes the tagline "successor to Vagrant" a dubious choice. It would be like referring to fleet as the successor to systemd. They're stacked layers driving existing utilities.
huslage 11y ago
Otto is adding stupid to stupid. Vagrant is a pile of garbage and Otto is adding more junk to that garbage. Who cares.
- rubiquity 11y ago
  Do you mind backing up your opinions? Vagrant is a very widely used and beloved tool. edit: I just noticed your profile indicates that you work at Docker, Inc. I'm trying to figure out whether I feel that plays into your opinion or not but I would expect a bit more professionalism at least.
  - huslage 11y ago
    No this isn't Docker speaking. This is me. I've always felt that Vagrant was a solution in search of a problem and no being at Docker hasn't changed that either way. I have colleagues that love Vagrant and they are certainly entitled to that opinion, as much as I'm entitled to think that it's horrible. I honestly haven't seen any value brought from Vagrant or its ilk to anyone. There is temporary relief from some very real problems of transmitting development environments around the place. But the tool ends up creating pets that you have to care for over long periods of time. You have to deal with entire operating systems when you really want to abstract away the OS in favor of getting some real work done. Configuration files as infrastructure aren't particularly interesting to me. I don't see how building annoying bits of configuration will fix anything in the long run. Also note that while I think the HashiCorp infrastructure-as-code attempts are quite lacking, their Consul and Vault tools are really nice. :)
    - rubiquity 11y ago
      > Configuration files as infrastructure aren't particularly interesting to me. How is this any different than a Dockerfile? Vagrantfile is certainly more abstract I guess.
- coldtea 11y ago
  Thanks for the insightful and well argued opinion.
discordianfish 11y ago
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. 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. Anyway, this sounds like an awesome "UX" - let's see how it plays out in reality.
Revell 11y ago
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). I'll definitely be keeping an eye on the project!
geerlingguy 11y ago
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 enough that it has become one of the two or three preferred tools for building local environments for developers. 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? 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".
- Cacti 11y ago
  I think you've pointed out exactly the reason why this product exists.
  - geerlingguy 11y ago
    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.
humbertomn 11y ago
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.
akurtzhs 11y ago
So the supported environments are available at https://www.ottoproject.io/docs/apps/index.html 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.
- andybak 11y ago
  I thought the omission of Python to be... strange.
  - kyllo 11y ago
    Probably punted because they couldn't decide between 2 or 3.
    - andybak 11y ago
      Do you have an axe to grind? It's not terribly hard to support both.
krick 11y ago
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. 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.
- bjwbell 11y ago
  Couldn't agree more. When I was young magic software seemed magic. Then I found out it's 10x harder to debug when it breaks.
- andybak 11y ago
  Yes - one size doesn't fit all. Yes - sometimes you need something very specific. But, please - it sounds like you've just damned us to repeat the same low-level tasks again and again. 80% of websites ARE the same. If you're in the 20% (or 10% or 1%) then good luck to you. But for those of us deploying another typical webapp - I'd really like to draw on community knowledge. I never wanted to learn devops same way as I never want to learn cryptography, oAuth, SQL internals, how nginx works etc. I just want to use tools that solve these problems for me.
temuze 11y ago
Never used Vagrant that much. How does Vagrant/Otto compare to Docker/Docker Compose/Docker Swarm?
RomanPushkin 11y ago
Fails 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.
- RomanPushkin 11y ago
  Easy to reproduce, latest everything: otto, Vagrant, VirtualBox
  - diggan 11y ago
    "Hah" says the person who is trying to reproduce this in about a month
- Jare 11y ago
  Same, despite running under Cygwin (babun).
loweja01 11y ago
yezsutexryckjg
loweja01 11y ago
Something Else!!!
Walkman 11y ago
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.
- thejerz 11y ago
  I agree, in spirit. Setting up an app server, a web server, a MySQL database, or a cron job is pretty easy once you get the hang of it. There are a lot of complex sysadmin tasks -- running a BIND server, an email server, a Cassandra cluster, etc. -- but that's not what the majority of developers are doing.
  - XorNot 11y ago
    I don't understand it, but as an SA there's also a lot of people who are incapable of thinking 5 minutes ahead to the next problem - which is also baffling because its pretty much the same as programming. You setup a cronjob, did you code the script well, who does is notify, how do we know when it fails, what's the recovery strategy?
- r0s 11y ago
  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.
- buster 11y ago
  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.
thejerz 11y ago
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.
- notacoward 11y ago
  I had sort of the same reaction. I just learned a bit of Vagrant recently. I needed something to set up a simple three-node environment for a tutorial I'm doing, and the best starting point happened to be a Vagrant project. It worked well enough that I've been thinking of other uses for it, especially as a basis for automated tests on the distributed system I work on (our current infra for that frankly sucks). Then I read this, and it doesn't look like it's a Vagrant successor in any way that's useful to me. I don't want it to try and figure out service dependencies for me, because I can absolutely guarantee that it's unable to do that for the component I care about. I don't want it fiddling with DNS. I think using the same description but different commands for dev vs. production is a terrible idea. They say Otto does application-level instead of machine-level configuration, but machine-level is what I want. They say multi-VM is too heavyweight but that's also what I want. It's opinionated in all the wrong ways. Everything in https://ottoproject.io/intro/vagrant-successor.html https://ottoproject.io/intro/vagrant-successor.html makes it clear that Otto is fundamentally different from Vagrant, which totally belies their claim (at the end) that it will replace Vagrant in any significant way. They should just come right out and say that they've created something different on top of Vagrant. Maybe it's cool, but it's not a successor. This brand hijacking just makes them seem fickle or shifty. Now I think I'll just leave Vagrant behind while my investment in it is still small, and learn one of the bazillion other tools that I could use to accomplish the same thing.
- bluehawk 11y ago
  Otto uses Vagrant under the hood. Vagrant isn't going anywhere as far as I can tell.
guessmyname 11y ago
It seems that my ISP is poisoning my Internet connection once again :( 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=
Borborygymus 11y ago
For the love of all that is holy, why do their sample code fragments have `smart' quotes in them?
jamesfisher 11y ago
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.
vellum 11y ago
Does this work on Digital Ocean droplets? Vagrant doesn't.
- cls59 11y ago
  How so? The DigitalOcean provider for Vagrant works great: https://github.com/smdahlen/vagrant-digitalocean https://github.com/smdahlen/vagrant-digitalocean
theCzar 11y ago
This seems very similar to PagodaBox's Nanobox product (https://nanobox.io/ https://nanobox.io/). What are the key differences between the two? I imagine I'll do a more thorough comparison myself later, but I was wondering if anyone else had taken a look.
dlandis 11y ago
I use Vagrant regularly for development work and it is a good tool, however, it does still have a lot 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. 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. I would prefer they focused on Vagrant and made it a really outstanding, polished tool.
- kbenson 11y ago
  Maybe they thought the best path to a really outstanding, polished tool was to approach the problem slightly differently and Otto is their solution? If that's the case (I really have no idea), maybe rather than devoting too much time to fixing vagrant they decided to limit the time spent on that to further what they thought is a better overall solution?
  - dlandis 11y ago
    Yeah unfortunately I think it's more about tackling entirely new problems in addition to the problems Vagrant already solves.
- mastazi 11y ago
  According to the blog post Otto is actually built on other tools including Vagrant (which provides the dev environments) and Terraform (which provides the infrastructure management), so I think they will keep actively developing Vagrant in the future.
allanmacgregor 11y ago
Does this mean that development focus will shift from Vagrant to Otto? Is Otto mean to replace vagrant?
- jamesgeck0 11y ago
  Maybe, eventually? But not right now. https://ottoproject.io/intro/vagrant-successor.html https://ottoproject.io/intro/vagrant-successor.html
atriix 11y ago
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.
sanderson1 11y ago
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 uses Vagrant to solve a different set of problems. 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. 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: https://nanobox.io https://nanobox.io 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.
bgentry 11y ago
Otto looks great, and is probably a substantial improvement over Vagrant. My biggest concern is that it still relies on VirtualBox for local dev. VirtualBox is unreliable and slow, especially its file mounting driver. I'd love to see this evolve to use a different virtualization solution, maybe something based on the OS X Hypervisor Framework (ala https://github.com/mist64/xhyve https://github.com/mist64/xhyve)
- stephenr 11y ago
  Vagrant works with parallels desktop (free plugin, requires parallels pro in v11+) and VMware fusion (with a paid plugin)
nacho2sweet 11y ago
"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.
digitalzombie 11y ago
I think I'll stick with Vagrant and Ansible. 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.
mhoad 11y ago
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.
happywolf 11y ago
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.
rmanalan 11y ago
How does this compare to azk http://www.azk.io/ http://www.azk.io/ ?
brento 11y ago
I'm not seeing anything about Python/Django. Will that be added eventually?

772 points by agonzalezro 11y ago

bovermyer 11y ago

There's a lot of magic here. I'd love to know what's going on beneath the hood.

davexunit 11y ago
That magic will surely prove to be problematic. I see lots of potential issues. It automatically installs other Hashicorp tools, presumably outside of your system's package manager, which means that it is a package manager in addition to whatever else it does. Where does it install software? How does it verify integrity? Does it build from source or use pre-built binaries? If they are pre-built binaries, how do I get the corresponding source code and build scripts? Does it bundle all other dependencies? How do I make sure I get security patches for the whole dependency tree? I don't expect that Hashicorp would have satisfactory answers to all these questions. Furthermore, automatic dependency installation sounds like it will make reproducibility difficult, and I imagine automatic application type detection will fail in spectacular ways. What happens when the magic doesn't work? The Appfile looks like yet another ad-hoc domain specific language that you need to learn that has the usual major deficiencies compared with using an existing general purpose programming language.

vezzy-fnord 11y ago

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.

dragonwriter 11y ago
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.

vinceguidry 11y ago

Wow, there goes my business idea. Kudos.

rco8786 11y ago
Why? If someone else is doing it that probably means there is a market for it.
- vinceguidry 11y ago
  Sure, but could I compete with free?
  - danesparza 11y ago
    Yes. Especially if you have a good tool that you pair with 'paid for' consulting. Consider RedHat or Canonical (among others).
  - skorecky 11y ago
    If you or someone created something that was basically Heroku in a box that could then be hosted anywhere. I would be interested. I want to build apps, not worry about hosting and servers.
    - endriju 11y ago
      Did you try http://www.openshift.org http://www.openshift.org? The self-hosted version is basically what you described, at least for the JVM languages.
      - skorecky 11y ago
        I have tried it, but just don't hold up as well as Heroku. I still use and love Heroku, but would be nice to have a similar option I could host anywhere on my terms.
        11y ago

cyber1 11y ago

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

ldpg 11y ago

Heads up blank page for docs on custom types: https://ottoproject.io/docs/apps/custom-plugin https://ottoproject.io/docs/apps/custom-plugin Eagerly waiting to see what goes there eventually - very exciting! Also, will there be a way to create custom Infra Types?

bryanlarsen 11y ago

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 instance you can use them with docker via https://github.com/progrium/buildstep https://github.com/progrium/buildstep 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.

ldpg 11y ago
In that analogy Heroku buildpacks are more like the boot the police put on your car.
jacques_chester 11y ago
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 binaries being silently substituted, the messy statefulness of their staging architecture. Oh, and most importantly, we made it all work in a disconnected environment. Which Heroku never intended. Speaking individually, not as a Pivot, if you didn't have to, I wouldn't recommend starting with Heroku's buildpacks. They solve a lot of problems, but no small part is solving Heroku's problems.
- cfthrowaway 11y ago
  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 https://github.com/cloudfoundry/stacks) into their buildpacks, which caused applications on CF distributions that used other stacks to break when using their buildpacks.

LukeB_UK 11y ago

All Ruby development environments look alike, all PHP development environments look alike, etc. Did they do any user research? Doesn't feel like it based on the above statement.

Kiro 11y ago
What do you mean? How is the statement false?
- mrrsm 11y ago
  As far as looking alike goes I think it could end with uses Ruby or uses PHP. A lot of modules will differ for different use cases. I may not need any of the modules another user needs.
  - cleverjake 11y ago
    nothing about mentions installing modules for you. This is about the environment, not the actual project
    - Carrok 11y ago
      PHP/Apache modules, which are very much environment based.
- vidarh 11y ago
  Ruby: MRI vs. REE vs jRuby vs Rubinius, for starters. And this choice is solved through a variety of mechanisms that people rely on for other parts of their infrastructure, and feel strongly about. For my part, this is also a solution that is way too late: We have Docker/Rocket and a range of similar tools. Why do it yet another way, when if you instead build a Docker image, you can take that Docker image and deploy it without having to translate your dependencies to a different format and re-test everything?
  - brudgers 11y ago

guelo 11y ago

Unfortunate name, there's a popular Java open source library called Otto.

cleverjake 11y ago
There are a lot of things called otto - https://github.com/search?q=otto&type=Repositories https://github.com/search?q=otto&type=Repositories doesn't mean its a bad name
- mikehc 11y ago
  Yeah, but look at the number of stars and forks. Square's Otto is a pretty popular library. Side note: I don't know why someone is down voting people saying this. I mean yeah they will not change their name I guess but it should be bad for the next big project to choose a name that is not taken by a popular project already.

buffoon 11y ago

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.

tomswartz07 11y ago
Strange. What issues were you having? We've been using Packer and Vagrant with Windows builds for the better part of a year now and it's been rock solid. We actually leverage it into our Windows Deployment Server to create automatically updated OS Images to be deployed to production machines.
- buffoon 11y ago
  WinRM dropouts when building images in packer, random failures that are unexplained, network not coming up in vagrant, consistency. I've partially written my own version of it in powershell and Hyper-V now.

wesleytodd 11y ago

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.

justizin 11y ago
This addresses a bigger picture that some folks have been (ab)using vagrant to accomplish and requesting features that belonged in a new project, rather than on top of vagrant.
- thejerz 11y ago
  Such as?
  - mastazi 11y ago
    Such as provisioning and deployment I guess... I've seen those requests over and over.
tptacek 11y ago
Which is why this uses Vagrant and doesn't replace it.
dragonwriter 11y ago
> 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. Seems to me it might, if you view its "one job" as coordinating a bunch of lower level tools that each do their own "one job". Well, and assuming it does it well.
Cacti 11y ago
Probably because they did such a good job with Vagrant that they realized they were running out of things to do and decided, in the interests of job security, to ride the train a little longer by "pivoting." Then again, who am I to complain? Vagrant is a superb tool and the endless and pointless reinventing of standards every few years keeps like 70% of us employed.

robbles 11y ago

Looks really cool, excited to see some more detail on how it actually works! 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? - JSON/YAML, possibly with support for templating like Ansible - A Ruby DSL - A limited, but well-tested and understood format like .ini files

deleted 11y ago
[deleted]
robbles 11y ago
Answering my own question after looking at the code: https://github.com/hashicorp/hcl#why https://github.com/hashicorp/hcl#why It's JSON-compatible, at least (valid JSON is valid HCL).
jweir 11y ago
The config format looks like the same format as Terraform.
- Perceptes 11y ago
  It's HCL. Same format used by Terraform and the just-announced Nomad.
davexunit 11y ago
> JSON/YAML, possibly with support for templating like Ansible When you are writing templates for your configuration files, what you've wanted all along was a real programming language.
- acveilleux 11y ago
  Yes and no, a lot of the ops folks I know peter out at pretty basic scripting and find a templating system easier.

mpdehaan2 11y ago

I'm kind of glad to see this, as I wrote https://github.com/mpdehaan/strider https://github.com/mpdehaan/strider for the reason that Packer and Vagrant used different config files. This appears to address that. OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like https://github.com/mitchellh/packer/issues/409 https://github.com/mitchellh/packer/issues/409 ) addressed more than I want glue on top. Anyway, if people want to hack on Strider, pull requests are welcome. 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. 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. The DSL changes appear to maybe be a step in that direction? Would probably benefit from more than one liners on the homepage, to show what is really involved more quickly.

antod 11y ago
> OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like https://github.com/mitchellh/packer/issues/409 https://github.com/mitchellh/packer/issues/409 ) addressed more than I want glue on top. Ahhhh that Packer issue. I have been following that one for what seems like years too.

alrs 11y ago

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

skorecky 11y ago
Why? This is what I love about Heroku. I get to build the app I want without worrying about all the other aspects of hosting that make me want to never launch an app ever again. I love the idea of focusing on the development part and letting something / someone else worry about hosting.
- whalesalad 11y ago
  Have you ever dealt with a large app deployment on Heroku? Unless you're willing to throw money at the problem it sucks.
  - skorecky 11y ago
    Yes and if you're a small team with limited resources and you don't have an operations person/team throwing money at the problem works. There will come a time when you will need to setup a more customized hosting solution but hopefully by then you can hire someone to do operations that knows what they are doing. I don't think Heroku or Otto are designed for big projects anyways, they're a great way to get up and running and help you grow without having to worry about infrastructure upfront or for a couple years.
    - sanderjd 11y ago
      > I don't think Heroku or Otto are designed for big projects anyways. If you're right about that in Otto's case, that's a bummer. It's frustrating that there is this seemingly intractable divide between things that are great to start with for a new project (Heroku, etc.) and things that scale well as a project grows huge (Kubernetes, etc.). Every time a devops tool comes out, I read about it in hopes that it has both the easy-start and but-scales-as-needed stories, and inevitably find people saying it's actually one or the other.

throwaway9851 11y ago

Key takeaways for me: - __Right now__, Otto appears to be Vagrant++. I wouldn't use this for prod, at least not for a while. - Otto is written in Go. Source is here: https://github.com/hashicorp/otto https://github.com/hashicorp/otto - Otto uses a plugin model for different applications. Plugins aren't supported yet. https://ottoproject.io/docs/plugins/app.html https://ottoproject.io/docs/plugins/app.html - Built in plugins don't appear to be consuming a sane plugin interface. How the built-in plugins work is non-obvious. - Under the hood, Otto appears to be using Packer, Terraform, and Vagrant. - 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. - Otto, Nomad, and Terraform all promise to solve the same problem in prod in different ways: -- Otto is a one-off push to set up infrastructure and deploy to prod. -- Nomad is for pushing jobs to help maintain long standing infrastructure in prod. -- Terraform is for periodic pushes to prod to create idemopotent infrastructure. In other words, from least to most robust IMO: Least Robust -------> Most Robust Otto --> Terraform --> Nomad

timdorr 11y ago
I think the Terraform/Nomad/Otto hierarchy is supposed to be like this: - Terraform defines that you have X servers with certain specs. - Otto defines that those servers are running Docker or whatever. - Nomad defines that your application is running in X containers in your infrastructure. So, it's a layered approach (Infrastructure -> System -> Application), akin to the layers of your network. Each one is isolated enough to not worry about the others. At least, that's how I'm hoping this all shakes out :)

solusipse 11y ago

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

skorecky 11y ago
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.
- solusipse 11y ago
  nothing wrong with one year last commit when project's pretty mature
makepanic 11y ago
there's also an android event bus by square http://square.github.io/otto/ http://square.github.io/otto/

ajsharma 11y ago

If Otto's Appfile mimics Heroku's app.json file (https://devcenter.heroku.com/articles/heroku-button#creating-the-app-json-file https://devcenter.heroku.com/articles/heroku-button#creating...), that'd be a huge win to me in having more sustainable Rails open source projects.

mikehc 11y ago

Why not choose a name that is not already used by other project? There is already a pretty popular library for android named Otto http://square.github.io/otto/ http://square.github.io/otto/

deleted 11y ago
[deleted]

drinchev 11y ago

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

mitchellh 11y ago

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 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. * 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. * 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. * Vagrant development will continue, we have some major Vagrant releases planned. Please see this page for more info: https://ottoproject.io/intro/vagrant-successor.html https://ottoproject.io/intro/vagrant-successor.html * 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. Thanks everyone, sorry for not being able to be more active in here. Have a great day!

ChuckMcM 11y ago
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?
- divan 11y ago
  Otto uses Vagrant under the hood.
  - vezzy-fnord 11y ago
    Indeed, which makes the tagline "successor to Vagrant" a dubious choice. It would be like referring to fleet as the successor to systemd. They're stacked layers driving existing utilities.

huslage 11y ago

Otto is adding stupid to stupid. Vagrant is a pile of garbage and Otto is adding more junk to that garbage. Who cares.

rubiquity 11y ago
Do you mind backing up your opinions? Vagrant is a very widely used and beloved tool. edit: I just noticed your profile indicates that you work at Docker, Inc. I'm trying to figure out whether I feel that plays into your opinion or not but I would expect a bit more professionalism at least.
- huslage 11y ago
  No this isn't Docker speaking. This is me. I've always felt that Vagrant was a solution in search of a problem and no being at Docker hasn't changed that either way. I have colleagues that love Vagrant and they are certainly entitled to that opinion, as much as I'm entitled to think that it's horrible. I honestly haven't seen any value brought from Vagrant or its ilk to anyone. There is temporary relief from some very real problems of transmitting development environments around the place. But the tool ends up creating pets that you have to care for over long periods of time. You have to deal with entire operating systems when you really want to abstract away the OS in favor of getting some real work done. Configuration files as infrastructure aren't particularly interesting to me. I don't see how building annoying bits of configuration will fix anything in the long run. Also note that while I think the HashiCorp infrastructure-as-code attempts are quite lacking, their Consul and Vault tools are really nice. :)
  - rubiquity 11y ago
    > Configuration files as infrastructure aren't particularly interesting to me. How is this any different than a Dockerfile? Vagrantfile is certainly more abstract I guess.
coldtea 11y ago
Thanks for the insightful and well argued opinion.

discordianfish 11y ago

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. 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. Anyway, this sounds like an awesome "UX" - let's see how it plays out in reality.

Revell 11y ago

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). I'll definitely be keeping an eye on the project!

geerlingguy 11y ago

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 enough that it has become one of the two or three preferred tools for building local environments for developers. 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? 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".

Cacti 11y ago
I think you've pointed out exactly the reason why this product exists.
- geerlingguy 11y ago
  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.

humbertomn 11y ago

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.

akurtzhs 11y ago

So the supported environments are available at https://www.ottoproject.io/docs/apps/index.html 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.

andybak 11y ago
I thought the omission of Python to be... strange.
- kyllo 11y ago
  Probably punted because they couldn't decide between 2 or 3.
  - andybak 11y ago
    Do you have an axe to grind? It's not terribly hard to support both.

krick 11y ago

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

bjwbell 11y ago
Couldn't agree more. When I was young magic software seemed magic. Then I found out it's 10x harder to debug when it breaks.
andybak 11y ago
Yes - one size doesn't fit all. Yes - sometimes you need something very specific. But, please - it sounds like you've just damned us to repeat the same low-level tasks again and again. 80% of websites ARE the same. If you're in the 20% (or 10% or 1%) then good luck to you. But for those of us deploying another typical webapp - I'd really like to draw on community knowledge. I never wanted to learn devops same way as I never want to learn cryptography, oAuth, SQL internals, how nginx works etc. I just want to use tools that solve these problems for me.

temuze 11y ago

Never used Vagrant that much. How does Vagrant/Otto compare to Docker/Docker Compose/Docker Swarm?

RomanPushkin 11y ago

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

RomanPushkin 11y ago
Easy to reproduce, latest everything: otto, Vagrant, VirtualBox
- diggan 11y ago
  "Hah" says the person who is trying to reproduce this in about a month
Jare 11y ago
Same, despite running under Cygwin (babun).

loweja01 11y ago

yezsutexryckjg

loweja01 11y ago

Something Else!!!

Walkman 11y ago

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.

thejerz 11y ago
I agree, in spirit. Setting up an app server, a web server, a MySQL database, or a cron job is pretty easy once you get the hang of it. There are a lot of complex sysadmin tasks -- running a BIND server, an email server, a Cassandra cluster, etc. -- but that's not what the majority of developers are doing.
- XorNot 11y ago
  I don't understand it, but as an SA there's also a lot of people who are incapable of thinking 5 minutes ahead to the next problem - which is also baffling because its pretty much the same as programming. You setup a cronjob, did you code the script well, who does is notify, how do we know when it fails, what's the recovery strategy?
r0s 11y ago
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.
buster 11y ago
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.

thejerz 11y ago

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.

notacoward 11y ago
I had sort of the same reaction. I just learned a bit of Vagrant recently. I needed something to set up a simple three-node environment for a tutorial I'm doing, and the best starting point happened to be a Vagrant project. It worked well enough that I've been thinking of other uses for it, especially as a basis for automated tests on the distributed system I work on (our current infra for that frankly sucks). Then I read this, and it doesn't look like it's a Vagrant successor in any way that's useful to me. I don't want it to try and figure out service dependencies for me, because I can absolutely guarantee that it's unable to do that for the component I care about. I don't want it fiddling with DNS. I think using the same description but different commands for dev vs. production is a terrible idea. They say Otto does application-level instead of machine-level configuration, but machine-level is what I want. They say multi-VM is too heavyweight but that's also what I want. It's opinionated in all the wrong ways. Everything in https://ottoproject.io/intro/vagrant-successor.html https://ottoproject.io/intro/vagrant-successor.html makes it clear that Otto is fundamentally different from Vagrant, which totally belies their claim (at the end) that it will replace Vagrant in any significant way. They should just come right out and say that they've created something different on top of Vagrant. Maybe it's cool, but it's not a successor. This brand hijacking just makes them seem fickle or shifty. Now I think I'll just leave Vagrant behind while my investment in it is still small, and learn one of the bazillion other tools that I could use to accomplish the same thing.
bluehawk 11y ago
Otto uses Vagrant under the hood. Vagrant isn't going anywhere as far as I can tell.

guessmyname 11y ago

It seems that my ISP is poisoning my Internet connection once again :( 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=

Borborygymus 11y ago

For the love of all that is holy, why do their sample code fragments have `smart' quotes in them?

jamesfisher 11y ago

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.

vellum 11y ago

Does this work on Digital Ocean droplets? Vagrant doesn't.

cls59 11y ago
How so? The DigitalOcean provider for Vagrant works great: https://github.com/smdahlen/vagrant-digitalocean https://github.com/smdahlen/vagrant-digitalocean

theCzar 11y ago

This seems very similar to PagodaBox's Nanobox product (https://nanobox.io/ https://nanobox.io/). What are the key differences between the two? I imagine I'll do a more thorough comparison myself later, but I was wondering if anyone else had taken a look.

dlandis 11y ago

I use Vagrant regularly for development work and it is a good tool, however, it does still have a lot 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. 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. I would prefer they focused on Vagrant and made it a really outstanding, polished tool.

kbenson 11y ago
Maybe they thought the best path to a really outstanding, polished tool was to approach the problem slightly differently and Otto is their solution? If that's the case (I really have no idea), maybe rather than devoting too much time to fixing vagrant they decided to limit the time spent on that to further what they thought is a better overall solution?
- dlandis 11y ago
  Yeah unfortunately I think it's more about tackling entirely new problems in addition to the problems Vagrant already solves.
mastazi 11y ago
According to the blog post Otto is actually built on other tools including Vagrant (which provides the dev environments) and Terraform (which provides the infrastructure management), so I think they will keep actively developing Vagrant in the future.

allanmacgregor 11y ago

Does this mean that development focus will shift from Vagrant to Otto? Is Otto mean to replace vagrant?

jamesgeck0 11y ago
Maybe, eventually? But not right now. https://ottoproject.io/intro/vagrant-successor.html https://ottoproject.io/intro/vagrant-successor.html

atriix 11y ago

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.

sanderson1 11y ago

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 uses Vagrant to solve a different set of problems. 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. 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: https://nanobox.io https://nanobox.io 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.

bgentry 11y ago

Otto looks great, and is probably a substantial improvement over Vagrant. My biggest concern is that it still relies on VirtualBox for local dev. VirtualBox is unreliable and slow, especially its file mounting driver. I'd love to see this evolve to use a different virtualization solution, maybe something based on the OS X Hypervisor Framework (ala https://github.com/mist64/xhyve https://github.com/mist64/xhyve)

stephenr 11y ago
Vagrant works with parallels desktop (free plugin, requires parallels pro in v11+) and VMware fusion (with a paid plugin)

nacho2sweet 11y ago

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

digitalzombie 11y ago

I think I'll stick with Vagrant and Ansible. 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.

mhoad 11y ago

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.

happywolf 11y ago

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.

rmanalan 11y ago

How does this compare to azk http://www.azk.io/ http://www.azk.io/ ?

brento 11y ago

I'm not seeing anything about Python/Django. Will that be added eventually?