NetAppDocs / element-software

https://docs.netapp.com/us-en/element-software/
0 stars 0 forks source link

Weird time period format in scheduleInfo object #205

Open scaleoutsean opened 1 month ago

scaleoutsean commented 1 month ago

Page URL

https://docs.netapp.com/us-en/element-software/api/reference_element_api_schedule.html

Page title

schedule

Summary

Creating a schedule from the UI, I got "retention": "24:0:00" for 1 day retention.

This is a UI bug, an API validation bug and a documentation bug (as long as the buggy behavior isn't documented, in the case Engineering doesn't want to fix it).

scheduleInfo object is said to include "the retention period for the snapshot that was created", but no one uses 24:0:00 to denote 24 hours. If this API bug won't be fixed, then please document these weird formats that scheduleInfo make give for people who rely on the API output.

This is on SolidFire 12.5.0.897.

{
  "id": 1,
  "result": {
    "schedules": [
      {
        "attributes": {
          "frequency": "Time Interval"
        },
        "hasError": false,
        "hours": 2,
        "lastRunStatus": "Success",
        "lastRunTimeStarted": null,
        "minutes": 0,
        "monthdays": [],
        "paused": false,
        "recurring": true,
        "runNextInterval": false,
        "scheduleID": 6,
        "scheduleInfo": {
          "enableRemoteReplication": true,
          "name": "replicated",
          "retention": "24:0:00",
          "snapMirrorLabel": null,
          "volumeID": 172
        },
        "scheduleName": "int-2h-rep-24h",
        "scheduleType": "Snapshot",
        "startingDate": null,
        "toBeDeleted": false,
        "weekdays": []
      }]}

Public issues must not contain sensitive information

scaleoutsean commented 1 month ago

By the way, this is how to create this 24:0:00 retention:

image

Even after changing to "Retain forever" and then back to 01:00:00 (days, hours, minutes), the API still returns the buggy output. I even tried from scratch by fully populating the time fields that way (01:00:00), but the API stores (and later returns) that buggy format.

netapp-pcarriga commented 3 weeks ago

Hi @scaleoutsean, thank you for bringing this to our attention.