Case for implementing backward compatibility

When users of older versions want to upgrade their Atlas versions to the latest one, they might face an issue because of certain validation checks in Atlas.

Existing types with attributes violating the attribute name rules (which were added in later Atlas versions) may have been added to the system.

All the existing types get populated at the time of Atlas startup and they all get validated.

If the users have Entity types or Classifications in the system that violate the naming rule, then Atlas raises an exception at the time of the service startup if the users have upgraded their environment to the latest version.

As a result of this exception that results at the time of Atlas startup, the typedef registry does not get populated. Even though users can log in to Atlas UI, they cannot view or use any types or Entities.

When users having data with such types try to upgrade their environment to the latest bits, they encounter issues as discussed earlier in this section.

Also, in their application.log they see an exception with a system output:

Error code: "ATLAS-400-00-09E" and Error message: "Invalid attribute name: <type name>.<attribute name>. Attribute already exists in another parent type: <parent type name>"

The backward compatibility feature is built to avoid these scenarios for such Entity types and Classifications.

How backward compatibility works

The backward compatibility feature is provided to skip exceptions coming from the attribute name rule.

From your Cloudera Manager instance > Configuration tab, a property must be added in your CM Safety Valve configuration.

atlas.skip.check.for.parent.child.attribute.name=true

Later, restart the Atlas service to apply this configuration.

When Atlas starts, no exceptions are raised and all the typedefs and Entities are displayed and available for use.

What Next:

After adding the backward compatibility configuration, all the validations and checks are disabled. You can create / update the types which have the same name attributes as their parent type attributes. The Atlas service operates in the same way as it was behaving prior to the Cloudera Runtime 7.1.7 version.

Error code: "ATLAS-400-00-09E" and Error message: "Invalid attribute name: <type name>.<attribute name>. Attribute already exists in another parent type: <parent type name>"

If the user does not want any of their migrated existing types (which violate the name rule) to be present in the current environment, the user can delete these types using the Atlas REST APIs and later remove the configuration from the Cloudera Manager Safety Valve. Finally, restart the Atlas service.