Search before asking
Motivation
Apache Fluss needs a first Kafka protocol compatibility milestone that allows standard Kafka producers to discover Fluss tables and write records without changing the Kafka client.
The target workflow is DDL-first: users create and manage tables and schemas through Fluss DDL, then produce JSON records through the Kafka protocol. Schema-aware conversion maps records into the pre-defined table schema and existing Fluss storage format. Kafka CreateTopics, DeleteTopics, and automatic table creation are not part of this milestone.
This umbrella is issue-driven: define a focused child issue, link its implementation PR, review it, and then move to the next capability. The foundation and Basic Produce tasks below follow dependency order. The previous four-PR approach has been retired and is not part of the current dependency chain.
Sub-tasks
Only scoped child issues are listed here. Each issue owns its scope, acceptance criteria, dependencies, and implementation PR. An issue is complete after the reviewed implementation meets those criteria and is merged, not merely after a PR is opened.
Foundation
Review and dependency order: #4264 → #4265 → #4275 → #4266.
Basic Produce
Core changes (independent review and merge)
Planned follow-ups
Create additional child issues progressively after the scoped foundation and Basic Produce tasks. These are directions for later issue scoping, not a commitment to reuse the closed implementation PRs.
Capability
- SASL/PLAIN authentication: handshake, per-connection authentication state, and credential validation.
- Schema-aware JSON Produce: table-metadata-based record mapping, JSON decoding, validation, and conversion to Fluss rows.
Delivery
- End-to-end validation of DDL → Metadata → Kafka producer → Fluss readback, including schema handling, acknowledgements, authentication, and failure cases.
- Configuration and compatibility documentation, supported API/version boundaries, DDL/JSON examples, and Fluss RPC/server regression coverage.
Future Work
Outside this Basic Produce milestone:
- Idempotent and transactional Produce.
- Bounded Produce admission and flow control.
- Kafka consumer and Fetch compatibility.
- Further authoritative ISR propagation and publisher/cache hardening beyond Metadata discovery.
Review workflow
- Create a child issue with a bounded scope, acceptance criteria, and explicit dependencies.
- Link a focused implementation PR to that child issue; do not close the umbrella from an individual PR.
- Review Kafka feature issues in dependency order. Keep dependent PRs as drafts and use incremental comparisons while prerequisites are unmerged.
- As prerequisites merge, rebase dependent branches onto the updated
main and validate again. Record completion through the child issues, then scope the next unit.
Willingness to contribute
Search before asking
Motivation
Apache Fluss needs a first Kafka protocol compatibility milestone that allows standard Kafka producers to discover Fluss tables and write records without changing the Kafka client.
The target workflow is DDL-first: users create and manage tables and schemas through Fluss DDL, then produce JSON records through the Kafka protocol. Schema-aware conversion maps records into the pre-defined table schema and existing Fluss storage format. Kafka
CreateTopics,DeleteTopics, and automatic table creation are not part of this milestone.This umbrella is issue-driven: define a focused child issue, link its implementation PR, review it, and then move to the next capability. The foundation and Basic Produce tasks below follow dependency order. The previous four-PR approach has been retired and is not part of the current dependency chain.
Sub-tasks
Only scoped child issues are listed here. Each issue owns its scope, acceptance criteria, dependencies, and implementation PR. An issue is complete after the reviewed implementation meets those criteria and is merged, not merely after a PR is opened.
Foundation
Review and dependency order: #4264 → #4265 → #4275 → #4266.
Basic Produce
Core changes (independent review and merge)
Planned follow-ups
Create additional child issues progressively after the scoped foundation and Basic Produce tasks. These are directions for later issue scoping, not a commitment to reuse the closed implementation PRs.
Capability
Delivery
Future Work
Outside this Basic Produce milestone:
Review workflow
mainand validate again. Record completion through the child issues, then scope the next unit.Willingness to contribute