ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMBARI-17894) Adding Services After A Stack/Ambari Upgrade Shows Empty Required Values
Date Mon, 25 Jul 2016 21:03:20 GMT
Jonathan Hurley created AMBARI-17894:
----------------------------------------

             Summary: Adding Services After A Stack/Ambari Upgrade Shows Empty Required Values
                 Key: AMBARI-17894
                 URL: https://issues.apache.org/jira/browse/AMBARI-17894
             Project: Ambari
          Issue Type: Bug
          Components: ambari-server
    Affects Versions: 2.4.0
            Reporter: Jonathan Hurley
            Assignee: Jonathan Hurley
            Priority: Blocker
             Fix For: 2.4.0


STR:

- Install Ambari 2.2.2 with Hive on HDP 2.4.2.0 and Kerberize
- Upgrade to Ambari 2.4.0
- Upgrade to HDP 2.5
- Distribute Keytabs
- Add a new service

At this point, the UI flags Hive as having configurations which need attention. The follow
are all blank and are marked as required:

{code}
hive-site/hive.server2.authentication.ldap.url
hiveserver2-site/hive.conf.restricted.list
hiveserver2-site/hive.security.authenticator.manager
hiveserver2-site/hive.security.authorization.manager
{code}

There are actually two problems here:

- The Kerberos wizard interprets the stack advisor "delete" attribute and improperly sets
config properties to blank instead of actually removing them

- The upgrade logic is adding properties back when it should not.

The Kerberos issue aside, we can't be adding properties back during upgrade stack merging
when those properties were specifically removed by the stack advisor prior.

For example (Ambari 2.2.2 installed with HDP 2.x)
- Ambari 2.2.2 does not have {{foo-site/property}} for HDP 2.x
- Ambari 2.4.0 adds {{foo-site/property}} for HDP 2.x, but instructs the upgrade not to add
it
- An upgrade to HDP 2.y sees that {{foo-site/property}} doesn't exist and thinks it's brand
new and needs to be merged.

The upgrade logic should check to see if {{foo-site/property}} is part of both 2.x and 2.y
default configurations. If it's part of both of them and is not currently set, then upgrade
should NOT set it.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message