nasa / utm-apis

The collection of APIs for NASA's UTM project in the form of OpenAPI documents.
55 stars 35 forks source link

Add a GET /constraints/ API #133

Open jeremie-leproust opened 6 years ago

jeremie-leproust commented 6 years ago

https://github.com/nasa/utm-apis/blob/3189acdb3ce13dd64258cecb0e4f3c40c158a202/uss-api/swagger.yaml#L62

Should we add a GET /constraints/ API to retrieve the list of active or future constraints (UAS volume reservations)? This would allow a USS that comes online to query those for instance.

nasajoey commented 6 years ago

We do need a way to have for folks to GET current UVRs. It is a little confusing right now... this endpoint exists, but is only required to be implemented by those USSs with the public safety role. You can see the endpoint here: https://github.com/nasa/utm-apis/blob/386b5566e7fbd833a63a74e4d00aff08140b0a78/public-safety-uss/swagger.yaml#L229

The odd part is that you are not guaranteed to have any such USS in any given place at any given time, so there is no certain way to find someone to hit at this endpoint. And we didn't want every USS to be responsible to every other USS to provide such data (what if they are wrong or out of date?).

There may be a solution in GUD by forcing anyone announcing a new UVR to write it into all grids that are affected. Unclear on potential solution for traditional discovery.

This is something that has to be further discussed. Thanks for opening ticket to track it.

nasajoey commented 6 years ago

I've added this to the gridded platform as an issue. We can use that to determine solutions for other discovery approaches as well: https://github.com/wing-aviation/InterUSS-Platform/issues/39

jeremie-leproust commented 6 years ago

I am not sure I understand the following sentence:

And we didn't want every USS to be responsible to every other USS to provide such data (what if they are wrong or out of date?).

Why wouldn't a USS only return the UVRs he owns, just like it does for operations (USSs don't return flights owned by other USSs)?

nasajoey commented 6 years ago

You are correct in your understanding and that was the intent of the statement… we would only want a USS to supply the UVRs that it announced/manages. The issue comes back to how we guarantee that USS is always around while the UVR is in effect. If that USS is unreachable or doesn’t stick around for whatever reason, then the information about that UVR may not ever get to a newcomer USS.

Having the UVR data available through some other means than a USS (some dedicated service or reliable data store) is important.

jeremie-leproust commented 6 years ago

Oh I see. Isn't that the same anyway for missions owned by a USS? Whenever a USS (instance) operates a mission, then it needs to stay online and available. Could it be the same for UVRs?

nasajoey commented 6 years ago

Yes, that could be a requirement. We've seen issues in testing where this becomes more involved than expected, but it is indeed possible.