Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terraform 1.0

github.com

Post reply on HN
Print view View original

11–20 of 315 posts

Re: Terraform 1.0

#11

Post by mwarkentin »

kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

The module passing got a lot better in 0.12 when you could pass full modules or resources as outputs and vars.

Re: Terraform 1.0

#12

Post by sandGorgon »

kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

have you tried pulumi ? what's your opinion ?

Re: Terraform 1.0

#13

Post by Hikikomori »

kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

Maybe try out https://www.pulumi.com/

Re: Terraform 1.0

#14

Post by cube2222 »

kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

> The biggest feature I would like to see is the ability to dump a pure representation of your evaluated configuration. This would allow reasonable diffs in CI. There are of course complications, especially if you use `data` resources but technically it is possible to do a very good job here which would make it so much easier to make changes.

The planned state, current state, and diff of them are all available as separate fields in the Terraform plan file, is that not what you're looking for?

Re: Terraform 1.0

#15

Post by pizza234 »

hnlmorg wrote: post #8
pizza234 wrote: post #4

Earlier quoted context omitted.

I think it's a very meaningful step, as it signals maturity - the platform changed significantly over the last couple of years, and it's (unfortunately but necessary) a pain to perform some upgrades, or at least, to redesign according to the new features. For example, we can't make full use of the modules flexibility which I think was added to 0.15 (module.kount anybody? :)), because it's a very painful process. Had…

I think the biggest problem is that the state file is a JSON blob who's hierarchy directly maps the structure of your code in Terraform. This makes refactoring a nightmare as you're continually having to fudge the state file and/or declare that a resource defined in code relates to a resource defined in state (I forget the exact CLI flag you pass to do this off hand).

Yes, I think is reflected into our situation. For our TF codebase, specifically, it would be greate to deduplicate modules (which is something that couldn't be done some time ago), but there is no simple way of, say, creating a new module, and slowly migrate resources into it.

In particular (AFAIK), there are no tools for moving stuff around, so in addition to the TF restructuring, one also need to write scripts to manually move the resources.

Re: Terraform 1.0

#16

Post by ptomato »

kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

> for example you can't create a kubernetes cluster then add a resource to it

I have no love for HCL, but you can do this by creating a kubernetes provider with the auth token pointing at the resource output for the auth token you generated for the cluster.

Re: Terraform 1.0

#17

Post by nrmitchi »

ptomato wrote: post #16
kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

> for example you can't create a kubernetes cluster then add a resource to it I have no love for HCL, but you can do this by creating a kubernetes provider with the auth token pointing at the resource output for the auth token you generated for the cluster.

Yes, however this will work (typically) if the cluster already exists (a previous run), but typically not if you creating the cluster, and kubernetes provider, as part of the same run.

IIRC you'll end up with a kubernetes provider without auth (typically pointing at your local machine), which is 1, not helpful, and 2) can be actively bad.

I believe the core issue here is that providers don't have the ability to specify a `depends_on` relation: https://github.com/hashicorp/terraform/issues/2430

Re: Terraform 1.0

#18

Post by thanatos519 »

kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

Amen! I found it excruciating that the language was always a few simple steps away from being homomorphic to JSON. I desperately needed to be able to manipulate it as data structures, not as strings. All of the ways I found to work around its limitations made me wish for something else entirely.

Re: Terraform 1.0

#19

Post by marenkay »

nrmitchi wrote: post #17
ptomato wrote: post #16

Earlier quoted context omitted.

> for example you can't create a kubernetes cluster then add a resource to it I have no love for HCL, but you can do this by creating a kubernetes provider with the auth token pointing at the resource output for the auth token you generated for the cluster.

Yes, however this will work (typically) if the cluster already exists (a previous run), but typically not if you creating the cluster, and kubernetes provider, as part of the same run. IIRC you'll end up with a kubernetes provider without auth (typically pointing at your local machine), which is 1, not helpful, and 2) can be actively bad. I believe the core issue here is that providers don't have the ability to speci…

This works even without the depends_on property. All you need to is have the module you use for creating the cluster have an output that is guaranteed to be a computed property.

Then use that computed property as input variable for whatever you want to deploy into Kubernetes.

We're using this with multiple providers and it works. Of course, an actual dependency that's visible would be better.

Re: Terraform 1.0

#20

Post by marenkay »

kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

Add an secrets provider to avoid having secrets in state files to that list.
Post reply on HN