Accumulo
  1. Accumulo
  2. ACCUMULO-118

accumulo could work across HDFS instances, which would help it to scale past a single namenode

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6.0
    • Component/s: master, tserver
    • Labels:
      None

      Description

      Consider using full path names to files, which would allow the servers to access the files on any HDFS file system.

      Work may exist elsewhere to run HDFS using a number of NameNode instances to break up the namespace.

      We may need a pluggable strategy to determine namespace for new files.

      1. ACCUMULO-118-01.txt
        5 kB
        Eric Newton
      2. ACCUMULO-118-02.txt
        6 kB
        Eric Newton

        Issue Links

        1.
        create a utility for converting the !METADATA table entry to a full path Sub-task Resolved Unassigned  
         
        2.
        ServerConstants.getBaseDirs() use fs default name, not instance.dfs.uri Sub-task Resolved Keith Turner  
         
        3.
        Get disk usage will not work across namenodes Sub-task Resolved Eric Newton  
         
        4.
        Offline map reduce will fail if tablet spans multiple namenodes Sub-task Resolved Keith Turner  
         
        5.
        RFile printinfo command does not handle multiple namenodes Sub-task Resolved Keith Turner  
         
        6.
        Monitor collects disk usage from single namenode Sub-task Resolved Josh Elser  
         
        7.
        Bulk import does sanity checks on client side using a single filesystem Sub-task Resolved Keith Turner  
         
        8.
        Changing Accumulo config can prevent locating root table files. Sub-task Resolved Keith Turner  
         
        9.
        Analyze all usages of instance.dfs.uri and instance.volumes Sub-task Resolved Keith Turner  
         
        10.
        Instance id and version info only stored on one hdfs instance Sub-task Resolved Keith Turner  
         
        11.
        Need utility to decommission dfs uris Sub-task Resolved Keith Turner  
         
        12.
        Garbage collector may delete referenced files after upgrade Sub-task Resolved Keith Turner  
         
        13.
        Write ahead logs from upgrade prematurely GCed Sub-task Resolved Eric Newton  
         
        14.
        Create utility for rewriting uris Sub-task Resolved Keith Turner

        100%

        Original Estimate - Not Specified Original Estimate - Not Specified
        Time Spent - 0.5h
         
        15.
        WALog entries not properly deleted after recovery during upgrade 1.5 -> 1.6 Sub-task Resolved Eric Newton  
         
        16.
        Accumulo fails when instance.volumes and fs.default.name are disjoint Sub-task Resolved Keith Turner  
         
        17.
        Recommend using viewfs:// or HA Namenode Sub-task Resolved Keith Turner  
         
        18.
        Deprecate instance.dfs.uri and instance.dfs.dir Sub-task Resolved Josh Elser  
         
        19.
        general.volume.chooser has no environment Sub-task Resolved Eric Newton  
         
        20.
        Log recovery is converting paths to relative Sub-task Resolved Keith Turner  
         
        21.
        updateAccumuloVersion only updates the data version on a single configured volume Sub-task Resolved Josh Elser  
         
        22.
        Copying failed bulk imports seems broken Sub-task Resolved Eric Newton  
         
        23.
        Suppress expected deprecation warnings from instance.dfs.{dir,uri} Sub-task Resolved Josh Elser  
         
        24.
        FileUtil expects instance.dfs.dir in tmpDir path Sub-task Resolved Josh Elser  
         
        25.
        Update ClientOpts to read from volumes or instance dir Sub-task Resolved Josh Elser  
         

          Activity

          Hide
          Keith Turner added a comment -

          One issue this is trying to solve is overcoming namenode scalability issues. Before working on this would need to investigate what is being done to make the namenode more scalable. Would need to decide if we want to contribute to that work, or spend time working around the issue.

          Show
          Keith Turner added a comment - One issue this is trying to solve is overcoming namenode scalability issues. Before working on this would need to investigate what is being done to make the namenode more scalable. Would need to decide if we want to contribute to that work, or spend time working around the issue.
          Hide
          Todd Lipcon added a comment -

          In HDFS 0.23 we have federation, which is (a) server side support so that a pool of DNs can have blocks that span multiple NNs/namespaces, and (b) client side mount table support "viewfs". So, you could have 10,000 DNs, a few NNs, and a client side mount table that divides up the namespace across those NNs.

          Show
          Todd Lipcon added a comment - In HDFS 0.23 we have federation, which is (a) server side support so that a pool of DNs can have blocks that span multiple NNs/namespaces, and (b) client side mount table support "viewfs". So, you could have 10,000 DNs, a few NNs, and a client side mount table that divides up the namespace across those NNs.
          Hide
          Eric Newton added a comment -

          Interesting! It looks like a 0.23.0 is very close to release, maybe?

          Show
          Eric Newton added a comment - Interesting! It looks like a 0.23.0 is very close to release, maybe?
          Hide
          Todd Lipcon added a comment -

          Yep, we've now released 0.23.0. It's still considered Alpha, but HDFS should be in basic working condition at least!

          Show
          Todd Lipcon added a comment - Yep, we've now released 0.23.0. It's still considered Alpha, but HDFS should be in basic working condition at least!
          Hide
          Eric Newton added a comment -

          If we used viewfs, we would still need a more flexible way of choosing where in the file system we want to put a tablet. Right now we use

          configured root of everything / tables / tableId / generated id / generated id . file extension
          

          Some possible implementations:

          • configure a particular table onto a namespace, by mounting another namespace at the tableId. But this would be difficult to predict and configure.
          • have a "namespace" property, on a per-table config, which would provide the root directory to use for the table. You could not ever change it, though. Also, it might be nice to have a table spread over multiple namespaces.
          • use a hashing technique to map names into different real namespaces. But if we did this as a layer over other filesystems, we would need to perform a read against all nns in order to list the contents of a directory. I'm not sure if we do very many directory listings, so maybe this wouldn't be worse.
          • pluggable component that would choose the filenames to use. You could use hashes to distribute files, or choose based on namenode health, decommission status, etc. Unfortunately, this would make the organization of the table's files less coherent.
          Show
          Eric Newton added a comment - If we used viewfs, we would still need a more flexible way of choosing where in the file system we want to put a tablet. Right now we use configured root of everything / tables / tableId / generated id / generated id . file extension Some possible implementations: configure a particular table onto a namespace, by mounting another namespace at the tableId. But this would be difficult to predict and configure. have a "namespace" property, on a per-table config, which would provide the root directory to use for the table. You could not ever change it, though. Also, it might be nice to have a table spread over multiple namespaces. use a hashing technique to map names into different real namespaces. But if we did this as a layer over other filesystems, we would need to perform a read against all nns in order to list the contents of a directory. I'm not sure if we do very many directory listings, so maybe this wouldn't be worse. pluggable component that would choose the filenames to use. You could use hashes to distribute files, or choose based on namenode health, decommission status, etc. Unfortunately, this would make the organization of the table's files less coherent.
          Hide
          Dave Marion added a comment -

          Just thinking...

          Configure Accumulo with one default namespace (ns1) for the system. Tables created with no namespace specified will go into ns1. Tables created with namespaces defined (ns2, ns3, etc) will use some default file creation load balancer (round-robin). Allow tables to use user-defined file creation load balancers. This might lead to defining back-up namespaces (ns4, ns5) later (Just a thought).

          Will need to provide a utility for moving files between namespaces so that the !METADATA table is updated correctly.

          Show
          Dave Marion added a comment - Just thinking... Configure Accumulo with one default namespace (ns1) for the system. Tables created with no namespace specified will go into ns1. Tables created with namespaces defined (ns2, ns3, etc) will use some default file creation load balancer (round-robin). Allow tables to use user-defined file creation load balancers. This might lead to defining back-up namespaces (ns4, ns5) later (Just a thought). Will need to provide a utility for moving files between namespaces so that the !METADATA table is updated correctly.
          Hide
          Eric Newton added a comment -

          I'm leaning towards using full-paths for filenames, and having the system select a path based on a pluggable component. The NN references would be handled by viewfs and federation.

          This will be an extensive change, and it's going to take a while to refactor the code to deal with full paths.

          There are a bunch of places where we rely on rename() being inexpensive. If we move something from /nn1/accumulo/tables to //nn2/accumulo/tables that will be expensive. Usually we are just renaming a file from foo.tmp to foo, which will work fine. But there are others:

          • bulk import
          • log archiving
          • others?

          these renames will need to be namespace aware.

          Show
          Eric Newton added a comment - I'm leaning towards using full-paths for filenames, and having the system select a path based on a pluggable component. The NN references would be handled by viewfs and federation. This will be an extensive change, and it's going to take a while to refactor the code to deal with full paths. There are a bunch of places where we rely on rename() being inexpensive. If we move something from /nn1/accumulo/tables to //nn2/accumulo/tables that will be expensive. Usually we are just renaming a file from foo.tmp to foo , which will work fine. But there are others: bulk import log archiving others? these renames will need to be namespace aware.
          Hide
          Keith Turner added a comment -

          Could consider supporting current paths starting with '/' or '../' and absolute paths like hdfs://NN/abspath. All of these have different prefixes so the code can easily disambiguate. The upside is that it takes less space in the metadata table and makes upgrade easier, the downside is that it makes the code more complex. The complexity can be managed by using centralized code to decode relative and absolute paths into absolute paths.

          Show
          Keith Turner added a comment - Could consider supporting current paths starting with '/' or '../' and absolute paths like hdfs://NN/abspath. All of these have different prefixes so the code can easily disambiguate. The upside is that it takes less space in the metadata table and makes upgrade easier, the downside is that it makes the code more complex. The complexity can be managed by using centralized code to decode relative and absolute paths into absolute paths.
          Hide
          David Medinets added a comment -

          Why was this switched to a blocker? What is it blocking?

          Show
          David Medinets added a comment - Why was this switched to a blocker? What is it blocking?
          Hide
          Josh Elser added a comment -

          I believe this means that Eric intends to not release 1.6 without this.

          Show
          Josh Elser added a comment - I believe this means that Eric intends to not release 1.6 without this.
          Hide
          Eric Newton added a comment -

          Yes, Josh Elser that's what I mean. It's time to start thinking about 1.6, and I intend for this to be part of that release. My goal is a working branch in 2 months.

          Show
          Eric Newton added a comment - Yes, Josh Elser that's what I mean. It's time to start thinking about 1.6, and I intend for this to be part of that release. My goal is a working branch in 2 months.
          Hide
          Keith Turner added a comment -

          It's time to start thinking about 1.6, and I intend for this to be part of that release. My goal is a working branch in 2 months.

          Do you plan to post a design doc outlining your approach to tackling this?

          Show
          Keith Turner added a comment - It's time to start thinking about 1.6, and I intend for this to be part of that release. My goal is a working branch in 2 months. Do you plan to post a design doc outlining your approach to tackling this?
          Hide
          Eric Newton added a comment -

          Yes, I'm working on it now.

          Show
          Eric Newton added a comment - Yes, I'm working on it now.
          Hide
          Eric Newton added a comment -

          Some thoughts about ACCUMULO-118, which will eventually become a design doc.

          Show
          Eric Newton added a comment - Some thoughts about ACCUMULO-118 , which will eventually become a design doc.
          Hide
          Josh Elser added a comment -

          With a different viewfs implementation, we could use a hash to
          determine the namespace and hide the whole switch between file
          systems:

          hash("/accumulo/tables/1/default_tablet/A0003892.rf") % 2 -> hdfs://nn1:12345
          hash("/accumulo/tables/1/default_tablet/F0004567.rf") % 2 -> hdfs://nn2:12345

          Unfortunately, renaming a file might force it to a new namespace.

          I bet you could be tricky with that actual hash+modulo in such a way which guarantees that it wouldn't change namespaces.

          Show
          Josh Elser added a comment - With a different viewfs implementation, we could use a hash to determine the namespace and hide the whole switch between file systems: hash("/accumulo/tables/1/default_tablet/A0003892.rf") % 2 -> hdfs://nn1:12345 hash("/accumulo/tables/1/default_tablet/F0004567.rf") % 2 -> hdfs://nn2:12345 Unfortunately, renaming a file might force it to a new namespace. I bet you could be tricky with that actual hash+modulo in such a way which guarantees that it wouldn't change namespaces.
          Hide
          Dave Marion added a comment - - edited

          Personally I am not a fan of the hash idea. I would rather see a mapping of namespace prefix to NN in the configuration (ns1 = hdfs://host:port, ns2 = hdfs://host:port). I'm thinking forward to table file load balancing across namespaces and backups (see my comment from 3/Apr/12). If for example you quiesced the database and performed a backup, then you could change the namespace mapping such that ns1 and ns2 point to the same hdfs://host:port if for some reason you lost the 2nd hdfs instance (it crashed, you wanted to remove it, etc).

          This could also allow for an upgrade of Hadoop wile Accumulo is still running. Think about the scenario where ns1 is on racks 1&2 and ns2 is on racks 3&4 of a cluster and the files of table T are spread across ns1 and ns2. You could change the configuration of the table file load balancer (new feature) that puts new files on ns2. You recompact the table so now all new files are on ns2. When done for all tables (and walogs), then you can shutdown ns1 and upgrade to a new version of Hadoop.

          Show
          Dave Marion added a comment - - edited Personally I am not a fan of the hash idea. I would rather see a mapping of namespace prefix to NN in the configuration (ns1 = hdfs://host:port, ns2 = hdfs://host:port). I'm thinking forward to table file load balancing across namespaces and backups (see my comment from 3/Apr/12). If for example you quiesced the database and performed a backup, then you could change the namespace mapping such that ns1 and ns2 point to the same hdfs://host:port if for some reason you lost the 2nd hdfs instance (it crashed, you wanted to remove it, etc). This could also allow for an upgrade of Hadoop wile Accumulo is still running. Think about the scenario where ns1 is on racks 1&2 and ns2 is on racks 3&4 of a cluster and the files of table T are spread across ns1 and ns2. You could change the configuration of the table file load balancer (new feature) that puts new files on ns2. You recompact the table so now all new files are on ns2. When done for all tables (and walogs), then you can shutdown ns1 and upgrade to a new version of Hadoop.
          Hide
          Christopher Tubbs added a comment -

          Personally I am not a fan of the hash idea. I would rather...

          Perhaps a per-table configuration of the hash function?

          Show
          Christopher Tubbs added a comment - Personally I am not a fan of the hash idea. I would rather... Perhaps a per-table configuration of the hash function?
          Hide
          Keith Turner added a comment -

          I would rather see a mapping of namespace prefix to NN in the configuration (ns1 = hdfs://host:port, ns2 = hdfs://host:port)

          I agree, I think making this explicit and straightforward is the way to go. Although, storing the namespace config in accumulo-site.xml seems error prone. In the worst case node1 defines ns1=hdfs://nn3 and node2 defines ns2=hdfs://nn4. I would advocate only storing this mapping in zookeeper.

          I'm thinking forward to table file load balancing across namespaces and backups (see my comment from 3/Apr/12).

          Dave Marion Would avoding storing direct pointers to namenodes in the metadata table be sufficient to satisfy this? Always have a level of indirection like viewfs?

          Eric Newton Would there be any reason for a single tablet to spread its files across multiple name nodes? Tablets currently have a directory column that tells a tablet where to create new files. This could be converted to an absolute path/url. When a tablet creates a new file, it uses this path. There may be some small efficiency gain when opening multiple files for tablet if all of the calls went to the same namenode.

             1< srv:dir  namespace://ns1/accumulo/tables/abc
             1< file:namespace://ns1/accumulo/tables/abc/F0000002.rf []    196,1
          

          Perhaps a per-table configuration of the hash function?

          Could possibly have a plugin thats called to choose the value of srv:dir for a new tablet. The input to this function could be the KeyExtent and list of available namespaces and it could return a namespace/url. The default implemention could hash+mod the tablets end row and use that index into the list of namespaces.

          Eric Newton once a design is settled on, I think it would be useful if the design doc outlined how this new feature will interact with bulk import, clone table, export/import table, and offline map reduce.

          Show
          Keith Turner added a comment - I would rather see a mapping of namespace prefix to NN in the configuration (ns1 = hdfs://host:port, ns2 = hdfs://host:port) I agree, I think making this explicit and straightforward is the way to go. Although, storing the namespace config in accumulo-site.xml seems error prone. In the worst case node1 defines ns1=hdfs://nn3 and node2 defines ns2=hdfs://nn4. I would advocate only storing this mapping in zookeeper. I'm thinking forward to table file load balancing across namespaces and backups (see my comment from 3/Apr/12). Dave Marion Would avoding storing direct pointers to namenodes in the metadata table be sufficient to satisfy this? Always have a level of indirection like viewfs? Eric Newton Would there be any reason for a single tablet to spread its files across multiple name nodes? Tablets currently have a directory column that tells a tablet where to create new files. This could be converted to an absolute path/url. When a tablet creates a new file, it uses this path. There may be some small efficiency gain when opening multiple files for tablet if all of the calls went to the same namenode. 1< srv:dir namespace://ns1/accumulo/tables/abc 1< file:namespace://ns1/accumulo/tables/abc/F0000002.rf [] 196,1 Perhaps a per-table configuration of the hash function? Could possibly have a plugin thats called to choose the value of srv:dir for a new tablet. The input to this function could be the KeyExtent and list of available namespaces and it could return a namespace/url. The default implemention could hash+mod the tablets end row and use that index into the list of namespaces. Eric Newton once a design is settled on, I think it would be useful if the design doc outlined how this new feature will interact with bulk import, clone table, export/import table, and offline map reduce.
          Hide
          Keith Turner added a comment -

          Would also be nice to outline an upgrade strategy in the design doc.

          Show
          Keith Turner added a comment - Would also be nice to outline an upgrade strategy in the design doc.
          Hide
          Adam Fuchs added a comment -

          How does this related to ACCUMULO-722? Seems like if we implemented ACCUMULO-722 then we wouldn't need this, but this is a much easier ticket, right?

          Show
          Adam Fuchs added a comment - How does this related to ACCUMULO-722 ? Seems like if we implemented ACCUMULO-722 then we wouldn't need this, but this is a much easier ticket, right?
          Hide
          Dave Marion added a comment -

          Would avoding storing direct pointers to namenodes in the metadata table be sufficient to satisfy this? Always have a level of indirection like viewfs?

          Yes, a simple direct mapping is what I would like to see. Using a hash function is not simple or direct and I don't see why its needed. If I have a backup of the files from ns1 on ns2 and vice versa (think hot backup) and ns2 fails, then I can just change the mapping so that both ns1 and ns2 point to the same Hadoop HDFS instance. No update of the metadata table needed.

          Show
          Dave Marion added a comment - Would avoding storing direct pointers to namenodes in the metadata table be sufficient to satisfy this? Always have a level of indirection like viewfs? Yes, a simple direct mapping is what I would like to see. Using a hash function is not simple or direct and I don't see why its needed. If I have a backup of the files from ns1 on ns2 and vice versa (think hot backup) and ns2 fails, then I can just change the mapping so that both ns1 and ns2 point to the same Hadoop HDFS instance. No update of the metadata table needed.
          Hide
          Dave Marion added a comment -

          Adam Fuchs I think they are related in that they are both solutions to the same problem. However, I think you can still use both solutions together.

          Show
          Dave Marion added a comment - Adam Fuchs I think they are related in that they are both solutions to the same problem. However, I think you can still use both solutions together.
          Hide
          Keith Turner added a comment - - edited

          I was looking at some docs on viewfs. If possible, I am thinking we should not do anything that would preclude using viewfs. It seems like if URIs were supported for tablet dirs and files (along with a way to choose a tablet dir) that this would almost be enough to support viewfs.

            1;m srv:dir viewfs://clusterX/accumulo1/tables/abc
            1;m file:viewfs://clusterX/accumulo1/tables/abc/F0000002.rf []    196,1
          
            1< srv:dir viewfs://clusterX/accumulo2/tables/abc
            1< file:viewfs://clusterX/accumulo2/tables/abc/F0000003.rf []    196,1
          

          If we want to further develop our own indirection layer, then maybe we should define our own URI prefix. Something like ans://. How independent should this URI be? Something like ans://<namespace name>/<path> would assume that you know where to look <namespace name> up. If the URI were like ans://<zookeepers><instance id><namespace name>/<path> then it would be more self contained. I do not think its necessary to make it self contained, its for internal use and would be translated by as needed.

          I was thinking about how bulk import will work in this federated world. Below is one way this could work.

          • Client calls import dir w/ /foo1
          • Accumlo client code uses local config to convert /foo1 to URI hdfs://nn1/foo1
          • hdfs://nn1/foo1 is passed to Accumulo server code via thrift
          • Accumulo server code looks at URI to determine where to move to, determines it has accumulo dir hdfs://nn1/accumulo.
          • moves files in hdfs://nn1/foo1 to hdfs://nn1/accumulo/tables/abc
          • Replaces hdfs://nn1/accumulo/tables/abc with ans://ns1/accumulo/tables/abc
          • Does bulk import of files in ans://ns1/accumulo/tables/abc

          Is this how this should work? The scenario above implies that Accumulo needs a dir on each namenode and way of mapping URIs to the appropriate Accumulo dir. Need to wor through this scenario w/ viewfs also.

          Show
          Keith Turner added a comment - - edited I was looking at some docs on viewfs. If possible, I am thinking we should not do anything that would preclude using viewfs. It seems like if URIs were supported for tablet dirs and files (along with a way to choose a tablet dir) that this would almost be enough to support viewfs. 1;m srv:dir viewfs://clusterX/accumulo1/tables/abc 1;m file:viewfs://clusterX/accumulo1/tables/abc/F0000002.rf [] 196,1 1< srv:dir viewfs://clusterX/accumulo2/tables/abc 1< file:viewfs://clusterX/accumulo2/tables/abc/F0000003.rf [] 196,1 If we want to further develop our own indirection layer, then maybe we should define our own URI prefix. Something like ans://. How independent should this URI be? Something like ans://<namespace name>/<path> would assume that you know where to look <namespace name> up. If the URI were like ans://<zookeepers> <instance id> <namespace name>/<path> then it would be more self contained. I do not think its necessary to make it self contained, its for internal use and would be translated by as needed. I was thinking about how bulk import will work in this federated world. Below is one way this could work. Client calls import dir w/ /foo1 Accumlo client code uses local config to convert /foo1 to URI hdfs://nn1/foo1 hdfs://nn1/foo1 is passed to Accumulo server code via thrift Accumulo server code looks at URI to determine where to move to, determines it has accumulo dir hdfs://nn1/accumulo. moves files in hdfs://nn1/foo1 to hdfs://nn1/accumulo/tables/abc Replaces hdfs://nn1/accumulo/tables/abc with ans://ns1/accumulo/tables/abc Does bulk import of files in ans://ns1/accumulo/tables/abc Is this how this should work? The scenario above implies that Accumulo needs a dir on each namenode and way of mapping URIs to the appropriate Accumulo dir. Need to wor through this scenario w/ viewfs also.
          Hide
          Eric Newton added a comment -

          Updated.

          Show
          Eric Newton added a comment - Updated.
          Hide
          ASF subversion and git services added a comment -

          Commit 1489969 from Eric Newton
          [ https://svn.apache.org/r1489969 ]

          ACCUMULO-118 support multiple namespaces for tables

          Show
          ASF subversion and git services added a comment - Commit 1489969 from Eric Newton [ https://svn.apache.org/r1489969 ] ACCUMULO-118 support multiple namespaces for tables
          Hide
          ASF subversion and git services added a comment -

          Commit 1489980 from Eric Newton
          [ https://svn.apache.org/r1489980 ]

          ACCUMULO-118 merge trunk into sandbox

          Show
          ASF subversion and git services added a comment - Commit 1489980 from Eric Newton [ https://svn.apache.org/r1489980 ] ACCUMULO-118 merge trunk into sandbox
          Hide
          ASF subversion and git services added a comment -

          Commit 1490262 from Eric Newton
          [ https://svn.apache.org/r1490262 ]

          ACCUMULO-118 merge trunk to branch

          Show
          ASF subversion and git services added a comment - Commit 1490262 from Eric Newton [ https://svn.apache.org/r1490262 ] ACCUMULO-118 merge trunk to branch
          Hide
          ASF subversion and git services added a comment -

          Commit 1490273 from Eric Newton
          [ https://svn.apache.org/r1490273 ]

          ACCUMULO-118 merge trunk into sandbox

          Show
          ASF subversion and git services added a comment - Commit 1490273 from Eric Newton [ https://svn.apache.org/r1490273 ] ACCUMULO-118 merge trunk into sandbox
          Hide
          ASF subversion and git services added a comment -

          Commit 1490337 from Eric Newton
          [ https://svn.apache.org/r1490337 ]

          ACCUMULO-118 merge trunk into sandbox

          Show
          ASF subversion and git services added a comment - Commit 1490337 from Eric Newton [ https://svn.apache.org/r1490337 ] ACCUMULO-118 merge trunk into sandbox
          Hide
          ASF subversion and git services added a comment -

          Commit 1490338 from Eric Newton
          [ https://svn.apache.org/r1490338 ]

          ACCUMULO-118 handle different uris

          Show
          ASF subversion and git services added a comment - Commit 1490338 from Eric Newton [ https://svn.apache.org/r1490338 ] ACCUMULO-118 handle different uris
          Hide
          Eric Newton added a comment -

          Right now I'm using "instance.namespaces" for the file system roots to use. It was noticed recently that the term "namespace" conflicts with the concept of "table namespaces". Anyone have a better term for these file system roots to use?

          • instance.dfs.uris
          • instance.dfs.dirs
          • instance.dfs.roots
          • instance.dfs.filesystems
          Show
          Eric Newton added a comment - Right now I'm using "instance.namespaces" for the file system roots to use. It was noticed recently that the term "namespace" conflicts with the concept of "table namespaces". Anyone have a better term for these file system roots to use? instance.dfs.uris instance.dfs.dirs instance.dfs.roots instance.dfs.filesystems
          Hide
          ASF subversion and git services added a comment -

          Commit 1490362 from Eric Newton
          [ https://svn.apache.org/r1490362 ]

          ACCUMULO-118 add apache license header to new files

          Show
          ASF subversion and git services added a comment - Commit 1490362 from Eric Newton [ https://svn.apache.org/r1490362 ] ACCUMULO-118 add apache license header to new files
          Hide
          ASF subversion and git services added a comment -

          Commit 1493756 from Eric Newton
          [ https://svn.apache.org/r1493756 ]

          ACCUMULO-118 fixed log recovery, du

          Show
          ASF subversion and git services added a comment - Commit 1493756 from Eric Newton [ https://svn.apache.org/r1493756 ] ACCUMULO-118 fixed log recovery, du
          Hide
          ASF subversion and git services added a comment -

          Commit 1493916 from Eric Newton
          [ https://svn.apache.org/r1493916 ]

          ACCUMULO-118 merge root, fix bunches of issues with gc

          Show
          ASF subversion and git services added a comment - Commit 1493916 from Eric Newton [ https://svn.apache.org/r1493916 ] ACCUMULO-118 merge root, fix bunches of issues with gc
          Hide
          ASF subversion and git services added a comment -

          Commit 1494226 from Eric Newton
          [ https://svn.apache.org/r1494226 ]

          ACCUMULO-118 switch to using "volume" instead of "namespace"

          Show
          ASF subversion and git services added a comment - Commit 1494226 from Eric Newton [ https://svn.apache.org/r1494226 ] ACCUMULO-118 switch to using "volume" instead of "namespace"
          Hide
          ASF subversion and git services added a comment -

          Commit 1494279 from Eric Newton
          [ https://svn.apache.org/r1494279 ]

          ACCUMULO-118 merge trunk to sandbox

          Show
          ASF subversion and git services added a comment - Commit 1494279 from Eric Newton [ https://svn.apache.org/r1494279 ] ACCUMULO-118 merge trunk to sandbox
          Hide
          ASF subversion and git services added a comment -

          Commit 1494310 from Eric Newton
          [ https://svn.apache.org/r1494310 ]

          ACCUMULO-118 use a configurable class to select volumes for new files

          Show
          ASF subversion and git services added a comment - Commit 1494310 from Eric Newton [ https://svn.apache.org/r1494310 ] ACCUMULO-118 use a configurable class to select volumes for new files
          Hide
          ASF subversion and git services added a comment -

          Commit 1494340 from Eric Newton
          [ https://svn.apache.org/r1494340 ]

          ACCUMULO-118 cleanup TODOs simplify VolumeManager interface, add some basic documentation

          Show
          ASF subversion and git services added a comment - Commit 1494340 from Eric Newton [ https://svn.apache.org/r1494340 ] ACCUMULO-118 cleanup TODOs simplify VolumeManager interface, add some basic documentation
          Hide
          ASF subversion and git services added a comment -

          Commit 1494648 from Eric Newton
          [ https://svn.apache.org/r1494648 ]

          ACCUMULO-118 fix fs chooser, enabled multi-volume where the first volume is not the same as the HDFS config

          Show
          ASF subversion and git services added a comment - Commit 1494648 from Eric Newton [ https://svn.apache.org/r1494648 ] ACCUMULO-118 fix fs chooser, enabled multi-volume where the first volume is not the same as the HDFS config
          Hide
          ASF subversion and git services added a comment -

          Commit 1494671 from Eric Newton
          [ https://svn.apache.org/r1494671 ]

          ACCUMULO-118 merge trunk to branch

          Show
          ASF subversion and git services added a comment - Commit 1494671 from Eric Newton [ https://svn.apache.org/r1494671 ] ACCUMULO-118 merge trunk to branch
          Hide
          ASF subversion and git services added a comment -

          Commit 1494736 from Eric Newton
          [ https://svn.apache.org/r1494736 ]

          ACCUMULO-118 use the correct data range for making file delete markers for !METADATA merges

          Show
          ASF subversion and git services added a comment - Commit 1494736 from Eric Newton [ https://svn.apache.org/r1494736 ] ACCUMULO-118 use the correct data range for making file delete markers for !METADATA merges
          Hide
          ASF subversion and git services added a comment -

          Commit 1494746 from Eric Newton
          [ https://svn.apache.org/r1494746 ]

          ACCUMULO-118 fix last TODO

          Show
          ASF subversion and git services added a comment - Commit 1494746 from Eric Newton [ https://svn.apache.org/r1494746 ] ACCUMULO-118 fix last TODO
          Hide
          ASF subversion and git services added a comment -

          Commit 1494759 from Eric Newton
          [ https://svn.apache.org/r1494759 ]

          ACCUMULO-118 merge to trunk

          Show
          ASF subversion and git services added a comment - Commit 1494759 from Eric Newton [ https://svn.apache.org/r1494759 ] ACCUMULO-118 merge to trunk
          Hide
          ASF subversion and git services added a comment -

          Commit 1494761 from Eric Newton
          [ https://svn.apache.org/r1494761 ]

          ACCUMULO-118 cleanup sandbox

          Show
          ASF subversion and git services added a comment - Commit 1494761 from Eric Newton [ https://svn.apache.org/r1494761 ] ACCUMULO-118 cleanup sandbox
          Hide
          ASF subversion and git services added a comment -

          Commit 1495020 from Eric Newton
          [ https://svn.apache.org/r1495020 ]

          ACCUMULO-118 add unit test for multiple volumes

          Show
          ASF subversion and git services added a comment - Commit 1495020 from Eric Newton [ https://svn.apache.org/r1495020 ] ACCUMULO-118 add unit test for multiple volumes
          Hide
          ASF subversion and git services added a comment -

          Commit 1495087 from Eric Newton
          [ https://svn.apache.org/r1495087 ]

          ACCUMULO-118 move unit test into test area

          Show
          ASF subversion and git services added a comment - Commit 1495087 from Eric Newton [ https://svn.apache.org/r1495087 ] ACCUMULO-118 move unit test into test area
          Hide
          ASF subversion and git services added a comment -

          Commit 1495096 from Eric Newton
          [ https://svn.apache.org/r1495096 ]

          ACCUMULO-118 there's only one default volume

          Show
          ASF subversion and git services added a comment - Commit 1495096 from Eric Newton [ https://svn.apache.org/r1495096 ] ACCUMULO-118 there's only one default volume
          Hide
          ASF subversion and git services added a comment -

          Commit 1495099 from Eric Newton
          [ https://svn.apache.org/r1495099 ]

          ACCUMULO-118 add a note to the user's manual about multi-volume configuration

          Show
          ASF subversion and git services added a comment - Commit 1495099 from Eric Newton [ https://svn.apache.org/r1495099 ] ACCUMULO-118 add a note to the user's manual about multi-volume configuration
          Hide
          ASF subversion and git services added a comment -

          Commit 1495105 from Eric Newton
          [ https://svn.apache.org/r1495105 ]

          ACCUMULO-118 fix rat check

          Show
          ASF subversion and git services added a comment - Commit 1495105 from Eric Newton [ https://svn.apache.org/r1495105 ] ACCUMULO-118 fix rat check
          Hide
          ASF subversion and git services added a comment -

          Commit 1496225 from Eric Newton
          [ https://svn.apache.org/r1496225 ]

          ACCUMULO-118 added getConnector method for VolumeManager test

          Show
          ASF subversion and git services added a comment - Commit 1496225 from Eric Newton [ https://svn.apache.org/r1496225 ] ACCUMULO-118 added getConnector method for VolumeManager test
          Hide
          ASF subversion and git services added a comment -

          Commit 1465b6e32a6b8b1c480908f0fd39e825b20c3d21 in branch refs/heads/master from [~keith_turner]
          [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=1465b6e ]

          ACCUMULO-118 made export table generate fully qualified path for export file in distcp file

          Show
          ASF subversion and git services added a comment - Commit 1465b6e32a6b8b1c480908f0fd39e825b20c3d21 in branch refs/heads/master from [~keith_turner] [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=1465b6e ] ACCUMULO-118 made export table generate fully qualified path for export file in distcp file
          Hide
          John Vines added a comment -

          This suite of tickets is really starting to concern me. These really seem to be the long poll in the tent for the 1.6 release and I'm starting to question how badly they're holding back the release. We have a mix of standing improvements that are encompassed with this feature with tickets for bugs found and bugs that are theoretically possible.

          I would like to start the conversation about marking this item and items around it as @Experimental and minimizing impact from the work done so far on single node instances.

          Show
          John Vines added a comment - This suite of tickets is really starting to concern me. These really seem to be the long poll in the tent for the 1.6 release and I'm starting to question how badly they're holding back the release. We have a mix of standing improvements that are encompassed with this feature with tickets for bugs found and bugs that are theoretically possible. I would like to start the conversation about marking this item and items around it as @Experimental and minimizing impact from the work done so far on single node instances.
          Hide
          Keith Turner added a comment -

          This suite of tickets is really starting to concern me.

          I am also concerned, I am worried about administrators having a really bad experience (bricked Accumulo instance). In hindsight I think this feature was merged in before it was complete and should not have been merged in. What can we learn from this to make development go more smoothly in the future?

          Personally I think if a new feature is incomplete (in terms of test, usability, documentation, etc), breaks other features of Accumulo, or introduces new problems it should not be merged in. I did not realize all of the problems absolute paths could cause until well after it was merged in. In hindsight I think the design of this feature should have started with administrative use cases. Maybe that would have brought to attention the problems w/ absolute paths much earlier.

          I would like to start the conversation about marking this item and items around it as @Experimental

          I wish it were that simple. Wether you use multiple namenodes or not, Accumulo will use absolute paths in 1.6 and administrators do not have a reliable way to manage those paths. I have a fix for ACCUMULO-1832 in the works, I should be done w/ that very soon. I think that fix will address my major concern w/ this issue.

          Show
          Keith Turner added a comment - This suite of tickets is really starting to concern me. I am also concerned, I am worried about administrators having a really bad experience (bricked Accumulo instance). In hindsight I think this feature was merged in before it was complete and should not have been merged in. What can we learn from this to make development go more smoothly in the future? Personally I think if a new feature is incomplete (in terms of test, usability, documentation, etc), breaks other features of Accumulo, or introduces new problems it should not be merged in. I did not realize all of the problems absolute paths could cause until well after it was merged in. In hindsight I think the design of this feature should have started with administrative use cases. Maybe that would have brought to attention the problems w/ absolute paths much earlier. I would like to start the conversation about marking this item and items around it as @Experimental I wish it were that simple. Wether you use multiple namenodes or not, Accumulo will use absolute paths in 1.6 and administrators do not have a reliable way to manage those paths. I have a fix for ACCUMULO-1832 in the works, I should be done w/ that very soon. I think that fix will address my major concern w/ this issue.
          Hide
          Eric Newton added a comment -

          I think this feature was merged in before it was complete

          Probably. But it was a pretty massive change, and maintaining it as a patch set, even with git's help, would have been very hard.

          I did not realize all of the problems absolute paths could cause

          Nor would we have if it was not merged in.

          should have started with administrative use cases

          I think we are getting better at this. For example, I can think of lots of ways that the initial WAL implementation caused a lot of grief for unsuspecting administrators. We fixed this after it was released into the wild based on feedback from the administrators. Ultimately these were fixed by moving the WAL to HDFS, and then ferreting out all the settings to make HDFS an appropriate store for the WAL.

          I think the use case of "what if administrators change the URL of a NN?" is a reasonable one, but was certainly not anything I was thinking about when I was changing thousands of lines of code to use full paths. The more subtle issues of determining aliases for namespaces (hdfs://example:9000 vs hdfs://example.com:9000), and recognizing real namespaces under viewfs are the sort of subtle things that we will only find through actual use.

          My initial goal of using concrete paths to simplify debugging might have been the wrong choice. Using some kind of indirect configuration that points to a real namespace (like viewfs) may have been better. But, that requires that you value "administrators should be able to easily move a NN to a new URL." The ability to do this with the old relative paths was not a design goal, so much as a useful result of using the shortest name possible for each file.

          These really seem to be the long poll in the tent for the 1.6 release

          Seems to me to not be so far behind namespaces. Constructive criticism includes suggestions on how to make things better. Working code is even more constructive.

          Show
          Eric Newton added a comment - I think this feature was merged in before it was complete Probably. But it was a pretty massive change, and maintaining it as a patch set, even with git's help, would have been very hard. I did not realize all of the problems absolute paths could cause Nor would we have if it was not merged in. should have started with administrative use cases I think we are getting better at this. For example, I can think of lots of ways that the initial WAL implementation caused a lot of grief for unsuspecting administrators. We fixed this after it was released into the wild based on feedback from the administrators. Ultimately these were fixed by moving the WAL to HDFS, and then ferreting out all the settings to make HDFS an appropriate store for the WAL. I think the use case of "what if administrators change the URL of a NN?" is a reasonable one, but was certainly not anything I was thinking about when I was changing thousands of lines of code to use full paths. The more subtle issues of determining aliases for namespaces (hdfs://example:9000 vs hdfs://example.com:9000), and recognizing real namespaces under viewfs are the sort of subtle things that we will only find through actual use. My initial goal of using concrete paths to simplify debugging might have been the wrong choice. Using some kind of indirect configuration that points to a real namespace (like viewfs) may have been better. But, that requires that you value "administrators should be able to easily move a NN to a new URL." The ability to do this with the old relative paths was not a design goal, so much as a useful result of using the shortest name possible for each file. These really seem to be the long poll in the tent for the 1.6 release Seems to me to not be so far behind namespaces. Constructive criticism includes suggestions on how to make things better. Working code is even more constructive.
          Hide
          Keith Turner added a comment -

          But it was a pretty massive change, and maintaining it as a patch set, even with git's help, would have been very hard.

          There is a cost there. There is also a cost to having incomplete features in master when we declare feature freeze. 1.5.0 and 1.6.0 were both delayed because of incomplete features. One possible solution to this for 1.7.0 development is to only merge in complete features to master.

          There are lots of commits related to all of the 1.6.0 features, many of them reworking code changed by previous commits related to the feature. If someone was working on another feature in a branch, this introduces a lot of unnecessary noise for them to deal with. Ideally they would only have to merge and resolve conflicts once per feature. Of course we will never achieve ideal ratio of 1, but I think we can easily make the commit per feature/bug ratio much lower than it currently is. I know Christopher Tubbs worked on namespaces in a branch for a long period of time, merging in changes and resolving conflicts, I am not sure how painful this was.

          For a feature like this that touches a lot of existing code, there is the option of refactoring w/o changing functionality and merging that into master. Of course the refactoring would be done to make the functionality changes in the branch easier. So its a multi-step process w/ the goal of always leaving master in state where its ready for release testing and minimizing the number of merges for other feature branches. This approach would also make code reviews of commits to master much easier. I am going to try doing this for the 1.7 features I work on.

          but was certainly not anything I was thinking about when I was changing thousands of lines

          I was trying to determine how we can flush out more potential issues before changing thousands of lines. If we can get as many people as possible to carefully review the design that would probably do the trick. I wonder if voting on design docs for new features would help. Voting would motivate me to carefully review a design because I would not want to vote until I had done so.

          Show
          Keith Turner added a comment - But it was a pretty massive change, and maintaining it as a patch set, even with git's help, would have been very hard. There is a cost there. There is also a cost to having incomplete features in master when we declare feature freeze. 1.5.0 and 1.6.0 were both delayed because of incomplete features. One possible solution to this for 1.7.0 development is to only merge in complete features to master. There are lots of commits related to all of the 1.6.0 features, many of them reworking code changed by previous commits related to the feature. If someone was working on another feature in a branch, this introduces a lot of unnecessary noise for them to deal with. Ideally they would only have to merge and resolve conflicts once per feature. Of course we will never achieve ideal ratio of 1, but I think we can easily make the commit per feature/bug ratio much lower than it currently is. I know Christopher Tubbs worked on namespaces in a branch for a long period of time, merging in changes and resolving conflicts, I am not sure how painful this was. For a feature like this that touches a lot of existing code, there is the option of refactoring w/o changing functionality and merging that into master. Of course the refactoring would be done to make the functionality changes in the branch easier. So its a multi-step process w/ the goal of always leaving master in state where its ready for release testing and minimizing the number of merges for other feature branches. This approach would also make code reviews of commits to master much easier. I am going to try doing this for the 1.7 features I work on. but was certainly not anything I was thinking about when I was changing thousands of lines I was trying to determine how we can flush out more potential issues before changing thousands of lines. If we can get as many people as possible to carefully review the design that would probably do the trick. I wonder if voting on design docs for new features would help. Voting would motivate me to carefully review a design because I would not want to vote until I had done so.
          Hide
          Keith Turner added a comment -

          My comment about voting on design documents was a possible solution to a problem. The problem is how can we get peer reviewed designs? How can we motivate each other to spend a good chunk of time critically thinking about our designs. This issue had a design document and I remember reading and thinking "makes sense". I do not remember investing much time trying to find flaws with it, I think I just wanted to get back to whatever I was immersed in at the time. My thinking is that calling for a vote on the dev list after writing a design doc for a feature seems like a simple thing to try w/o any additional overhead because we have the dev list in place.

          Show
          Keith Turner added a comment - My comment about voting on design documents was a possible solution to a problem. The problem is how can we get peer reviewed designs? How can we motivate each other to spend a good chunk of time critically thinking about our designs. This issue had a design document and I remember reading and thinking "makes sense". I do not remember investing much time trying to find flaws with it, I think I just wanted to get back to whatever I was immersed in at the time. My thinking is that calling for a vote on the dev list after writing a design doc for a feature seems like a simple thing to try w/o any additional overhead because we have the dev list in place.
          Hide
          Josh Elser added a comment -

          I think the short of it here: it's hard.

          I remember when Eric was initially working on absolute paths and I thought "hrm, that's a good idea. should simplify a lot of things in the end". In hindsight, I don't think I really considered all of the difficulties that the changes introduce (most notably around upgrades and namenode/namespace decommissioning).

          Maintaining a long-running feature branch isn't too bad as long as the code you tweaked also doesn't change out from underneath you.

          I agree with you Keith, I think that focusing on design docs before starting to work on it can help quite a bit on a couple of levels (avoid flaws in design, catch bugs earlier, net a better architected solutions). Additionally, firming up a design can also help us break down "really big" problems into "slightly less big" problems which will likely help manage those changes. I think we've generally tried to abstain from requiring voting, but if that's what we need to get eyes on ideas, so be it. If we can get good, thought-out reviews without voting (which I think we've been fairly decent at so far, but we haven't had "big" designs go through review yet), I'd rather stay that way.

          Show
          Josh Elser added a comment - I think the short of it here: it's hard. I remember when Eric was initially working on absolute paths and I thought "hrm, that's a good idea. should simplify a lot of things in the end". In hindsight, I don't think I really considered all of the difficulties that the changes introduce (most notably around upgrades and namenode/namespace decommissioning). Maintaining a long-running feature branch isn't too bad as long as the code you tweaked also doesn't change out from underneath you. I agree with you Keith, I think that focusing on design docs before starting to work on it can help quite a bit on a couple of levels (avoid flaws in design, catch bugs earlier, net a better architected solutions). Additionally, firming up a design can also help us break down "really big" problems into "slightly less big" problems which will likely help manage those changes. I think we've generally tried to abstain from requiring voting, but if that's what we need to get eyes on ideas, so be it. If we can get good, thought-out reviews without voting (which I think we've been fairly decent at so far, but we haven't had "big" designs go through review yet), I'd rather stay that way.
          Hide
          Mike Drob added a comment -

          This seems like it would be a good discussion for the mailing list, to make sure it gets more eyes on it, instead of just the folks paying attention to the JIRA.

          Show
          Mike Drob added a comment - This seems like it would be a good discussion for the mailing list, to make sure it gets more eyes on it, instead of just the folks paying attention to the JIRA.
          Hide
          Dave Marion added a comment -

          calling for a vote on the dev list after writing a design doc for a feature seems like a simple thing to try

          caveat that if you don't know anything about the subject, then don't vote. I can see the situation where someone gives a +1 for an idea after reading the design doc, but not really understanding what it will entail to complete the task. Maybe not a vote, but a "yes, I've read it and my comments / questions are in the associated JIRA."

          Show
          Dave Marion added a comment - calling for a vote on the dev list after writing a design doc for a feature seems like a simple thing to try caveat that if you don't know anything about the subject, then don't vote. I can see the situation where someone gives a +1 for an idea after reading the design doc, but not really understanding what it will entail to complete the task. Maybe not a vote, but a "yes, I've read it and my comments / questions are in the associated JIRA."
          Hide
          Josh Elser added a comment -

          I was just testing this out. I tried to add a new volume to an existing 1.6 instance I had lying around.

          I expected that each volume I specified in instance.volumes was the "equivalent" of how multiple instance.dfs.uri+instance.dfs.dir would have worked. In other words, I expected each element in instance.volumes to be the base directory that Accumulo would write to. Instead, it actually wrote to that volume + instance.dfs.dir.

          This irks me for a few reasons:

          1. I must have the same base directory used in HDFS across all volumes (not the end of the world, but I don't see any reason to impose that on our end).
          2. I expected instance.volumes to be a replacement to instance.dfs.dir and instance.dfs.uri, but the new configuration still relies on the old configuration.

          Let me try to be crystal clear. I had an existing installation on machine1 in /accumulo1.6 in HDFS. I tried to add a second volume, stored on machine2, in /accumulo1.6-newvolume (I already had an /accumulo1.6 from other testing on machine2). I configured my instance.volumes value to hdfs://machine1:8020/accumulo1.6,hdfs://machine2:8020/accumulo1.6-newvolume. Sadly, when invoking bin/accumulo init --add-volumes, this failed on me because it actually looked in hdfs://machine1:8020/accumulo1.6/accumulo and hdfs://machine2:8020/accumulo1.6-newvolume/accumulo.

          Show
          Josh Elser added a comment - I was just testing this out. I tried to add a new volume to an existing 1.6 instance I had lying around. I expected that each volume I specified in instance.volumes was the "equivalent" of how multiple instance.dfs.uri + instance.dfs.dir would have worked. In other words, I expected each element in instance.volumes to be the base directory that Accumulo would write to. Instead, it actually wrote to that volume + instance.dfs.dir . This irks me for a few reasons: I must have the same base directory used in HDFS across all volumes (not the end of the world, but I don't see any reason to impose that on our end). I expected instance.volumes to be a replacement to instance.dfs.dir and instance.dfs.uri , but the new configuration still relies on the old configuration. Let me try to be crystal clear. I had an existing installation on machine1 in /accumulo1.6 in HDFS. I tried to add a second volume, stored on machine2, in /accumulo1.6-newvolume (I already had an /accumulo1.6 from other testing on machine2). I configured my instance.volumes value to hdfs://machine1:8020/accumulo1.6,hdfs://machine2:8020/accumulo1.6-newvolume . Sadly, when invoking bin/accumulo init --add-volumes , this failed on me because it actually looked in hdfs://machine1:8020/accumulo1.6/accumulo and hdfs://machine2:8020/accumulo1.6-newvolume/accumulo .
          Hide
          Josh Elser added a comment -

          And then I realized that this was the precise thing that ACCUMULO-2061 was recommendation. I'll bump the priority on that issue to denote my frustration with the current mechanisms and approval of that idea.

          Show
          Josh Elser added a comment - And then I realized that this was the precise thing that ACCUMULO-2061 was recommendation. I'll bump the priority on that issue to denote my frustration with the current mechanisms and approval of that idea.
          Hide
          Sean Busbey added a comment -

          All subtasks against this ticket are now complete. Any objections to closing it out?

          Show
          Sean Busbey added a comment - All subtasks against this ticket are now complete. Any objections to closing it out?
          Hide
          Josh Elser added a comment -

          Would be good to have someone else look through the potential "bugs" from direct FileSystem usage that I outlined on ACCUMULO-2552.

          I believe that list doesn't have anything that would be blocker for initial functionality, so I think I'm good to close this issue out.

          Show
          Josh Elser added a comment - Would be good to have someone else look through the potential "bugs" from direct FileSystem usage that I outlined on ACCUMULO-2552 . I believe that list doesn't have anything that would be blocker for initial functionality, so I think I'm good to close this issue out.
          Hide
          Sean Busbey added a comment -

          Issue closed; please file any newly discovered issues as follow on tickets.

          Show
          Sean Busbey added a comment - Issue closed; please file any newly discovered issues as follow on tickets.
          Hide
          ASF subversion and git services added a comment -

          Commit 1587749 from dlmarion@apache.org in branch 'site/trunk'
          [ https://svn.apache.org/r1587749 ]

          Changed name of ACCUMULO-118 feature

          Show
          ASF subversion and git services added a comment - Commit 1587749 from dlmarion@apache.org in branch 'site/trunk' [ https://svn.apache.org/r1587749 ] Changed name of ACCUMULO-118 feature

            People

            • Assignee:
              Eric Newton
              Reporter:
              Eric Newton
            • Votes:
              3 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2,016h Original Estimate - 2,016h
                2,016h
                Remaining:
                Remaining Estimate - 2,016h
                2,016h
                Logged:
                Remaining Estimate - 2,016h
                0.5h

                  Development