FLEXMEASURES_MAX_PLANNING_HORIZON can be int

[Flix6x]

Closes #570.

[coveralls]

Pull Request Test Coverage Report for Build 3943213675

• 18 of 19 (94.74%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.02%) to 65.362%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
flexmeasures/data/models/planning/storage.py	3	4	75.0%

Files with Coverage Reduction	New Missed Lines	%
flexmeasures/data/models/planning/storage.py	1	88.4%

Totals
Change from base Build 3943014511:	0.02%
Covered Lines:	6847
Relevant Lines:	9835

---

💛 - Coveralls

[nhoening]

I was just thinking about this, and it seems to me that this is a rather large default horizon. This will eat a lot of CPU budget.
To me, ~10% of this is reasonable (a bit over 2 weeks for a 1-hour sensor, a day for a 5-minute sensor)

[nhoening]

Also a thought for the future: this might have to change per account (at first via an attribute, I guess), as this is possibly relevant for billing flex scheduling services.

[Flix6x]

I was just thinking about this, and it seems to me that this is a rather large default horizon. This will eat a lot of CPU budget.

This is not the default horizon (which is currently set to 2 days), but the default max horizon. I agree that this is a rather large value, but it is what the FlexMeasures scheduler can currently handle without the scheduling jobs timing out after 180 seconds.

I also thought of coupling this PR with the introduction of a config setting to allow FlexMeasures hosts to overwrite python-rq's default job timeout of 180 seconds for the scheduling queue, but I decided to save that for a separate PR. That would be a simple change in app.py, something like:

Queue(name="scheduling", default_timeout=app.config["FLEXMEASURES_PLANNING_TIMEOUT"])

[nhoening]

Oh yes, sorry for the oversight. Actually, I would advise we give FLEXMEASURES_PLANNING_HORIZON the same treatment (that it can be an int).

[Flix6x]

I thought about that, too, but I didn't find the use case particularly convincing. Is it a worthwhile extra feature, or just resolves an itchy asymmetry?

[nhoening]

The latter. But these things matter for user experience. I would expect these two to work the same.
And I believe we are not breaking existing settings here. Now is the cheapest time to do this.

[Flix6x]

Now is the cheapest time to do this.

I started implementing your request, but it turns out this is probably not true. The FLEXMEASURES_PLANNING_HORIZON is used in API versions 1.2 and 1.3, which allow retrieving schedules for multiple sensors in a single API call. That code assumes that the planning horizon is the same for all of these sensors, which with an integer FLEXMEASURES_PLANNING_HORIZON would no longer be the case. So this would currently require refactoring of already deprecated code.

I'd say it is cheaper to implement your request after these API versions are sunset.

[nhoening]

Sounds reasonable, can we make a ticket for version 0.14?

[Flix6x]

#586