Panic and access denied about opencost HOT 6 CLOSED

With version prod-1.19.1, it no longer panics. Thanks!

from opencost.

The Access Denied is expected if a key isn't supplied to read your spot data information, or the node you're running this on hasn't been provisioned with the correct permissions to look at s3 buckets.

The panic is not expected-- looking into this.

from opencost.

I just shipped #64 to hopefully stop the panics and come up with some sensible logs. If possible could you upgrade?

In the meantime, I know we have issues where default storageclass isn't set. Mind checking the storageclass on your PV's?

kubectl get storageclass

should return something like

gp2 (default) kubernetes.io/aws-ebs 12d
If no (default) gets returned, that would be helpful information.

from opencost.

Thanks for the quick response!
Using version prod-1.18.3, I still have the same panic.

kubectl get storageclass:
NAME            PROVISIONER             AGE
default         kubernetes.io/aws-ebs   1y
gp2 (default)   kubernetes.io/aws-ebs   1y

We do have some pv/pvc where we specify an empty storageclass to avoid auto-provisioning of EBS volumes. I don't know if that can be a problem.

from opencost.

Hi @guillaumeger , two things:

• Looks like master with the defensive programming upgrades (#64) to not panic in this situation did not make it to 1.18.3 . We'll put it in tonight's release.

• Yes, empty storageclass in the PVClaim was the issue. We will need to better support auto-provisioned EBS (#69) For now, though, #68 contains a workaround to allow you to use the cost-model minus support for manually provisioned PVs. I will update this bug when #68 makes it into production.

from opencost.

#68 is in production and I've filed #69 to track the root cause, so closing for now. Let me know if I can help in any other way.

from opencost.