Skip to content

Howl send vc00 - #90

Open
jackbdoughty wants to merge 18 commits into
mainfrom
howl_vc00
Open

jackbdoughty wants to merge 18 commits into
mainfrom
howl_vc00

Conversation

@jackbdoughty

@jackbdoughty jackbdoughty commented Sep 17, 2026 •

Copy link
Copy Markdown
Contributor

Allows howl to send a vc00 containing veto info and also correctly passes veto info to event messages.
Removes functionality for passing just one probability and having all vetoes go off this.
Also does some refactoring as the main howl function was looking quite long.

To test I did different variations of saluki howl sarada:9092 JackDTest with different arguments e.g. names, enabled, probabilities. Look for results on saluki consume sarada:9092/JackDTest_vetoConfig. Have a play and see if chosen arguments affect the result in an expected way.

Also check that vc00 is sent after the run start as mentioned in ticket.

@Tom-Willemsen

Copy link
Copy Markdown
Member

I think there might be a misunderstanding here - enabled vetoes are the ones that a user has said they care about, probabilities are the ones actually applied to events.

So from a Saluki perspective it --enabled false,... --probability 0.5,... does make sense.

Comment thread src/howl.rs Outdated
Comment thread src/howl.rs Outdated
Comment thread src/howl.rs Outdated
Comment thread src/howl.rs Outdated
Comment thread src/main.rs Outdated
Comment thread src/howl.rs
.expect("Failed to get system time")
.as_nanos()
.try_into()
.expect("This will fail after April 11th, 2262");

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah crap what a showstopper

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should petition for a national day of mourning

@rerpha rerpha left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good - i think we want to probably also send a veto config update each time a run start is sent too (this is what kafka_dae_control does)

Comment thread src/howl.rs Outdated
Comment on lines +487 to +498
let mut config: ClientConfig = ClientConfig::new();
config.set("bootstrap.servers", conf.broker);

if let Some(kafka_options) = &conf.kafka_config {
for option in kafka_options {
println!(
"Setting Kafka config option {}={}",
option.key, option.value
);
config.set(&option.key, &option.value);
}
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it'd be good to pull this out to a separate function - we will probably use it elsewhere at some point. it'd also probably be easy to unit test!

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(feel free to not do this in this PR btw, can appreciate it may scope creep the ticket)

@jackbdoughty

Copy link
Copy Markdown
Contributor Author

looks good - i think we want to probably also send a veto config update each time a run start is sent too (this is what kafka_dae_control does)

bit confused- in the howl function we send a run start, then the veto config update, then calls on produce messages to start a loop, send a load of fake run data then start another run- why not have the produce messages func start with sending run start, spew data and loop, means that we don't need the extra call to send_run_start in howl func.?

@jackbdoughty

jackbdoughty commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor Author

I've put what I mean in the last commit- not tested it but would this work in theory?

@rerpha

rerpha commented Sep 23, 2026

Copy link
Copy Markdown
Collaborator

looks good - i think we want to probably also send a veto config update each time a run start is sent too (this is what kafka_dae_control does)

bit confused- in the howl function we send a run start, then the veto config update, then calls on produce messages to start a loop, send a load of fake run data then start another run- why not have the produce messages func start with sending run start, spew data and loop, means that we don't need the extra call to send_run_start in howl func.?

yes - i think that makes sense to me.

I think you generally want a loop of

send run start
send veto update
send lots of events

(if --frames-per-run > 0)
send run stop
go to "send run start"

@rerpha

rerpha commented Sep 23, 2026

Copy link
Copy Markdown
Collaborator

one thing that's important is that the job id of the run start and stop need to match.

PS will review this properly soon - had a bit of time to look initially

@jackbdoughty

Copy link
Copy Markdown
Contributor Author

one thing that's important is that the job id of the run start and stop need to match.

PS will review this properly soon - had a bit of time to look initially

No problem thanks for the comments 👌

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants