It's easy to imagine that merging my PR would open a Pandora's box, leading to people requesting full Ansible support, without really thinking through if they make sense in the context of Terraform.
The one thing that would make sense for Hashicorp, is to figure out how to distribute provisioners, similar to https://registry.terraform.io for modules. Distributing provisioners faces the following problems:
- it's not possible to use terraform init to fetch provisioners from the registry: https://github.com/radekg/terraform-provisioner-ansible/pull...
- provisioner file name can't contain os / architecture in the file name requiring manual deployment programs: https://github.com/radekg/terraform-provisioner-ansible#inst...
I personally like the fact that provisioners do not need to be in the core but distribution is a bit of a pain.
I'm curious what you think of this crazy idea?:
With databases, some ecosystems use declarative migrations, where you keep a description of your schema, and the system automatically takes you from here to there. I've heard .Net people say how nice this is. On the other hand with Rails & Django you have delta scripts that give imperative directions for getting from here to there, rather than a declaration of the end state. I like that solution a lot, because sometimes you need more control over what to do. (For example, changing a one-to-many relationship to many-to-many, and moving the existing data.)
It seems to me that Cloudformation and Terraform take the declarative approach to cloud management, and there is no tool for the imperative approach. (Cloudformation has Change Sets but you can't write those or edit them; they just tell you its plan.) Resizing your database's EBS volume may be an example where you want to give careful instructions. Try that in Cloudformation and it will destroy the old volume and attach a new one. :-)
I'd love a tool that lets you keep a history of "cloud migrations", where you write both the "up" and the "down". It could be as simple as some organization around a bunch of fog/boto/aws-sdk scripts, although it would be even nicer if it had helper methods like in Rails, e.g. add_autoscaling_group, and those would usually know how to reverse themselves.
The really great feature would be to have "transactional DDL" for cloud migrations. With database migrations you get this for Postgres but not MySQL, and it's really nice. I know this isn't 100% possible, but CloudFormation comes close already with its rollback attempts. You'd definitely need your own layer of helper methods for this, because I can't imagine implementing it without something like a Command pattern. (The way AWS auto-generates their API tools, maybe it wouldn't even be that difficult to generate an identical API that just records what you want to do.)
I've pitched this idea a few times to AWS people, but maybe you should do it instead. :-)
Anyway, Hashicorp has contributed a ton to my developer happiness, so I wish you great success. Oh, and congratulations on your wedding!
With CloudFormation you can use custom lambda backed resources.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
https://aws.amazon.com/blogs/aws/cloudformation-macros/
That could be really useful!
We did a dirty solution for this with Ansible. We have a base playbook (with roles and all that jazz) that sets up a server and then we can write patches which are separate playbooks.
After the patch has run we simply store the patchlevel in a file on the server so that we dont "double-apply" any patches on the next patch-run.
We're going to be getting deep into multi-cloud (via acquisition), so your thesis on the topic was interesting to read.
I remember reading that original post all those years back and have built with all of your tools, so it'll be a thrill to dig into using Hashicorp as we do this. :)
Please please please make terraform imports automatically generate .tf configs.
I love Terraform. I’m glad it exists. Platform as a config. A fantastic idea and execution.
I don't want to dream up names for every little thing when 98% of them already have 'name' attributes and look almost exactly the same
Congrats on your wedding!
The project that really kicked off HashiCorp was Vagrant, and I "launched" it right here on HN over 8 years ago: https://news.ycombinator.com/item?id=1175901 So its always fun to see things come back around. :) For those that are less familiar these days, HashiCorp now has many major OSS projects: Vagrant, Packer, Consul, Terraform, Vault, Nomad (in addition to lots of minor ones and libraries) addressing different areas.
For the HN crowd, there are a couple background viewpoints that I would also like to share that may be helpful on painting the backdrop on the product and business behind HashiCorp. A first quick one is my tweet on the four dimensions for "multi-cloud": https://twitter.com/mitchellh/status/1022162653618135040 At HashiCorp we're mostly looking at enabling #1 (workflow portability), though that has downstream effects of helping with the other dimensions as well.
Second, I often get asked "Why multi-cloud?" And I wrote up a fairly long answer on Reddit about that with real examples that I recommend: https://www.reddit.com/r/devops/comments/91afzz/why_multiclo...
While I'm happy to answer any questions, this post is rather late for me local time (past 10:30 PM here) and I'm leaving tomorrow to get married this weekend so I can't promise anything!