hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-16756) InterfaceAudience annotate our protobuf; distinguish internal; publish public
Date Tue, 04 Oct 2016 05:00:32 GMT

     [ https://issues.apache.org/jira/browse/HBASE-16756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

stack updated HBASE-16756:
--------------------------
    Description: 
This is a follow-on from the work done over in HBASE-15638 Shade protobuf.

Currently protobufs are not annotated as our java classes are even though they are being used
by downstream Coprocessor Endpoints; i.e. if a CPEP wants to update a Cell in HBase or refer
to a server in the cluster, 9 times out of 10 they will depend on the HBase Cell.proto and
its generated classes or the ServerName definition in HBase.proto file.

This makes it so we cannot make breaking changes to the Cell type or relocate the ServerName
definition to another file if we want CPEPs to keep working.

The issue gets compounded by HBASE-15638 "Shade protobuf" where protos used internally are
relocated, and given another package name altogether. Currently we leave behind the old protos
(sort-of duplicated) so CPEPs keep working but going forward, IF WE CONTINUE DOWN THIS PATH
OF SHADING PROTOS (we may revisit if hadoop ends up isolating its classpath), then we need
to 'publish' protos that we will honor as we would classes annotate with @InterfaceAudience.Public
as part of our public API going forward.

What is involved is a review of the current protos under hbase-protocol. Sort out what is
to be made public. We will likely have to break up current proto files into smaller collections
since they currently contain mixes of public and private types. Deprecate the fat Admin and
Client protos.  This will allow us to better narrow the set of what we make public. These
new files could live in the hbase-protocol module suitably annotated or they could be done
up in a new module altogether. TODO.

  was:
This is a follow-on from the work done over in HBASE-15638 Shade protobuf.

Currently protobufs are not annotated as our java classes are even though they are being used
by downstream Coprocessor Endpoints; i.e. if a CPEP wants to update a Cell in HBase or refer
to a server in the cluster, 9 times out of 10 they will depend on the HBase Cell.proto and
its generated classes or the ServerName definition in HBase.proto file.

This makes it so we cannot make breaking changes to the Cell type or relocate the ServerName
definition to another file if we want CPEPs to keep working.

The issue gets compounded by HBASE-15638 "Shade protobuf" where protos used internally are
relocated, and given another package name altogether. Currently we leave behind the old protos
(sort-of duplicated) so CPEPs keep working but going forward, IF WE CONTINUE DOWN THIS PATH
OF SHADING PROTOS (we may revisit if hadoop ends up isolating its classpath), then we need
to 'publish' protos that we will honor as we would classes annotate with @InterfaceAudience.Public
as part of our public API going forward.

What is involved is a review of the current protos under hbase-protocol. Sort out what is
to be made public. We will likely have to break up current proto files into smaller collections
since they currently contain mixes of public and private types. This will allow us to better
narrow the set of what we make public. These new files could live in the hbase-protocol module
suitably annotated or they could be done up in a new module altogether. TODO.


> InterfaceAudience annotate our protobuf; distinguish internal; publish public
> -----------------------------------------------------------------------------
>
>                 Key: HBASE-16756
>                 URL: https://issues.apache.org/jira/browse/HBASE-16756
>             Project: HBase
>          Issue Type: Task
>          Components: Protobufs
>            Reporter: stack
>
> This is a follow-on from the work done over in HBASE-15638 Shade protobuf.
> Currently protobufs are not annotated as our java classes are even though they are being
used by downstream Coprocessor Endpoints; i.e. if a CPEP wants to update a Cell in HBase or
refer to a server in the cluster, 9 times out of 10 they will depend on the HBase Cell.proto
and its generated classes or the ServerName definition in HBase.proto file.
> This makes it so we cannot make breaking changes to the Cell type or relocate the ServerName
definition to another file if we want CPEPs to keep working.
> The issue gets compounded by HBASE-15638 "Shade protobuf" where protos used internally
are relocated, and given another package name altogether. Currently we leave behind the old
protos (sort-of duplicated) so CPEPs keep working but going forward, IF WE CONTINUE DOWN THIS
PATH OF SHADING PROTOS (we may revisit if hadoop ends up isolating its classpath), then we
need to 'publish' protos that we will honor as we would classes annotate with @InterfaceAudience.Public
as part of our public API going forward.
> What is involved is a review of the current protos under hbase-protocol. Sort out what
is to be made public. We will likely have to break up current proto files into smaller collections
since they currently contain mixes of public and private types. Deprecate the fat Admin and
Client protos.  This will allow us to better narrow the set of what we make public. These
new files could live in the hbase-protocol module suitably annotated or they could be done
up in a new module altogether. TODO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message