Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 0.9.0
    • Component/s: service/hadoop
    • Labels:
      None

      Description

      Separate Hadoop install and configuration scripts into more generic functions.

      We should have something like:

      {start,stop,install,configure,cleanup}

      _hadoop

      Naming consistency would be helpful.

      1. WHIRR-294-only-services-hadoop-for-trunk.patch
        19 kB
        Andrei Savu
      2. WHIRR-294.patch
        30 kB
        Andrei Savu
      3. WHIRR-294.patch
        26 kB
        Andrei Savu
      4. WHIRR-294.patch
        38 kB
        Tom White
      5. WHIRR-294.patch
        39 kB
        Tom White
      6. WHIRR-294.patch
        26 kB
        Tom White
      7. WHIRR-294.patch
        26 kB
        Tom White
      8. WHIRR-294.patch
        19 kB
        Tom White
      9. WHIRR-294.patch
        17 kB
        Tom White

        Issue Links

          Activity

          Hide
          Tom White added a comment -

          Here's an untested patch for Hadoop (including CDH). It includes a method on ClusterActionHandlerSupport for enforcing naming consistency of functions.

          I haven't included stop or cleanup functions since they don't exist currently (so are not called by anything), and can be added in a follow on JIRA.

          I still need to run integration tests for this.

          Show
          Tom White added a comment - Here's an untested patch for Hadoop (including CDH). It includes a method on ClusterActionHandlerSupport for enforcing naming consistency of functions. I haven't included stop or cleanup functions since they don't exist currently (so are not called by anything), and can be added in a follow on JIRA. I still need to run integration tests for this.
          Hide
          Tom White added a comment -

          Updated patch for Hadoop and CDH which passes integration tests on EC2 and Rackspace.

          Show
          Tom White added a comment - Updated patch for Hadoop and CDH which passes integration tests on EC2 and Rackspace.
          Hide
          Andrei Savu added a comment -

          Looks good but I believe that some of the start functions are doing a bit too much (e.g. start_namenode is doing setup work, cdh start_hadoop_daemon installing services). We should move that code to the install / configure functions so that we can reuse the start / stop functions when updating the configuration or doing rolling restarts.

          Show
          Andrei Savu added a comment - Looks good but I believe that some of the start functions are doing a bit too much (e.g. start_namenode is doing setup work, cdh start_hadoop_daemon installing services). We should move that code to the install / configure functions so that we can reuse the start / stop functions when updating the configuration or doing rolling restarts.
          Hide
          Tom White added a comment -

          The namenode start is doing some work to set up directories after the daemon has started, so it needs to stay there, although it should be made idempotent. The namenode format operation could be moved out, but it's only called once so is not really a problem in practice. The CDH start does some package installation - I'll move this to the install script.

          Show
          Tom White added a comment - The namenode start is doing some work to set up directories after the daemon has started, so it needs to stay there, although it should be made idempotent. The namenode format operation could be moved out, but it's only called once so is not really a problem in practice. The CDH start does some package installation - I'll move this to the install script.
          Hide
          Tom White added a comment -

          Here's a patch which makes the changes in my previous comment. Ran Hadoop integration tests successfully.

          Show
          Tom White added a comment - Here's a patch which makes the changes in my previous comment. Ran Hadoop integration tests successfully.
          Hide
          Tom White added a comment -

          Synced with trunk. I'd like to commit this later unless there are any comments or objections.

          Show
          Tom White added a comment - Synced with trunk. I'd like to commit this later unless there are any comments or objections.
          Hide
          Andrei Savu added a comment -

          Looks good but I'm unable to run the CDH Hbase integration test. This could be only a local (connection) error.

          Show
          Andrei Savu added a comment - Looks good but I'm unable to run the CDH Hbase integration test. This could be only a local (connection) error.
          Hide
          Tom White added a comment -

          Thanks for taking a look, Andrei. Here's a new patch with an HBase start function separated out. Not quite ready for commit as I'm also having problems with the HBase integration test.

          Show
          Tom White added a comment - Thanks for taking a look, Andrei. Here's a new patch with an HBase start function separated out. Not quite ready for commit as I'm also having problems with the HBase integration test.
          Hide
          Tom White added a comment -

          Regenerated patch.

          Show
          Tom White added a comment - Regenerated patch.
          Hide
          Tom White added a comment -

          (Not ready for commit yet - still needs testing.)

          Show
          Tom White added a comment - (Not ready for commit yet - still needs testing.)
          Hide
          Andrei Savu added a comment -

          How about fixing WHIRR-337 before? It should simplify things.

          Show
          Andrei Savu added a comment - How about fixing WHIRR-337 before? It should simplify things.
          Hide
          Tom White added a comment -

          Agreed that WHIRR-337 should go in first.

          Show
          Tom White added a comment - Agreed that WHIRR-337 should go in first.
          Hide
          Andrei Savu added a comment -

          Not a blocker for 0.7.0 - moving to 0.8.0.

          Show
          Andrei Savu added a comment - Not a blocker for 0.7.0 - moving to 0.8.0.
          Hide
          Andrei Savu added a comment -

          I'm giving another try to this one tomorrow. I think I will start from scratch.

          Show
          Andrei Savu added a comment - I'm giving another try to this one tomorrow. I think I will start from scratch.
          Hide
          Andrei Savu added a comment -

          Extracted functions for starting the Hadoop daemons. This patch needs WHIRR-221. Integration tests are passing on aws-ec2. Next: add functions to stop the daemons.

          Show
          Andrei Savu added a comment - Extracted functions for starting the Hadoop daemons. This patch needs WHIRR-221 . Integration tests are passing on aws-ec2. Next: add functions to stop the daemons.
          Hide
          Andrei Savu added a comment -

          Add stop scripts for Hadoop daemons. Tomorrow: do the same for CDH and we should be done with this one.

          Show
          Andrei Savu added a comment - Add stop scripts for Hadoop daemons. Tomorrow: do the same for CDH and we should be done with this one.
          Hide
          Tom White added a comment -

          This looks good to me. Do we need to define dependencies as NN <- DN <- JT <- TT, when it's possible to start them in any order in the case of Hadoop, at least? Does doing this slow things down?

          There are some import reorderings which should be removed in the final patch (imports should be alphabetical).

          Show
          Tom White added a comment - This looks good to me. Do we need to define dependencies as NN <- DN <- JT <- TT, when it's possible to start them in any order in the case of Hadoop, at least? Does doing this slow things down? There are some import reorderings which should be removed in the final patch (imports should be alphabetical).
          Hide
          David Alves added a comment - - edited

          This looks good to me. Do we need to define dependencies as NN <- DN <- JT <- TT, when it's possible to start them in any order in the case of Hadoop, at least? Does doing this slow things down?

          Dependencies will help by failing fast when the user forgets to add some required dependency to the instance template (e.g starting a cluster without a namenode), besides since hadoop start scripts are fire and forget and no "online delay" will be set the additional time required is minimal. What would happen tipically is that NN and JT are started together (only one node) and then DN and TT are started at the same time and in parallel in the cluster.

          Show
          David Alves added a comment - - edited This looks good to me. Do we need to define dependencies as NN <- DN <- JT <- TT, when it's possible to start them in any order in the case of Hadoop, at least? Does doing this slow things down? Dependencies will help by failing fast when the user forgets to add some required dependency to the instance template (e.g starting a cluster without a namenode), besides since hadoop start scripts are fire and forget and no "online delay" will be set the additional time required is minimal. What would happen tipically is that NN and JT are started together (only one node) and then DN and TT are started at the same time and in parallel in the cluster.
          Hide
          Tom White added a comment -

          Thanks for the explanation, David. +1 for the patch.

          Show
          Tom White added a comment - Thanks for the explanation, David. +1 for the patch.
          Hide
          Andrei Savu added a comment -

          Thanks Tom for reviewing. I will rework this as soon as we get WHIRR-221 in.

          Show
          Andrei Savu added a comment - Thanks Tom for reviewing. I will rework this as soon as we get WHIRR-221 in.
          Hide
          Andrei Savu added a comment -

          Updated patch for current trunk. I am now looking into changing services/cdh.

          Show
          Andrei Savu added a comment - Updated patch for current trunk. I am now looking into changing services/cdh.
          Hide
          Andrei Savu added a comment -

          I've done some work on rewriting services/cdh as a set of standalone roles (cdh-namenode, cdh-datanode, cdh-zookeeper etc.). What do you think about this approach? I know MapR is using a similar approach: mapr-namenode, mapr-zookeeper etc. Overriding the install / configure functions seems like a hack and it gets even more ugly as we add support for start / stop / cleanup functions.

          Show
          Andrei Savu added a comment - I've done some work on rewriting services/cdh as a set of standalone roles (cdh-namenode, cdh-datanode, cdh-zookeeper etc.). What do you think about this approach? I know MapR is using a similar approach: mapr-namenode, mapr-zookeeper etc. Overriding the install / configure functions seems like a hack and it gets even more ugly as we add support for start / stop / cleanup functions.
          Hide
          Tom White added a comment -

          Seems reasonable to me. Another idea I had was to specify the pattern for functions - e.g. by default it's whirr.<service>.<function>-function (where <function> is install, configure, etc). This could be overridable to e.g. whirr.<service>.<function>-cdh-function. However, specifying that is not very user-friendly, so your suggestion is probably preferable. How would we do it compatibly?

          Show
          Tom White added a comment - Seems reasonable to me. Another idea I had was to specify the pattern for functions - e.g. by default it's whirr.<service>.<function>-function (where <function> is install, configure, etc). This could be overridable to e.g. whirr.<service>.<function>-cdh-function . However, specifying that is not very user-friendly, so your suggestion is probably preferable. How would we do it compatibly?
          Hide
          Andrei Savu added a comment -

          How would we do it compatibly?

          I think we shouldn't worry too much about keeping things fully backwards compatible before 1.0.0 as long as we document the changes in the release notes.

          Show
          Andrei Savu added a comment - How would we do it compatibly? I think we shouldn't worry too much about keeping things fully backwards compatible before 1.0.0 as long as we document the changes in the release notes.
          Hide
          Tom White added a comment -

          It's important that point releases (e.g. 0.7.1 to 0.7.2) should maintain compatibility though.

          Show
          Tom White added a comment - It's important that point releases (e.g. 0.7.1 to 0.7.2) should maintain compatibility though.
          Hide
          Andrei Savu added a comment -

          I completely agree!

          Show
          Andrei Savu added a comment - I completely agree!

            People

            • Assignee:
              Andrei Savu
              Reporter:
              Andrei Savu
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development