Are these bugs in 5.12?

Using sensuctl 5.12, you can have a role-binding and delete the defined role without an error.

Using sensuctl 5.12, you can also delete an asset in use by a check.

Using sensuctl 5.12, you can create a check with an asset that doesn’t exist.

Using 5.9, the following rules allow me “resolve” and “clear silence” from the dashboard (under events).

sensuctl role create local-admin --verb get,list,create,update,delete --resource assets,checks,entities,events,filters,hooks,silenced --namespace linux
ensuctl role-binding create local-admin --role=local-admin --group=linux --namespace linux

Using 5.12, I get an error

Error: GraphQL error: request unauthorized
at new ApolloError (http://sensu/static/js/vendor_a994.js:89:91772)
at QueryManager. (http://sensu/static/js/vendor_a994.js:89:110592)
at step (http://sensu/static/js/vendor_a994.js:104:2609)
at (http://sensu/static/js/vendor_a994.js:104:2714)
at http://sensu/static/js/vendor_a994.js:104:1625
at Promise.n._execute (http://sensu/static/js/vendor_a994.js:89:36878)
at Promise._resolveFromExecutor (http://sensu/static/js/vendor_a994.js:89:61413)
at new Promise (http://sensu/static/js/vendor_a994.js:89:54229)
at __awaiter (http://sensu/static/js/vendor_a994.js:104:1366)
at (http://sensu/static/js/vendor_a994.js:89:110418)
at notifySubscription (http://sensu/static/js/vendor_a994.js:104:42763)
at onNotify (http://sensu/static/js/vendor_a994.js:104:43379)
at (http://sensu/static/js/vendor_a994.js:104:44193)
at notifySubscription (http://sensu/static/js/vendor_a994.js:104:42763)
at onNotify (http://sensu/static/js/vendor_a994.js:104:43379)
at (http://sensu/static/js/vendor_a994.js:104:44193)

quick check in for the things that I can asnwer for the asset issues you bring up in 5.12…

The need to have to adjust your checks when you delete an asset is a known issue:

Not sure if there is a long term plan to automatically remove asset references, but personally I think its bad idea to do by default. It’s a bit dangerous to do that on behalf of the user by default…because some workflows people are using with cm or gitOps approach to manage resources may require purging a resource before uploaded a new version if it. If deleting an asset caused references to the asset to be deleted in other resources may cause huge problems for people using automated workflows.

And in general requiring referenced named resources like an asset to to exist before a check could be uploaded would actually be an anti-feature as it will make it much harder to automate resource deployment because you’d have to deploy resources in a specific order.

There maybe room here for a high level validation feature to validate the connections between resources for an entire namespace that can be run after all changes are made in a namespace. But validating connections like that when editting a single resource will be problematic as it starts requiring people to have to be very careful with the ordering they use to change resources.


Asset dependency management is complicated, if only because it’s not always clear what the right thing to do is. I agree that if a check using an asset is deleted, that the asset should stick around, because who knows what’s supposed to happen next.

I’m more concerned that you can delete a resource (e.g. role or asset) in use by something else, causing something else to break in the future.

I can see your argument that a user’s workflow may want to delete and recreate an object (perhaps in use by something else).

A solution for this outside of Sensu is to have a validation script (perhaps invoked by cm) that all your dependencies exist.