You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is sometimes useful to conditionally execute bosh operators (in addition to the ? refer to hash keys that may or may not exist) depending on the presence of key/value in the manifest.
{ "op": "test", "path": "/best_biscuit/name", "value": "Choco Leibniz" }
Tests that the specified value is set in the document. If the test fails, then the patch as a whole should not apply.
This would enable bosh operators to check their prereqs explicitly, and be ignored if preqs are not met.
It seems to support precondition and post conditions and fail if not met with a default error message:
Expects a specific value for a path. Fails otherwise with default error message.
- type: test
path: /instance_groups/name=uaa/instances
value: 0
Expects no value for a path. Fails otherwise with default error message
- type: test
path: /instance_groups/name=uaa/instances-not
absent: true
A possible extension would be something like the following to support skipping the current ops file (an any previously applied mutations) when a test fail, and proceed to other ops files specific to the bosh cli.
Expects a specific value for a path. Skip current ops file with a warning when unmet
- type: test
path: /instance_groups/name=uaa/instances
value: 0
on_violations: skip_ops_file
message: "my custom message: prereq X not met, skipping feature Y"
Expects a specific value for a path. When unmet, fail the whole bosh int command and display a custom message
- type: test
path: /instance_groups/name=uaa/instances
value: 0
on_violations: fail
message: "my custom message: prereq X not met, please fix config"
It is sometimes useful to conditionally execute bosh operators (in addition to the
? refer to hash keys that may or may not exist
) depending on the presence of key/value in the manifest.This issue suggests to implement a support similar to the json patch test syntax
This would enable bosh operators to check their prereqs explicitly, and be ignored if preqs are not met.
/CC @voelzmo
Here is a related specific use-case (for a bosh-based on demand service broker similar to cppforlife/bosh-generic-sb-release): orange-cloudfoundry/cf-ops-automation-broker#30
The text was updated successfully, but these errors were encountered: