A task manifest does not support "windowed" schedule types

[geauxvirtual]

For a task manifest, the manifest includes a schedule plus the workflow. When the task manifest is unmarshalled, the schedule is unmarshalled into the following struct.

type Schedule struct {
    // Type specifies the type of the schedule. Currently, the type of "simple", "windowed" and "cron" are supported.
    Type string
    // Interval specifies the time duration.
    Interval string
    // StartTime specifies the beginning time.
    StartTime *time.Time
    // StopTime specifies the end time.
    StopTime *time.Time
}

For a windowed schedule type, the schedule would need to include Type, Interval, StartTime, and StopTime.

Golang json encoder does not support time.Time type by default, and to correctly unmarshal into a time.Time type requires writing a UnmarshalJSON function on the Schedule type, which currently does not exist.

[geauxvirtual]

To compound this issue, with the addition of PR #951, tasks can be autoloaded into snapd. However, if a task manifest is loaded via this mechanism, the manifest is treated the same as a request from the REST API, which unmarshals the request into a task object with the following schedule struct.

type Schedule struct {
    Type           string `json:"type,omitempty"`
    Interval       string `json:"interval,omitempty"`
    StartTimestamp *int64 `json:"start_timestamp,omitempty"`
    StopTimestamp  *int64 `json:"stop_timestamp,omitempty"`
}

So between snapd and snapctl, there is no consistency with unmarshaling the schedule with regards to windowed schedule types.

[geauxvirtual]

There also seems to be a loss of information from creation of a task with a windowed schedule when the task is exported from snapd.

For example, say a user creates a task using the following command

build/bin/snapctl task create -w examples/tasks/mock-file-wf.json -i 5s --duration 30m

This will create a task with a windowed schedule that will start immediately and execute every 5s for 30 minutes. What snapctl does is generate a start timestamp of now and stop timestamp of now plus 30 minutes before sending the request to the REST API.

Now when a user exports this task from snapd, this is the output.

{
    "id": "4f7a7fe4-f1db-4a5b-a5b8-36efa91b1d48",
    "name": "Task-4f7a7fe4-f1db-4a5b-a5b8-36efa91b1d48",
    "deadline": "5s",
    "workflow": {
        "collect": {
            "metrics": {
                "/intel/mock/*/baz": {
                    "version": 0
                },
                "/intel/mock/bar": {
                    "version": 0
                },
                "/intel/mock/foo": {
                    "version": 0
                }
            },
            "config": {
                "/intel/mock": {
                    "password": "secret",
                    "user": "root"
                }
            },
            "process": [
                {
                    "plugin_name": "passthru",
                    "plugin_version": 0,
                    "publish": [
                        {
                            "plugin_name": "mock-file",
                            "plugin_version": 0,
                            "config": {
                                "file": "/tmp/snap_published_mock_file.log"
                            },
                            "target": ""
                        }
                    ],
                    "target": ""
                }
            ]
        }
    },
    "schedule": {
        "type": "windowed",
        "interval": "5s",
        "start_timestamp": 1473299027,
        "stop_timestamp": 1473300827
    },
    "creation_timestamp": 1473299026,
    "last_run_timestamp": 1473299057,
    "hit_count": 6,
    "task_state": "Running",
    "href": "http://localhost:8181/v1/tasks/4f7a7fe4-f1db-4a5b-a5b8-36efa91b1d48",
    "Err": null
}

As seen above, the schedule shows a start_timestamp and stop_timestamp. This information is of little importance in creating a task from this exported manifest as those values will no longer be valid, nor does it give the user any useful information on the schedule of the task without decoding the start_timestamp and stop_timestamp to figure how long the task was set to run for.

[katarzyna-z]

Golang json encoder does not support time.Time type by default, and to correctly unmarshal into a time.Time type requires writing a UnmarshalJSON function on the Schedule type, which currently does not exist.

Golang JSON encoder is able to deal with time.Time. time.Time has UnmarshaJSON method but the time must be given as a quoted string in RFC 3339 format.

The issue was mainly caused by missing tags for JSON parser in this struct:

type Schedule struct {
    // Type specifies the type of the schedule. Currently, the type of "simple", "windowed" and "cron" are supported.
    Type string
    // Interval specifies the time duration.
    Interval string
    // StartTime specifies the beginning time.
    StartTime *time.Time
    // StopTime specifies the end time.
    StopTime *time.Time
}