When generating the pricing map, we're missing out on pricing information for us-east1 compute instances. All of the sku's properly to parse for the pricing map, so it's not the regex to find and filter SKU's/ One of the methods we have is getPricingInfoFromSku:
https://github.com/grafana/cloudcost-exporter/blob/main/pkg/google/compute/pricing_map.go#L231-L238
This makes the assumption that the first pricing is the correct one. This works for most of the compute instances except those that exist in us-east. My hunch is that us-east1 machines are the same price as other regional compute instances within the US, so we need to better handle multiple regions in the pricing.
I altered the execution of the program to print out all of the sku's with multiple regions and output log file and uploaded it:
log.txt
There's 6235 sku's:
cat log.txt| wc -l
Let's filter out sku's that aren't networking:
cat log.txt | grep -v -i network | wc -l
239
Okay so 239 sku's is much more favorable then 6235. Here's a sample:
So the very short of it is we need to handle parsing sku's with multiple regions in such a way that ensures each region gets a princingInfo object added to it.
When generating the pricing map, we're missing out on pricing information for
us-east1compute instances. All of the sku's properly to parse for the pricing map, so it's not the regex to find and filter SKU's/ One of the methods we have is getPricingInfoFromSku: https://github.com/grafana/cloudcost-exporter/blob/main/pkg/google/compute/pricing_map.go#L231-L238 This makes the assumption that the first pricing is the correct one. This works for most of the compute instances except those that exist in us-east. My hunch is thatus-east1machines are the same price as other regional compute instances within the US, so we need to better handle multiple regions in the pricing.I altered the execution of the program to print out all of the sku's with multiple regions and output log file and uploaded it: log.txt
There's 6235 sku's:
Let's filter out sku's that aren't networking:
Okay so 239 sku's is much more favorable then 6235. Here's a sample:
So the very short of it is we need to handle parsing sku's with multiple regions in such a way that ensures each region gets a princingInfo object added to it.