Added endpoint /api/uptime/ for posting and getting uptime days from …#35
Added endpoint /api/uptime/ for posting and getting uptime days from …#35jnation3406 merged 11 commits intomainfrom
Conversation
…downtime database. It uses rise set and the semester bounds to take in a list of full or partial days and create or remove downtimes from them.
jashan-lco
left a comment
jashan-lco
left a comment
There was a problem hiding this comment.
Looks good for what I think it's trying to do. API feels very convoluted and designed for a very specific use case.
I still don't understand why we can't just have CRUD Uptime resources with simple start/end times and then do merging/complement logic with downtimes in a view at runtime or in the scheduler.
| """ | ||
| Modifies existing downtimes based on input uptimes on resources. | ||
|
|
||
| Takes output of UptimesSerializer and calculates the exact uptime windows using rise_set, then merges |
There was a problem hiding this comment.
Consider annotating the type annotation as such: list[UptimesSerializer]. Maybe one day type hints will work for Django.
|
|
||
| urlpatterns = [ | ||
| re_path(r'^$', DowntimeListView.as_view(), name='web-downtime-list'), | ||
| re_path(r'^api/uptime/', UptimeView.as_view(), name='uptime'), |
There was a problem hiding this comment.
Same as below, uptime-groups?
| telescope_info = configdb.get_telescope_info(uptime_group['site'], uptime_group['enclosure'], | ||
| uptime_group['telescope'], uptime_group['instrument_type']) | ||
| rise_set_site = { | ||
| 'latitude': Angle(degrees=telescope_info['latitude']), |
There was a problem hiding this comment.
What happens when this information is incorrect in configdb or changed? What's the process of getting a consistent view? Submit another request? Will that get rid of the downtime blocks created by the previous request or will those be "merged" into the new set?
There was a problem hiding this comment.
Hmm... On the one hand those values rarely change, but you are right that it is possible to change the hour angles associated with the telescope, which would vary its nighttime intervals. Again, these change very very rarely or not at all for most telescopes, but in the case that they did change within a semester with existing downtimes from this method, and then someone called this method again to delete one of those downtimes, then if the ha limit was grown (so the night interval was smaller), then it would leave a sliver of "uptime" outside the now current ha limit. In practice though this sliver shouldn't cause any problems downstream in our system since the new ha limits would prohibit scheduling or accepting new requests in those slivers of time, regardless of the lack of downtime there.
TLDR this could lead to slightly inconsistent uptimes/downtimes but I don't think it would break anything.
Yeah, I agree this is totally specialized for the AEON workflow, and for merging "uptime" definitions into our existing Downtime model. I thought a bit about creating a complement Uptime model, and then whenever someone requests Downtimes it merges both, but that felt like it would complicate the existing usage just to support this AEON use case so I thought it would be better to just shoe horn their use case into the existing Downtime model. There are some questions I had if we had both Downtime and Uptime models, like what do we do if they have competing views of the world defined for the same resource, i.e. downtime in one but uptime in another for the same time period? And also with a simple Uptime model that defines start/end intervals of uptime, we are still left with the problem of AEON only knowing the fraction of the day they want, and not specific start / end of night times for scheduling. |
Downtime takes precedence seems like the most conservative and safest option to me. |
When we are combining uptime + downtime, that means we are first taking the complement of uptime to get downtime, then combining downtime (from uptime) + downtime (from downtime). So what does downtime taking precedence mean in that case? I.e. if we have 1 day of uptime in the semester, then the rest of the semester is "downtime". But then if we also define a period of short downtimes surrounding a few days in the semester, that implies the time in between them is uptime. But if we combine the downtimes and uptime to get a total downtime, we would be left with only the uptime day. The only sensible thing I can think of is just having some restriction like for a resource and semester you can only define 1+ uptimes or 1+ downtimes but not both. But then the definition of using downtime or uptime for that resource and semester is based on what we create first for it which I don't like either. |
…d some more tests around getting uptimes
2 participants
…downtime database. It uses rise set and the semester bounds to take in a list of full or partial days and create or remove downtimes from them.
This API is intended for AEON use cases, to take in uptime "nights" in the format they prefer and calculate and create downtimes from that. It is a stepping stone to providing a full calendar UI to manage their instruments available nights.