[ https://issues.apache.org/jira/browse/IMPALA-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510322#comment-16510322 ]
Tim Armstrong commented on IMPALA-7164: --------------------------------------- [~philip] I'm not opposed to that, but I think we can do the work incrementally if we separate out public/non-public counters first before we do a global change that enshrines all of the existing counters in the thrift definition. I'm thinking that there are probably < 50 counters that are actually widely used so putting those in one place feels pretty manageable once we identify them. > Define public API for RuntimeProfile > ------------------------------------ > > Key: IMPALA-7164 > URL: https://issues.apache.org/jira/browse/IMPALA-7164 > Project: IMPALA > Issue Type: Improvement > Components: Backend > Reporter: Tim Armstrong > Priority: Major > Labels: resource-management, usability > > Currently the only public API for the runtime profile is the Thrift > definition. The exact layout and counters are all implementation-dependent > and subject to change. People are trying to build tools that consume runtime > profiles and process them, but that's hard since the counters can change from > version to version and sometimes the semantics change. > I think we need to figure out which things are part of the public API, > validate that they make sense and document them clearly. We should also > clearly document that things outside of this public API are subject to change > without notice. I don't think the public API necessarily needs to be > "porcelain", but we should generally try to avoid unnecessary changes and > mention any changes in release notes etc. > We could start simple and just collect "public" counter names in a module and > comment each of them. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org