Behavioral Changes in Ozone

Cloudera Runtime 7.3.2

Migration of the ozone debug recover command to the admin om lease recover Ozone admin CLI command

The ozone debug recover command, used for lease recovery, now resides under the admin om lease recover Ozone admin CLI command.

Example,

# ozone admin om lease recover --path=ofs://<ozone.service.id>/hsyncvol/hsyncbuck/hsync/File_0.txt
Lease recovery SUCCEEDED on ofs://<ozone.service.id>/hsyncvol/hsyncbuck/hsync/File_0.txt

Changed functionality of the --all option in the ozone sh snapshot lsDiff command

Previous behavior:

Previously, the --all option was used to list snapshot diff jobs of any status.

New behavior:

Now, the --all option is used for listing limit. When the --all option is set, the listing limit is effectively set to Integer.MAX_VALUE. For the original --all behavior to list snapshot diff jobs, use the --all-status option instead.

Changed listing and deleting behavior at volume level

Previous behavior:

Previously, recursive listing and deleting a volume was supported using the ozone fs command that worked only if FSO bucket existed in volume.

New behavior:

Now, recursive listing and deleting a volume is supported only by using the ozone shell command and not the ozone fs command. The ozone shell command works for both OBS and FSO buckets inside a volume.

Example

• Recursive delete command

  # ozone fs -rm -R -skipTrash ofs://ozone1713158544/vol/

  Sample output

  24/04/15 13:12:47 WARN ozone.BasicRootedOzoneFileSystem: Recursive volume delete using ofs is not supported
  rm: Recursive volume delete using ofs is not supported. Instead use 'ozone sh volume delete -r -skipTrash -id <OM_SERVICE_ID> <Volume_URI>' command

• Recursive list command

  # ozone fs -ls -R ofs://ozone1713158544/vol/

  Sample output

  24/04/15 13:12:53 WARN ozone.BasicRootedOzoneFileSystem: Recursive root/volume list using ofs is not supported
  ls: Recursive list root/volume using ofs is not supported. Instead use 'ozone sh key list <Volume_URI>' command

Migration of the ozone debug chunkinfo API to the ozone debug replicas chunk-info API

Previous behavior:

Previously, the ozone debug chunkinfo API returned the following JSON response:

{
  "KeyLocations" : [ [ {
    "Locations" : {
      "files" : [ "<block_path>" ],
      "pipelineID" : "<pipeline_id>"
    },
    "Datanode-HostName" : "<host_name>",
    "Datanode-IP" : "<host_ip>",
    "Container-ID" : <id>,
    "Block-ID" : <blockid>
  },{},{}
]]}

New behavior:

Now, the ozone debug chunkinfo API is relocated to the ozone debug replicas chunk-info API and returns the following JSON response:

{
  "volumeName" : "<vol>",
  "bucketName" : "<buck>",
  "name" : "<key>",
  "keyLocations" : [ [ {
    "datanode" : {
      "hostname" : "<host_name>",
      "ip" : "<host_ip>",
      "uuid" : "<uuid>"
    },
    "file" : "<block_path>",
    "blockData" : {
      "blockID" : {
        "containerID" : <id>,
        "localID" : <localid>,
        "blockCommitSequenceId" : <bcsid>
      },
      "size" : <size>,
      "chunks" : [ {
        "offset" : <offset>,
        "len" : <len>,
        "checksums" : [ "<checksum>" ],
        "checksumType" : "<ctype>",
        "bytesPerChecksum" : <bpc>
      } ]
    }
  }, {}, {}
]]}

As part of this API update, the following keys are updated:

Table 1. JSON key mapping for the relocated ozone debug chunkinfo API

Key name	Key in the previous JSON	Key in the current JSON
Block path	data["KeyLocations"][0][0]["Locations"]["files"][0]	data["keyLocations"][0][0]["file"]
Container ID	"Container-ID"	blockData.blockID.containerID
Block ID	"Block-ID"	blockData.blockID.localID
Hostname	"Datanode-HostName"	datanode.hostname

The S3 Gateway web UI is moved to a new port

Previous behavior:

The S3 Gateway web UI was accessible on ports 9878 for HTTP and 9879 for HTTPS, just like S3 buckets.

New behavior:

The S3 Gateway web UI resides on new ports to avoid conflicts with S3 buckets. The new ports are 19878 for HTTP and 19879 for HTTPS.