Comment by mitchellh | Hacker News Reader

Comment by mitchellh | Hacker News Reader

Hello, I'm one of the founders of HashiCorp! We're super excited about this. I'm really proud of the team that got us to this point, thankful to our communities, and just generally excited about the future for us.

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!

I would love to give Terraform a spin. However one thing our team needs is support for Ansible. If you look at https://github.com/hashicorp/terraform/issues/2661, radekg has worked on an Ansible Provisioner, but it looks like not many people know about it. Could some of your team maybe look at the following pull request https://github.com/hashicorp/terraform/pull/19021 and help radekq to ship the Ansible Provisioner? Thanks!

Hey, thanks for the shout-out! I'm doing what I can to make the provisioner work as reasonably as possible. It would be awesome to get it into the core, but indeed, there's no pick up from Hashicorp. It might be that Ansible is just too wide of a scope to settle on one man's implementation, there are so many different workflows for Ansible, some of which going way past the Terraform provisioner.

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.

Thanks for the contribution. So we definitely want to get Ansible in and there is a lot of pressure to do so. At this time the focus is 100% on 0.12 core and then we're going to take a look at provisioners again. Sorry for the delay.

Thank you. I'll keep maintaining the PR until then.

Congratulations! I've been a fan of Vagrant for a long time and have done some Vault as well. I haven't yet had a chance to try Terraform, but everyone says it is better than Cloudformation. :-)

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!

It seems to me that Cloudformation and Terraform take the declarative approach to cloud management, and there is no tool for the imperative approach.

With CloudFormation you can use custom lambda backed resources.

Hmm, thanks for mentioning this. It looks like it's just over a month old? Here are the docs I found:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

https://aws.amazon.com/blogs/aws/cloudformation-macros/

That could be really useful!

It’s been around for at least two years from what I can tell.

I'd love a tool that lets you keep a history of "cloud migrations", where you write both the "up" and the "down".

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.

I've asked aws in the past for an API that lets you describe a sequence of changes in a batch, it tells you whether there's any problems with the sequence (like "at step nine of this batch, you tried to create an instance in a vpc subnet that was deleted by step four of this batch"). And then if there are no issues with the batch, another API lets you have aws execute the batch. It sounds a lot like the DDL transactions you mentioned.

I wrote a tool to auto migrate postres using HashiCorp Config Language. It has the issues you describe — hard to rename tables and adding indexes can take a long time on existing data. It’s pretty convenient if you work within the constraints however.

https://github.com/aj0strow/pgschema

Congrats on the round and this weekend. :)

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

If there is one software company out there that deserves all the love and support (and money) the tech world can give, then it's HashiCorp.

Just last night I spent several hours fighting terraform. The cloud UI concepts differ from terraform configs, it’s quite a mind bender.

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.

Can you talk a bit about your password management bits? One of the other programs within our shop said they were going to use (or were doing a pilot) of password management with your kit.

get this shit firmed up and released ASAP! https://www.hashicorp.com/blog/hashicorp-terraform-0-12-prev...

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

Thank you for your contributions, they make devops sane for those of use whose primary role isn't to shepherd servers.

Congrats on your wedding!

Congratulations, Mitchell! Great work by the team and the community!

Congrats team!!

Reply on news.ycombinator.com