Jonathan Hsieh created HBASE-13233:
--
Summary: add hbase-11339 branch to the patch testing script
Key: HBASE-13233
URL: https://issues.apache.org/jira/browse/HBASE-13233
Project: HBase
Issue
Andrew Purtell created HBASE-13234:
--
Summary: Improve the obviousness of the download link on
hbase.apache.org
Key: HBASE-13234
URL: https://issues.apache.org/jira/browse/HBASE-13234
Project: HBase
On Fri, Mar 13, 2015 at 11:59 AM, Andrew Purtell apurt...@apache.org
wrote:
There's no reason our HDFS usage should be exposed in the HBase client
code, and I think the application classpath feature for YARN in that
version can isolate us on the MR side.
I was thinking more the case where
Do we need to couple decisions for 1.1 and 2.0 in the same discussion?
On Fri, Mar 13, 2015 at 10:16 AM, Sean Busbey bus...@cloudera.com wrote:
I think the last time this came up the answer to when? was
* 1.1 in time for phoenix 5
* 2.0 later than 6 months and sooner than 6 years from 1.0
You’re going to need to set up a trust in Kerberos. Either single way trust or
two way trust.
YMMV.
Its not as simple as just setting up an SSL although you can set up an SSL to
encrypt the traffic between clusters, however the clusters themselves are not
secured.
HTH
On Mar 12, 2015, at
That was my question.. We can discuss them independently? Or is there a
reason not to?
On Fri, Mar 13, 2015 at 11:10 AM, Sean Busbey bus...@cloudera.com wrote:
On Fri, Mar 13, 2015 at 12:31 PM, Andrew Purtell apurt...@apache.org
wrote:
Do we need to couple decisions for 1.1 and 2.0 in the
The only reason I can think of to make decisions now would be if we want to
ensure we have consensus for the changes for Phoenix and enough time to
implement them.
Given that AFAIK it's those changes that'll drive having a 1.1 release,
seems prudent. But I haven't been tracking the changes
I think we can solve this generally for Hadoop 2.6.0+. There's no reason
our HDFS usage should be exposed in the HBase client code, and I think the
application classpath feature for YARN in that version can isolate us on
the MR side. I am willing to do this work in time for 1.1.
Srikanth Srungarapu created HBASE-13235:
---
Summary: Revisit the security auditing semantics.
Key: HBASE-13235
URL: https://issues.apache.org/jira/browse/HBASE-13235
Project: HBase
Issue
I think the last time this came up the answer to when? was
* 1.1 in time for phoenix 5
* 2.0 later than 6 months and sooner than 6 years from 1.0
Can we discuss some goal post dates for these versions?
I'd like to help Allen get HBASE-13231 (shell script update) done, and he's
wondering how
On Fri, Mar 13, 2015 at 12:31 PM, Andrew Purtell apurt...@apache.org
wrote:
Do we need to couple decisions for 1.1 and 2.0 in the same discussion?
Like what? Interface changes for Phoenix maybe?
--
Sean
[
https://issues.apache.org/jira/browse/HBASE-13232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John resolved HBASE-13232.
Resolution: Fixed
Hadoop Flags: Reviewed
Thanks Nick. Pushed the trivial change to
Nope, goes beyond a VPN.
Securing a cluster can be a very painful task.
On Mar 13, 2015, at 6:05 AM, Akmal Abbasov akmal.abba...@icloud.com wrote:
Hi Wilm,
My initial choice was to use VPN, but I couldn’t find any related information.
Hi,
putting the many good hints in this thread
[
https://issues.apache.org/jira/browse/HBASE-13234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-13234.
Resolution: Fixed
Hadoop Flags: Reviewed
Pushed site source change to master.
Josh Elser created HBASE-13236:
--
Summary: Clean up m2e-related warnings/errors from poms
Key: HBASE-13236
URL: https://issues.apache.org/jira/browse/HBASE-13236
Project: HBase
Issue Type:
Andrew Purtell created HBASE-13237:
--
Summary: Improve trademark marks on the hbase.apache.org homepage
Key: HBASE-13237
URL: https://issues.apache.org/jira/browse/HBASE-13237
Project: HBase
Andrew Purtell created HBASE-13238:
--
Summary: Time out locks and abort if HDFS is wedged
Key: HBASE-13238
URL: https://issues.apache.org/jira/browse/HBASE-13238
Project: HBase
Issue Type:
When I made that remark I was thinking of a recent discussion we had at a
joint Phoenix and HBase developer meetup. The difference of opinion was
certainly civilized. (smile) I'm not aware of any specific written
discussion, it may or may not exist. I'm pretty sure a revival of HBASE-9203
would
Sean Busbey created HBASE-13240:
---
Summary: add an exemption to test-patch for build-only changes.
Key: HBASE-13240
URL: https://issues.apache.org/jira/browse/HBASE-13240
Project: HBase
Issue
Sean Busbey created HBASE-13241:
---
Summary: Add tests for group level grants
Key: HBASE-13241
URL: https://issues.apache.org/jira/browse/HBASE-13241
Project: HBase
Issue Type: Improvement
zhangduo created HBASE-13242:
Summary: TestPerColumnFamilyFlush.testFlushingWhenLogRolling hung
Key: HBASE-13242
URL: https://issues.apache.org/jira/browse/HBASE-13242
Project: HBase
Issue Type:
Jaymin Patel created HBASE-13239:
Summary: Hbase grants at specific column level does not work for
Groups
Key: HBASE-13239
URL: https://issues.apache.org/jira/browse/HBASE-13239
Project: HBase
Hi Jerry,
Hi, Vladimir
Hope I understand your question correctly.
If both local cluster and remote cluster are Kerberos enabled,
ExportSnapshot from local to remote will work as long as both
clusters' Kerberos
have been set up in a way that they understand each other.
Where I can find
Hi Talat,
I was considering replication, but decided to start with snapshots. Moreover,
there are some drawbacks with replication, like propagation of user error, etc.
Also I need a secure connection between data-centers, and I can't find
information about this.
On 13 Mar 2015, at 05:45,
Ashish Singhi created HBASE-13226:
-
Summary: Document enable_table_replication and
disable_table_replication shell commands
Key: HBASE-13226
URL: https://issues.apache.org/jira/browse/HBASE-13226
Hi,
putting the many good hints in this thread aside ... isn't this more a
question of network deployment, than a question for hbase or hadoop
features?
I think a more general plan would be the usage of some VPN channel
technology. By this plan
a) the data is transferred secure
b) the machines
Gustavo Anatoly created HBASE-13229:
---
Summary: Bug compatibility validation to start
local-regionservers.sh and local-master-backup.sh
Key: HBASE-13229
URL: https://issues.apache.org/jira/browse/HBASE-13229
Hi,
Am 13.03.2015 um 12:05 schrieb Akmal Abbasov:
My initial choice was to use VPN, but I couldn’t find any related information.
well, I think that's because hbase or hadoop has nothing to do with vpn.
It's completely independent. Just configure a VPN for the all machines
in cluster A and
Matteo Bertozzi created HBASE-13227:
---
Summary: LoadIncrementalHFile should skip non-files inside a
possible family-dir
Key: HBASE-13227
URL: https://issues.apache.org/jira/browse/HBASE-13227
Hi Wilm,
My initial choice was to use VPN, but I couldn’t find any related information.
Hi,
putting the many good hints in this thread aside ... isn't this more a
question of network deployment, than a question for hbase or hadoop
features?
I think a more general plan would be the usage
Matteo Bertozzi created HBASE-13228:
---
Summary: Create procedure v2 branch
Key: HBASE-13228
URL: https://issues.apache.org/jira/browse/HBASE-13228
Project: HBase
Issue Type: Sub-task
FYI, some time next week I'm going to try to simplify our jira role list.
When I go to add new contributors it takes forever, I'm guessing because of
the list size.
I think I can trim it down some by making sure folks who are committers are
in the committer list and not the contributor list.
Jonathan Hsieh created HBASE-13230:
--
Summary: [mob] reads hang when trying to read rows with large mobs
(10MB)
Key: HBASE-13230
URL: https://issues.apache.org/jira/browse/HBASE-13230
Project: HBase
[
https://issues.apache.org/jira/browse/HBASE-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu resolved HBASE-12766.
Resolution: Duplicate
Dupe of HBASE-13136
TestSplitLogManager#testGetPreviousRecoveryMode sometimes
[
https://issues.apache.org/jira/browse/HBASE-13064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Stepachev resolved HBASE-13064.
--
Resolution: Duplicate
Release Note: seems fixed by HBASE-13076 and other issues.
[
https://issues.apache.org/jira/browse/HBASE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh resolved HBASE-3743.
---
Resolution: Duplicate
This is essentially a dupe of HBASE-8329 and HBASE-5867, both of which
On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell apurt...@apache.org
wrote:
+1
I think it would be fine to trim the contributor list too. We can always
add people back on demand in order to (re)assign issues.
I wasn't sure how we generate the list of contributors. But then I noticed
that we
I'm -1 (non-binding) on weakening our compatibility promises. The more we can
isolate our users from the impact of changes upstream the better.
We can't though in general. Making compatibility promises we can't keep
because our upstreams don't (see the dependencies section of Hadoop's
+1
I think it would be fine to trim the contributor list too. We can always
add people back on demand in order to (re)assign issues.
On Fri, Mar 13, 2015 at 8:32 AM, Sean Busbey bus...@cloudera.com wrote:
FYI, some time next week I'm going to try to simplify our jira role list.
When I go to
How about I make a saved jira query for people who have had jira's assigned
to them, add a link to that query for our here are the contributors
section, and then trim off from the role anyone who hasn't been assigned an
issue in the last year?
That sounds like a very fair
On Fri, Mar 13, 2015 at 11:18 AM, Andrew Purtell apurt...@apache.org
wrote:
I'm -1 (non-binding) on weakening our compatibility promises. The more
we can
isolate our users from the impact of changes upstream the better.
We can't though in general. Making compatibility promises we can't keep
Allen Wittenauer created HBASE-13231:
Summary: shell script rewrite
Key: HBASE-13231
URL: https://issues.apache.org/jira/browse/HBASE-13231
Project: HBase
Issue Type: New Feature
There's no reason our HDFS usage should be exposed in the HBase client code
I did look at this in the past, IIRC, our dependency was we use
hadoop-common code to read our XML configuration files
I would +1 a code duplication to remove the dependency.
I also think it is important for the end
There's no reason our HDFS usage should be exposed in the HBase client
code, and I think the application classpath feature for YARN in that
version can isolate us on the MR side.
I was thinking more the case where we have to bump our version of Guava
because our version and Hadoop's version are
Anoop Sam John created HBASE-13232:
--
Summary: ConnectionManger : Batch pool threads and metaLookup pool
threads should use different name pattern
Key: HBASE-13232
URL:
45 matches
Mail list logo
