7 ms·

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 t

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.
  - ChuckMcM 11y ago
    That makes sense, the announcement seems to imply that really the problem was that Vagrantfiles were too restrictive, so make a Vagrant 2.0 that can read the old files (and will whine) and it uses the new super "Appfile" format as its native format. Maybe there is a tool to convert a Vagrantfile to an Appfile automatically (as Appfiles are supposed to be able to do everything Vagrant can do and more) Anyway, in a more typical software development environment you'd provide such transition tools and carry your users along, so that the next version already starts with a huge base of users. Rather than throw out the old way and come in with a new completely incompatible way to do things. Very confusing.
    - verbin217 11y ago
      I think the idea is that Otto is the (new) interface and Vagrant is a potential implementation. A 2.0 would hide this distinction.
- ichilton 11y ago
  It sounds more like a new product, new direction than Vagrant 2.0....
  - justizin 11y ago
    My take: I think the notion is, it will make sense to use Otto directly from the git-go the way it was for Vagrant in the past. They still work at different levels, with Otto more likely trying to satisfy needs for things like "Ruby" and "Redis" while Vagrant is still more explicit.
- dragonwriter 11y ago
  > Why isn't Otto named Vagrant 2.0 or something? While Otto may be replacing Vagrant as the preferred directly-used tool for most users, its a higher level tool where Vagrant still exists and is used under the covers. Since Vagrant still exists and is maintained and is used by Otto (as well as being usable independently), it would be extremely confusing if Otto was called Vagrant 2.0. > Its confusing to be "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. The main issue Otto seems to be fixing with Vagrant is that Vagrant, alone, isn't a complete solution, a suite of other tools are needed by typical teams; Otto incorporates Vagrant and those other tools, puts an abstraction layer over them, and lets you use them together.
  - nickbauman 11y ago
    I commonly use Ansible with Vagrant: the two play very well together. Otto seems to be an alternative to Ansible.
  - randx838 11y ago
    > it would be extremely confusing if Otto was called Vagrant 2.0 But that is the closest thing anyone thinks of when you say "successor." Then having to explain that it's not a successor, well, you've done it yourself.
    - drb311 11y ago
      Windows was the successor to DOS, built on DOS. Maybe this is like that?!
- PaulHoule 11y ago
  It's pretty depressing to see Hashicorp adding more layers to a system that already has way too much accidental complexity. Ruby on Rails, for instance, is a beautiful example of an internal DSL, but the Vagrant DSL is awful, you could write a much easier to read/use internal DSL in Java. Then there is the issue that Packer and Vagrant are two different tools. Why should you need to change anything about your provisioners AT ALL when you are trying to burn an image? Doesn't that just defeat the whole point of devops? And then there is the issue that when Vagrant can't talk to the mothership, it doesn't work right. It goes on and on. People are screaming out today that "devops is a big waste of time" and I think 80% of that is that Packer and Vagrant are so awful and putting another layer is going to make it 95% awfulness from Hashicorp.
  - grubernaut 11y ago
    > Doesn't that just defeat the whole point of devops? > devops is a big waste of time Devops is about culture, not about tooling.
    - PaulHoule 11y ago
      Culture and tooling go together. Software managers all the time are bitching that their developers get it into their heads that they need a reproducible build environments and then the three of them go screw off for two weeks trying to get Vagrant to work 100% right.
  - kcorbitt 11y ago
    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 another thin layer of magic trying to shellac over the issues of everything below it, but rather to have a hard think and rebuild everything from the ground up with more appropriate primitives. Sort of like what NixOS is trying to do (haven't used it, so can't attest to how successful it has been).
- lazzlazzlazz 11y ago
  Given how different Otto and Vagrant are, and that Vagrant development will continue independently of Otto, I think it would be very confusing to name them the same thing.
- timthelion 11y ago
  It is bad to name different products using the same name. See gnome2 vs 3. Few would be hating on gnome3 if it wasn't named gnome.
loweja01 11y ago
ftrtggt4
Cacti 11y ago
What does Otto do that Vagrant doesn't? I mean, Vagrant is pretty good! What do I need Otto for that I can't do with Vagrant and a few scripts (that I'm likely to have to write anyway)?
- kvz 11y ago
  Otto lets you create infra and deploy to it. So it covers production, not just development. On top of that it offers default stacks for PHP/Ruby/etc that will be maintained by the community. From what I understand, if you're demands aren't too specific, you'll profit from infra/os/apps all set up as a foundation for you app. It detects what app you have and hence you can even have an empty Appfile (similar to Vagrantfile, does more, requires less, hence the magic)
  - Cacti 11y ago
    I dunno, I have yet to find a real-world situation where the demands/requirements aren't "too specific". There are always obnoxious little kinks unless you are using some tool from scratch as the basis of your entire operation. Particularly in production! And I don't see why we need default stacks, don't we already have that with Vagrant? Isn't that the entire point of the Vagrant file and the setup file? You grab an image, you grab the post-setup file, and off you go? Is it really that much work to write a post-setup script to run apt-get and do some config work? It just seems like we're reinventing the wheel, again. And again, and again. And we invent all these new tools just to go through and spend another 6 years fixing them, improving them, debugging them, cajoling others into using them, etc., instead of just improving the tools we already have. Or perhaps I'm just in a shitty mood, I dunno. All I know is that the only reason I can use Vagrant in my professional life is PRECISELY because it's not for production deployment, and that's awesome, because it fills a very specific and needful spot that was vacant before. Why do we always have to keep expanding, cannot we not be happy with just really good tools for a really good specific purpose? P.S. Thanks for the info.
    - parasubvert 11y ago
      "Why do we always have to keep expanding, cannot we not be happy with just really good tools for a really good specific purpose?" Because that tool, along with the beer in their fridge, is for paid by VC money, who needs to recoup their investment. $99 Vagrant licenses for use with VMware isn't going to cut it.

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.
- ChuckMcM 11y ago
  That makes sense, the announcement seems to imply that really the problem was that Vagrantfiles were too restrictive, so make a Vagrant 2.0 that can read the old files (and will whine) and it uses the new super "Appfile" format as its native format. Maybe there is a tool to convert a Vagrantfile to an Appfile automatically (as Appfiles are supposed to be able to do everything Vagrant can do and more) Anyway, in a more typical software development environment you'd provide such transition tools and carry your users along, so that the next version already starts with a huge base of users. Rather than throw out the old way and come in with a new completely incompatible way to do things. Very confusing.
  - verbin217 11y ago
    I think the idea is that Otto is the (new) interface and Vagrant is a potential implementation. A 2.0 would hide this distinction.
ichilton 11y ago
It sounds more like a new product, new direction than Vagrant 2.0....
- justizin 11y ago
  My take: I think the notion is, it will make sense to use Otto directly from the git-go the way it was for Vagrant in the past. They still work at different levels, with Otto more likely trying to satisfy needs for things like "Ruby" and "Redis" while Vagrant is still more explicit.
dragonwriter 11y ago
> Why isn't Otto named Vagrant 2.0 or something? While Otto may be replacing Vagrant as the preferred directly-used tool for most users, its a higher level tool where Vagrant still exists and is used under the covers. Since Vagrant still exists and is maintained and is used by Otto (as well as being usable independently), it would be extremely confusing if Otto was called Vagrant 2.0. > Its confusing to be "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. The main issue Otto seems to be fixing with Vagrant is that Vagrant, alone, isn't a complete solution, a suite of other tools are needed by typical teams; Otto incorporates Vagrant and those other tools, puts an abstraction layer over them, and lets you use them together.
- nickbauman 11y ago
  I commonly use Ansible with Vagrant: the two play very well together. Otto seems to be an alternative to Ansible.
- randx838 11y ago
  > it would be extremely confusing if Otto was called Vagrant 2.0 But that is the closest thing anyone thinks of when you say "successor." Then having to explain that it's not a successor, well, you've done it yourself.
  - drb311 11y ago
    Windows was the successor to DOS, built on DOS. Maybe this is like that?!
PaulHoule 11y ago
It's pretty depressing to see Hashicorp adding more layers to a system that already has way too much accidental complexity. Ruby on Rails, for instance, is a beautiful example of an internal DSL, but the Vagrant DSL is awful, you could write a much easier to read/use internal DSL in Java. Then there is the issue that Packer and Vagrant are two different tools. Why should you need to change anything about your provisioners AT ALL when you are trying to burn an image? Doesn't that just defeat the whole point of devops? And then there is the issue that when Vagrant can't talk to the mothership, it doesn't work right. It goes on and on. People are screaming out today that "devops is a big waste of time" and I think 80% of that is that Packer and Vagrant are so awful and putting another layer is going to make it 95% awfulness from Hashicorp.
- grubernaut 11y ago
  > Doesn't that just defeat the whole point of devops? > devops is a big waste of time Devops is about culture, not about tooling.
  - PaulHoule 11y ago
    Culture and tooling go together. Software managers all the time are bitching that their developers get it into their heads that they need a reproducible build environments and then the three of them go screw off for two weeks trying to get Vagrant to work 100% right.
- kcorbitt 11y ago
  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 another thin layer of magic trying to shellac over the issues of everything below it, but rather to have a hard think and rebuild everything from the ground up with more appropriate primitives. Sort of like what NixOS is trying to do (haven't used it, so can't attest to how successful it has been).
lazzlazzlazz 11y ago
Given how different Otto and Vagrant are, and that Vagrant development will continue independently of Otto, I think it would be very confusing to name them the same thing.
timthelion 11y ago
It is bad to name different products using the same name. See gnome2 vs 3. Few would be hating on gnome3 if it wasn't named gnome.

loweja01 11y ago

ftrtggt4

Cacti 11y ago

What does Otto do that Vagrant doesn't? I mean, Vagrant is pretty good! What do I need Otto for that I can't do with Vagrant and a few scripts (that I'm likely to have to write anyway)?

kvz 11y ago
Otto lets you create infra and deploy to it. So it covers production, not just development. On top of that it offers default stacks for PHP/Ruby/etc that will be maintained by the community. From what I understand, if you're demands aren't too specific, you'll profit from infra/os/apps all set up as a foundation for you app. It detects what app you have and hence you can even have an empty Appfile (similar to Vagrantfile, does more, requires less, hence the magic)
- Cacti 11y ago
  I dunno, I have yet to find a real-world situation where the demands/requirements aren't "too specific". There are always obnoxious little kinks unless you are using some tool from scratch as the basis of your entire operation. Particularly in production! And I don't see why we need default stacks, don't we already have that with Vagrant? Isn't that the entire point of the Vagrant file and the setup file? You grab an image, you grab the post-setup file, and off you go? Is it really that much work to write a post-setup script to run apt-get and do some config work? It just seems like we're reinventing the wheel, again. And again, and again. And we invent all these new tools just to go through and spend another 6 years fixing them, improving them, debugging them, cajoling others into using them, etc., instead of just improving the tools we already have. Or perhaps I'm just in a shitty mood, I dunno. All I know is that the only reason I can use Vagrant in my professional life is PRECISELY because it's not for production deployment, and that's awesome, because it fills a very specific and needful spot that was vacant before. Why do we always have to keep expanding, cannot we not be happy with just really good tools for a really good specific purpose? P.S. Thanks for the info.
  - parasubvert 11y ago
    "Why do we always have to keep expanding, cannot we not be happy with just really good tools for a really good specific purpose?" Because that tool, along with the beer in their fridge, is for paid by VC money, who needs to recoup their investment. $99 Vagrant licenses for use with VMware isn't going to cut it.