I think you want windows releases thought right? Honestly not in a position to keep making those, someone would need to contribute build tooling on github actions, I am just too far out of it with windows

@natemccurdy has left the channel

Any chance that changes to support puppet-systemd 8.x in choria-mcollective could be released to forge any time soon?

will do releases soon yes, been on 3 month break

Hello, I want to build choria and configure configure to use them with Oracle8+ servers, how can I get started with it?

the el8 rpm probably just works?

yes but I need some guidance and steps to get started, like setting and configure broker, server, client etc

Suggest you refer to the docs on choria.io

I checked the docs and it doesnt really tell how to install, configure and test

it looks like a general doc with info about choria

Did you check https://choria.io/docs/deployment/ ?

I went through this and it doesnt explain how can I write a manifest for choria (broker,server and agent)

can anyone help? I have an oracle8 vm and Its using puppet agent to get manifest

I was previously using MCO but as its EOL so thats why i am moving to choria, i am new to this so thats why if there is anyone who have worked on this

It’s all covered there

its running choria --version 0.29.4

Which error did you get when you tried to install it with puppet?

this didnt worked

the choria class has no "broker" parameter. The broker is managed with choria::broker. Here is the conf I use for end-to-end testing of choria when I update the FreeBSD ports: https://github.com/smortex/freebsd-puppet-test-infrastructure/tree/production/site-modules/profile/manifests/choria

hello! i'd like to propose the following PR for your review: https://github.com/choria-io/go-choria/pull/2282 we've hit a situation with an overloaded choria broker during a "reconnection storm" and increasing the connection timeout on the choria servers - along with tls_timeout and auth_timeout on the broker - resolved the issue.

Hmm, how many nodes are reconnecting? They should have random reconnect delays and expo backoff to help already. Do you have big RSA keys maybe? Like 4K or similar?

6K nodes. 2K keys. broker running on an aws ec2 instance (t3a.medium). i could see in the logs the backoff algorithm running. but in the environment i have, that wasn't enough. i went ahead, built a choria package with the connect timeout option, installed in a choria server, and that server could connect to the broker. these are the sort of messages i see in the broker during the reconnection storm:

{
  "component": "network_broker",
  "level": "error",
  "msg": "redact:41534 - cid:29307 - TLS handshake timeout",
  "time": "2025-10-15T06:24:23-05:00"
}

and this is what i see in the server:

{"component":"server","connection":"redact","identity":"redact","level":"info","msg":"Sleeping 3.062s till the next reconnection attempt","time":"2025-10-14T11:53:50-05:00"}
{"component":"server","connection":"redact","identity":"redact","level":"error","msg":"NATS client encountered an error: EOF","time":"2025-10-14T11:53:50-05:00"}
{"component":"server","connection":"redact","identity":"redact","level":"info","msg":"Sleeping 8.839s till the next reconnection attempt","time":"2025-10-14T11:54:08-05:00"}
{"component":"server","connection":"redact","identity":"redact","level":"error","msg":"NATS client encountered an error: EOF","time":"2025-10-14T11:54:08-05:00"}
{"component":"server","connection":"redact","identity":"redact","level":"info","msg":"Sleeping 4.7s till the next reconnection attempt","time":"2025-10-14T11:54:24-05:00"}
{"component":"server","connection":"redact","identity":"redact","level":"error","msg":"NATS client encountered an error: EOF","time":"2025-10-14T11:54:24-05:00"}
{"component":"server","connection":"redact","identity":"redact","level":"info","msg":"Sleeping 10.622s till the next reconnection attempt","time":"2025-10-14T11:54:38-05:00"}
{"component":"server","connection":"redact","identity":"redact","level":"error","msg":"NATS client encountered an error: read tcp redact:57536-\u003eredact:4222: read: connection reset by peer","time":"2025-10-14T11:54:38-05:00"}

Yeah sounds like typical RSA certs that are very heavy. Not sure if Puppet can make different algo certs yet but that would really help. It’s one broker or a cluster? 6k nodes really not that bad.

Oh those are really crappy instances. With 2k key size certs you should probably go for something bigger. More CPUs would help as the TLS will use that well.

Can add another option but obviously prefer to identify the issue cos that’s not normal

Puppet has an option for elliptic curves, but that's rarely used. Worth a try

it's one broker only. in practical terms, increasing the instance size might tackle the problem. but why giving aws more money if a configuration option would also handle it? 😛 under usual load, the broker is performing fine, responses from the fleet are processed quick enough. so increasing the instance for a situation that does not happen often does not seem ideal. and if i can go a little further, conceptually it seems we really need the connect timeout. since we are providing a way to tune the timers on the broker side (tls_timeout/auth_timeout), we'd also need a way to reflect that on the server side. i hope you agree 🙂

Yeah. Will review next week am ooo atm

oh, no problem. enjoy your time off. and thank you so much for being open to discuss/review this. really appreciate it.

Hey Guys, so I just build a custom choria module using rpm, its 0.29v. I configured broker using broker.conf file and on another server I configured server using server.conf and client.conf. It works, when i did

choria ping

it returned me the nodes hostname. Now I want to get facts like ip addresses and stuff but it returns

null

I also added this

plugin.choria.facts_source = facter

plugin.choria.facts_file = /etc/choria/facts.json

in server.conf file but it still not getting the facts although it return the IP address when I do this

sudo jq -r '.ipaddress' /etc/choria/facts.json

192.168.20.30