Billie Cleek
Billie Cleek
/remove-lifecycle stale
Where do we stand with this? Should we close it or is there something we can do to push forward on the alignment with kubernetes error expectations?
/remove-lifecycle stale
/remove-lifecycle stale
I can make that change. The `reason`, though, should probably be a `metav1.StatusReason` instead of a `string` so that users cannot easily swap the `reason` and `message` arguments unintentionally. But...
Yeah, the few places I need it, `metav1.StatusReasonUnknown` can be used for success (e.g. `Allowed()`)
If `ValidationResponse` is to have three parameters as you suggested with `ValidationResponse(allowed bool, reason, message string)`, then an argument for the reason has to be provided.
After making the changes locally that you suggested, @sbueringer, I'm less convinced that's the direction this should go. Being able to provide the human readable message to `Allowed` and `Denied`...
It looks like that will nearly be sufficient. The query args in prepared statements don't leverage the option, though. Is that an oversight or intentional?. Is your fork the new...
You're right, they check for `q.result` and `q.rows` being nil, and return `nil, err` if so. Although it's technically possible for a driver to return both rows and an error,...