[jira] [Created] (HBASE-5815) ZKUtil.createWithParents should be transactional

2012-04-17 Thread Jesse Yates (Created) (JIRA)
ZKUtil.createWithParents should be transactional


 Key: HBASE-5815
 URL: https://issues.apache.org/jira/browse/HBASE-5815
 Project: HBase
  Issue Type: Improvement
Reporter: Jesse Yates
Assignee: Jesse Yates
 Fix For: 0.96.0, 0.94.1


Should solve a lot of tricky corner cases when you create the parent, get an 
update to watchers (who read ZK, but find no children) and then create the 
children. 

--
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] [Created] (HBASE-5790) ZKUtil deleteRecurisively should be a recoverable operation

2012-04-13 Thread Jesse Yates (Created) (JIRA)
ZKUtil deleteRecurisively should be a recoverable operation
---

 Key: HBASE-5790
 URL: https://issues.apache.org/jira/browse/HBASE-5790
 Project: HBase
  Issue Type: Improvement
Reporter: Jesse Yates
Assignee: Jesse Yates
 Fix For: 0.96.0, 0.94.1


As of 3.4.3 Zookeeper now has full, multi-operation transaction. This means we 
can wholesale delete chunks of the zk tree and ensure that we don't have any 
pesky recursive delete issues where we delete the children of a node, but then 
a child joins before deletion of the parent. Even without transactions, this 
should be the behavior, but it is possible to make it much cleaner now that we 
have this new feature in zk.

--
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] [Created] (HBASE-5775) ZKUtil doesn't handle deleteRecurisively cleanly

2012-04-12 Thread Jesse Yates (Created) (JIRA)
ZKUtil doesn't handle deleteRecurisively cleanly


 Key: HBASE-5775
 URL: https://issues.apache.org/jira/browse/HBASE-5775
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.94.0
Reporter: Jesse Yates
Assignee: Jesse Yates
 Fix For: 0.94.0, 0.96.0


ZKUtil.deleteNodeRecursively()'s contract says that it handles deletion of the 
node and all its children. However, nothing is mentioned as to what happens if 
the node you are attempting to delete doesn't actually exist. Turns out, it 
throws a null pointer exception. I
'm proposing that we change the code s.t. it handles the case where the parent 
is already gone and exits cleanly, rather than failing horribly.

--
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] [Created] (HBASE-5548) Add ability to get a table in the shell

2012-03-09 Thread Jesse Yates (Created) (JIRA)
Add ability to get a table in the shell
---

 Key: HBASE-5548
 URL: https://issues.apache.org/jira/browse/HBASE-5548
 Project: HBase
  Issue Type: Improvement
  Components: shell
Reporter: Jesse Yates
 Fix For: 0.96.0


Currently, all the commands that operate on a table in the shell first have to 
take the table as name as input. 

There are two main considerations:
* It is annoying to have to write the table name every time, when you should 
just be able to get a reference to a table
* the current implementation is very wasteful - it creates a new HTable for 
each call (but reuses the connection since it uses the same configuration)

We should be able to get a handle to a single HTable and then operate on that.

--
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] [Created] (HBASE-5526) Optional file permission settings

2012-03-05 Thread Jesse Yates (Created) (JIRA)
Optional file permission settings
-

 Key: HBASE-5526
 URL: https://issues.apache.org/jira/browse/HBASE-5526
 Project: HBase
  Issue Type: New Feature
  Components: regionserver
Reporter: Jesse Yates
Assignee: Jesse Yates
 Fix For: 0.94.0


Currently many all the files created by the HBase user are just written using 
the default file permissions granted by hdfs. However, it is often times 
adventageous to only allow a subset of the world to view the actual data 
written by hbase when scanning the raw hdfs files. 

This ticket covers setting permissions for files written to hdfs that are 
storing actual user data, as opposed to _all_ files written to hdfs as many of 
them contain non-identifiable metadata.

--
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] [Created] (HBASE-5354) Source to standalone deployment script

2012-02-08 Thread Jesse Yates (Created) (JIRA)
Source to standalone deployment script
--

 Key: HBASE-5354
 URL: https://issues.apache.org/jira/browse/HBASE-5354
 Project: HBase
  Issue Type: New Feature
  Components: build, scripts
Affects Versions: 0.94.0
Reporter: Jesse Yates
Assignee: Jesse Yates
Priority: Minor


Automating the testing of source code in a 'real' instance can be a bit of a 
pain, even getting it into standalone mode.
Steps you need to go through:
1) Build the project
2) Copy it to the deployment directory
3) Shutdown the current cluster (if it is running)
4) Untar the tar
5) Update the configs to point to a local data cluster
6) Startup the new deployment

Yeah, its not super difficult, but it would be nice to just have a script to 
make it button push easy.

--
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] [Created] (HBASE-5353) HA/Distributed HMaster via RegionServers

2012-02-08 Thread Jesse Yates (Created) (JIRA)
HA/Distributed HMaster via RegionServers


 Key: HBASE-5353
 URL: https://issues.apache.org/jira/browse/HBASE-5353
 Project: HBase
  Issue Type: Improvement
  Components: master, regionserver
Affects Versions: 0.94.0
Reporter: Jesse Yates
Priority: Minor


Currently, the HMaster node must be considered a 'special' node (single point 
of failure), meaning that the node must be protected more than the other 
commodity machines. It should be possible to instead have the HMaster be much 
more available, either in a distributed sense (meaning a bit rewrite) or with 
multiple instances and automatic failover. 

--
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] [Created] (HBASE-5350) Fix jamon generated package names

2012-02-07 Thread Jesse Yates (Created) (JIRA)
Fix jamon generated package names
-

 Key: HBASE-5350
 URL: https://issues.apache.org/jira/browse/HBASE-5350
 Project: HBase
  Issue Type: Bug
  Components: monitoring
Affects Versions: 0.92.0
Reporter: Jesse Yates
 Fix For: 0.94.0


Previously, jamon was creating the template files in "org.apache.hbase", but it 
should be "org.apache.hadoop.hbase", so it's in line with rest of source files.

--
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] [Created] (HBASE-5348) Constraint configuration loaded with bloat

2012-02-07 Thread Jesse Yates (Created) (JIRA)
Constraint configuration loaded with bloat
--

 Key: HBASE-5348
 URL: https://issues.apache.org/jira/browse/HBASE-5348
 Project: HBase
  Issue Type: Bug
  Components: coprocessors, regionserver
Affects Versions: 0.94.0
Reporter: Jesse Yates
Assignee: Jesse Yates
Priority: Minor


Constraints load the configuration but don't load the 'correct' configuration, 
but instead instantiate the default configuration (via new Configuration). It 
should just be Configuration(false)

--
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] [Created] (HBASE-5318) Support Eclipse Indigo

2012-02-01 Thread Jesse Yates (Created) (JIRA)
Support Eclipse Indigo 
---

 Key: HBASE-5318
 URL: https://issues.apache.org/jira/browse/HBASE-5318
 Project: HBase
  Issue Type: Improvement
  Components: build
Affects Versions: 0.94.0
 Environment: Eclipse Indigo (1.4.1) which includes m2eclipse (1.0 SR1).
Reporter: Jesse Yates
Assignee: Jesse Yates
Priority: Minor


The current 'standard' release of Eclipse (indigo) comes with m2eclipse 
installed. However, as of m2e v1.0, "interesting lifecycle phases" are now 
handled via a 'connector'. However, several of the plugins we use don't support 
connectors. This means that eclipse bails out and won't build the project or 
view it as 'working' even though it builds just fine from the the command line.

Since Eclipse is one of the major java IDEs and that Indigo has been around for 
a while, we should make it easy to for new devs to pick up the code and for 
older devs to upgrade painlessly. The original build should not be modified in 
any significant way.

--
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] [Created] (HBASE-4879) Add Constraint support to shell

2011-11-27 Thread Jesse Yates (Created) (JIRA)
Add Constraint support to shell
---

 Key: HBASE-4879
 URL: https://issues.apache.org/jira/browse/HBASE-4879
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.94.0
Reporter: Jesse Yates


Follow-on ticket to HBASE-4605. Extend the shell functionality to include 
altering a table to add a Constraint. 

Discussion around this can be found at:
http://search-hadoop.com/m/EeYb3dezMM

--
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] [Created] (HBASE-4605) Add constraints as a top-level feature

2011-10-17 Thread Jesse Yates (Created) (JIRA)
Add constraints as a top-level feature
--

 Key: HBASE-4605
 URL: https://issues.apache.org/jira/browse/HBASE-4605
 Project: HBase
  Issue Type: Improvement
  Components: client, coprocessors
Affects Versions: 0.94.0
Reporter: Jesse Yates
Assignee: Jesse Yates


>From Jesse's comment on dev:
{quote}
What I would like to propose is a simple interface that people can use to 
implement a 'constraint' (matching the classic database definition). This would 
help ease of adoption by helping HBase more easily check that box, help 
minimize code duplication across organizations, and lead to easier adoption.

Essentially, people would implement a 'Constraint' interface for checking keys 
before they are put into a table. Puts that are valid get written to the table, 
but if not people can will throw an exception that gets propagated back to the 
client explaining why the put was invalid.

Constraints would be set on a per-table basis and the user would be expected to 
ensure the jars containing the constraint are present on the machines serving 
that table.

Yes, people could roll their own mechanism for doing this via coprocessors each 
time, but this would make it easier to do so, so you only have to implement a 
very minimal interface and not worry about the specifics.
{quote}

--
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] [Created] (HBASE-4561) Update Maven documentation in book

2011-10-09 Thread Jesse Yates (Created) (JIRA)
Update Maven documentation in book
--

 Key: HBASE-4561
 URL: https://issues.apache.org/jira/browse/HBASE-4561
 Project: HBase
  Issue Type: Improvement
  Components: documentation
Reporter: Jesse Yates
Priority: Minor


The maven documentation is a little out of date and has recently led to some 
confusion about tests. This would cleanup the maven documents in the book to be 
more explicit about how maven should be used.

--
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] [Created] (HBASE-4559) Refactor TestAvroServer into an integration test

2011-10-09 Thread Jesse Yates (Created) (JIRA)
Refactor TestAvroServer into an integration test


 Key: HBASE-4559
 URL: https://issues.apache.org/jira/browse/HBASE-4559
 Project: HBase
  Issue Type: Improvement
  Components: test
Reporter: Jesse Yates


TestAvroServer is a beefy test, spins up a mini cluster, does a large series of 
manipulations and then spins it down. It take about 2 mins to run on a local 
machine, which on the high side for a 'unit' test. 

This is part of the implentation discussed in 
http://search-hadoop.com/m/L9OzBNEOJK1

--
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