Re: DISCUSS: Heads-up 2.1.5 RC in next few days and suggest EOL'ing 2.1 branch
No problem. I'll can keep up the 2.1 branch and squeeze some more releases out of it. Can do the branch-2.0 if we need one there too. S On Thu, May 16, 2019 at 8:13 PM 张铎(Duo Zhang) wrote: > Usually at least we will keep two minor release lines? I could also take > the release work of branch-2.1, until 2.3.0 is out. > > Allan Yang 于2019年5月17日周五 上午10:45写道： > > > Why so soon... branch-2.2 is not stable yet. branch-2.1 is the only > stable > > branch in 2.x since branch-2.0 is already EOL’d. > > Best Regards > > Allan Yang > > > > > > 张铎(Duo Zhang) 于2019年5月17日周五 上午10:23写道： > > > > > The next RC for 2.2.0 will be available soon... > > > > > > Sean Busbey 于2019年5月17日周五 上午10:13写道： > > > > > > > Too early to EOL 2.1. > > > > > > > > Also we didn't EOL 2.0 at 2.0.5 because folks wanted a post 2.2.0 > > > release. > > > > > > > > On Thu, May 16, 2019, 18:26 Zach York > > > > wrote: > > > > > > > > > I like the proactive approach to EOLing branches, but I don't think > > we > > > > can > > > > > quite EOL a branch when there is no newer branch (2.2.0) out. If > > that's > > > > > 2.1.6, that's fine. > > > > > > > > > > On Thu, May 16, 2019 at 3:18 PM Stack wrote: > > > > > > > > > > > Was going to put up an RC for 2.1.5 in next day or so after a > > review > > > of > > > > > > unresolved JIRAs that have 2.1.5 as fix version. It is coming up > on > > > two > > > > > > months since 2.1.4 and by the time we're done, there'll be 90+ > > > changes. > > > > > > Branch-2.1 nightlies have started to stabilize again. > > > > > > > > > > > > Was also thinking of EOL'ing the 2.1 branch. We EOL'd 2.0 branch > at > > > > > 2.0.5. > > > > > > We have too many branches as it is. What do folks think? 2.2.0 > > isn't > > > > out > > > > > > yet so maybe wait on 2.1.6? That'd be fine too. > > > > > > > > > > > > Thanks, > > > > > > S > > > > > > > > > > > > > > > > > > > > >
Re: DISCUSS: Heads-up 2.1.5 RC in next few days and suggest EOL'ing 2.1 branch
Usually at least we will keep two minor release lines? I could also take the release work of branch-2.1, until 2.3.0 is out. Allan Yang 于2019年5月17日周五 上午10:45写道： > Why so soon... branch-2.2 is not stable yet. branch-2.1 is the only stable > branch in 2.x since branch-2.0 is already EOL’d. > Best Regards > Allan Yang > > > 张铎(Duo Zhang) 于2019年5月17日周五 上午10:23写道： > > > The next RC for 2.2.0 will be available soon... > > > > Sean Busbey 于2019年5月17日周五 上午10:13写道： > > > > > Too early to EOL 2.1. > > > > > > Also we didn't EOL 2.0 at 2.0.5 because folks wanted a post 2.2.0 > > release. > > > > > > On Thu, May 16, 2019, 18:26 Zach York > > > wrote: > > > > > > > I like the proactive approach to EOLing branches, but I don't think > we > > > can > > > > quite EOL a branch when there is no newer branch (2.2.0) out. If > that's > > > > 2.1.6, that's fine. > > > > > > > > On Thu, May 16, 2019 at 3:18 PM Stack wrote: > > > > > > > > > Was going to put up an RC for 2.1.5 in next day or so after a > review > > of > > > > > unresolved JIRAs that have 2.1.5 as fix version. It is coming up on > > two > > > > > months since 2.1.4 and by the time we're done, there'll be 90+ > > changes. > > > > > Branch-2.1 nightlies have started to stabilize again. > > > > > > > > > > Was also thinking of EOL'ing the 2.1 branch. We EOL'd 2.0 branch at > > > > 2.0.5. > > > > > We have too many branches as it is. What do folks think? 2.2.0 > isn't > > > out > > > > > yet so maybe wait on 2.1.6? That'd be fine too. > > > > > > > > > > Thanks, > > > > > S > > > > > > > > > > > > > > >
Re: DISCUSS: Heads-up 2.1.5 RC in next few days and suggest EOL'ing 2.1 branch
Why so soon... branch-2.2 is not stable yet. branch-2.1 is the only stable branch in 2.x since branch-2.0 is already EOL’d. Best Regards Allan Yang 张铎(Duo Zhang) 于2019年5月17日周五 上午10:23写道： > The next RC for 2.2.0 will be available soon... > > Sean Busbey 于2019年5月17日周五 上午10:13写道： > > > Too early to EOL 2.1. > > > > Also we didn't EOL 2.0 at 2.0.5 because folks wanted a post 2.2.0 > release. > > > > On Thu, May 16, 2019, 18:26 Zach York > > wrote: > > > > > I like the proactive approach to EOLing branches, but I don't think we > > can > > > quite EOL a branch when there is no newer branch (2.2.0) out. If that's > > > 2.1.6, that's fine. > > > > > > On Thu, May 16, 2019 at 3:18 PM Stack wrote: > > > > > > > Was going to put up an RC for 2.1.5 in next day or so after a review > of > > > > unresolved JIRAs that have 2.1.5 as fix version. It is coming up on > two > > > > months since 2.1.4 and by the time we're done, there'll be 90+ > changes. > > > > Branch-2.1 nightlies have started to stabilize again. > > > > > > > > Was also thinking of EOL'ing the 2.1 branch. We EOL'd 2.0 branch at > > > 2.0.5. > > > > We have too many branches as it is. What do folks think? 2.2.0 isn't > > out > > > > yet so maybe wait on 2.1.6? That'd be fine too. > > > > > > > > Thanks, > > > > S > > > > > > > > > >
Re: DISCUSS: Heads-up 2.1.5 RC in next few days and suggest EOL'ing 2.1 branch
The next RC for 2.2.0 will be available soon... Sean Busbey 于2019年5月17日周五 上午10:13写道： > Too early to EOL 2.1. > > Also we didn't EOL 2.0 at 2.0.5 because folks wanted a post 2.2.0 release. > > On Thu, May 16, 2019, 18:26 Zach York > wrote: > > > I like the proactive approach to EOLing branches, but I don't think we > can > > quite EOL a branch when there is no newer branch (2.2.0) out. If that's > > 2.1.6, that's fine. > > > > On Thu, May 16, 2019 at 3:18 PM Stack wrote: > > > > > Was going to put up an RC for 2.1.5 in next day or so after a review of > > > unresolved JIRAs that have 2.1.5 as fix version. It is coming up on two > > > months since 2.1.4 and by the time we're done, there'll be 90+ changes. > > > Branch-2.1 nightlies have started to stabilize again. > > > > > > Was also thinking of EOL'ing the 2.1 branch. We EOL'd 2.0 branch at > > 2.0.5. > > > We have too many branches as it is. What do folks think? 2.2.0 isn't > out > > > yet so maybe wait on 2.1.6? That'd be fine too. > > > > > > Thanks, > > > S > > > > > >
[jira] [Created] (HBASE-22438) Backport 'HBASE-20970 Update hadoop check versions for hadoop3 in hbase-personality' to branch-2.1/branch-2.0
Duo Zhang created HBASE-22438: - Summary: Backport 'HBASE-20970 Update hadoop check versions for hadoop3 in hbase-personality' to branch-2.1/branch-2.0 Key: HBASE-22438 URL: https://issues.apache.org/jira/browse/HBASE-22438 Project: HBase Issue Type: Bug Reporter: Duo Zhang -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: DISCUSS: Heads-up 2.1.5 RC in next few days and suggest EOL'ing 2.1 branch
Too early to EOL 2.1. Also we didn't EOL 2.0 at 2.0.5 because folks wanted a post 2.2.0 release. On Thu, May 16, 2019, 18:26 Zach York wrote: > I like the proactive approach to EOLing branches, but I don't think we can > quite EOL a branch when there is no newer branch (2.2.0) out. If that's > 2.1.6, that's fine. > > On Thu, May 16, 2019 at 3:18 PM Stack wrote: > > > Was going to put up an RC for 2.1.5 in next day or so after a review of > > unresolved JIRAs that have 2.1.5 as fix version. It is coming up on two > > months since 2.1.4 and by the time we're done, there'll be 90+ changes. > > Branch-2.1 nightlies have started to stabilize again. > > > > Was also thinking of EOL'ing the 2.1 branch. We EOL'd 2.0 branch at > 2.0.5. > > We have too many branches as it is. What do folks think? 2.2.0 isn't out > > yet so maybe wait on 2.1.6? That'd be fine too. > > > > Thanks, > > S > > >
[jira] [Resolved] (HBASE-22420) TestRSGroupsBalacne.testGroupBalance is flaky
[ https://issues.apache.org/jira/browse/HBASE-22420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang resolved HBASE-22420. Resolution: Duplicate Duplicate with HBASE-22424 > TestRSGroupsBalacne.testGroupBalance is flaky > - > > Key: HBASE-22420 > URL: https://issues.apache.org/jira/browse/HBASE-22420 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.2.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > > org.apache.hadoop.hbase.constraint.ConstraintException: > org.apache.hadoop.hbase.constraint.ConstraintException: should keep at least > one server in 'default' RSGroup. > at > org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveServers(RSGroupAdminServer.java:318) > at > org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint$RSGroupAdminServiceImpl.moveServers(RSGroupAdminEndpoint.java:209) > at > org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:13870) > at > org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:873) > at > org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:413) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:132) > at > org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324) > at > org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304) > at sun.reflect.GeneratedConstructorAccessor55.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at > org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:99) > at > org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:89) > at > org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:363) > at > org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.handleRemoteException(ProtobufUtil.java:351) > at > org.apache.hadoop.hbase.client.MasterCallable.call(MasterCallable.java:101) > at > org.apache.hadoop.hbase.client.HBaseAdmin$72.callExecService(HBaseAdmin.java:3165) > at > org.apache.hadoop.hbase.client.SyncCoprocessorRpcChannel.callBlockingMethod(SyncCoprocessorRpcChannel.java:69) > at > org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService$BlockingStub.moveServers(RSGroupAdminProtos.java:14277) > at > org.apache.hadoop.hbase.rsgroup.RSGroupAdminClient.moveServers(RSGroupAdminClient.java:110) > at > org.apache.hadoop.hbase.rsgroup.VerifyingRSGroupAdminClient.moveServers(VerifyingRSGroupAdminClient.java:78) > at > org.apache.hadoop.hbase.rsgroup.TestRSGroupsBase.addGroup(TestRSGroupsBase.java:197) > at > org.apache.hadoop.hbase.rsgroup.TestRSGroupsBalance.testGroupBalance(TestRSGroupsBalance.java:83) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at
[jira] [Resolved] (HBASE-22404) Open/Close region request may be executed twice when master restart
[
https://issues.apache.org/jira/browse/HBASE-22404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang resolved HBASE-22404.
Resolution: Fixed
> Open/Close region request may be executed twice when master restart
> ---
>
> Key: HBASE-22404
> URL: https://issues.apache.org/jira/browse/HBASE-22404
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.2.0, 2.3.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
>
> We found this problem when run ITBLL for our internal branch which based
> branch-2.2.
> # Master A schedule a TRSP which will reopen region1. And this TRSP firstly
> schdule a sub remote procedure: CloseRegionProcedure and send the close
> region request to RS.
> # Master A shutdown and Master B is the new active master. And restore this
> TRSP and the remote procedure CloseRegionProcedure.
> # RS reported to the new Master B and the CloseRegionProcedure finished.
> Then the TRSP schdule a new OpenRegionProcedure and send open region request
> to RS.
> # {color:#FF}But meanwhile Master B send the close region request to RS
> again{color}.
> # The open region request finished firstly and report to master succeed. The
> master thought the region was opened on RS. But the RS excuted the close
> region request again and closed the region1.
> # The Master thought the region opened but the RS closed the region. Then
> the new TRSP will stuck forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-22429) hbase-vote download step requires URL to end with '/'
[ https://issues.apache.org/jira/browse/HBASE-22429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-22429. Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.3.5 2.2.1 2.3.0 1.4.10 1.5.0 3.0.0 > hbase-vote download step requires URL to end with '/' > -- > > Key: HBASE-22429 > URL: https://issues.apache.org/jira/browse/HBASE-22429 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Tak Lon (Stephen) Wu >Priority: Trivial > Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.2.1, 1.3.5 > > > The hbase-vote script's download step requires the sourcedir URL be > terminated with a path separator or else the retrieval will escape the > candidate's directory and mirror way too much. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22437) HBOSS: Add Hadoop 2 / 3 profiles
Sean Mackrory created HBASE-22437: - Summary: HBOSS: Add Hadoop 2 / 3 profiles Key: HBASE-22437 URL: https://issues.apache.org/jira/browse/HBASE-22437 Project: HBase Issue Type: Improvement Reporter: Sean Mackrory Assignee: Sean Mackrory Original discussion on HBASE-22149 indicated interest running HBOSS on Hadoop 2, and HBase itself maintains profiles for Hadoop 2 and 3. There's no fundamental reason we can't - there are some minor incompatibilities in the code, but no fundamental mismatch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: DISCUSS: Heads-up 2.1.5 RC in next few days and suggest EOL'ing 2.1 branch
I like the proactive approach to EOLing branches, but I don't think we can quite EOL a branch when there is no newer branch (2.2.0) out. If that's 2.1.6, that's fine. On Thu, May 16, 2019 at 3:18 PM Stack wrote: > Was going to put up an RC for 2.1.5 in next day or so after a review of > unresolved JIRAs that have 2.1.5 as fix version. It is coming up on two > months since 2.1.4 and by the time we're done, there'll be 90+ changes. > Branch-2.1 nightlies have started to stabilize again. > > Was also thinking of EOL'ing the 2.1 branch. We EOL'd 2.0 branch at 2.0.5. > We have too many branches as it is. What do folks think? 2.2.0 isn't out > yet so maybe wait on 2.1.6? That'd be fine too. > > Thanks, > S >
DISCUSS: Heads-up 2.1.5 RC in next few days and suggest EOL'ing 2.1 branch
Was going to put up an RC for 2.1.5 in next day or so after a review of unresolved JIRAs that have 2.1.5 as fix version. It is coming up on two months since 2.1.4 and by the time we're done, there'll be 90+ changes. Branch-2.1 nightlies have started to stabilize again. Was also thinking of EOL'ing the 2.1 branch. We EOL'd 2.0 branch at 2.0.5. We have too many branches as it is. What do folks think? 2.2.0 isn't out yet so maybe wait on 2.1.6? That'd be fine too. Thanks, S
Re: [DISCUSS] Updating categorical info on Jira
Thank you. Will use them. On Thu, May 16, 2019 at 2:07 PM Josh Elser wrote: > Sorry, not "hbase-filesystem" but "Filesystem Integration" > > On 5/16/19 2:04 PM, Josh Elser wrote: > > Thanks, Biju. > > > > I've created "Quotas" and "Scheduler" components. There is also an > > "hbase-filesystem" component which can be used for the HBOSS project > > (saw you added a label for that this morning). > > > > We'll probably have to beg, but hopefully folks can self-police and use > > components a bit more rigorously :) > > > > On 5/16/19 11:07 AM, Biju N wrote: > >> Hi Josh, > >> JIRA items related to "quota" is the one which I was going through > >> recently which was not in the component list. It would help if all > >> supported quota features gets added to the component list. > >> The next one which is good to add is "scheduler". To give some > >> context > >> why this will help here is the one of the key scheduler related tickets > >> https://issues.apache.org/jira/browse/HBASE-11355. With having a > >> component > >> "scheduler" it will help any one to quickly filter on them to understand > >> what was done/implemented and the reasoning which may not be available > in > >> the code. Currently it takes some time for users who are not familiar > >> with > >> the code base. > >> > >> I am sure there are others which need to be added. One request to the > >> "dev" > >> team. Before a change is committed, if we can make sure that a > >> "component" > >> is assigned to the ticket (some tickets may not need it), JIRA can be a > >> quick source of documentation. Hope we can update the old tickets as and > >> when someone goes through with the proper component it belongs to. > >> > >> On Thu, May 16, 2019 at 9:36 AM Josh Elser wrote: > >> > >>> Biju -- we have the ability to define components. > >>> > >>> It sounds like the consensus is that folks prefer components over > >>> free-form labels. > >>> > >>> What are the components that you hoped to find that aren't there? > >>> > >>> On 5/13/19 6:31 PM, Biju N wrote: > FYI. There are instances where we don't have "components" which can > help > filter a feature for e.g. Quota is a good example. That is a reason > for > using labels. This helps in filtering the tickets and get an > >>> understanding > of a feature. > > On Mon, May 13, 2019 at 5:36 PM Andrew Purtell > > wrote: > > > I’ve been using components so am accidentally in agreement. Didn’t > > know > > which to use, just picked one. We should document this preference. > > > >> On May 13, 2019, at 12:52 PM, Jan Hentschel < > > jan.hentsc...@ultratendency.com> wrote: > >> > >> Agree with Sean. I would prefer to use labels where we have > >> something, > > which is not HBase-specific (such as the “beginner” label), and > >>> components > > otherwise. > >> > >> From: Sean Busbey > >> Reply-To: "dev@hbase.apache.org" > >> Date: Monday, May 13, 2019 at 9:48 PM > >> To: dev > >> Subject: Re: [DISCUSS] Updating categorical info on Jira > >> > >> labels are shared across the entire jira instance whereas components > >> are under the control of the project. personally I prefer > components. > >> > >> the only labels I like are when we use "beginner" or if we were to > >> move away from "Hadoop Flags" to an incompatible change label. > >> > >> On Mon, May 13, 2019 at 2:34 PM Josh Elser > els...@apache.org>> wrote: > >> > >> I see BijuN doing a lot of work lately to try to categorize issues > >> better. Thanks to him for trying to make Jira more usable in that > >>> regard! > >> > >> One concern I have is that we have duplicative categorization: > >> components and labels. I prefer components as they push us into > >> curated > >> "names" whereas a label might have skew in capitalization (e.g. > >>> "quota", > >> "Quota", "quotas", "space quota"). > >> > >> What do others think? > >> > >> > >> > >> -- > >> Sean > >> > > > > >>> > >> >
Re: [DISCUSS] Updating categorical info on Jira
Sorry, not "hbase-filesystem" but "Filesystem Integration" On 5/16/19 2:04 PM, Josh Elser wrote: Thanks, Biju. I've created "Quotas" and "Scheduler" components. There is also an "hbase-filesystem" component which can be used for the HBOSS project (saw you added a label for that this morning). We'll probably have to beg, but hopefully folks can self-police and use components a bit more rigorously :) On 5/16/19 11:07 AM, Biju N wrote: Hi Josh, JIRA items related to "quota" is the one which I was going through recently which was not in the component list. It would help if all supported quota features gets added to the component list. The next one which is good to add is "scheduler". To give some context why this will help here is the one of the key scheduler related tickets https://issues.apache.org/jira/browse/HBASE-11355. With having a component "scheduler" it will help any one to quickly filter on them to understand what was done/implemented and the reasoning which may not be available in the code. Currently it takes some time for users who are not familiar with the code base. I am sure there are others which need to be added. One request to the "dev" team. Before a change is committed, if we can make sure that a "component" is assigned to the ticket (some tickets may not need it), JIRA can be a quick source of documentation. Hope we can update the old tickets as and when someone goes through with the proper component it belongs to. On Thu, May 16, 2019 at 9:36 AM Josh Elser wrote: Biju -- we have the ability to define components. It sounds like the consensus is that folks prefer components over free-form labels. What are the components that you hoped to find that aren't there? On 5/13/19 6:31 PM, Biju N wrote: FYI. There are instances where we don't have "components" which can help filter a feature for e.g. Quota is a good example. That is a reason for using labels. This helps in filtering the tickets and get an understanding of a feature. On Mon, May 13, 2019 at 5:36 PM Andrew Purtell wrote: I’ve been using components so am accidentally in agreement. Didn’t know which to use, just picked one. We should document this preference. On May 13, 2019, at 12:52 PM, Jan Hentschel < jan.hentsc...@ultratendency.com> wrote: Agree with Sean. I would prefer to use labels where we have something, which is not HBase-specific (such as the “beginner” label), and components otherwise. From: Sean Busbey Reply-To: "dev@hbase.apache.org" Date: Monday, May 13, 2019 at 9:48 PM To: dev Subject: Re: [DISCUSS] Updating categorical info on Jira labels are shared across the entire jira instance whereas components are under the control of the project. personally I prefer components. the only labels I like are when we use "beginner" or if we were to move away from "Hadoop Flags" to an incompatible change label. On Mon, May 13, 2019 at 2:34 PM Josh Elser els...@apache.org>> wrote: I see BijuN doing a lot of work lately to try to categorize issues better. Thanks to him for trying to make Jira more usable in that regard! One concern I have is that we have duplicative categorization: components and labels. I prefer components as they push us into curated "names" whereas a label might have skew in capitalization (e.g. "quota", "Quota", "quotas", "space quota"). What do others think? -- Sean
Re: [DISCUSS] Updating categorical info on Jira
Thanks, Biju. I've created "Quotas" and "Scheduler" components. There is also an "hbase-filesystem" component which can be used for the HBOSS project (saw you added a label for that this morning). We'll probably have to beg, but hopefully folks can self-police and use components a bit more rigorously :) On 5/16/19 11:07 AM, Biju N wrote: Hi Josh, JIRA items related to "quota" is the one which I was going through recently which was not in the component list. It would help if all supported quota features gets added to the component list. The next one which is good to add is "scheduler". To give some context why this will help here is the one of the key scheduler related tickets https://issues.apache.org/jira/browse/HBASE-11355. With having a component "scheduler" it will help any one to quickly filter on them to understand what was done/implemented and the reasoning which may not be available in the code. Currently it takes some time for users who are not familiar with the code base. I am sure there are others which need to be added. One request to the "dev" team. Before a change is committed, if we can make sure that a "component" is assigned to the ticket (some tickets may not need it), JIRA can be a quick source of documentation. Hope we can update the old tickets as and when someone goes through with the proper component it belongs to. On Thu, May 16, 2019 at 9:36 AM Josh Elser wrote: Biju -- we have the ability to define components. It sounds like the consensus is that folks prefer components over free-form labels. What are the components that you hoped to find that aren't there? On 5/13/19 6:31 PM, Biju N wrote: FYI. There are instances where we don't have "components" which can help filter a feature for e.g. Quota is a good example. That is a reason for using labels. This helps in filtering the tickets and get an understanding of a feature. On Mon, May 13, 2019 at 5:36 PM Andrew Purtell I’ve been using components so am accidentally in agreement. Didn’t know which to use, just picked one. We should document this preference. On May 13, 2019, at 12:52 PM, Jan Hentschel < jan.hentsc...@ultratendency.com> wrote: Agree with Sean. I would prefer to use labels where we have something, which is not HBase-specific (such as the “beginner” label), and components otherwise. From: Sean Busbey Reply-To: "dev@hbase.apache.org" Date: Monday, May 13, 2019 at 9:48 PM To: dev Subject: Re: [DISCUSS] Updating categorical info on Jira labels are shared across the entire jira instance whereas components are under the control of the project. personally I prefer components. the only labels I like are when we use "beginner" or if we were to move away from "Hadoop Flags" to an incompatible change label. On Mon, May 13, 2019 at 2:34 PM Josh Elser els...@apache.org>> wrote: I see BijuN doing a lot of work lately to try to categorize issues better. Thanks to him for trying to make Jira more usable in that regard! One concern I have is that we have duplicative categorization: components and labels. I prefer components as they push us into curated "names" whereas a label might have skew in capitalization (e.g. "quota", "Quota", "quotas", "space quota"). What do others think? -- Sean
Re: [DISCUSS] Updating categorical info on Jira
Hi Josh, JIRA items related to "quota" is the one which I was going through recently which was not in the component list. It would help if all supported quota features gets added to the component list. The next one which is good to add is "scheduler". To give some context why this will help here is the one of the key scheduler related tickets https://issues.apache.org/jira/browse/HBASE-11355. With having a component "scheduler" it will help any one to quickly filter on them to understand what was done/implemented and the reasoning which may not be available in the code. Currently it takes some time for users who are not familiar with the code base. I am sure there are others which need to be added. One request to the "dev" team. Before a change is committed, if we can make sure that a "component" is assigned to the ticket (some tickets may not need it), JIRA can be a quick source of documentation. Hope we can update the old tickets as and when someone goes through with the proper component it belongs to. On Thu, May 16, 2019 at 9:36 AM Josh Elser wrote: > Biju -- we have the ability to define components. > > It sounds like the consensus is that folks prefer components over > free-form labels. > > What are the components that you hoped to find that aren't there? > > On 5/13/19 6:31 PM, Biju N wrote: > > FYI. There are instances where we don't have "components" which can help > > filter a feature for e.g. Quota is a good example. That is a reason for > > using labels. This helps in filtering the tickets and get an > understanding > > of a feature. > > > > On Mon, May 13, 2019 at 5:36 PM Andrew Purtell > > > wrote: > > > >> I’ve been using components so am accidentally in agreement. Didn’t know > >> which to use, just picked one. We should document this preference. > >> > >>> On May 13, 2019, at 12:52 PM, Jan Hentschel < > >> jan.hentsc...@ultratendency.com> wrote: > >>> > >>> Agree with Sean. I would prefer to use labels where we have something, > >> which is not HBase-specific (such as the “beginner” label), and > components > >> otherwise. > >>> > >>> From: Sean Busbey > >>> Reply-To: "dev@hbase.apache.org" > >>> Date: Monday, May 13, 2019 at 9:48 PM > >>> To: dev > >>> Subject: Re: [DISCUSS] Updating categorical info on Jira > >>> > >>> labels are shared across the entire jira instance whereas components > >>> are under the control of the project. personally I prefer components. > >>> > >>> the only labels I like are when we use "beginner" or if we were to > >>> move away from "Hadoop Flags" to an incompatible change label. > >>> > >>> On Mon, May 13, 2019 at 2:34 PM Josh Elser >> els...@apache.org>> wrote: > >>> > >>> I see BijuN doing a lot of work lately to try to categorize issues > >>> better. Thanks to him for trying to make Jira more usable in that > regard! > >>> > >>> One concern I have is that we have duplicative categorization: > >>> components and labels. I prefer components as they push us into curated > >>> "names" whereas a label might have skew in capitalization (e.g. > "quota", > >>> "Quota", "quotas", "space quota"). > >>> > >>> What do others think? > >>> > >>> > >>> > >>> -- > >>> Sean > >>> > >> > > >
[jira] [Resolved] (HBASE-22436) Implement listNamespaces method for AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-22436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-22436. --- Resolution: Duplicate Oh, the github PR has already modified AsyncAdmin... Resolved as duplicated. > Implement listNamespaces method for AsyncAdmin > -- > > Key: HBASE-22436 > URL: https://issues.apache.org/jira/browse/HBASE-22436 > Project: HBase > Issue Type: Sub-task > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.3.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22436) Implement listNamespaces method for AsyncAdmin
Duo Zhang created HBASE-22436: - Summary: Implement listNamespaces method for AsyncAdmin Key: HBASE-22436 URL: https://issues.apache.org/jira/browse/HBASE-22436 Project: HBase Issue Type: Sub-task Components: Admin, asyncclient, Client Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 3.0.0, 2.3.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-22416) HBOSS: unit tests fail with ConnectionLoss when IPv6 enabled and not set up locally
[
https://issues.apache.org/jira/browse/HBASE-22416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved HBASE-22416.
Resolution: Fixed
Hadoop Flags: Reviewed
Thanks for the review, Sean!
> HBOSS: unit tests fail with ConnectionLoss when IPv6 enabled and not set up
> locally
> ---
>
> Key: HBASE-22416
> URL: https://issues.apache.org/jira/browse/HBASE-22416
> Project: HBase
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Labels: HBOSS
> Fix For: hbase-filesystem-1.0.0-alpha1
>
> Attachments: HBASE-22416.001.patch
>
>
> I've seen that the HBOSS unit tests will fail for me with a ConnectionLoss
> exception. This is resolved when I force ipv4. My hunch is that we don't
> block for curator to become connected, and because of my local setup, the
> ipv6 lookup happens first and has to time-out. The test starts running but
> Curator hasn't yet become connected, so we fail with a ConnectionLoss in the
> test itself.
> We should wait for Curator to become connected and maybe add
> {{-Djava.net.preferIPv4Stack=true}} to surefire opts
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSS] Updating categorical info on Jira
Biju -- we have the ability to define components. It sounds like the consensus is that folks prefer components over free-form labels. What are the components that you hoped to find that aren't there? On 5/13/19 6:31 PM, Biju N wrote: FYI. There are instances where we don't have "components" which can help filter a feature for e.g. Quota is a good example. That is a reason for using labels. This helps in filtering the tickets and get an understanding of a feature. On Mon, May 13, 2019 at 5:36 PM Andrew Purtell wrote: I’ve been using components so am accidentally in agreement. Didn’t know which to use, just picked one. We should document this preference. On May 13, 2019, at 12:52 PM, Jan Hentschel < jan.hentsc...@ultratendency.com> wrote: Agree with Sean. I would prefer to use labels where we have something, which is not HBase-specific (such as the “beginner” label), and components otherwise. From: Sean Busbey Reply-To: "dev@hbase.apache.org" Date: Monday, May 13, 2019 at 9:48 PM To: dev Subject: Re: [DISCUSS] Updating categorical info on Jira labels are shared across the entire jira instance whereas components are under the control of the project. personally I prefer components. the only labels I like are when we use "beginner" or if we were to move away from "Hadoop Flags" to an incompatible change label. On Mon, May 13, 2019 at 2:34 PM Josh Elser els...@apache.org>> wrote: I see BijuN doing a lot of work lately to try to categorize issues better. Thanks to him for trying to make Jira more usable in that regard! One concern I have is that we have duplicative categorization: components and labels. I prefer components as they push us into curated "names" whereas a label might have skew in capitalization (e.g. "quota", "Quota", "quotas", "space quota"). What do others think? -- Sean
