Hi Ismael, Thanks for your comments.
Regarding the loophole issue, keep in mind that the alter topics > authorization would still be required, so I don't think it's an issue > It could be an issue for people trying to provide a Kafka-as-a-Service offering, couldn't it? I mean if the providers are using the policy to enforce a maximum number of partitions rule on their customers, but they've also given those customers Alter(Topic) so they can change topics configs then this API provides a loophole that wouldn't otherwise exist. Moreover the motivation in KIP-170 suggests to me that this isn't a hypothetical issue. update the KIP so that the request must > be sent to the Controller and we wait until the data is propagated into the > Controller's metadata cache > About whether we send the request to the controller and when we consider the request to have completed successfully... Currently the kafka-topics.sh tool considers the change successful if the change was written to ZK. I'm happy to change it, but: a) I wanted to highlight that it would be a small change in semantics b) OTOH is there any benefit to clients to change the success criterion to when the metadata cache gets updated? If not then shouldn't we stick to the existing criterion of a successful write to ZK? Thanks, Tom On 12 September 2017 at 16:30, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Tom, > > OK, I suggest not calling any policy then. We can do a separate KIP for > overhauling topic policies so that they work with all operations for 1.1.0. > Regarding the loophole issue, keep in mind that the alter topics > authorization would still be required, so I don't think it's an issue. > Users that really need a policy will have to wait until 1.1.0, but that's > no worse than if KIP-195 doesn't make it into 1.0.0. > > If you remove the policy text and update the KIP so that the request must > be sent to the Controller and we wait until the data is propagated into the > Controller's metadata cache (similar to create topic), it's a +1 from me. > > Ismael > > On Tue, Sep 12, 2017 at 10:26 AM, Tom Bentley <t.j.bent...@gmail.com> > wrote: > > > 2. About using the create topics policy, I'm not sure. Aside from the > > > naming issue, there's also the problem that the policy doesn't know if > a > > > creation or update is taking place. This matters because one may not > want > > > to allow the number of partitions to be changed after creation as it > > > affects the semantics if keys are used. One option is to introduce a > new > > > interface that can be used by create, alter and delete with a new > config. > > > And deprecate CreateTopicPolicy. I doubt many are using it. What do you > > > think? > > > > > > > I included the part about the create topics policy because I felt it was > > better, in the short term, to prevent the loophole than to just ignore > it. > > The create topic policy is obviously not a good fit for applying to topic > > modifications, but I think designing a good policy interface that covered > > creation, modification and deletion could be the subject of its own KIP. > > Note that modification would include the APIs proposed in KIP-195 and > > KIP-179. KIP-170 is already proposing to change the creation policy and > add > > a deletion policy, so shouldn't the changes necessary for KIP-195 be > > considered as part of that KIP? > > > > I'm happy to propose something in KIP-195 if you really want, though it > > would put in doubt whether it could be part of Kafka 1.0.0. > > >
