| Table of Contents |
|---|
...
- FileSetProperties.setUseExisting(true) (or DATA_USE_EXISTING / "data.use.existing") to reuse an existing location and Hive table. The dataset will assume that it does not own the existing data in that location and Hive table, and therefore, when you delete or truncate the dataset, the data will not be deleted.
- FileSetProperties.setPossessExisting(true) (or DATA_POSSESS_EXISTING / "data.possess.existing") to assume ownership an existing location and Hive table. The dataset will assume that it owns the existing data in that location and Hive table, and therefore, when you delete or truncate the dataset, all data will be deleted, including the previously existing data and Hive partitions.
...
To support app level impersonation wherein application, datasets and streams can have their own owner and the operation performed in CDAP should impersonated their respective owner CDAP should have access to the owner principal and their associated keytabs. Owner principals of an entity is provided during the entity creation step (see REST APIs documentation in next section). CDAP expect
For user's keytab access CDAP uses the following conventions:
- All keytabs must be present on the local filesystem on which CDAP Master is running.
- These keytabs must be present under a path which can be in one of the following formats and cdap should have read access on all the keytabs:
- /dir1>/<dir2>/${name}.keytab
- /dir1>/<dir2>/${name}/${name}.keytab
The above path is provided to CDAP as a configuration parameter in cdap-site.xml for example:
Code Block title cdap-site.xml <property> <name>security.keytab.path</name> <value>/etc/security/keytabs/${name}.keytab</value> </property>Where ${name} will be replaced by CDAP by the short user name of the kerberos principal CDAP is impersonating.