-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[uss_qualifier] move SCD dss-specific scenarios to DSS subdir #559
[uss_qualifier] move SCD dss-specific scenarios to DSS subdir #559
Conversation
c0b4223
to
ba9795c
Compare
|
||
[`IDGeneratorResource`](../../../../resources/interuss/id_generator.py) providing the operational intent reference IDs for this scenario. | ||
|
||
### planning_area |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is the right conceptual resource to use. The thing we want when the PUT calls are made is the information for an actual operational intent, and I think that's best provided via a flight intent. A planning area is an area in which flights might be planned and it would be very unlikely that a flight would take up the entire planning area. Even if it's programmatically valid, I don't think we want to set a conceptual example to equate an operational intent's extents with a planning area.
As a side note, it looks like we should be using more of the flight intent information that we are instead hardcoding -- e.g., the op intent state is hardcoded to Accepted even though the provided flight intent may indicate InUse rather than Planned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an important point.
I opted for often not using the flight intents as requirements about authentication, synchronization and proper handling of interactions seem like they can be comprehensively checked with relatively simple areas, and we can programmatically make sure to cover every possible state of an OIR.
Flight intents seem to come with some machinery that is often not strictly required (although I'd need to double-check that impression), possibly we could introduce another kind of resources that represents a realistic operational intent volume?
(The motivation for removing the flight intents here was to end up with a relatively simple configuration for probing only a DSS. However that's not a hard requirement)
In the present case, I'll revert to the previous version of the scenario but keep the move to the dss
subdirectory
045d264
to
94fba8a
Compare
Reverted to use the flight intents, and the OIR state is now read from them. |
46b1e65
to
0541b05
Compare
a95648f
to
b372d0a
Compare
b372d0a
to
9171f7d
Compare
Scope of the PR has been reduced to simple move of files. |
[uss_qualidier] move dss-specific test scenarios to the dss subdirectory 1ca6a5b
More recent dss-specific scenarios have all been added to the dss subdir. This PR moves these scenarios there too:
OpIntentReferenceAccessControl
DSSInteroperability