This message was deleted.
# general
b
This message was deleted.
c
Hi Brett,
I guess I would have expect to see the previous cost be that of my last PR.
The differences show the cost changes that would occur if you apply the TF plan, so if you un-applied changes in your main branch then you will see the costs for those too.
Why is it reporting e2-medium for the default-pools?
It looks like e2-medium is the default machine type in the terraform docs, but i’m guessing you were expecting e2-micro since that’s what’s in the shared vars file… what does the TF plan show for machine type?
j
In regards to the cost changes, I see now - thanks. So what I'm doing in my modules will only ever show the current cost since I destroy everything on merge.
Right, I'd expect the cost for the e2-micro but checking the plan it's only known after apply so I'm guessing that's why you guys are using the default here?
notice the e2-micro is in the
google_container_node_pool.this
resource and the plan does show it. I would have expected the same from
google_container_cluster
, weird.
👀 1
c
For the default node pool, we’re expecting the configuration to be in a top level
node_config
block, not a nested one
node_pools [ node_config…
. So if I add that:
Copy code
resource "google_container_cluster" "this" {

  node_config {
    machine_type = var.machine_type
  }
  ...
I see the ec2-micro pricing for default_pool.
Does that jive with what you’re seeing or is terraform figuring out that since you set
name = "default-pool"
in the `node_pool`block that you want the default to use e2-micro?
j
Yup that jives, let me muck around with it a bit more. I still trying to grasp the other question a bit too. Is it fair to say if we do not want to keep our infrastructure up between commits (again here we are just running kitchen tests for child modules) we have no way of generating diffs of cost between commits?
c
Yes, that’s fair BUT other people are running into similar situations (e.g. https://github.com/infracost/infracost/issues/1192). Being able to directly compare infracost json breakdowns seems like a pretty obvious feature that opens up a lot of doors (don’t hold me to it, but I would guess we’ll have something in a month or two). Then the question becomes where do we store the “old” output. Maybe github artifacts? maybe a hosted service? seems like different people will need different things. It would be great if you’d be willing to give some feedback or test stuff out once we start working on that.
j
Sweet, thanks for the follow up! I'll test it out on my stuff for sure, just let me know. I'm all in on GitHub (consolidated convenience vs best of breed) so my initial preference on where to store the old data would be there. I actually assumed that's why we needed to register with your API because it stored the data across runs.