101–110 of 185 posts
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.
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.
Earlier quoted context omitted.
It's pretty depressing to see Hashicorp adding more layers to a system that already has way too much accidental complexity. Ruby on Rails, for instance, is a beautiful example of an internal DSL, but the Vagrant DSL is awful, you could write a much easier to read/use internal DSL in Java. Then there is the issue that Packer and Vagrant are two different tools. Why should you need to change anything about your provisi…
I don't agree with everything you've said, but I do feel like otto is in danger of being another teetering piece on top of the base-os/virtualbox-os/vagrant(+ansible/chef/puppet)/guest-application tower, which are all leaky abstractions and all cause problems in practice and make debugging complicated. "Accidental complexity" is the right phrase. I can't help but think that what the DevOps world really needs isn't an…
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,…
> 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.
Earlier quoted context omitted.
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 runn…
> 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…
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,…
The config format looks like the same format as Terraform.
Hello everyone! I just wanted to note that I'm running around at HashiConf and likely won't be around to answer as many questions or comments as I'd like. But thank you for all the activity around this and we're excited to show this to you today. I want to just give a few key notes, though many other folks around here are right. * For Otto 0.1, we focused on developer experience. We don't recommend deploying for anyt…
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…
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.
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 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.