Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(settings): Add periodically updating runtime config options #251

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

enochtangg
Copy link
Member

This PR is responsible for adding runtime configs to taskbroker. The path to the yaml file is defined under Config.runtime_config_path. This can be used to override with a ConfigMap in k8s. Otherwise, defaults are defined under runtime_config_defaults.yaml. The runtime config manager reloads the configuration file into memory as part of the maintenance task (which currently runs every 60 seconds).

@enochtangg enochtangg requested a review from a team as a code owner March 13, 2025 16:27
Copy link

codecov bot commented Mar 13, 2025

Codecov Report

Attention: Patch coverage is 80.35714% with 11 lines in your changes missing coverage. Please review.

Project coverage is 83.30%. Comparing base (d54b137) to head (0c49f54).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/runtime_config.rs 81.48% 10 Missing ⚠️
src/main.rs 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #251      +/-   ##
==========================================
- Coverage   83.35%   83.30%   -0.05%     
==========================================
  Files          19       20       +1     
  Lines        3568     3624      +56     
==========================================
+ Hits         2974     3019      +45     
- Misses        594      605      +11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@enochtangg enochtangg force-pushed the fetch-runtime-configs branch from f576c6f to be0e779 Compare March 13, 2025 16:32
src/main.rs Outdated
@@ -50,6 +51,9 @@ async fn log_task_completion(name: &str, task: JoinHandle<Result<(), Error>>) {
async fn main() -> Result<(), Error> {
let args = Args::parse();
let config = Arc::new(Config::from_args(&args)?);
let runtime_config = Arc::new(RuntimeConfigManager::new(
config.runtime_config_path.clone(),
));
Copy link
Member

Choose a reason for hiding this comment

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

Will this get pushed into the InflightActivationStore?

Copy link
Member Author

Choose a reason for hiding this comment

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

If we eventually require the it to need runtime configs, then yes. Otherwise, dropping tasks via killswitching happens outside of InflightActivationStore

Comment on lines 11 to 14
pub struct RuntimeConfigManager {
pub config: RwLock<RuntimeConfig>,
pub path: String,
}
Copy link
Member

@john-z-yang john-z-yang Mar 13, 2025

Choose a reason for hiding this comment

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

I think it might be worthwhile to just let the RuntimeConfigManager also take ownership of the green thread that polls the file. Something like

pub struct RuntimeConfigManager {
    ...
    handle: JoinHandle<()>
}
impl RuntimeConfigManager {
    pub fn new(path: String) -> Self {
        ...
        handle: tokio::spawn(async {
            // file IO here
        });
    }
impl Drop for RuntimeConfigManager {
    fn drop(&mut self) {
        self.handle.abort();
    }
}

So we don't need to schedule it on main anymore

Copy link
Member Author

Choose a reason for hiding this comment

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

What is the advantage of scheduling the tokio thread inside RuntimeConfigManager rather than in main alongside the maintenance task? If we put this in the config manager, how do we call it periodically?

Copy link
Member

@john-z-yang john-z-yang Mar 13, 2025

Choose a reason for hiding this comment

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

For me the main advantage is that RuntimeConfigManager is a self contained thing that doesn't rely on another thing to make it work properly. Right now, the contents of RuntimeConfigManager is only correct if something else is always calling reload_config on it.

What is the advantage of scheduling the tokio thread inside RuntimeConfigManager rather than in main alongside the maintenance task? If we put this in the config manager, how do we call it periodically?

You don't need to call it periodically anymore, since it reloads on its own in the green thread it owns.

impl RuntimeConfigManager {
    pub fn new(path: String) -> Self {
        handle: tokio::spawn(async {
            loop {
                sleep(...).await;
                 // file IO here
            }
        });
    }

Copy link
Member Author

@enochtangg enochtangg Mar 13, 2025

Choose a reason for hiding this comment

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

I see, I'm okay treating it as an actual "manager" which spawns itself own tokio thread and is in-charge of polling itself.

You don't need to call it periodically anymore, since it reloads on its own in the green thread it owns.

Oops, "calling it periodically" were the wrong words. I meant having the IO work execute periodically. In your snippet, we'd sleep right? Is there a difference between sleeping and using interval.tick()? Do both yield execution to the scheduler?

Copy link
Member

@john-z-yang john-z-yang Mar 13, 2025

Choose a reason for hiding this comment

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

In your snippet, we'd sleep right? Is there a difference between sleeping and using interval.tick()? Do both yield execution to the scheduler?

Yup, both will yield execution to the scheduler because they're both using .await. You're right it's probably better to use interval instead of sleep here because interval will take into account how long the file IO took.

The difference between interval and sleep is that sleep is yielding execution for the duration of its parameter, where as by default interval fires using the system clock. For example

loop {
    a();
    sleep(Duration::from_secs(1).await;
}

vs

let timer = time::interval(Duration::from_secs(1);
loop {
    a();
    timer.tick().await;
}

In the former, it does not matter how long calling a() will take. Once a() finishes, we will sleep for 1 second. But in the second example, timer.tick().await will take until it has been 1 second since last time timer.tick().await has returned. This gets kind of complicated when a() takes longer than 1 second and if we configure the MissedTickBehavior.

Copy link
Member

@john-z-yang john-z-yang Mar 13, 2025

Choose a reason for hiding this comment

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

Also circling back to the original conversation, I think if we want to drive the update of RuntimeConfig explicitly in main, it's also fine since we're doing that with upkeep anyway. So it maybe better to follow existing patterns.

@enochtangg enochtangg requested a review from john-z-yang March 13, 2025 20:52
src/config.rs Outdated
@@ -116,6 +119,7 @@ impl Default for Config {
kafka_auto_offset_reset: "latest".to_owned(),
kafka_send_timeout_ms: 500,
db_path: "./taskbroker-inflight.sqlite".to_owned(),
runtime_config_path: "./runtime_config_defaults.yaml".to_owned(),
Copy link
Member

Choose a reason for hiding this comment

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

Do we want this to be an Option instead, so are we expecting that this file will always exists? If so, let's add it to the integration tests because the rebalancing one is failing from not being able to find this file

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, now that we have defaults, we don't need to read from a default file anymore. Updated!

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