[jira] [Commented] (HBASE-5905) Protobuf interface for Admin: split between the internal and the external/customer interface

2012-05-08 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270818#comment-13270818
 ] 

stack commented on HBASE-5905:
--

If we were to make an InternalClusterProtocol, we could:

1. Subclass the user-facing open and close messages (thats all that would need 
it as I see it).
2. We could do the internal version of open and close as extensions 
(https://developers.google.com/protocol-buffers/docs/proto#extensions) naming 
the extensions 'Internal' or something or we could do nested extensions naming 
the nested extention ForInternalUse?

I'm thinking that since there are only open and close effected, and since its 
only the one field in open and only two in close region, its not enough to 
justify doing the above extra work?  How about we doc the .proto file 'for 
internal use' only and be done with it?

 Protobuf interface for Admin: split between the internal and the 
 external/customer interface
 

 Key: HBASE-5905
 URL: https://issues.apache.org/jira/browse/HBASE-5905
 Project: HBase
  Issue Type: Improvement
  Components: client, master, regionserver
Affects Versions: 0.96.0
Reporter: nkeywal

 After a short discussion with Stack, I create a jira.
 --
 I'am a little bit confused by the protobuf interface for closeRegion.
 We have two types of closeRegion today:
 1) the external ones; available in client.HBaseAdmin. They take the server 
 and the region identifier as a parameter and nothing else.
 2) The internal ones, called for example by the master. They have more 
 parameters (like versionOfClosingNode or transitionInZK).
 When I look at protobuf.ProtobufUtil, I see:
   public static void closeRegion(final AdminProtocol admin,
   final byte[] regionName, final boolean transitionInZK) throws 
 IOException {
 CloseRegionRequest closeRegionRequest =
   RequestConverter.buildCloseRegionRequest(regionName, transitionInZK);
 try {
   admin.closeRegion(null, closeRegionRequest);
 } catch (ServiceException se) {
   throw getRemoteException(se);
 }
   }
 In other words, it seems that we merged the two interfaces into a single one. 
 Is that the intend?
 I checked, the internal fields in closeRegionRequest are all optional (that's 
 good). Still, it means that the end user could use them or at least would 
 need to distinguish between the optional for functional reasons and the 
 optional - do not use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5905) Protobuf interface for Admin: split between the internal and the external/customer interface

2012-05-02 Thread nkeywal (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13266839#comment-13266839
 ] 

nkeywal commented on HBASE-5905:


This would make sense if we think that customers should/will use the protobuf 
interface.

 Protobuf interface for Admin: split between the internal and the 
 external/customer interface
 

 Key: HBASE-5905
 URL: https://issues.apache.org/jira/browse/HBASE-5905
 Project: HBase
  Issue Type: Improvement
  Components: client, master, regionserver
Affects Versions: 0.96.0
Reporter: nkeywal

 After a short discussion with Stack, I create a jira.
 --
 I'am a little bit confused by the protobuf interface for closeRegion.
 We have two types of closeRegion today:
 1) the external ones; available in client.HBaseAdmin. They take the server 
 and the region identifier as a parameter and nothing else.
 2) The internal ones, called for example by the master. They have more 
 parameters (like versionOfClosingNode or transitionInZK).
 When I look at protobuf.ProtobufUtil, I see:
   public static void closeRegion(final AdminProtocol admin,
   final byte[] regionName, final boolean transitionInZK) throws 
 IOException {
 CloseRegionRequest closeRegionRequest =
   RequestConverter.buildCloseRegionRequest(regionName, transitionInZK);
 try {
   admin.closeRegion(null, closeRegionRequest);
 } catch (ServiceException se) {
   throw getRemoteException(se);
 }
   }
 In other words, it seems that we merged the two interfaces into a single one. 
 Is that the intend?
 I checked, the internal fields in closeRegionRequest are all optional (that's 
 good). Still, it means that the end user could use them or at least would 
 need to distinguish between the optional for functional reasons and the 
 optional - do not use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5905) Protobuf interface for Admin: split between the internal and the external/customer interface

2012-05-01 Thread nkeywal (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265710#comment-13265710
 ] 

nkeywal commented on HBASE-5905:


I don't think so. But we could add a specific comment?

 Protobuf interface for Admin: split between the internal and the 
 external/customer interface
 

 Key: HBASE-5905
 URL: https://issues.apache.org/jira/browse/HBASE-5905
 Project: HBase
  Issue Type: Improvement
  Components: client, master, regionserver
Affects Versions: 0.96.0
Reporter: nkeywal

 After a short discussion with Stack, I create a jira.
 --
 I'am a little bit confused by the protobuf interface for closeRegion.
 We have two types of closeRegion today:
 1) the external ones; available in client.HBaseAdmin. They take the server 
 and the region identifier as a parameter and nothing else.
 2) The internal ones, called for example by the master. They have more 
 parameters (like versionOfClosingNode or transitionInZK).
 When I look at protobuf.ProtobufUtil, I see:
   public static void closeRegion(final AdminProtocol admin,
   final byte[] regionName, final boolean transitionInZK) throws 
 IOException {
 CloseRegionRequest closeRegionRequest =
   RequestConverter.buildCloseRegionRequest(regionName, transitionInZK);
 try {
   admin.closeRegion(null, closeRegionRequest);
 } catch (ServiceException se) {
   throw getRemoteException(se);
 }
   }
 In other words, it seems that we merged the two interfaces into a single one. 
 Is that the intend?
 I checked, the internal fields in closeRegionRequest are all optional (that's 
 good). Still, it means that the end user could use them or at least would 
 need to distinguish between the optional for functional reasons and the 
 optional - do not use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5905) Protobuf interface for Admin: split between the internal and the external/customer interface

2012-05-01 Thread Todd Lipcon (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265928#comment-13265928
 ] 

Todd Lipcon commented on HBASE-5905:


Maybe we can split out an AdminProtocol from an InternalClusterProtocol, etc?

 Protobuf interface for Admin: split between the internal and the 
 external/customer interface
 

 Key: HBASE-5905
 URL: https://issues.apache.org/jira/browse/HBASE-5905
 Project: HBase
  Issue Type: Improvement
  Components: client, master, regionserver
Affects Versions: 0.96.0
Reporter: nkeywal

 After a short discussion with Stack, I create a jira.
 --
 I'am a little bit confused by the protobuf interface for closeRegion.
 We have two types of closeRegion today:
 1) the external ones; available in client.HBaseAdmin. They take the server 
 and the region identifier as a parameter and nothing else.
 2) The internal ones, called for example by the master. They have more 
 parameters (like versionOfClosingNode or transitionInZK).
 When I look at protobuf.ProtobufUtil, I see:
   public static void closeRegion(final AdminProtocol admin,
   final byte[] regionName, final boolean transitionInZK) throws 
 IOException {
 CloseRegionRequest closeRegionRequest =
   RequestConverter.buildCloseRegionRequest(regionName, transitionInZK);
 try {
   admin.closeRegion(null, closeRegionRequest);
 } catch (ServiceException se) {
   throw getRemoteException(se);
 }
   }
 In other words, it seems that we merged the two interfaces into a single one. 
 Is that the intend?
 I checked, the internal fields in closeRegionRequest are all optional (that's 
 good). Still, it means that the end user could use them or at least would 
 need to distinguish between the optional for functional reasons and the 
 optional - do not use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5905) Protobuf interface for Admin: split between the internal and the external/customer interface

2012-04-30 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265072#comment-13265072
 ] 

stack commented on HBASE-5905:
--

Sorry N, should have read closer (was running out the door):

bq. In other words, it seems that we merged the two interfaces into a single 
one. Is that the intend?

Yes

bq. I checked, the internal fields in closeRegionRequest are all optional 
(that's good). Still, it means that the end user could use them or at least 
would need to distinguish between the optional for functional reasons and the 
optional - do not use.

Agree.

I'd say this minor issue though given pb classes do not come out through pur 
admin public api, just the api on servers.

 Protobuf interface for Admin: split between the internal and the 
 external/customer interface
 

 Key: HBASE-5905
 URL: https://issues.apache.org/jira/browse/HBASE-5905
 Project: HBase
  Issue Type: Improvement
  Components: client, master, regionserver
Affects Versions: 0.96.0
Reporter: nkeywal

 After a short discussion with Stack, I create a jira.
 --
 I'am a little bit confused by the protobuf interface for closeRegion.
 We have two types of closeRegion today:
 1) the external ones; available in client.HBaseAdmin. They take the server 
 and the region identifier as a parameter and nothing else.
 2) The internal ones, called for example by the master. They have more 
 parameters (like versionOfClosingNode or transitionInZK).
 When I look at protobuf.ProtobufUtil, I see:
   public static void closeRegion(final AdminProtocol admin,
   final byte[] regionName, final boolean transitionInZK) throws 
 IOException {
 CloseRegionRequest closeRegionRequest =
   RequestConverter.buildCloseRegionRequest(regionName, transitionInZK);
 try {
   admin.closeRegion(null, closeRegionRequest);
 } catch (ServiceException se) {
   throw getRemoteException(se);
 }
   }
 In other words, it seems that we merged the two interfaces into a single one. 
 Is that the intend?
 I checked, the internal fields in closeRegionRequest are all optional (that's 
 good). Still, it means that the end user could use them or at least would 
 need to distinguish between the optional for functional reasons and the 
 optional - do not use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (HBASE-5905) Protobuf interface for Admin: split between the internal and the external/customer interface

2012-04-30 Thread Jimmy Xiang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265102#comment-13265102
 ] 

Jimmy Xiang commented on HBASE-5905:


Is there a way to specify a parameter private/internal in pb?  Otherwise, we 
may end up with some private protocol for internal usage.

 Protobuf interface for Admin: split between the internal and the 
 external/customer interface
 

 Key: HBASE-5905
 URL: https://issues.apache.org/jira/browse/HBASE-5905
 Project: HBase
  Issue Type: Improvement
  Components: client, master, regionserver
Affects Versions: 0.96.0
Reporter: nkeywal

 After a short discussion with Stack, I create a jira.
 --
 I'am a little bit confused by the protobuf interface for closeRegion.
 We have two types of closeRegion today:
 1) the external ones; available in client.HBaseAdmin. They take the server 
 and the region identifier as a parameter and nothing else.
 2) The internal ones, called for example by the master. They have more 
 parameters (like versionOfClosingNode or transitionInZK).
 When I look at protobuf.ProtobufUtil, I see:
   public static void closeRegion(final AdminProtocol admin,
   final byte[] regionName, final boolean transitionInZK) throws 
 IOException {
 CloseRegionRequest closeRegionRequest =
   RequestConverter.buildCloseRegionRequest(regionName, transitionInZK);
 try {
   admin.closeRegion(null, closeRegionRequest);
 } catch (ServiceException se) {
   throw getRemoteException(se);
 }
   }
 In other words, it seems that we merged the two interfaces into a single one. 
 Is that the intend?
 I checked, the internal fields in closeRegionRequest are all optional (that's 
 good). Still, it means that the end user could use them or at least would 
 need to distinguish between the optional for functional reasons and the 
 optional - do not use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira