[GH-ISSUE #459] RFC: Mooncake Config Module #161

New issue

Closed

opened 2026-10-29 21:10:18 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-29 21:10:18 +00:00

Owner

Originally created by @xiaguan on GitHub (Jun 9, 2025).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/459

As the number of configuration options and constants in Mooncake keeps growing, it's becoming necessary to introduce a centralized config module to manage them in a clean and consistent way.

Motivation

Improve maintainability by organizing scattered configs and constants.
Make it easier to set and override config values through JSON, environment variables, or other external methods.
Provide clear documentation for each config, so ops and users know exactly what each option does.
Define the config class in C++ and expose it to Python.
Store-related config should be built on top of the transfer engine config or at least include it, as they are closely tied together.

Originally created by @xiaguan on GitHub (Jun 9, 2025). Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/459 As the number of configuration options and constants in Mooncake keeps growing, it's becoming necessary to introduce a centralized config module to manage them in a clean and consistent way. **Motivation** - Improve maintainability by organizing scattered configs and constants. - Make it easier to set and override config values through JSON, environment variables, or other external methods. - Provide clear documentation for each config, so ops and users know exactly what each option does. - Define the config class in C++ and expose it to Python. - Store-related config should be built on top of the transfer engine config or at least include it, as they are closely tied together.

bsakaguchi

2026-10-29 21:10:18 +00:00

closed this issue
added the
stale

auto-closed
labels

bsakaguchi commented

2026-10-29 21:10:19 +00:00

Author

Owner

@stmatengss commented on GitHub (Jun 9, 2025):

As the number of configuration options and constants in Mooncake keeps growing, it's becoming necessary to introduce a centralized config module to manage them in a clean and consistent way.

Motivation

Improve maintainability by organizing scattered configs and constants.

Make it easier to set and override config values through JSON, environment variables, or other external methods.

Provide clear documentation for each config, so ops and users know exactly what each option does.

Define the config class in C++ and expose it to Python.

Store-related config should be built on top of the transfer engine config or at least include it, as they are closely tied together.

We should support both JSON and YAML for easy integration with other projects. BTW, there is still a Python-based MooncakeConfig in the wheel. Should we modify it to fit into the requirements?

@stmatengss commented on GitHub (Jun 9, 2025): > As the number of configuration options and constants in Mooncake keeps growing, it's becoming necessary to introduce a centralized config module to manage them in a clean and consistent way. > > **Motivation** > > * Improve maintainability by organizing scattered configs and constants. > * Make it easier to set and override config values through JSON, environment variables, or other external methods. > * Provide clear documentation for each config, so ops and users know exactly what each option does. > * Define the config class in C++ and expose it to Python. > * Store-related config should be built on top of the transfer engine config or at least include it, as they are closely tied together. We should support both JSON and YAML for easy integration with other projects. BTW, there is still a Python-based MooncakeConfig in the wheel. Should we modify it to fit into the requirements?

bsakaguchi commented

2026-10-29 21:10:19 +00:00

Author

Owner

@xiaguan commented on GitHub (Jun 9, 2025):

BTW, there is still a Python-based MooncakeConfig in the wheel. Should we modify it to fit into the requirements?

Would be great if we could merge them. Keeping multiple config versions around gets messy.

@xiaguan commented on GitHub (Jun 9, 2025): > BTW, there is still a Python-based MooncakeConfig in the wheel. Should we modify it to fit into the requirements? Would be great if we could merge them. Keeping multiple config versions around gets messy.

bsakaguchi commented

2026-10-29 21:10:19 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 8, 2026):

This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

@github-actions[bot] commented on GitHub (Jul 8, 2026): This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

bsakaguchi commented

2026-10-29 21:10:19 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 16, 2026):

Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.

@github-actions[bot] commented on GitHub (Jul 16, 2026): Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.

bsakaguchi referenced this issue

2026-10-29 21:26:46 +00:00

[PR #161] [CLOSED] [TransferEngine] Refactor TE Return Value - part 2 #1363