What do when encountered a provisioning failure

[gianarb]

We have encountered a provisioning failure for your device test1-g7tqp-master-0.

The PacketAPI returns:

403 You are not authorized to view this device

Right now the MachineController tries over and over without an end. it does not sound great. Should we treat the error as we do when the controller receives a 404? We assume that the server is not running anymore and we make the reconciliation as a success. It is not ideal because 403 will may be fixed by generating a new API key. I think the API is not returning the right status code here.

@deitch

[deitch]

This is a good point. We need better logic for it. "403 not authorized" is not the same as "404 does not exist". In a delete, if we cannot find the device, then the state is how we want it to be and successful. In a create, if 404, we want to keep trying until we find it.

But a 403 needs to generate a different kind of error. What is the usual k8s controller behaviour here?

[gianarb]

As I wrote, I think the status code returned by the API makes things harder. When I open the packet.net UI I do not see that server. So for me, it should be 404.

Do we know why an unprovisioned cluster returns 403 and it is not just treated as a cluster not found?

[deitch]

What is the query that we made that returns 403?

[gianarb]

GET device by ID

[deitch]

That is strange. You can replicate it regularly? 403 is an auth issue, not a device-not-found issue. Unless it returns 403 if a device isn't found, because maybe it exists but you don't have rights to see it?

Can you try with direct curl?

[gianarb]

No I do not know how to reproduce a provisioning failure in our cloud

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[deitch]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten