Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-1662

puppet: Fix hadoop configuration file incompleteness due to hiera conversion

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: backlog
    • Fix Version/s: 1.0.0
    • Component/s: deployment
    • Labels:
      None

      Description

      The changes from BIGTOP-1634 omit kerberos_realm and hadoop_security_authentication variables from some classes so that they're not correctly entered in the generated configuration files. Also, a hasty "fix" to hadoop-env.sh causes all variables to remain unset always.

        Activity

        Hide
        michaelweiser Michael Weiser added a comment -

        Patch that fixes the issues.

        Show
        michaelweiser Michael Weiser added a comment - Patch that fixes the issues.
        Hide
        evans_ye Evans Ye added a comment -

        Hey Michael Weiser, I've tested the patch. In general, this is a great work. We're getting the kerberos feature almost fixed.
        There's a realm configuration missing in cluster.yaml that causing all the principal in hdfs-site.xml not having realm, hence namenode startup fail.
        Here's a quick and dirty fix I added into cluster.yaml:

        hadoop::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        

        This will propagate realm setting to hadoop's init.pp. After adding this I can successfully provision a kerberos cluster.

        Here's the kerberos setting I added in site.yaml FYR (copied from cluster.yaml):

        hadoop::hadoop_security_authentication: "kerberos"
        kerberos::site::domain: "do.main"
        kerberos::site::realm: "DO.MAIN"
        kerberos::site::kdc_server: "bigtop1.docker"
        kerberos::site::kdc_port: "88"
        kerberos::site::admin_port: "749"
        kerberos::site::keytab_export_dir: "/var/lib/bigtop_keytabs"
        

        However, for an official fix, we shall use the naming convention introduced in BIGTOP-1634, that would be something like this:

        hadoop::common_hdfs::kerberos_realm: "%{hiera('kerberos::site::realm')}
        

        and then updated $hadoop::kerberos_realm to $hadoop::common_hdfs::kerberos_realm in hadoop init.pp.

        Are you planning to fix one component each time? We've solr, zookeeper, oozie, hue, and hbase, which are also need to be fixed as well. I'm ok to fix it one by one. But how about rename the title to specific to hadoop, so that we can do other components in separated JIRA.

        Show
        evans_ye Evans Ye added a comment - Hey Michael Weiser , I've tested the patch. In general, this is a great work. We're getting the kerberos feature almost fixed. There's a realm configuration missing in cluster.yaml that causing all the principal in hdfs-site.xml not having realm, hence namenode startup fail. Here's a quick and dirty fix I added into cluster.yaml: hadoop::kerberos_realm: "%{hiera('kerberos::site::realm')}" This will propagate realm setting to hadoop's init.pp. After adding this I can successfully provision a kerberos cluster. Here's the kerberos setting I added in site.yaml FYR (copied from cluster.yaml): hadoop::hadoop_security_authentication: "kerberos" kerberos::site::domain: " do .main" kerberos::site::realm: "DO.MAIN" kerberos::site::kdc_server: "bigtop1.docker" kerberos::site::kdc_port: "88" kerberos::site::admin_port: "749" kerberos::site::keytab_export_dir: "/ var /lib/bigtop_keytabs" However, for an official fix, we shall use the naming convention introduced in BIGTOP-1634 , that would be something like this: hadoop::common_hdfs::kerberos_realm: "%{hiera('kerberos::site::realm')} and then updated $hadoop::kerberos_realm to $hadoop::common_hdfs::kerberos_realm in hadoop init.pp. Are you planning to fix one component each time? We've solr, zookeeper, oozie, hue, and hbase, which are also need to be fixed as well. I'm ok to fix it one by one. But how about rename the title to specific to hadoop, so that we can do other components in separated JIRA.
        Hide
        michaelweiser Michael Weiser added a comment -

        Evans Ye: You're spot-on about setting hadoop::kerberos_realm instead of hadoop::common_yarn::kerberos_realm in cluster.yaml. I've updated the patch accordingly. I've intentionally added the variable to the hadoop main module class so it can be handed down from there as a default to all the sub-classes (hdfs, yarn, mapred and httpfs).

        As for the other modules: All the realm-setting is already in place in cluster.yaml and should work:

        user@debian:~/bigtop/bigtop-deploy/puppet# grep kerberos_realm hieradata/bigtop/cluster.yaml 
        hadoop::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        hadoop-hbase::common_config::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        solr::server::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        hadoop-oozie::server::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        hcatalog::server::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        hcatalog::webhcat::server::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        hadoop-zookeeper::server::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        hue::server::kerberos_realm: "%{hiera('kerberos::site::realm')}"
        

        I have to admit, I haven't tested them all. But I seem to remember from my tests for BIGTOP-1634 that their config files changed accordingly when I set kerberos::site::realm. Can you check in your environment that the realm turns up correctly for those other modules?

        Show
        michaelweiser Michael Weiser added a comment - Evans Ye : You're spot-on about setting hadoop::kerberos_realm instead of hadoop::common_yarn::kerberos_realm in cluster.yaml. I've updated the patch accordingly. I've intentionally added the variable to the hadoop main module class so it can be handed down from there as a default to all the sub-classes (hdfs, yarn, mapred and httpfs). As for the other modules: All the realm-setting is already in place in cluster.yaml and should work: user@debian:~/bigtop/bigtop-deploy/puppet# grep kerberos_realm hieradata/bigtop/cluster.yaml hadoop::kerberos_realm: "%{hiera('kerberos::site::realm')}" hadoop-hbase::common_config::kerberos_realm: "%{hiera('kerberos::site::realm')}" solr::server::kerberos_realm: "%{hiera('kerberos::site::realm')}" hadoop-oozie::server::kerberos_realm: "%{hiera('kerberos::site::realm')}" hcatalog::server::kerberos_realm: "%{hiera('kerberos::site::realm')}" hcatalog::webhcat::server::kerberos_realm: "%{hiera('kerberos::site::realm')}" hadoop-zookeeper::server::kerberos_realm: "%{hiera('kerberos::site::realm')}" hue::server::kerberos_realm: "%{hiera('kerberos::site::realm')}" I have to admit, I haven't tested them all. But I seem to remember from my tests for BIGTOP-1634 that their config files changed accordingly when I set kerberos::site::realm. Can you check in your environment that the realm turns up correctly for those other modules?
        Hide
        evans_ye Evans Ye added a comment -

        it can be handed down from there as a default to all the sub-classes (hdfs, yarn, mapred and httpfs).

        Ok that's reasonable to me. These components won't adopt different realm at all.

        All the realm-setting is already in place in cluster.yaml and should work:

        Sorry I'm not that familiar with hiera, but now I get it, it should work. I've tested other components and the realm has been successfully propagated.
        So, +1 on this patch, I'll commit this later.

        Show
        evans_ye Evans Ye added a comment - it can be handed down from there as a default to all the sub-classes (hdfs, yarn, mapred and httpfs). Ok that's reasonable to me. These components won't adopt different realm at all. All the realm-setting is already in place in cluster.yaml and should work: Sorry I'm not that familiar with hiera, but now I get it, it should work. I've tested other components and the realm has been successfully propagated. So, +1 on this patch, I'll commit this later.
        Hide
        evans_ye Evans Ye added a comment -

        Committed. Thanks Michael Weiser, now we have kerberos feature back to normal!

        Show
        evans_ye Evans Ye added a comment - Committed. Thanks Michael Weiser , now we have kerberos feature back to normal!

          People

          • Assignee:
            michaelweiser Michael Weiser
            Reporter:
            michaelweiser Michael Weiser
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development