busbey commented on issue #476: HBASE-11062 hbtop URL: https://github.com/apache/hbase/pull/476#issuecomment-525744723 > Downsides are it'd be awkward doing 'hbase hbtop'...etc. We could fix this by making it easier to add commands to the `hbase` wrapper. Could also ship a "default" hbtop version with instructions for updating if needed. Easier to do that updating if it has its own release cycle and artifacts compared to "download hbase X.Y.Z and pull out these jars for hbtop..." > On the Stack's first concern (that we should use a 3rd party terminal/libs instead of writing our own), I think we should use a terminal lib to avoid reinventing the wheel ideally. And as Andrew mentioned, we don't want to support that kinds of issues. Although I couldn't find a good terminal lib at the first try, I can retry to do that. Should I do it before it's committed? Or as a new issue after it's committed? Let's bias for action here. All of the terminal implementation stuff is marked IA.Private. If we find a suitable terminal library later we can change it out. > I want to make it available for not only branch-2+ but also branch-1. If we commit it to hbase-operator-tools, how do we manage the codes for the different versions? We need to create branches in hbase-operator-tools for the HBase versions? This is an unknown for that repo so far. Ideally we'd build compatibility into the tool so that we have a single place to do maintenance instead of having to go across branches. That said if branches are a lower barrier then branches it is. > Also, I want to add metrics to hbtop after it's committed. To do this, I will first need to add the metrics to ClusterMetrics in the HBase main project, and then add to hbtop itself. In this case, I think we will need to do release management in hbase-operator-tools as other hbase ecosystems like Phoenix do. Is this correct? > > For example, let's see we add some metrics to ClusterMetrics in hbase-2.1.6 and add the metrics to hbtop. After that, if we run the latest hbtop against hbase-2.1.5, it will crash because ClusterMetrics in hbase-2.1.5 doesn't have the additional metrics yet. So in this case, I think we need to create release tags for hbase-2.1.5 and hbase-2.1.6 in hbase-operator-tools, and need to run hbtop in a proper tag against the hbase version. yeah that's correct. Probably we'd need to do graceful fallback about what's available either through introspection of the returned metric or blunt version checks. a pain to be sure. > I think HBCK2 also has this kind of issue potentially. > But, I might be wrong. If so, please correct me. HBCK2 does have this issue and we're still iterating on the right trade off for handling it.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
