Conversation
Signed-off-by: Robert Young <robertyoungnz@gmail.com>
robobario
force-pushed
the
design-process
branch
from
ec2d412 to
5ef06be
Compare
| * Wire-protocol changes (e.g. format of encrypted data emitted by Proxy) | ||
|
|
||
| Design proposals should be submitted to the [design repository](https://github.com/kroxylicious/design). | ||
|
|
There was a problem hiding this comment.
Should the cross posting of the design proposal kroxylicious-dev@googlegroups.com be part of the process?
There was a problem hiding this comment.
Yes, please! In fact I'd advocate:
- When the PR is "Ready for Review" (i.e. it's fine to open it as a Draft a solicit feedback from individual etc, but then announce to the whole community when you're ready for feedback from the whole community)
- If we end up doing formal voting on PRs: when asking to start the vote.
- When and if the PR is accepted (i.e. merged).
There was a problem hiding this comment.
added an instruction to post to the list when it's ready-to-review.
I think adding in voting procedure into this PR will complicate things, might be best put into a separate PR
tombentley
left a comment
tombentley
left a comment
There was a problem hiding this comment.
Thanks @robobario I left a few comments.
|
|
||
| Public APIs include (but are not limited to): | ||
| * Proxy configuration YAML | ||
| * Filter configuration YAML |
There was a problem hiding this comment.
I think we can generalise this from Filter to Plugin configuration. But also we should be clear that this only applies to those Plugins provided by the project ("1st party plugins" is the phrase I would use, but maybe it's worth a sentence to define it in words).
There was a problem hiding this comment.
do we need some weasel words like 'stable 1st party plugins'
| * Proxy configuration YAML | ||
| * Filter configuration YAML | ||
| * Kubernetes CRDs | ||
| * Operator manifested resources (like public bootstrap server addresses) |
There was a problem hiding this comment.
I didn't immediately understand what you meant here. But really I think this is mostly covered by the CRD part isn't it?
The semantics you want are a bit tricky, because it's not the kube resource themselves, so much as the visible parts of them. For example, so long as the hostname, port and expected protocol of a VC didn't change we are at liberty to change how those are provided in terms of the Kube resources.
There was a problem hiding this comment.
Yeah my thought was that the bootstrap servers is something that we can't just change lightly from one version of the operator to the next as established clients would lose connectivity. The CRD may be unchanged in that case, but if we change the naming scheme of the k8s Service for example, then some connectivity may be broken.
| * Kubernetes CRDs | ||
| * Operator manifested resources (like public bootstrap server addresses) | ||
| * Filter API (and other plugins) interfaces | ||
| * Wire-protocol changes (e.g. format of encrypted data emitted by Proxy) |
There was a problem hiding this comment.
Question: What about the test support maven modules? And the record tools module?
Aside: We should probably fix the split packages in those modules as part of Kroxylicious 1.0, so that we're moving towards having jars which are Java modules.
| * Changes to existing API signatures or behavior | ||
| * Removal or deprecation of APIs | ||
|
|
||
| Public APIs include (but are not limited to): |
There was a problem hiding this comment.
I need to define public API for the Kroxylicious 1.0 proposal, and it's also helpful to refer to it from a CLAUDE.md, so I think we should actually have a single source of truth as an .md in the kroxylicious/kroxylicious repo.
We should also make it an exhaustive list "Public APIs are:" not "include (but not limited to)". Otherwise it's all a bit too vague.
There was a problem hiding this comment.
I'm wondering if this PR can progress without listing out the public APIs.
On one hand I see that it's not very friendly to have a process laid out for Public APIs without defining what Public APIs are, but then on the other we are already directing users to create design proposals without having anything written down.
I'm wondering if we can live with separating things so we at least have this doc somewhere saying we need design proposals, then add in the comprehensive Public API lists later.
| * Wire-protocol changes (e.g. format of encrypted data emitted by Proxy) | ||
|
|
||
| Design proposals should be submitted to the [design repository](https://github.com/kroxylicious/design). | ||
|
|
There was a problem hiding this comment.
Yes, please! In fact I'd advocate:
- When the PR is "Ready for Review" (i.e. it's fine to open it as a Draft a solicit feedback from individual etc, but then announce to the whole community when you're ready for feedback from the whole community)
- If we end up doing formal voting on PRs: when asking to start the vote.
- When and if the PR is accepted (i.e. merged).
Signed-off-by: Robert Young <robertyoungnz@gmail.com>
Signed-off-by: Robert Young <robertyoungnz@gmail.com>
| * Kubernetes CRDs | ||
| * Operator manifested resources (like public bootstrap server addresses) | ||
| * Filter API (and other plugins) interfaces | ||
| * Wire-protocol changes (e.g. format of encrypted data emitted by Proxy) |
There was a problem hiding this comment.
I think people might struggle to understand what's meant by wire protocol changes. When I first read it, I wondered if you were referring to the API versions that a filter supported. I do agree that calling out the public API surface of filters as inscope is right.
How about adding a bullet
- Any public APIs surfaced by the filters included with Kroxylicous. This includes but is not limited to:
- changes to record headers added or mutated by the filter
- changes to how a filter mutates record keys or values (this includes changes to parcelling used by the record encryption).
3 participants
We decided in our community call to require a design proposal for public API changes