Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.7.0
    • Fix Version/s: 0.7.0
    • Component/s: None
    • Labels:
      None

      Description

      Phoenix (https://github.com/forcedotcom/phoenix) is an open source BSD-style licensed SQL skin over Apache HBase, delivered as a client-embedded JDBC driver. The Phoenix query engine transforms your SQL query into one or more HBase scans, and orchestrates their execution to produce standard JDBC result sets. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows. Applications interact with Phoenix through a standard JDBC interface; all the usual interfaces are supported.

      As an enhancement of significant value to Apache HBase, in a Bigtop distribution Phoenix would have a role similar to that of Datafu, a collection of enhancements to Apache Pig.

      1. 993.patch
        35 kB
        Andrew Purtell
      2. 993.patch
        34 kB
        Andrew Purtell
      3. 993.patch
        34 kB
        Andrew Purtell
      4. 993.patch
        33 kB
        Andrew Purtell
      5. 993.patch
        32 kB
        Andrew Purtell
      6. 993.patch
        32 kB
        Andrew Purtell
      7. 993-delta.patch
        1 kB
        Andrew Purtell

        Issue Links

          Activity

          Hide
          Andrew Purtell added a comment - - edited

          Attaching a patch as placeholder. It builds an RPM out of the head of Phoenix's master branch. Some build changes to Phoenix for supporting builds against Hadoop 2 were merged in yesterday. There's more work remaining:

          • Phoenix should have a build option for not producing a fatjar
          • The RPM build should link in Hadoop and HBase jars from HADOOP_HOME and HBASE_HOME
          • Bigtop patch needs build support for DEBs
          • Bigtop patch needs integration tests, Phoenix has a test suite of end to end tests which should be easily repurposed for that

          Another patch forthcoming soon after these issues are sorted out.

          Show
          Andrew Purtell added a comment - - edited Attaching a patch as placeholder. It builds an RPM out of the head of Phoenix's master branch. Some build changes to Phoenix for supporting builds against Hadoop 2 were merged in yesterday. There's more work remaining: Phoenix should have a build option for not producing a fatjar The RPM build should link in Hadoop and HBase jars from HADOOP_HOME and HBASE_HOME Bigtop patch needs build support for DEBs Bigtop patch needs integration tests, Phoenix has a test suite of end to end tests which should be easily repurposed for that Another patch forthcoming soon after these issues are sorted out.
          Hide
          Andrew Purtell added a comment - - edited

          Updated patch.

          • Actually the Phoenix client fatjar is useful. The install adds a version independent symlink for ease of configuration for JDBC users.
          • Added build support for DEBs. Confirmed a working install on my Ubuntu dev laptop.
          • Added smoke tests based on Phoenix's suite of end to end tests. Currently this will execute each test by shelling out to the hbase bin script to set up the environment. This saves a lot of work otherwise, and will be amenable to change should the Phoenix tests be modified at some future time to be drivers that can run against a running cluster.
          Show
          Andrew Purtell added a comment - - edited Updated patch. Actually the Phoenix client fatjar is useful. The install adds a version independent symlink for ease of configuration for JDBC users. Added build support for DEBs. Confirmed a working install on my Ubuntu dev laptop. Added smoke tests based on Phoenix's suite of end to end tests. Currently this will execute each test by shelling out to the hbase bin script to set up the environment. This saves a lot of work otherwise, and will be amenable to change should the Phoenix tests be modified at some future time to be drivers that can run against a running cluster.
          Hide
          Roman Shaposhnik added a comment -

          Great stuff, Andrew! I've assigned this bug to you and will provide a review shortly. Personally I'm very excited to see Phoenix integrated into the Bigtop.

          Show
          Roman Shaposhnik added a comment - Great stuff, Andrew! I've assigned this bug to you and will provide a review shortly. Personally I'm very excited to see Phoenix integrated into the Bigtop.
          Hide
          Andrew Purtell added a comment -

          Thanks Roman.

          For follow-on work for deeper Phoenix/HBase integration, we might consider an "/etc/hbase/modules.d/" convention for adding additional site xml files and scripts to execute after regionserver (re)start. HBase coprocessor applications like Phoenix could drop bits there and trigger a regionserver reload in postinstall. Would be HBase init script changes and maybe a couple of tweaks to upstream source. Does this sounds reasonable? If so I'll start thinking about it while the basic packaging stuff is under review.

          Show
          Andrew Purtell added a comment - Thanks Roman. For follow-on work for deeper Phoenix/HBase integration, we might consider an "/etc/hbase/modules.d/" convention for adding additional site xml files and scripts to execute after regionserver (re)start. HBase coprocessor applications like Phoenix could drop bits there and trigger a regionserver reload in postinstall. Would be HBase init script changes and maybe a couple of tweaks to upstream source. Does this sounds reasonable? If so I'll start thinking about it while the basic packaging stuff is under review.
          Hide
          Bruno Mahé added a comment -

          It would be great to have Phoenix!

          I took a quick look at the package and it looks great so far.
          Some comments:

          • I see the package depends on useradd, chkconfig and service, but I don't see any service scripts or users being created. So are these dependencies needed?
          Show
          Bruno Mahé added a comment - It would be great to have Phoenix! I took a quick look at the package and it looks great so far. Some comments: I see the package depends on useradd, chkconfig and service, but I don't see any service scripts or users being created. So are these dependencies needed?
          Hide
          Andrew Purtell added a comment -

          I see the package depends on useradd, chkconfig and service, but I don't see any service scripts or users being created.

          Updated patch. Originally I was tinkering with an init script for Phoenix, but I think the above mentioned HBase "/etc/hbase/modules.d" style configuration for Coprocessor applications is the way to go. Would like to tackle that in a followup, and suggest the scope of this issue is installing Phoenix as a library.

          Show
          Andrew Purtell added a comment - I see the package depends on useradd, chkconfig and service, but I don't see any service scripts or users being created. Updated patch. Originally I was tinkering with an init script for Phoenix, but I think the above mentioned HBase "/etc/hbase/modules.d" style configuration for Coprocessor applications is the way to go. Would like to tackle that in a followup, and suggest the scope of this issue is installing Phoenix as a library.
          Hide
          Andrew Purtell added a comment -

          After BIGTOP-1004 goes in I'll update this patch to replace Hadoop jars in the Phoenix lib/ with symlinks.

          Show
          Andrew Purtell added a comment - After BIGTOP-1004 goes in I'll update this patch to replace Hadoop jars in the Phoenix lib/ with symlinks.
          Hide
          Andrew Purtell added a comment -

          Latest patch requires BIGTOP-1004. Also fixes package dependencies for Debian and updates Phoenix version to 2.0 to reflect version updates on Phoenix master branch.

          Show
          Andrew Purtell added a comment - Latest patch requires BIGTOP-1004 . Also fixes package dependencies for Debian and updates Phoenix version to 2.0 to reflect version updates on Phoenix master branch.
          Hide
          Andrew Purtell added a comment -

          Now that BIGTOP-1004 is in, this is ready for review and commit.

          Show
          Andrew Purtell added a comment - Now that BIGTOP-1004 is in, this is ready for review and commit.
          Hide
          Peter Linnell added a comment -

          Andrew, Thanks for this! My initial review of the patch looks good. Give me a day to test a build, as I now have a new build machine setup for Bigtop

          Show
          Peter Linnell added a comment - Andrew, Thanks for this! My initial review of the patch looks good. Give me a day to test a build, as I now have a new build machine setup for Bigtop
          Hide
          Andrew Purtell added a comment -

          Phoenix 2.x has added a secondary indexing capability and some end to end tests. Will update the patch here with more smokes for those shortly. Please consider the patch unfinished.

          Show
          Andrew Purtell added a comment - Phoenix 2.x has added a secondary indexing capability and some end to end tests. Will update the patch here with more smokes for those shortly. Please consider the patch unfinished.
          Hide
          Roman Shaposhnik added a comment -

          Andrew, what's your estimate on when this patch could be considered ready for review/inclusion into Bigtop 0.7.0? Would love to have this as part of the release, but also there's no rush.

          Show
          Roman Shaposhnik added a comment - Andrew, what's your estimate on when this patch could be considered ready for review/inclusion into Bigtop 0.7.0? Would love to have this as part of the release, but also there's no rush.
          Hide
          Andrew Purtell added a comment -

          Should have time this week to add the smokes for index and run through a build again to make sure everything is still good.

          Show
          Andrew Purtell added a comment - Should have time this week to add the smokes for index and run through a build again to make sure everything is still good.
          Hide
          Andrew Purtell added a comment -

          Unfortunately things came up. I will be at a conference next week. This is something I plan to pick up when I return.

          Show
          Andrew Purtell added a comment - Unfortunately things came up. I will be at a conference next week. This is something I plan to pick up when I return.
          Hide
          Sean Mackrory added a comment -

          I've built RPMs on openSUSE 12.3 and installed / removed DEBs on Ubuntu 10.04, and the packaging looks mainly good to me (although the patch seems pretty messed up when trying to apply it). A few questions / nitpicks:

          • It doesn't look like there are any tarball releases, and we're just building from a tarball of the master branch. Are there plans at Phoenix to cut a tarball release we can consume?
          • Would this be the first time we're packaging a BSD-licensed component? We've previously listed Apache licenses as requirements for inclusion, but I think BSD is close enough. I presume there are no hoops we need to jump through before distributing BSD-licensed bits as an Apache project?
          • The package includes -tests and -sources JARs which we usually don't do. There's a versionless symlink for tests so it looks intentional - but what's the intention?
          • There are 2 other JARs without versionless symlinks. We might as well do all of them since it's handy when scripting infrastructure around Bigtop.
          • We're creating an empty /usr/lib/phoenix/bin directory. Maybe clean it up? Better yet, we could include a wrapper around the sqlline.sh CLI client they bundle
          Show
          Sean Mackrory added a comment - I've built RPMs on openSUSE 12.3 and installed / removed DEBs on Ubuntu 10.04, and the packaging looks mainly good to me (although the patch seems pretty messed up when trying to apply it). A few questions / nitpicks: It doesn't look like there are any tarball releases, and we're just building from a tarball of the master branch. Are there plans at Phoenix to cut a tarball release we can consume? Would this be the first time we're packaging a BSD-licensed component? We've previously listed Apache licenses as requirements for inclusion, but I think BSD is close enough. I presume there are no hoops we need to jump through before distributing BSD-licensed bits as an Apache project? The package includes -tests and -sources JARs which we usually don't do. There's a versionless symlink for tests so it looks intentional - but what's the intention? There are 2 other JARs without versionless symlinks. We might as well do all of them since it's handy when scripting infrastructure around Bigtop. We're creating an empty /usr/lib/phoenix/bin directory. Maybe clean it up? Better yet, we could include a wrapper around the sqlline.sh CLI client they bundle
          Hide
          Andrew Purtell added a comment -

          Surely the patch here has bitrotted. I have a new one in the works.

          It doesn't look like there are any tarball releases, and we're just building from a tarball of the master branch. Are there plans at Phoenix to cut a tarball release we can consume?

          I don't think so, but there is a release tag in their repository so the update patch uses that instead of 'master'.

          The package includes -tests and -sources JARs which we usually don't do. There's a versionless symlink for tests so it looks intentional - but what's the intention?

          Running smoke tests using the Groovy shell after package install rather than cloning HBase and Phoenix unit test setup into Bigtop POMs. The versionless symlink isn't necessary though.

          Can drop -sources

          Better yet, we could include a wrapper around the sqlline.sh CLI client they bundle

          Sounds good

          Show
          Andrew Purtell added a comment - Surely the patch here has bitrotted. I have a new one in the works. It doesn't look like there are any tarball releases, and we're just building from a tarball of the master branch. Are there plans at Phoenix to cut a tarball release we can consume? I don't think so, but there is a release tag in their repository so the update patch uses that instead of 'master'. The package includes -tests and -sources JARs which we usually don't do. There's a versionless symlink for tests so it looks intentional - but what's the intention? Running smoke tests using the Groovy shell after package install rather than cloning HBase and Phoenix unit test setup into Bigtop POMs. The versionless symlink isn't necessary though. Can drop -sources Better yet, we could include a wrapper around the sqlline.sh CLI client they bundle Sounds good
          Hide
          Andrew Purtell added a comment -

          Better yet, we could include a wrapper around the sqlline.sh CLI client they bundle

          Sounds good

          On second thought, let's not create a bin/

          A SQLLine wrapper won't be any use unless Phoenix is installed as a coprocessor on the HBase tables. BIGTOP-1007 contemplates how to manage HBase coprocessor applications as part of package management, but I don't have time to do it for 0.7.

          Show
          Andrew Purtell added a comment - Better yet, we could include a wrapper around the sqlline.sh CLI client they bundle Sounds good On second thought, let's not create a bin/ A SQLLine wrapper won't be any use unless Phoenix is installed as a coprocessor on the HBase tables. BIGTOP-1007 contemplates how to manage HBase coprocessor applications as part of package management, but I don't have time to do it for 0.7.
          Hide
          Andrew Purtell added a comment -

          there is a release tag in their repository so the update patch uses that instead of 'master'

          I tried both the 2.0.0 and 2.0.1 release branches but both have a compilation problem against the current HBase version selected by bigtop.mk. This issue is fixed on the Phoenix trunk. We can continue to check out their master branch, I'd imagine settling on a suitable stable SHA, or I can make a point release that is 2.0.1 with just this fix. Let me ask them about doing the latter.

          Show
          Andrew Purtell added a comment - there is a release tag in their repository so the update patch uses that instead of 'master' I tried both the 2.0.0 and 2.0.1 release branches but both have a compilation problem against the current HBase version selected by bigtop.mk. This issue is fixed on the Phoenix trunk. We can continue to check out their master branch, I'd imagine settling on a suitable stable SHA, or I can make a point release that is 2.0.1 with just this fix. Let me ask them about doing the latter.
          Hide
          Roman Shaposhnik added a comment -

          Andrew Purtell I'd really appreciate if you could make a point release. Depending on a branch is a no-go for a Bigtop release, and if we just depend on a particular SHA it'll be better to turn that SHA into a point release upstream.

          Show
          Roman Shaposhnik added a comment - Andrew Purtell I'd really appreciate if you could make a point release. Depending on a branch is a no-go for a Bigtop release, and if we just depend on a particular SHA it'll be better to turn that SHA into a point release upstream.
          Hide
          Andrew Purtell added a comment -

          There is a new release candidate branch at https://github.com/forcedotcom/phoenix/tree/2.0.2 that should be in a released state within a few days. I am proceeding using this in bigtop.mk as source:

          +PHOENIX_NAME=phoenix
          +PHOENIX_RELNOTES_NAME=Phoenix: A SQL skin over HBase
          +PHOENIX_PKG_NAME=phoenix
          +PHOENIX_BASE_VERSION=2.0.2
          +PHOENIX_PKG_VERSION=2.0.2
          +PHOENIX_RELEASE_VERSION=1
          +PHOENIX_TARBALL_DST=phoenix-$(PHOENIX_BASE_VERSION).tar.gz
          +PHOENIX_TARBALL_SRC=$(PHOENIX_BASE_VERSION).tar.gz
          +PHOENIX_SITE=https://github.com/forcedotcom/phoenix/archive
          +PHOENIX_ARCHIVE=$(PHOENIX_SITE)
          +$(eval $(call PACKAGE,phoenix,PHOENIX))
          
          Show
          Andrew Purtell added a comment - There is a new release candidate branch at https://github.com/forcedotcom/phoenix/tree/2.0.2 that should be in a released state within a few days. I am proceeding using this in bigtop.mk as source: +PHOENIX_NAME=phoenix +PHOENIX_RELNOTES_NAME=Phoenix: A SQL skin over HBase +PHOENIX_PKG_NAME=phoenix +PHOENIX_BASE_VERSION=2.0.2 +PHOENIX_PKG_VERSION=2.0.2 +PHOENIX_RELEASE_VERSION=1 +PHOENIX_TARBALL_DST=phoenix-$(PHOENIX_BASE_VERSION).tar.gz +PHOENIX_TARBALL_SRC=$(PHOENIX_BASE_VERSION).tar.gz +PHOENIX_SITE=https://github.com/forcedotcom/phoenix/archive +PHOENIX_ARCHIVE=$(PHOENIX_SITE) +$(eval $(call PACKAGE,phoenix,PHOENIX))
          Hide
          James Taylor added a comment -

          FYI, the Phoenix 2.0.2 release is out now.

          Show
          James Taylor added a comment - FYI, the Phoenix 2.0.2 release is out now.
          Hide
          Andrew Purtell added a comment -

          Updated patch:

          • Build Phoenix 2.0.2 release
          • Don't create /usr/lib/phoenix/bin
          • Delete the -sources JAR before creating the package
          • Adds smoke tests that run the Phoenix 2.0.2 end2end tests for new index and aggregation function features

          Only thing remaining is a rebuild of Bigtop 0.7 artifacts, install to a dev box, and check that mvn verify for Phoenix works as expected. I did test the command line invocations used by the Groovy shell from within a Phoenix build.

          Show
          Andrew Purtell added a comment - Updated patch: Build Phoenix 2.0.2 release Don't create /usr/lib/phoenix/bin Delete the -sources JAR before creating the package Adds smoke tests that run the Phoenix 2.0.2 end2end tests for new index and aggregation function features Only thing remaining is a rebuild of Bigtop 0.7 artifacts, install to a dev box, and check that mvn verify for Phoenix works as expected. I did test the command line invocations used by the Groovy shell from within a Phoenix build.
          Hide
          Peter Linnell added a comment -

          Andy,

          Updated patch looks good with a couple of nits.
          Line 52 and 85:

          /bin/bash instead please.

          The rest looks good to me. I've not done a build and cannot until I am back home this weekend.

          If you can confirm a build on a .deb and .rpm distro, then it is +1 with th ae nits fixed.

          Thanks and much appreciation for a great addition to Bigtop!

          Show
          Peter Linnell added a comment - Andy, Updated patch looks good with a couple of nits. Line 52 and 85: /bin/bash instead please. The rest looks good to me. I've not done a build and cannot until I am back home this weekend. If you can confirm a build on a .deb and .rpm distro, then it is +1 with th ae nits fixed. Thanks and much appreciation for a great addition to Bigtop!
          Hide
          Roman Shaposhnik added a comment -

          +1 to Peter's feedback. Andrew Purtell would be very nice if we can wrap this one up in a few days.

          Show
          Roman Shaposhnik added a comment - +1 to Peter's feedback. Andrew Purtell would be very nice if we can wrap this one up in a few days.
          Hide
          Andrew Purtell added a comment -

          Latest patch. Changes:

          • Fixed sh vs. bash nits
          • Fixed misformatting of deb package description
          • Fixed test jar resolution for mvn verify, removed version independent symlink to the -tests jar now that this is no longer needed

          Built and installed on an Ubuntu 13.04 dev box. 'mvn verify' runs the Phoenix end to end unit tests using the 'hbase' launch script. You may need to change umask to 022 first, this is a HDFS minicluster issue, not something related to Phoenix.

          Also built and installed the packages successfully on a CentOS6 box.

          I think this is ready for commit and will do so if I can get a +1.

          Show
          Andrew Purtell added a comment - Latest patch. Changes: Fixed sh vs. bash nits Fixed misformatting of deb package description Fixed test jar resolution for mvn verify, removed version independent symlink to the -tests jar now that this is no longer needed Built and installed on an Ubuntu 13.04 dev box. 'mvn verify' runs the Phoenix end to end unit tests using the 'hbase' launch script. You may need to change umask to 022 first, this is a HDFS minicluster issue, not something related to Phoenix. Also built and installed the packages successfully on a CentOS6 box. I think this is ready for commit and will do so if I can get a +1.
          Hide
          Roman Shaposhnik added a comment -

          +1. Please go ahead and commit it today so I can enable its builds on our Jenkins server.

          Also, could you please illuminate one aspect of it that is a bit of a mystery to me: how come using it as a JDBC driver doesn't require co-processors, but using sqlline.sh does?

          Show
          Roman Shaposhnik added a comment - +1. Please go ahead and commit it today so I can enable its builds on our Jenkins server. Also, could you please illuminate one aspect of it that is a bit of a mystery to me: how come using it as a JDBC driver doesn't require co-processors, but using sqlline.sh does?
          Hide
          James Taylor added a comment -

          Phoenix always requires the use of coprocessors. The sqlline we bundle is just a SQL client that uses the Phoenix JDBC driver.

          Show
          James Taylor added a comment - Phoenix always requires the use of coprocessors. The sqlline we bundle is just a SQL client that uses the Phoenix JDBC driver.
          Hide
          Roman Shaposhnik added a comment -

          James Taylor thanks for the explanation – makes perfect sense!

          Andrew Purtell now that I understand it better, would you mind restoring sqlline.sh and making it available?

          Show
          Roman Shaposhnik added a comment - James Taylor thanks for the explanation – makes perfect sense! Andrew Purtell now that I understand it better, would you mind restoring sqlline.sh and making it available?
          Hide
          Andrew Purtell added a comment -

          now that I understand it better, would you mind restoring sqlline.sh and making it available?

          Roman Shaposhnik I think presently a bin/ directory for Phoenix may give some people the wrong idea, you can't just install the Phoenix package and launch something from its bin/ and expect it to work. Some manual HBase configuration is required first. A next step I would like to take is to allow HBase coprocessor application packages a way to adjust the HBase default site configuration automatically, that is BIGTOP-1007. Do you still want a bin/sqlline.sh here? No big deal, really.

          Show
          Andrew Purtell added a comment - now that I understand it better, would you mind restoring sqlline.sh and making it available? Roman Shaposhnik I think presently a bin/ directory for Phoenix may give some people the wrong idea, you can't just install the Phoenix package and launch something from its bin/ and expect it to work. Some manual HBase configuration is required first. A next step I would like to take is to allow HBase coprocessor application packages a way to adjust the HBase default site configuration automatically, that is BIGTOP-1007 . Do you still want a bin/sqlline.sh here? No big deal, really.
          Hide
          Roman Shaposhnik added a comment -

          Andrew Purtell I see where you're coming from. Let me ask you a few questions about the implementation and perhaps we can settle on a solution that makes sense. My understanding of the co-processors is that it is possible to load them up from the HBase shell and I would imagine that it is how the Phoenix implementation does it – from the client side. Hence wouldn't it be correct to assume that sqlline.sh will simply try to load them up and if that fails we can always bail with a helpful message saying that a certain amount of HBase configuration is required? Perhaps we can even suggest what needs to be done.

          Thoughts?

          Show
          Roman Shaposhnik added a comment - Andrew Purtell I see where you're coming from. Let me ask you a few questions about the implementation and perhaps we can settle on a solution that makes sense. My understanding of the co-processors is that it is possible to load them up from the HBase shell and I would imagine that it is how the Phoenix implementation does it – from the client side. Hence wouldn't it be correct to assume that sqlline.sh will simply try to load them up and if that fails we can always bail with a helpful message saying that a certain amount of HBase configuration is required? Perhaps we can even suggest what needs to be done. Thoughts?
          Hide
          Roman Shaposhnik added a comment -

          Andrew Purtell also, what are the chance of HBASE-8734 getting into HBase 0.96 so that we can target this functionality for Bigtop 0.8.0?

          Show
          Roman Shaposhnik added a comment - Andrew Purtell also, what are the chance of HBASE-8734 getting into HBase 0.96 so that we can target this functionality for Bigtop 0.8.0?
          Hide
          Andrew Purtell added a comment - - edited

          My understanding of the co-processors is that it is possible to load them up from the HBase shell and I would imagine that it is how the Phoenix implementation does it – from the client side

          There are two ways to load a coprocessor - 'system coprocessors' are loaded based on a setting in the HBase site file, and 'table coprocessors' are loaded from a specification in table schema metadata. Table coprocessors are dynamically loaded when the table is loaded and IIRC Phoenix uses these. However, in both cases the coprocessor classes need to be on the classpath of the regionserver, and this is constructed by the HBase binscript when the daemon is launched. Actually, coprocessors can be loaded by URL, so could be stored on HDFS, but I'm not sure I recommend that. And, Phoenix also uses custom filters which cannot be loaded that way, those must be on the classpath.

          what are the chance of HBASE-8734 getting into HBase 0.96

          There may not need be any changes beyond the binscripts. Such changes would be minor and not change any existing functionality in an incompatible way, so I don't see why not.

          Show
          Andrew Purtell added a comment - - edited My understanding of the co-processors is that it is possible to load them up from the HBase shell and I would imagine that it is how the Phoenix implementation does it – from the client side There are two ways to load a coprocessor - 'system coprocessors' are loaded based on a setting in the HBase site file, and 'table coprocessors' are loaded from a specification in table schema metadata. Table coprocessors are dynamically loaded when the table is loaded and IIRC Phoenix uses these. However, in both cases the coprocessor classes need to be on the classpath of the regionserver, and this is constructed by the HBase binscript when the daemon is launched. Actually, coprocessors can be loaded by URL, so could be stored on HDFS, but I'm not sure I recommend that. And, Phoenix also uses custom filters which cannot be loaded that way, those must be on the classpath. what are the chance of HBASE-8734 getting into HBase 0.96 There may not need be any changes beyond the binscripts. Such changes would be minor and not change any existing functionality in an incompatible way, so I don't see why not.
          Hide
          Roman Shaposhnik added a comment -

          Andrew Purtell thanks for the detailed explanation! My personal take now is that it would be useful to expose the sqlline.sh since it sounds like manually configuring HBase's classpath is actually not that involved (and with the possibility of taking jars from HDFS could even be trivial).

          Show
          Roman Shaposhnik added a comment - Andrew Purtell thanks for the detailed explanation! My personal take now is that it would be useful to expose the sqlline.sh since it sounds like manually configuring HBase's classpath is actually not that involved (and with the possibility of taking jars from HDFS could even be trivial).
          Hide
          Andrew Purtell added a comment -

          My personal take now is that it would be useful to expose the sqlline.sh

          Ok. If you would like something a bit more, like a wrapper of some kind in /usr/bin ("hbase-phoenix-sqlline"?) let me know.

          with the possibility of taking jars from HDFS could even be trivial

          Well... to do this for coprocessors put the path to the jar in HDFS into the table attribute, and to do this for filters set 'hbase.dynamic.jars.dir' in the HBase site config and make sure the jar is located in that directory. Ok, so now Phoenix is "installed" on HDFS but that dynamic jars dir is a DLL hell. What I want to do in BIGTOP-1007 is set up a standard for HBase configuration fragments for coprocessor applications packaged by Bigtop, with helpful modifications on the HBase side as needed to avoid repeating history.

          I also don't think hosting package bits on a distributed filesystem fits well with OS level package management. A DEB or RPM cannot presume the service or its dependencies are running at install or removal time. (Not suggesting you suggested that - just making a point.) Highly likely this is going to be an issue with YARN apps down the road.

          Show
          Andrew Purtell added a comment - My personal take now is that it would be useful to expose the sqlline.sh Ok. If you would like something a bit more, like a wrapper of some kind in /usr/bin ("hbase-phoenix-sqlline"?) let me know. with the possibility of taking jars from HDFS could even be trivial Well... to do this for coprocessors put the path to the jar in HDFS into the table attribute, and to do this for filters set 'hbase.dynamic.jars.dir' in the HBase site config and make sure the jar is located in that directory. Ok, so now Phoenix is "installed" on HDFS but that dynamic jars dir is a DLL hell. What I want to do in BIGTOP-1007 is set up a standard for HBase configuration fragments for coprocessor applications packaged by Bigtop, with helpful modifications on the HBase side as needed to avoid repeating history. I also don't think hosting package bits on a distributed filesystem fits well with OS level package management. A DEB or RPM cannot presume the service or its dependencies are running at install or removal time. (Not suggesting you suggested that - just making a point.) Highly likely this is going to be an issue with YARN apps down the road.
          Hide
          Andrew Purtell added a comment -

          Updated patch adds /usr/lib/phoenix/bin/sqlline.sh. Does substitutions on this file for the Bigtop package layout. Because this needs a log4j properties file, I've also added an etc dir and pre and post install steps for setting that up with 'alternatives'.

          This is what a user will get if launching this file:

          [apurtell@centos6 ~]$ /usr/lib/phoenix/bin/sqlline.sh localhost
          Error: ERROR 2006 (INT08): Incompatible jars detected between client and server. Ensure that phoenix.jar is put on the classpath of HBase in every region server: null (state=INT08,code=2006)
          0: jdbc:phoenix:localhost> 
          

          The script and substitutions are ok, what is missing is an update to the HBase regionserver classpath to include the Phoenix jar there. If I do that, then it works as expected.

          Show
          Andrew Purtell added a comment - Updated patch adds /usr/lib/phoenix/bin/sqlline.sh. Does substitutions on this file for the Bigtop package layout. Because this needs a log4j properties file, I've also added an etc dir and pre and post install steps for setting that up with 'alternatives'. This is what a user will get if launching this file: [apurtell@centos6 ~]$ /usr/lib/phoenix/bin/sqlline.sh localhost Error: ERROR 2006 (INT08): Incompatible jars detected between client and server. Ensure that phoenix.jar is put on the classpath of HBase in every region server: null (state=INT08,code=2006) 0: jdbc:phoenix:localhost> The script and substitutions are ok, what is missing is an update to the HBase regionserver classpath to include the Phoenix jar there. If I do that, then it works as expected.
          Hide
          Roman Shaposhnik added a comment -

          Andrew Purtell very nice! +1 and please commit ASAP so I can do the needful on the Jenkins side of things.

          Show
          Roman Shaposhnik added a comment - Andrew Purtell very nice! +1 and please commit ASAP so I can do the needful on the Jenkins side of things.
          Hide
          Peter Linnell added a comment -

          +1 here too. Thanks for the hard work.... We hope to be not too difficult

          Show
          Peter Linnell added a comment - +1 here too. Thanks for the hard work.... We hope to be not too difficult
          Hide
          Andrew Purtell added a comment -

          I've prepped a commit that is the most recent '993.patch' with the additional changes attached as '993-delta.patch'.

          Yesterday I was testing with RPMs, today I built DEBs too and noticed new lintian warnings. To address those warnings, I remove the executable bit from jars under /usr/lib/phoenix and also add a dependency on bash indirectly through bigtop-utils for sqlline.sh. Adding a dependency on bash directly causes a new lintian error (core dep without versioning) and I thought bigtop-utils was the lesser evil to choose from.

          Will commit in a few hours unless objection.

          Show
          Andrew Purtell added a comment - I've prepped a commit that is the most recent '993.patch' with the additional changes attached as '993-delta.patch'. Yesterday I was testing with RPMs, today I built DEBs too and noticed new lintian warnings. To address those warnings, I remove the executable bit from jars under /usr/lib/phoenix and also add a dependency on bash indirectly through bigtop-utils for sqlline.sh. Adding a dependency on bash directly causes a new lintian error (core dep without versioning) and I thought bigtop-utils was the lesser evil to choose from. Will commit in a few hours unless objection.
          Hide
          Andrew Purtell added a comment -

          Committed. Thanks everyone for the reviews and helpful comments, and the attention to detail.

          Show
          Andrew Purtell added a comment - Committed. Thanks everyone for the reviews and helpful comments, and the attention to detail.
          Hide
          Roman Shaposhnik added a comment -

          Perfect! I've enabled the full set of Jenkins jobs for it – lets see it appear in our trunk repositories.

          Andrew Purtell thanks a bunch for making another really cool component available in Bigtop!

          Show
          Roman Shaposhnik added a comment - Perfect! I've enabled the full set of Jenkins jobs for it – lets see it appear in our trunk repositories. Andrew Purtell thanks a bunch for making another really cool component available in Bigtop!

            People

            • Assignee:
              Andrew Purtell
              Reporter:
              Andrew Purtell
            • Votes:
              1 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development