-
Notifications
You must be signed in to change notification settings - Fork 526
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
Block-builder-scheduler initial structure #9650
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The skeleton LGTM! I left few minor comments. No need for me to re-review it.
} | ||
|
||
func (cfg *Config) RegisterFlags(f *flag.FlagSet) { | ||
f.StringVar(&cfg.BuilderConsumerGroup, "block-builder-scheduler.builder-consumer-group", "block-builder", "The Kafka consumer group used by block-builders.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what this will be used for. I didn't expect block builders to have a consumer group at all, given all offsets should be tracked by the scheduler. I suggest to remove this for now, and re-introduce it in a later PR if it will be effectively used (if so, why?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes. This is something @codesome and I discussed: in the v1 of the scheduler, we'll just have the block-builder workers continue to checkpoint offsets to Kafka. For 2 reasons:
- get v1 out quicker
- less risky for backlogs: if there is a large backlog that takes 6 hours to consume, we'll get smaller section-granularity checkpoints rather than everything riding on that 6 hour job to complete.
(But it's mostly about reason number 1.) Let me know your thoughts.
|
||
func (cfg *Config) RegisterFlags(f *flag.FlagSet) { | ||
f.StringVar(&cfg.BuilderConsumerGroup, "block-builder-scheduler.builder-consumer-group", "block-builder", "The Kafka consumer group used by block-builders.") | ||
f.StringVar(&cfg.SchedulerConsumerGroup, "block-builder-scheduler.scheduler-consumer-group", "block-builder-scheduler", "The Kafka consumer group used by block-builder-scheduler.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider removing scheduler-
prefix if ends up we'll not need the builder consumer groups too.
f.StringVar(&cfg.SchedulerConsumerGroup, "block-builder-scheduler.scheduler-consumer-group", "block-builder-scheduler", "The Kafka consumer group used by block-builder-scheduler.") | |
f.StringVar(&cfg.SchedulerConsumerGroup, "block-builder-scheduler.consumer-group", "block-builder-scheduler", "The Kafka consumer group used by block-builder-scheduler.") |
What this PR does
Adds initial structure for
block-builder-scheduler
living at pkg/blockbuilder/scheduler. Adds a newblock-builder-scheduler
target to the binary. This target currently just connects to Kafka and records per-partition start and end offset gauge metrics. In the future it will compute jobs and assign them to block-builder workers.Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]
.about-versioning.md
updated with experimental features.