It would certainly be possible to have the field be optional and only include it if some flag is set in the DescribeClusterOptions instance passed to Admin.describeCluster() that in turn would translate to a boolean in MetadataRequest indicating that we are asking for this piece of information.
I’m not entirely sure that this extra complexity would be worth it for the modestly smaller response size, in a message that already contains things like the hostname and rack identifier per broker. /noa > On 4 Nov 2019, at 14:45, Gwen Shapira <g...@confluent.io> wrote: > > Cluster metadata is sent to clients on a very regular basis. Adding > start-time there seems quite repetitive. Especially considering that > this information is only useful in very specific cases. > > Can we add this capability to the Admin API in a way that won't impact > normal client workflow? > > On Mon, Nov 4, 2019 at 4:05 AM Noa Resare <n...@resare.com> wrote: >> >> Thank you for the feedback, Stanislav! >> >> I agree that it would be good to harmonise the naming, and start-time-ms >> definitely more descriptive. >> >> I have updated the proposal to reflect this, and also added the updated json >> RPC changes. Please have a look. >> >> /noa >> >>> On 1 Nov 2019, at 09:13, Stanislav Kozlovski <stanis...@confluent.io> wrote: >>> >>> Hey Noa, >>> >>> KIP-436 added a JMX metric in Kafka for this exact use-case, called >>> `start-time-ms`. Perhaps it would be useful to name this public interface >>> in the same way for consistency. >>> >>> Could you update the KIP to include the specific RPC changes regarding the >>> metadata request/responses? Here is a recent example of how to portray the >>> changes - >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-525+-+Return+topic+metadata+and+configs+in+CreateTopics+response >>> >>> Thanks, >>> Stanislav! >>> >>> On Mon, Oct 14, 2019 at 2:46 PM Noa Resare <n...@resare.com> wrote: >>> >>>> We are in the process of migrating the pieces of automation that currently >>>> reads and modifies zookeeper state to use the Admin API. >>>> >>>> One of the things that we miss doing this is access to the start time of >>>> brokers in a cluster which is used by our automation doing rolling >>>> restarts. We currently read this from the timestamp field from the >>>> epehmeral broker znodes in zookeeper. To address this limitation, I have >>>> authored KIP-536, that proposes adding a timestamp field to the Node class >>>> that the AdminClient.describeCluster() method returns. >>>> >>>> >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-536%3A+Propagate+broker+timestamp+to+Admin+API >>>> < >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-536:+Propagate+broker+timestamp+to+Admin+API >>>>> >>>> >>>> Any and all feedback is most welcome >>>> >>>> cheers >>>> noa >>> >>> >>> >>> -- >>> Best, >>> Stanislav >>
