[OOZIE-1890] Make oozie-site empty and reconcile defaults between oozie-default and the code

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 4.2.0
• Component/s: core
• Assignee: seoeun
• Reporter: Robert Kanter
• Created: 19/Jun/14 17:01
• Updated: 20/Aug/15 01:26
• Resolved: 06/Nov/14 01:20

Description

As shwetha and puru suggested in OOZIE-1888, oozie-site vs oozie-default is a point of confusion for users. We've also had issues in the past where they've had different values from each other and/or from the code's default (i.e. conf.get(PROP_NAME, DEFAULT_VALUE)).

We should make oozie-default the only source of truth by:

1. Putting all configuration properties in oozie-default.
2. Making oozie-site empty; if the user wants to change a property, they can copy it out of the for-reference oozie-default.
3. Getting rid of the code defaults. It's easy for these to be out of sync with oozie-default, leading to confusion. They aren't used anyway because oozie-default should always be there (and will now have every property)

This will require looking through all classes to make sure we're not missing anything from oozie-default and also checking that we put the proper default value (from all 3 sources) into oozie-default. It may be nice to also reorder the properties in oozie-default alphabetically (and also do this going forward with new properties).

Also, oozie.service.WorkflowAppService.system.libpath should be set to "/user/${user.name}/share/lib" (which is what OOZIE-1888 wanted to do).

Issue Links

• breaks: OOZIE-2104 oozie server dies on startup if oozie-site redefines ActionExecutor classes
• breaks: OOZIE-2322 Oozie Web UI doesn't work with Kerberos in Internet Explorer 10 or 11 and curl
• relates to: OOZIE-1888 oozie.service.WorkflowAppService.system.libpath is wrong in oozie-default.xml
• relates to: OOZIE-2338 Invalid configuration defined reported for some valid configs
• links to: review board