- CDPD-87175: Incorrect labeling for REST Catalog
events in Ranger audit list
- 7.3.1.600
- 7.3.1.400, 7.3.1.500
HiveAuthorizer needs the
authorization context enriched to have the client_type
for the auditing purposes. Currently when calls are made into Ranger
HiveAuthorizer from REST Catalog, Ranger is not able to
differentiate the plugins between HMS / REST catalog and hence the
audit is not correctly done for the calls made from REST Catalog
service. With this change, requests from the Rest catalog will appear
in the Ranger audit list with the client type set to
restCatalog. All such requests show up as
HiveMetaStore instead.
- CDPQE-40109: REST Catalog needs to be
reconfigured, after migration DL from LD to EDL.
- After migrating the Data Lake (DL) from
Light Duty to Enterprise Data Lake (EDL), all previously configured
REST Catalog settings are missing. These include configurations such
as the Hive Metastore (HMS) REST catalog enablement flag and Knox
settings.
- Manually reconfigure the REST Catalog
settings after Data Lake migration. This includes the following:
- Reenable the REST catalog flag in HMS.
- Repeat the necessary Knox configurations.
- CDPQE-40110: REST Catalog needs to be
reconfigured, after performing backup & restore to new DL
- When performing a Data Lake backup and
restore to new DL, any REST Catalog configurations made through Cloudera Manager, including enabling the Hive
Metastore REST Catalog and Knox settings, are not retained in the
restored Data Lake.
- Manually reconfigure the REST Catalog
settings after Data Lake backup or restore. This includes the
following:
- Reenable the REST catalog flag in HMS.
- Repeat the necessary Knox configurations.
- DOCS-25855: REST Catalog needs to be reconfigured
after performing upgrade recovery
- When a patch upgrade fails for a cluster
with REST Catalog, perform an SDX Upgrade recover operation on the
Data Lake as the REST Catalog settings are not retained.
- 7.3.1.400, 7.3.1.500, 7.3.1.600,
7.3.1.700
- Manually reconfigure the REST Catalog
settings after performing a Data Lake upgrade recovery. This includes
the following:
- Reenable the REST catalog flag in HMS.
- Repeat the necessary Knox configurations.
- DOCS-26132: Data Lake Zero Downtime Upgrade (ZDU)
is not supported as High Availability (HA) support not available for
REST Catalog
- 7.3.1.600
- 7.3.1.400, 7.3.1.500
- Data Lake Zero Downtime Upgrade (ZDU) is
not supported for REST Catalog. At the time of a rolling upgrade, when
the HMS role is stopped, Rest APIs calls are failing with the HTTP
500 error.
- None
- DOCS-25891: Ranger Audits not recorded for roles
or client ids
- 7.3.1.400
- 7.3.1.400
- When running a Curl call or selecting a
query from the Spark client via
CLIENT-ID and
CLIENT_SECRET, there is no audit log recorded in Apache
Ranger.
- Apache Ranger audits for the REST Catalog
meta operations will not show up unless HMS and REST Catalog is
restarted after configuring Apache Knox and the IDBroker and
reenabling REST Catalog for Cloudera Data Sharing.
- DOCS-25863: Rollback query on Cloudera does not pick up correct
metadata file and snapshot on Snowflake
- 7.3.1.400
- After performing a rollback for table in
Apache Hive, the pointer shows the correct file in Cloudera, but Snowflake shows the
last snapshot instead of the snapshot targeted by the rollback.
- In Snowflake, remove the table from the
current schema with DROP and recreate it.
- DOCS-25892: Materialized View and Metadata Read
Fails from External Client (EMR)
- 7.3.1.400 and its service packs and
hotfixes
- After you create a materialized view for
an Apache Hive table and try to read it using the AWS Elastic Map
Reduce (EMR) external client, the read operation fails. This is
because the Iceberg REST 1.3.1 specification supported by Cloudera are not supporting external
clients yet.
- DOCS-25895: Compatibility and Access Solutions
for Cloudera Iceberg REST Catalog with Snowflake
- 7.3.1.400 and higher service packs
and
cumulative hotfixes
-
Cloudera complies with the current
Apache Iceberg REST Catalog API specification, providing
credentials in the response to the LoadTable
API call. Snowflake currently does not use the credentials in the
LoadTable API response. Instead, Snowflake retrieves
the credentials via a separate API call.
This issue has been raised with Snowflake, and they acknowledge it
and are actively working on a resolution.
- Until the update is available, consider
using the external volume approach suggested by Snowflake when
accessing the Iceberg REST catalog from Snowflake.
- CDPD-85253: Rest Catalog service should use only
HMS RangerHiveAuthorizer for its command authorization
- 7.3.1.500
- 7.3.1.500
- Due to the static nature of the hive
ranger plugin, having a new instance of HivePlugin for REST Catalog
causes overwriting of the hivePlugin reference and using it for
authorization. This is caused due to the REST Catalog being embedded
in the HMS and not having its separate service. You have to use
hiveMetasore as an application filter in
to see the audit events.
- CDPD-82812: The High Availability feature is not
working for Rest Catalog
- 7.3.2
- 7.3.1.400 and higher service packs
and cumulative hotfixes
-
The Knox topology file cdp-share-access.xml
created during Cloudera Data Sharing setup cannot
handle multiple Hive Metastore nodes. In case of a node failure,
the healthy nodes cannot reliably take over the workload.
- CDPD-91447: Upon enabling REST Catalog on NTP
setup hive metastore report health issues
- 7.3.1.600
- 7.3.1.500
- Enabling REST Catalog for a ARM-based Enterprise
data lake deployment with an NTP setup might result in memory leak
issues for Hive Metastore.
- CDPD-84118: Hive Metastore Servlet Security Layer
Performance and Resource Management Issues
- 7.3.1.600
- 7.3.1.400, 7.3.1.500
- The Hive Metastore
servlet
security layer created a new UserGroupInformation
(UGI) object for every incoming HTTP request and immediately closed
associated FileSystem handles after each request
completed. This approach led to significant performance degradation in
high-traffic environments where the same users make frequent API
calls. This could lead to potential memory leaks when
FileSystem resources were not properly cleaned up.
- CDPD-81718: Check Metering V2 Service health before starting
Rest Catalog Jetty Server
- 7.3.1.400 and higher service packs and cumulative
hotfixes
- Checking the Metering V2 Service health status before
starting the REST Catalog service has been temporarily removed. This check was causing
failures in environments where the Metering Service is not available, such as certain Cloudera Manager-based environments.
- None
- CDPD-83244: Snowflake Catalog Integration Secret Rotation
- 7.3.1.400 and higher service packs and cumulative
hotfixes
- When creating a Snowflake catalog integration, Snowflake
does not allow changing the
CLIENT ID for the integration, only the
secret. However, when using Knox to generate these credentials, both a new CLIENT
ID and a new secret are generated. Replacing the catalog integration is not
possible if it has active tables.
- Change the catalog integration for each table individually
or create a new table. Alternatively, you can use a workaround by altering the catalog
integration with only the new secret for the old
CLIENT ID, provided
you have the correct Ranger policy for the new CLIENT ID.
- CDPD-83243: Snowflake Catalog Integration with Vended
Credentials is not supported
- 7.3.1.400 and higher service packs and cumulative
hotfixes
- Snowflake catalog integration with vended credentials is
not supported. Attempting to use the
/credentials API endpoint results
in a No route to host or BadRequestException error,
and table creation fails.
- None
- CDPD-82198: Metering events are sent for deleted or unauthorized
tables
- 7.3.1.400 and higher service packs and cumulative
hotfixes
- Metering events are generated for deleted or unauthorized
tables. If API calls are made for tables that do not exist or fail on the server side
(for example, the user is not authorized on the table, or an error occurs while
processing the request on the backend in the Hive Metastore, Apache Ranger, or Apache
Knox), these calls are still metered and billed. This is expected behavior.
- None
