Fixed issues in Ozone
Review the list of Ozone issues that are resolved in Cloudera Runtime 7.1.4.
- CDPD-17352: HDDS-4193: Range used by AWS S3 MultipartUpload copy-from-source must be inclusive.
- This issue is now resolved.
- Ozone filesystem trash is not automatically cleaned up.
- This issue is now resolved. This fix disables the Hadoop filesystem trash support in Ozone. Usually, when a file stored on a Hadoop compatible filesystem is deleted via the fs shell, the file is moved to the trash and eventually purged after the fs.trash.interval has elapsed. When the target filesystem is Ozone, the file is deleted immediately without being moved to trash. Trash support for the Ozone filesystem will be added in the subsequent release of CDP Private Cloud Base.
- CDPD-15243: The Ozone volume s3v is an internal volume that is used to contain all buckets created through the s3 gateway.
- When you create the first s3 bucket, the s3 volume is created automatically with the appropriate ACLs on a secure cluster.
- CDPD-15080: Ozone key names are now interpreted as filesystem paths and are normalized before storing in Ozone.
- Using the Hadoop filesystem API, you can now access the keys uploaded via the Ozone S3 API.
- CDPD-7358: Upgrade to Guava 28.1 to avoid CVE-2018-10237
- Ozone has been upgraded to use Guava version 28.1 to avoid CVE-2018-10237.
- CDPD-7370: Ozone - Upgrade to Jetty 9.4.26 to avoid CVEs
- Ozone now uses Jetty 9.4.26, which addresses the following CVEs: CVE‑2017‑7656, CVE‑2017‑7657,CVE‑2017‑7658, CVE‑2018‑12536, CVE‑2017‑9735, CVE‑2019‑10247.