[DISCUSS] In flight work to complete before 2.5.0RC0

[Andrew Purtell <ap...@apache.org>]

As your branch-2.5 RM I am assembling a list of work items that should be
completed before a 2.5.0RC0 candidate is submitted for the PMC's
consideration.

I have so far:

- OpenTracing span naming convention and coverage improvements.

- Shell exit code fixes/improvements.

- The "encryption improvements umbrella". Arguable, but let's include it
for now. Can all be resolved as Later if need be.

Let's discuss what else, if anything, should be on this list, or if one or
more of the above items does not constitute a release blocker. I consider
incomplete work-in-progress a blocker. Obviously all of the work in
progress should land before release. For WIP, let's also agree on a
definition of done.

-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] In flight work to complete before 2.5.0RC0

[Andrew Purtell <an...@gmail.com>]

Thanks Duo.

I haven’t been around much lately but will be reviewing and progressing PRs for branch-2 / branch-2.5 more actively now. A committer or contributor looking for a review can at-mention me on a relevant JIRA to get my attention. That will drop a notification mail into my inbox. (GitHub emails go to /dev/null, there are too many.) 

> On Dec 8, 2021, at 6:09 PM, 张铎 <pa...@gmail.com> wrote:
> 
> OpenTracing -> OpenTelemetry :)
> 
> For me, I think the OpenTelemetry part is a blocker, we must finish it
> before cutting an RC since the current implementation is already landed on
> branch-2.5 and it breaks some Otel best practises, so we should not release
> it out.
> 
> Now it is only Nick doing the work and Tak Lon Wu and I reviewing the PRs.
> And I also joined the CNCF slack channel and saw Nick is working hard in
> communication with the Otel community on how to better implement tracing in
> HBase, for example, how to trace big scans.
> I would encourage more people in our community to involve so we can make
> progress faster.
> 
> Thanks.
> 
> Sean Busbey <bu...@apache.org> 于2021年12月9日周四 10:02写道：
> 
>> If we don't want to wait for HBASE-26543 (fix arg parsing for shell)
>> then we should revert HBASE-24772 from branch-2.5 prior to an RC.
>> 
>> 
>>> On Wed, Dec 8, 2021 at 7:34 PM Andrew Purtell <ap...@apache.org> wrote:
>>> 
>>> As your branch-2.5 RM I am assembling a list of work items that should be
>>> completed before a 2.5.0RC0 candidate is submitted for the PMC's
>>> consideration.
>>> 
>>> I have so far:
>>> 
>>> - OpenTracing span naming convention and coverage improvements.
>>> 
>>> - Shell exit code fixes/improvements.
>>> 
>>> - The "encryption improvements umbrella". Arguable, but let's include it
>>> for now. Can all be resolved as Later if need be.
>>> 
>>> Let's discuss what else, if anything, should be on this list, or if one
>> or
>>> more of the above items does not constitute a release blocker. I consider
>>> incomplete work-in-progress a blocker. Obviously all of the work in
>>> progress should land before release. For WIP, let's also agree on a
>>> definition of done.
>>> 
>>> --
>>> Best regards,
>>> Andrew
>>> 
>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>> decrepit hands
>>>   - A23, Crosstalk
>> 

Re: [DISCUSS] In flight work to complete before 2.5.0RC0

[Nick Dimiduk <nd...@apache.org>]

Hi Andrew and team,

The other one I'd like to land for 2.5 is the region visualizer
on HBASE-25865. It stalled for most of the year as it required embedding an
HTTP/JSON API into the Master's WebUI, and I identified issues with our
shading of Jersey and its associated JSR implementations. Since those have
been fixed in hbase-thirdparty-4.0.0, I'd like to revive this feature and
bring it home to conclusion.

There are screenshots of the progress thus far attached to the jira. I've
implemented one visualization, a stacked bar chart that illustrates the
total storefile size per table per region server. As a stretch-goal (or
follow-on), I'd also like to implement a region size histogram. Once we
have a couple in place, there should be enough code infrastructure that
adding other views will be relatively painless. For now, the browser-side
development goes slowly because I have limited JavaScript skills.

As mentioned, this feature relies on an HTTP/JSON endpoint being exposed by
the WebUI that hosts the visualization. I have implemented the bare minimum
required endpoint for the visualization that I have on the
sub-task HBASE-25895. While I intend this to be advertised as an
internal-only, IA.Private API, it deserves some scrutiny.

Thanks,
Nick

On Thu, Dec 9, 2021 at 4:03 PM Nick Dimiduk <nd...@apache.org> wrote:

> The OpenTelemetry improvements are tracked as subtasks of HBASE-26419 [0].
> More eyes on the open PRs would be very helpful, and if anyone is
> interested in joining the discussion in the CNCF community, you can join
> their Slack [1]. One change often depends on the previous, so I have been
> working through the list and pushing patches onto a feature branch [2].
>
> Thanks,
> Nick
>
> [0]: https://issues.apache.org/jira/browse/HBASE-26419
> [1]: https://cloud-native.slack.com/archives/C0150QF88FL
> [2]:
> https://github.com/ndimiduk/hbase/tree/26419-otel-semantic-conventions
>
> On Wed, Dec 8, 2021 at 6:09 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
>> OpenTracing -> OpenTelemetry :)
>>
>> For me, I think the OpenTelemetry part is a blocker, we must finish it
>> before cutting an RC since the current implementation is already landed on
>> branch-2.5 and it breaks some Otel best practises, so we should not
>> release
>> it out.
>>
>> Now it is only Nick doing the work and Tak Lon Wu and I reviewing the PRs.
>> And I also joined the CNCF slack channel and saw Nick is working hard in
>> communication with the Otel community on how to better implement tracing
>> in
>> HBase, for example, how to trace big scans.
>> I would encourage more people in our community to involve so we can make
>> progress faster.
>>
>> Thanks.
>>
>> Sean Busbey <bu...@apache.org> 于2021年12月9日周四 10:02写道：
>>
>> > If we don't want to wait for HBASE-26543 (fix arg parsing for shell)
>> > then we should revert HBASE-24772 from branch-2.5 prior to an RC.
>> >
>> >
>> > On Wed, Dec 8, 2021 at 7:34 PM Andrew Purtell <ap...@apache.org>
>> wrote:
>> > >
>> > > As your branch-2.5 RM I am assembling a list of work items that
>> should be
>> > > completed before a 2.5.0RC0 candidate is submitted for the PMC's
>> > > consideration.
>> > >
>> > > I have so far:
>> > >
>> > > - OpenTracing span naming convention and coverage improvements.
>> > >
>> > > - Shell exit code fixes/improvements.
>> > >
>> > > - The "encryption improvements umbrella". Arguable, but let's include
>> it
>> > > for now. Can all be resolved as Later if need be.
>> > >
>> > > Let's discuss what else, if anything, should be on this list, or if
>> one
>> > or
>> > > more of the above items does not constitute a release blocker. I
>> consider
>> > > incomplete work-in-progress a blocker. Obviously all of the work in
>> > > progress should land before release. For WIP, let's also agree on a
>> > > definition of done.
>> > >
>> > > --
>> > > Best regards,
>> > > Andrew
>> > >
>> > > Words like orphans lost among the crosstalk, meaning torn from truth's
>> > > decrepit hands
>> > >    - A23, Crosstalk
>> >
>>
>

Re: [DISCUSS] In flight work to complete before 2.5.0RC0

["张铎(Duo Zhang)" <pa...@gmail.com>]

OpenTracing -> OpenTelemetry :)

For me, I think the OpenTelemetry part is a blocker, we must finish it
before cutting an RC since the current implementation is already landed on
branch-2.5 and it breaks some Otel best practises, so we should not release
it out.

Now it is only Nick doing the work and Tak Lon Wu and I reviewing the PRs.
And I also joined the CNCF slack channel and saw Nick is working hard in
communication with the Otel community on how to better implement tracing in
HBase, for example, how to trace big scans.
I would encourage more people in our community to involve so we can make
progress faster.

Thanks.

Sean Busbey <bu...@apache.org> 于2021年12月9日周四 10:02写道：

> If we don't want to wait for HBASE-26543 (fix arg parsing for shell)
> then we should revert HBASE-24772 from branch-2.5 prior to an RC.
>
>
> On Wed, Dec 8, 2021 at 7:34 PM Andrew Purtell <ap...@apache.org> wrote:
> >
> > As your branch-2.5 RM I am assembling a list of work items that should be
> > completed before a 2.5.0RC0 candidate is submitted for the PMC's
> > consideration.
> >
> > I have so far:
> >
> > - OpenTracing span naming convention and coverage improvements.
> >
> > - Shell exit code fixes/improvements.
> >
> > - The "encryption improvements umbrella". Arguable, but let's include it
> > for now. Can all be resolved as Later if need be.
> >
> > Let's discuss what else, if anything, should be on this list, or if one
> or
> > more of the above items does not constitute a release blocker. I consider
> > incomplete work-in-progress a blocker. Obviously all of the work in
> > progress should land before release. For WIP, let's also agree on a
> > definition of done.
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
>

Re: [DISCUSS] In flight work to complete before 2.5.0RC0

[Sean Busbey <bu...@apache.org>]

If we don't want to wait for HBASE-26543 (fix arg parsing for shell)
then we should revert HBASE-24772 from branch-2.5 prior to an RC.


On Wed, Dec 8, 2021 at 7:34 PM Andrew Purtell <ap...@apache.org> wrote:
>
> As your branch-2.5 RM I am assembling a list of work items that should be
> completed before a 2.5.0RC0 candidate is submitted for the PMC's
> consideration.
>
> I have so far:
>
> - OpenTracing span naming convention and coverage improvements.
>
> - Shell exit code fixes/improvements.
>
> - The "encryption improvements umbrella". Arguable, but let's include it
> for now. Can all be resolved as Later if need be.
>
> Let's discuss what else, if anything, should be on this list, or if one or
> more of the above items does not constitute a release blocker. I consider
> incomplete work-in-progress a blocker. Obviously all of the work in
> progress should land before release. For WIP, let's also agree on a
> definition of done.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk