21–30 of 185 posts
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
Wow, there goes my business idea. Kudos.
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 ) 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.
Earlier quoted context omitted.
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.
nothing about mentions installing modules for you. This is about the environment, not the actual project
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,…
Sounds like a big bag of "nope."
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.
What do you mean? How is the statement false?
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?
- __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
- Otto uses a plugin model for different applications. Plugins aren't supported yet. 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