API endpoint for scheduling asset

[Flix6x]

Description

Schedule an asset using a flex-model that consists of a list of flex-models for individual power sensors.

Look & Feel

URI: assets/801/schedules/trigger

Body:

{
    "flex-model" : [
        {"sensor" : 1, "power-capacity" : "1MW"},
        {"sensor" : 2, "power-capacity" : "10kW"},
        {"sensor" : 3, "soc-at-start" : 10.0},
    ],
    "flex-context" : {
        "consumption-price-sensor" : 8,
        "production-price-sensor" : 9,
        "inflexible-device-sensors" : [14, 15]
    }
}

Further Improvements

Work in progress:

• [V] Tests
  • integration test that resembles toy tutorial case (battery + solar + EV)
  • test with more than 2 flexible sensors
• [F] Check user is authorized to reference sensors in flex-model and flex-context: moved to 904 read permissions of entities within flex model or flex context #1071
• [F] Ensure that flexible sensors fall under the asset (inflexible sensors may still come from a different asset)
• [F] Unpack flex-model into one flex-model per sensor
• [V] Dependent scheduling jobs
• [F] Documentation of endpoint
• [F] Marshmallow validation

Created follow-up issues:

• CLI needs option to set model and context from file (editable?)
• Extend tutorial

Related Items

Closes #485.

[Flix6x]

Technically, I guess I now implemented this todo, by putting the last job ID (that of the 'done job') in the response. However, I recall we discussed returning a full list of job IDs, so that the API user can use the existing get_schedule endpoint to retrieve schedules for individual sensors. In that case, the next step would be to spec such a response.

For example:

{
    "schedules": [
        {
            "sensor": 1,
            "schedule": "<uuid>"
        },
        {
            "sensor": 2,
            "schedule": "<uuid>"
        }
    ]
}

[victorgarcia98]

True, returning a list of schedules would be the way to go. That way, we can reuse the endpoint to get the schedules.

[Flix6x]

I'm not too sure about my change here, but I believe I saw duplicate jobs in the queue otherwise.

[victorgarcia98]

We are enqueuing them later altogether. We are not checking the function argument, though. This is something to be fixed.

[Flix6x]

I'm not very clear on what this does.

[victorgarcia98]

Me neither... This came from the function create_scheduling_job. I'm not sure why would a job exist, maybe, if the job id is provided and it coincides with one that was queued?

[victorgarcia98]

We should probably move the enqueue here..

[victorgarcia98]

I mean doing something like if enqueue: ...

[victorgarcia98]

The trigger can also deal with inflexible devices so this is incomplete.

[Flix6x]

The first part is true. However, no schedules are created for the inflexible devices.

[victorgarcia98]

This example should be updated with the new schema changes (sensor_flex_model field, etc)

[Flix6x]

That sensor_flex_model field is not a field in the public API, but rather a field that gets created when the endpoint validation partly deserializes the flex-model field. It essentially belongs to a schema that is internal to our platform, used only for the purpose of sequential scheduling. The endpoint logic picks up the still serialized sensor_flex_model field and passes it to the job kwargs.

[victorgarcia98]

TODO

[victorgarcia98]

Couldn't this wrap the single device flex model schema? Either extend it via inheritance or nesting it?

[Flix6x]

It could, but I don't want to actually deserialize the sensor flex model here, because it needs to be passed to the job kwargs in serialized form. I agree that it's neater, though. I could see if I can do something with telling the endpoint decorator to partially deserialize the schema, i.e. only the sensor field. At first glance it seems possible.

[Flix6x]

We actually don't have a single device flex model schema. We currently have the ProcessSchedulerFlexModelSchema and the StorageFlexModelSchema, and potentially others in the future. Right now the use of fields.Dict already suggests that the SequentialFlexModelSchema is agnostic to the underlying types of flex models, so that has its merits, too.

[victorgarcia98]

This schema could be used via the CLI so the status_if_not_found will not make sense there. As an alternative, we can catch the exception in the CLI and display the proper message.

[victorgarcia98]

Alternatively, we can avoid this situation by providing an already deserialized asset using the AssetIdField as a CLI field.

[Flix6x]

Removing the status_if_not_found=404 here would mean that visiting /assets/<non-existing-id>/schedules/trigger would return a validation error (422 status?) rather than 404 Not Found.

I would actually be fine with that. Given that we are POSTing a resource (job) rather than GETting a resource (asset) here, the asset should be seen as part of the POSTed payload to be validated.
Even though at first glance it doesn't seem correct if the asset ID is coming from the path, we have already started to treat the payload more RESTlike by including it in with the JSON data to be validated within the same schema.
In the future, we'd want to move to a RESTful approach to jobs anyway, and then the asset truly becomes part of the JSON payload.

We might already reconsider the choice of endpoint, but I am wary of increasing the scope of this PR too much.

For now I'll remove the 404 here.

Concerning the CLI, we hardly use schemas there at the moment, as opposed to fields, so maybe it's not that much of a problem?

[victorgarcia98]

value arg doesn't have the right type considering that you are using int(value) to convert the object to int, is it str?