Hello.
(sensu-go 6.2)
I’ve been automating the sensu publishing for alerts, prune is tricky. But it looks fine.
I want to fail the config build in Jenkins automatically, but I don’t see a -dry-run in create as in prune
is there a way to do sensuctl validation without actually making changes ?
M.
Howdy! When I was at Sensu, I opened up this request: --dry-run flag for sensuctl create · Issue #3475 · sensu/sensu-go · GitHub. I’d recommend giving it a 
so that the team can prioritize the request.
Hey!
I’ve commented into the github issue,
There’s probably a need to look at an inverse to prune that has the same level of flaggable controls.
It would be nice for example to be able to do a recursive create-like operation that was limited to specific resource types and label selection like prune does. It’s probably gonna need to be a new command to make sure create stays backwards compatible and works as expected.
Good to know… I just tough in a solution. create everything in a throwaway namespace, and then delete
My question then if which one has priority sensuctl --namespace xx or namescpace in the yaml ?
Hey,
namespace in the yaml takes priority.
Here’s the document reference:
https://docs.sensu.io/sensu-go/latest/sensuctl/create-manage-resources/#create-resources-across-namespaces
I was going to suggest the throwaway namespace as well. Once your yaml files are namespace-free, you can switch between namespaces pretty easily.
thinking more on this…
We might be able to prototype this as an installable sensuctl command asset.
Hello Jeff.
Thanks for your help. I implemented the temp namespace and I’m validating the checks.
I see sometimes sensuctl cannot execute a sequence of commands, is there a cooldown time before posting the next sensuctl create ?:
**[Step 3/3]* replacing sensu tokens in /usr/local/teamcity-agent/work/cea1f0f6630bf6ac/extract/sensu-go-conf/app/01_sensu_checks_embedded.yml*
[23:10:23] **[Step 3/3]* validating /01_sensu_checks_embedded.yml ...*
[23:10:32] **[Step 3/3]* 01_sensu_checks_embedded.yml validated*
[23:10:32] **[Step 3/3]* validating 01_sensu_filters_embedded.yml ...*
[23:10:37] **[Step 3/3]* Error: error putting resource #0 with name "emb-occurrences_3_filter" and namespace "prd-build" (/api/core/v2/namespaces/prd-build/filters/emb-occurrences_3_filter): PUT "/api/core/v2/namespaces/prd-build/filters/emb-occurrences_3_filter": Put https://poc-sensu-go.devops.wepay-inc.com:8080/api/core/v2/namespaces/prd-build/filters/emb-occurrences_3_filter: dial tcp <sensu_ip>: connect: connection refused*whoa…
that’s new to me
technically this would not be a sensuctl issue… the sensu-backend api that’s refusing connection. sensuctl is really just an api client. The error there was the backend refusing a connection.
And i don’t know of any imposed connection limits off the top of my head. There is an imposed limit on the maximum size of an api request in terms of bytes. But that wouldn’t show up as n intermittent refusal.
Could be some other connection limit your network is imposing? Do you have a load balancer in the mix between your sensuctl client and your backend?
Thanks for your quick answer! … I was thinking that maybe sensuctl was doing some async work and exiting while backend was still working.
I do have a load balancer. but as you say. I should look into the backend por possible hiccup sources (maybe an etcd node disconnecting or a flaky leader).
If I don’t see obvious errors I’ll reach out.
thanks.
Hello Jeff.
Found the issue: I’m using this as part of a build job and another apps are using the api.
it seems you cannot have concurrent sensuctl create. I added a bit of sleep and retry logic. not great but it works.
is there and api call I can make to validate if sensu is busy creating resources?
| [Step 3/3] Error: error putting resource #0 with name emb-debug-handler and namespace prd-build (/api/core/v2/namespaces/prd-build/handlers/emb-debug-handler): PUT /api/core/v2/namespaces/prd-build/handlers/emb-debug-handler: Put https://poc-sensu-go:8080/api/core/v2/namespaces/prd-build/handlers/emb-debug-handler: dial tcp :8080: connect: connection refused |
|---|
|[18:27:58]|[Step 3/3] Unable to reach sensu server, retrying|
|[18:27:58]|[Step 3/3] validating 01_sensu_handlers_embedded.yml ...|
|[18:28:07]|[Step 3/3] 01_sensu_handlers_embedded.yml validated|
|[18:28:07]|[Step 3/3] Process exited with code 0|wow,
interesting. I’m going to see if I can reproduce locally.
I dont think is_busy like call will work. The problem with trying to do a validate or ready call is that it would be inherently racy… there’s no way to ensure that something else wont do a put after you do your is busy like call…so you end up back in the same position really.
This should be filed as an issue I think and so we can see if api functionality can be extended to help alleviate the problem.
quick follow up question,
Is your automation touching the same resource that you are trying to use sensuctl with or just the same api endpoint?
I want to make sure when i test this I cover the correct test case.
Hello Jef
It should be mostly different resources in the same namespace. but some collisions happen if you build different branches of the same repository.
so not 100% pure.
haven’t isolated the scenario yet.
M.