From dev-return-117967-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Thu Sep 17 21:01:38 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mailroute1-lw-us.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with ESMTPS id 0A398180642 for ; Thu, 17 Sep 2020 23:01:38 +0200 (CEST) Received: from mail.apache.org (localhost [127.0.0.1]) by mailroute1-lw-us.apache.org (ASF Mail Server at mailroute1-lw-us.apache.org) with SMTP id 1B6BF1240C0 for ; Thu, 17 Sep 2020 21:01:37 +0000 (UTC) Received: (qmail 48356 invoked by uid 500); 17 Sep 2020 21:01:35 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 48334 invoked by uid 99); 17 Sep 2020 21:01:35 -0000 Received: from spamproc1-he-fi.apache.org (HELO spamproc1-he-fi.apache.org) (95.217.134.168) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Sep 2020 21:01:35 +0000 Received: from localhost (localhost [127.0.0.1]) by spamproc1-he-fi.apache.org (ASF Mail Server at spamproc1-he-fi.apache.org) with ESMTP id 82BF3C0414 for ; Thu, 17 Sep 2020 21:01:34 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamproc1-he-fi.apache.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamproc1-he-fi.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=confluent.io Received: from mx1-he-de.apache.org ([116.203.227.195]) by localhost (spamproc1-he-fi.apache.org [95.217.134.168]) (amavisd-new, port 10024) with ESMTP id sqZ3lFV6fEg7 for ; Thu, 17 Sep 2020 21:01:30 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::32c; helo=mail-ot1-x32c.google.com; envelope-from=jolshan@confluent.io; receiver= Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 674A97F99E for ; Thu, 17 Sep 2020 21:01:30 +0000 (UTC) Received: by mail-ot1-x32c.google.com with SMTP id a2so3244430otr.11 for ; Thu, 17 Sep 2020 14:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=confluent.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RO4TguUptXcJhtsOswuo+/LeFNzAroZV2EYw6gAyF+I=; b=RPIDh3wV9wAIC5nG9Dn7Z4CBYtzSLsN2rla5T1h7iOS3s70tOSN7+fIMpKt3oNE/95 wQRAvK9G9F0KBOw5QXdlNbfaHk/K8LwWwHhLs9mLhrG4Ml/cmnEvfHKrjAuPpef+G0tb sI2G9uXw3CFo99CelNwMufhaO3QNaqpO6wNGqQwmnFGwxwXFPVIGW35mSi/3XAzwWIm3 0O5iWLn6hSuD50sHf7x8DJ9HIbZh1oQLpc4hY7knhLiOy1Bbr9NuCSLdXTBAwMRre+DZ HRA3HKL0xlYAbduirizXKnYWH0C1VKW0/HIY385M43N9RcJPjnTogITccqZjTR3yZNU4 EbXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RO4TguUptXcJhtsOswuo+/LeFNzAroZV2EYw6gAyF+I=; b=SEpzsDiPigEAxj2tju8IgJfU3haML6HNzCa7hQoeyUx+eVkZC7OPwQq2aPHZROex3U W86UxhS/Hy8oCd5QG0PSjklMq93v+74zmgEZ4M67NQbg37o+uPIGag4vIOgU77pxrhvc qUpKLL1BtHPyLPzQgMIPnab/B7dfx2cPZoQZ/su76Pxd9lhnxzPkNKlDHsiXyEaVhUg2 8kp2DCmtnSuRWRtPHikEdo5yqM+T3czyMB01ri8930BdtyBg3+UXgoOipA8hBZQOR1uA rlBMRopM0mSchrnpuRUoMYY1KInlCpHAME9pACOy4irUSgOdJY4cxth2OD8NHrEse12L XKTg== X-Gm-Message-State: AOAM533eEty9bpvROpwQClWmkeqmu6D9GBIvj/SEaMwgHq26QxLAFmOt ge4JTaQURO9zBvVbTifk9nPTDV/scxW2ydzLsBWzv90w4ccfoQ== X-Google-Smtp-Source: ABdhPJxz3yShlUER+C3/HP2KHLtfyyOC6oHWfA+VOYR8nlyQebRUUUMtHtQZAJMkF2KiyhMSSteO9CmmKgMC44EfXQk= X-Received: by 2002:a05:6830:1f16:: with SMTP id u22mr20000687otg.118.1600376488456; Thu, 17 Sep 2020 14:01:28 -0700 (PDT) MIME-Version: 1.0 References: <3be1ee1a-6ba8-458c-9c93-661fef74513f@www.fastmail.com> <051e55ba-bbc3-40e0-98c8-a9b1918b0da1@www.fastmail.com> <093cdcb5ea5eedfb9a4e32b06168195ffb706fb2.camel@apache.org> In-Reply-To: From: Justine Olshan Date: Thu, 17 Sep 2020 14:01:17 -0700 Message-ID: Subject: Re: [DISCUSS] KIP-516: Topic Identifiers To: dev@kafka.apache.org Content-Type: multipart/alternative; boundary="0000000000001a44d005af88b060" --0000000000001a44d005af88b060 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, I've thought some more about removing the topic name field from some of the requests. On closer inspection of the requests/responses, it seems that the internal changes would be much larger than I expected. Some protocols involve clients, so they would require changes too. I'm thinking that for now, removing the topic name from these requests and responses are out of scope. I have decided to just keep the change LeaderAndIsrResponse to remove the topic name, and have updated the KIP to reflect this change. I have also mentioned the other requests and responses in future work. I'm hoping to start the voting process soon, so let me know if there is anything else we should discuss. Thank you, Justine On Tue, Sep 15, 2020 at 3:57 PM Justine Olshan wrote= : > Hello again, > To follow up on some of the other comments: > > 10/11) We can remove the topic name from these requests/responses, and > that means we will just have to make a few internal changes to make > partitions accessible by topic id and partition. I can update the KIP to > remove them unless anyone thinks they should stay. > > 12) Addressed in the previous email. I've updated the KIP to include > tagged fields for the requests and responses. (More on that below) > > 13) I think part of the idea for including this information is to prepare > for future changes. Perhaps the directory structure might change from > topicName_partitionNumber to something like topicID_partitionNumber. Then > it would be useful to have the topic name in the file since it would not = be > in the directory structure. Supporting topic renames might be easier if t= he > other fields are included. Would there be any downsides to including this > information? > > 14) Yes, we would need to copy the partition metadata file in this > process. I've updated the KIP to include this. > > 15) I believe Lucas meant v1 and v2 here. He was referring to how the > requests would fall under different IBP and meant that older brokers woul= d > have to use the older version of the request and the existing topic > deletion process. At first, it seemed like tagged fields would resolve > the IBP issue. However, we may need IBP for this request after all since > the controller handles the topic deletion differently depending on the IB= P > version. In an older version, we can't just send a StopReplica delete the > topic immediately like we'd want to for this KIP. > > This makes me wonder if we want tagged fields on all the requests after > all. Let me know your thoughts! > > Justine > > On Tue, Sep 15, 2020 at 1:03 PM Justine Olshan > wrote: > >> Hi all, >> Jun brought up a good point in his last email about tagged fields, and >> I've updated the KIP to reflect that the changes to requests and respons= es >> will be in the form of tagged fields to avoid changing IBP. >> >> Jun: I plan on sending a followup email to address some of the other >> points. >> >> Thanks, >> Justine >> >> On Mon, Sep 14, 2020 at 4:25 PM Jun Rao wrote: >> >>> Hi, Justine, >>> >>> Thanks for the updated KIP. A few comments below. >>> >>> 10. LeaderAndIsr Response: Do we need the topic name? >>> >>> 11. For the changed request/response, other than LeaderAndIsr, >>> UpdateMetadata, Metadata, do we need to include the topic name? >>> >>> 12. It seems that upgrades don't require IBP. Does that mean the new >>> fields >>> in all the request/response are added as tagged fields without bumping = up >>> the request version? It would be useful to make that clear. >>> >>> 13. Partition Metadata file: Do we need to include the topic name and t= he >>> partition id since they are implied in the directory name? >>> >>> 14. In the JBOD mode, we support moving a partition's data from one dis= k >>> to >>> another. Will the new partition metadata file be copied during that >>> process? >>> >>> 15. The KIP says "Remove deleted topics from replicas by sending >>> StopReplicaRequest V2 for any topics which do not contain a topic ID, a= nd >>> V3 for any topics which do contain a topic ID.". However, it seems the >>> updated controller will create all missing topic IDs first before doing >>> other actions. So, is StopReplicaRequest V2 needed? >>> >>> Jun >>> >>> On Fri, Sep 11, 2020 at 10:31 AM John Roesler >>> wrote: >>> >>> > Thanks, Justine! >>> > >>> > Your response seems compelling to me. >>> > >>> > -John >>> > >>> > On Fri, 2020-09-11 at 10:17 -0700, Justine Olshan wrote: >>> > > Hello all, >>> > > Thanks for continuing the discussion! I have a few responses to you= r >>> > points. >>> > > >>> > > Tom: You are correct in that this KIP has not mentioned the >>> > > DeleteTopicsRequest. I think that this would be out of scope for >>> now, but >>> > > may be something worth adding in the future. >>> > > >>> > > John: We did consider sequence ids, but there are a few reasons to >>> favor >>> > > UUIDs. There are several cases where topics from different clusters >>> may >>> > > interact now and in the future. For example, Mirror Maker 2 may >>> benefit >>> > > from being able to detect when a cluster being mirrored is deleted >>> and >>> > > recreated and globally unique identifiers would make resolving issu= es >>> > > easier than sequence IDs which may collide between clusters. KIP-40= 5 >>> > > (tiered storage) will also benefit from globally unique IDs as shar= ed >>> > > buckets may be used between clusters. >>> > > >>> > > Globally unique IDs would also make functionality like moving topic= s >>> > > between disparate clusters easier in the future, simplify any futur= e >>> > > implementations of backups and restores, and more. In general, >>> unique IDs >>> > > would ensure that the source cluster topics do not conflict with th= e >>> > > destination cluster topics. >>> > > >>> > > If we were to use sequence ids, we would need sufficiently large >>> cluster >>> > > ids to be stored with the topic identifiers or we run the risk of >>> > > collisions. This will give up any advantage in compactness that >>> sequence >>> > > numbers may bring. Given these advantages I think it makes sense to >>> use >>> > > UUIDs. >>> > > >>> > > Gokul: This is an interesting idea, but this is a breaking change. >>> Out of >>> > > scope for now, but maybe worth discussing in the future. >>> > > >>> > > Hope this explains some of the decisions, >>> > > >>> > > Justine >>> > > >>> > > >>> > > >>> > > On Fri, Sep 11, 2020 at 8:27 AM Gokul Ramanan Subramanian < >>> > > gokul2411s@gmail.com> wrote: >>> > > >>> > > > Hi. >>> > > > >>> > > > Thanks for the KIP. >>> > > > >>> > > > Have you thought about whether it makes sense to support >>> authorizing a >>> > > > principal for a topic ID rather than a topic name to achieve >>> tighter >>> > > > security? >>> > > > >>> > > > Or is the topic ID fundamentally an internal detail similar to >>> epochs >>> > used >>> > > > in a bunch of other places in Kafka? >>> > > > >>> > > > Thanks. >>> > > > >>> > > > On Fri, Sep 11, 2020 at 4:06 PM John Roesler >>> > wrote: >>> > > > >>> > > > > Hello Justine, >>> > > > > >>> > > > > Thanks for the KIP! >>> > > > > >>> > > > > I happen to have been confronted recently with the need to keep >>> > track of >>> > > > a >>> > > > > large number of topics as compactly as possible. I was going to >>> come >>> > up >>> > > > > with some way to dictionary encode the topic names as integers, >>> but >>> > this >>> > > > > seems much better! >>> > > > > >>> > > > > Apologies if this has been raised before, but I=E2=80=99m wonde= ring >>> about the >>> > > > > choice of UUID vs sequence number for the ids. Typically, I=E2= =80=99ve >>> seen >>> > UUIDs >>> > > > > in two situations: >>> > > > > 1. When processes need to generate non-colliding identifiers >>> without >>> > > > > coordination. >>> > > > > 2. When the identifier needs to be =E2=80=9Cuniversally unique= =E2=80=9D; I.e., >>> the >>> > > > > identifier needs to distinguish the entity from all other >>> entities >>> > that >>> > > > > could ever exist. This is useful in cases where entities from a= ll >>> > kinds >>> > > > of >>> > > > > systems get mixed together, such as when dumping logs from all >>> > processes >>> > > > in >>> > > > > a company into a common system. >>> > > > > >>> > > > > Maybe I=E2=80=99m being short-sighted, but it doesn=E2=80=99t s= eem like either >>> really >>> > > > > applies here. It seems like the brokers could and would achieve >>> > consensus >>> > > > > when creating a topic anyway, which is all that=E2=80=99s requi= red to >>> > generate >>> > > > > non-colliding sequence ids. For the second, as you mention, we >>> could >>> > > > assign >>> > > > > a UUID to the cluster as a whole, which would render any resour= ce >>> > scoped >>> > > > to >>> > > > > the broker universally unique as well. >>> > > > > >>> > > > > The reason I mention this is that, although a UUID is way more >>> > compact >>> > > > > than topic names, it=E2=80=99s still 16 bytes. In contrast, a 4= -byte >>> integer >>> > > > > sequence id would give us 4 billion unique topics per cluster, >>> which >>> > > > seems >>> > > > > like enough ;) >>> > > > > >>> > > > > Considering the number of different times these topic >>> identifiers are >>> > > > sent >>> > > > > over the wire or stored in memory, it seems like it might be >>> worth >>> > the >>> > > > > additional 4x space savings. >>> > > > > >>> > > > > What do you think about this? >>> > > > > >>> > > > > Thanks, >>> > > > > John >>> > > > > >>> > > > > On Fri, Sep 11, 2020, at 03:20, Tom Bentley wrote: >>> > > > > > Hi Justine, >>> > > > > > >>> > > > > > This looks like a very welcome improvement. Thanks! >>> > > > > > >>> > > > > > Maybe I missed it, but the KIP doesn't seem to mention changi= ng >>> > > > > > DeleteTopicsRequest to identify the topic using an id. Maybe >>> > that's out >>> > > > > of >>> > > > > > scope, but DeleteTopicsRequest is not listed among the Future >>> Work >>> > APIs >>> > > > > > either. >>> > > > > > >>> > > > > > Kind regards, >>> > > > > > >>> > > > > > Tom >>> > > > > > >>> > > > > > On Thu, Sep 10, 2020 at 3:59 PM Satish Duggana < >>> > > > satish.duggana@gmail.com >>> > > > > > wrote: >>> > > > > > >>> > > > > > > Thanks Lucas/Justine for the nice KIP. >>> > > > > > > >>> > > > > > > It has several benefits which also include simplifying the >>> topic >>> > > > > > > deletion process by controller and logs cleanup by brokers = in >>> > corner >>> > > > > > > cases. >>> > > > > > > >>> > > > > > > Best, >>> > > > > > > Satish. >>> > > > > > > >>> > > > > > > On Wed, Sep 9, 2020 at 10:07 PM Justine Olshan < >>> > jolshan@confluent.io >>> > > > > > > wrote: >>> > > > > > > > Hello all, it's been almost a year! I've made some change= s >>> to >>> > this >>> > > > > KIP >>> > > > > > > and hope to continue the discussion. >>> > > > > > > > One of the main changes I've added is now the metadata >>> response >>> > > > will >>> > > > > > > include the topic ID (as Colin suggested). Clients can >>> obtain the >>> > > > > topicID >>> > > > > > > of a given topic through a TopicDescription. The topicId wi= ll >>> > also be >>> > > > > > > included with the UpdateMetadata request. >>> > > > > > > > Let me know what you all think. >>> > > > > > > > Thank you, >>> > > > > > > > Justine >>> > > > > > > > >>> > > > > > > > On 2019/09/13 16:38:26, "Colin McCabe" >> > >>> > wrote: >>> > > > > > > > > Hi Lucas, >>> > > > > > > > > >>> > > > > > > > > Thanks for tackling this. Topic IDs are a great idea, >>> and >>> > this >>> > > > is >>> > > > > a >>> > > > > > > really good writeup. >>> > > > > > > > > For /brokers/topics/[topic], the schema version should = be >>> > bumped >>> > > > to >>> > > > > > > version 3, rather than 2. KIP-455 bumped the version of th= is >>> > znode >>> > > > to >>> > > > > 2 >>> > > > > > > already :) >>> > > > > > > > > Given that we're going to be seeing these things as >>> strings >>> > as >>> > > > lot >>> > > > > (in >>> > > > > > > logs, in ZooKeeper, on the command-line, etc.), does it mak= e >>> > sense to >>> > > > > use >>> > > > > > > base64 when converting them to strings? >>> > > > > > > > > Here is an example of the hex representation: >>> > > > > > > > > 6fcb514b-b878-4c9d-95b7-8dc3a7ce6fd8 >>> > > > > > > > > >>> > > > > > > > > And here is an example in base64. >>> > > > > > > > > b8tRS7h4TJ2Vt43Dp85v2A >>> > > > > > > > > >>> > > > > > > > > The base64 version saves 15 letters (to be fair, 4 of >>> those >>> > were >>> > > > > > > dashes that we could have elided in the hex representation.= ) >>> > > > > > > > > Another thing to consider is that we should specify tha= t >>> the >>> > > > > > > all-zeroes UUID is not a valid topic UUID. We can't use >>> null >>> > for >>> > > > this >>> > > > > > > because we can't pass a null UUID over the RPC protocol >>> (there >>> > is no >>> > > > > > > special pattern for null, nor do we want to waste space >>> reserving >>> > > > such >>> > > > > a >>> > > > > > > pattern.) >>> > > > > > > > > Maybe I missed it, but did you describe "migration of..= . >>> > existing >>> > > > > > > topic[s] without topic IDs" in detail in any section? It >>> seems >>> > like >>> > > > > when >>> > > > > > > the new controller becomes active, it should just generate >>> random >>> > > > > UUIDs for >>> > > > > > > these, and write the random UUIDs back to ZooKeeper. It >>> would be >>> > > > good >>> > > > > to >>> > > > > > > spell that out. We should make it clear that this happens >>> > regardless >>> > > > > of >>> > > > > > > the inter-broker protocol version (it's a compatible change= ). >>> > > > > > > > > "LeaderAndIsrRequests including an is_every_partition >>> flag" >>> > > > seems a >>> > > > > > > bit wordy. Can we just call these "full >>> LeaderAndIsrRequests"? >>> > Then >>> > > > > the >>> > > > > > > RPC field could be named "full". Also, it would probably b= e >>> > better >>> > > > > for the >>> > > > > > > RPC field to be an enum of { UNSPECIFIED, INCREMENTAL, FULL >>> }, so >>> > > > that >>> > > > > we >>> > > > > > > can cleanly handle old versions (by treating them as >>> UNSPECIFIED) >>> > > > > > > > > In the LeaderAndIsrRequest section, you write "A final >>> > deletion >>> > > > > event >>> > > > > > > will be secheduled for X ms after the LeaderAndIsrRequest w= as >>> > first >>> > > > > > > received..." I guess the X was a placeholder that you >>> intended >>> > to >>> > > > > replace >>> > > > > > > before posting? :) In any case, this seems like the kind o= f >>> > thing >>> > > > we'd >>> > > > > > > want a configuration for. Let's describe that configuratio= n >>> key >>> > > > > somewhere >>> > > > > > > in this KIP, including what its default value is. >>> > > > > > > > > We should probably also log a bunch of messages at WARN >>> level >>> > > > when >>> > > > > > > something is scheduled for deletion, as well. (Maybe this >>> was >>> > > > > assumed, but >>> > > > > > > it would be good to mention it). >>> > > > > > > > > I feel like there are a few sections that should be >>> moved to >>> > > > > "rejected >>> > > > > > > alternatives." For example, in the DeleteTopics section, >>> since >>> > we're >>> > > > > not >>> > > > > > > going to do option 1 or 2, these should be moved into >>> "rejected >>> > > > > > > alternatives," rather than appearing inline. Another case >>> is >>> > the >>> > > > > "Should >>> > > > > > > we remove topic name from the protocol where possible" >>> section. >>> > This >>> > > > > is >>> > > > > > > clearly discussing a design alternative that we're not >>> proposing >>> > to >>> > > > > > > implement: removing the topic name from those protocols. >>> > > > > > > > > Is it really necessary to have a new >>> > /admin/delete_topics_by_id >>> > > > > path >>> > > > > > > in ZooKeeper? It seems like we don't really need this. >>> Whenever >>> > > > > there is >>> > > > > > > a new controller, we'll send out full LeaderAndIsrRequests >>> which >>> > will >>> > > > > > > trigger the stale topics to be cleaned up. The active >>> > controller >>> > > > will >>> > > > > > > also send the full LeaderAndIsrRequest to brokers that are >>> just >>> > > > > starting >>> > > > > > > up. So we don't really need this kind of two-phase commi= t >>> > (send >>> > > > out >>> > > > > > > StopReplicasRequest, get ACKs from all nodes, commit by >>> removing >>> > > > > > > /admin/delete_topics node) any more. >>> > > > > > > > > You mention that FetchRequest will now include UUID to >>> avoid >>> > > > issues >>> > > > > > > where requests are made to stale partitions. However, >>> adding a >>> > UUID >>> > > > to >>> > > > > > > MetadataRequest is listed as future work, out of scope for >>> this >>> > KIP. >>> > > > > How >>> > > > > > > will the client learn what the topic UUID is, if the metada= ta >>> > > > response >>> > > > > > > doesn't include that information? It seems like adding the >>> UUID >>> > to >>> > > > > > > MetadataResponse would be an improvement here that might no= t >>> be >>> > too >>> > > > > hard to >>> > > > > > > make. >>> > > > > > > > > best, >>> > > > > > > > > Colin >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > On Mon, Sep 9, 2019, at 17:48, Ryanne Dolan wrote: >>> > > > > > > > > > Lucas, this would be great. I've run into issues with >>> > topics >>> > > > > being >>> > > > > > > > > > resurrected accidentally, since a client cannot easil= y >>> > > > > distinguish >>> > > > > > > between >>> > > > > > > > > > a deleted topic and a new topic with the same name. I= 'd >>> > need >>> > > > the >>> > > > > ID >>> > > > > > > > > > accessible from the client to solve that issue, but >>> this >>> > is a >>> > > > > good >>> > > > > > > first >>> > > > > > > > > > step. >>> > > > > > > > > > >>> > > > > > > > > > Ryanne >>> > > > > > > > > > >>> > > > > > > > > > On Wed, Sep 4, 2019 at 1:41 PM Lucas Bradstreet < >>> > > > > lucas@confluent.io> >>> > > > > > > wrote: >>> > > > > > > > > > > Hi all, >>> > > > > > > > > > > >>> > > > > > > > > > > I would like to kick off discussion of KIP-516, an >>> > > > > implementation >>> > > > > > > of topic >>> > > > > > > > > > > IDs for Kafka. Topic IDs aim to solve topic >>> uniqueness >>> > > > > problems in >>> > > > > > > Kafka, >>> > > > > > > > > > > where referring to a topic by name alone is >>> insufficient. >>> > > > Such >>> > > > > > > cases >>> > > > > > > > > > > include when a topic has been deleted and recreated >>> with >>> > the >>> > > > > same >>> > > > > > > name. >>> > > > > > > > > > > Unique identifiers will help simplify and improve >>> Kafka's >>> > > > topic >>> > > > > > > deletion >>> > > > > > > > > > > process, as well as prevent cases where brokers may >>> > > > incorrectly >>> > > > > > > interact >>> > > > > > > > > > > with stale versions of topics. >>> > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>> > > > >>> > >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-516%3A+Topic+Iden= tifiers >>> > > > > > > > > > > Looking forward to your thoughts. >>> > > > > > > > > > > >>> > > > > > > > > > > Lucas >>> > > > > > > > > > > >>> > >>> > >>> >> --0000000000001a44d005af88b060--