[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013642#comment-16013642 ] Jerry He commented on HBASE-16757: -- Agree. I misunderstood your previous comment. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013626#comment-16013626 ] Duo Zhang commented on HBASE-16757: --- It would be great if they can be done at the same time. But for things like AccessController, the function of CP is much more complicated than EP, so I think we can do the EP change first if we do not have enough time to do the CP change. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013625#comment-16013625 ] Jerry He commented on HBASE-16757: -- Do you mean to provide new client API to access the services? Or the service side changes? It can not be done at the same time? I agree we should do it sooner rather than later for 2.0 to avoid compatibility dragging into another major release. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013407#comment-16013407 ] Duo Zhang commented on HBASE-16757: --- I think we can change the endpoint API first? It is visible to user and for compatibility we need to keep the old endpoint API at least for a whole major version. Thanks. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566905#comment-15566905 ] stack commented on HBASE-16757: --- Thanks [~jerryhe] > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15560761#comment-15560761 ] Jerry He commented on HBASE-16757: -- I created two sub-tasks to cover TokenProvider and MultiRowMutation. Apparently AccessController and VisibilityLabels controller need more thinking. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15547704#comment-15547704 ] stack commented on HBASE-16757: --- Of ones to convert, I have: + TokenProvider + AccessControl + MultiRowMutation + VisibilityLabels Thats a start. There are other CPEPs but they seem fine as they are. There are three in the new hbase-coprocessor module and another out in hbase-examples. These latter can live apart from hbase-server and hbase-client though rsgroup could probably be made core at some point. The remaining serve as good examples of how to do a CPEP. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15547674#comment-15547674 ] Jerry He commented on HBASE-16757: -- Hi, [~stack] Do you have a list? bq. The TokenProvider methods could easily be moved. I was thinking about doing this long ago. TokenProvider is easily confusing from my experience and hard to explain to people why it needs to be additionally configured. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15546571#comment-15546571 ] stack commented on HBASE-16757: --- Sub-tasks off this issue seems good. No plan as yet. Just marking out that this needs to be done. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15546507#comment-15546507 ] Gary Helmling commented on HBASE-16757: --- Yeah, TokenProvider with the use of TokenIdentifiers will be tightly tied up in RPC internals. What's the plan to manage the process of integrating these? Create a separate sub-task per CPEP? I can take a stab at integrating TokenProvider when I have some time. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[ https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15546399#comment-15546399 ] stack commented on HBASE-16757: --- bq. Auth, as pointed out by Matteo Bertozzi, is not a Coprocessor Endpoint though it is cast as one invoked natively by RPC. The above was my mistake (not [~mbertozzi]'s). Please forgive my messy understanding of what is going on here. Thanks for clarification [~ghelmling]. Main point is that yeah, time to integrate these CPEPs as core. The TokenProvider is bound up in RPC at least. I could not move it out of the guts of hbase. On AC CPEP, similar though I spent less effort on this one. > Integrate functionality currently done up as Coprocessor Endpoints into core. > - > > Key: HBASE-16757 > URL: https://issues.apache.org/jira/browse/HBASE-16757 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack > > As part of the work over in HBASE-15638, "Shade Protobufs", I could not but > help noticing that of the seven or eight Coprocessor Endpoints bundled with > hbase, half should have been converted to be core long time again. In fact, > some of these core CPEPs are no longer viable as CPEPs, if they ever were, > given how intertwined with core they are. > For example, MultiRowMutation, the nice CPEP that allows us do cross-row > transactions used natively amending hbase:meta, has much of its facility > baked into core without which it could not run. In an exercise, I was able to > convert this one over without having to alter public APIs in Table or Admin. > Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it > is cast as one invoked natively by RPC. > VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually > depend on VisibiltyLabel related classes. > SecureBulkLoad is not in any violation being a CPEP provided to add API > ahead-of-time since properly deprecated and already integrated to core but I > mention it here for completeness sake. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16757) Integrate functionality currently done up as Coprocessor Endpoints into core.
[
https://issues.apache.org/jira/browse/HBASE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15546128#comment-15546128
]
Gary Helmling commented on HBASE-16757:
---
{quote}
Auth, as pointed out by Matteo Bertozzi, is not a Coprocessor Endpoint though
it is cast as one invoked natively by RPC.
{quote}
Not quite sure what you mean by this. But, security makes use of two
coprocessor services:
* AccessController - implements grant/revoke/list permissions/check permissions
* TokenProvider - provides methods to obtain a delegation token as a cp service
call against the meta region
The TokenProvider methods could easily be moved into say the master APIs.
Originally it needed to be kept external as we had a separate RPC engine for
secure authentication.
The AccessController methods don't make sense outside of the authorization
provided by AccessController. I think it would make the most sense for moving
those to be part of the work of pulling all of the authorization functionality
into core and removing AccessController completely.
> Integrate functionality currently done up as Coprocessor Endpoints into core.
> -
>
> Key: HBASE-16757
> URL: https://issues.apache.org/jira/browse/HBASE-16757
> Project: HBase
> Issue Type: Task
> Components: Coprocessors
>Reporter: stack
>
> As part of the work over in HBASE-15638, "Shade Protobufs", I could not but
> help noticing that of the seven or eight Coprocessor Endpoints bundled with
> hbase, half should have been converted to be core long time again. In fact,
> some of these core CPEPs are no longer viable as CPEPs, if they ever were,
> given how intertwined with core they are.
> For example, MultiRowMutation, the nice CPEP that allows us do cross-row
> transactions used natively amending hbase:meta, has much of its facility
> baked into core without which it could not run. In an exercise, I was able to
> convert this one over without having to alter public APIs in Table or Admin.
> Auth, as pointed out by [~mbertozzi], is not a Coprocessor Endpoint though it
> is cast as one invoked natively by RPC.
> VisibilityLabels is a CPEP but core types -- Query and Mutation -- actually
> depend on VisibiltyLabel related classes.
> SecureBulkLoad is not in any violation being a CPEP provided to add API
> ahead-of-time since properly deprecated and already integrated to core but I
> mention it here for completeness sake.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
