Due to the way capabilities are stored in the underlying authorize.conf file, they are inherently unordered, and the order returned by splunkd via the REST API is not determined by the order they were created (even when created by the same REST API). This results in non-empty plans for the same configuration after apply.
Due to the way capabilities are stored in the underlying
authorize.conf
file, they are inherently unordered, and the order returned bysplunkd
via the REST API is not determined by the order they were created (even when created by the same REST API). This results in non-empty plans for the same configuration after apply.This can be seen by reordering the list of capabilities passed in the test, which results in this failed acceptance test: