Skip to content

[CI/mock_uss] Add optionnal 'modification of activated flight' behaviour #1290

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.

Sign up for GitHub

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

Draft
the-glu wants to merge 1 commit into
base: main
Choose a base branch
from
+40 −4
Draft

[CI/mock_uss] Add optionnal 'modification of activated flight' behaviour #1290

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions .github/workflows/monitoring-test.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,9 @@ jobs:
name: ${{ inputs.name }} test
permissions:
contents: read
strategy:
matrix:
behaviour_activated_flights_editables: [true, false]
steps:
- name: Job information
run: |
Expand All @@ -36,20 +39,20 @@ jobs:
- name: Load monitoring image
uses: ./.github/actions/load-image
- name: Run ${{ inputs.name }} test
run: ${{ inputs.script }}
run: export MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE=${{ matrix.behaviour_activated_flights_editables }} && ${{ inputs.script }}
- name: Save containers and tracer logs as artifact
if: always()
uses: actions/upload-artifact@v5
with:
name: monitoring-test-${{ inputs.name }}-logs
name: monitoring-test-${{ inputs.name }}-${{ matrix.behaviour_activated_flights_editables }}-logs
path: |
logs
monitoring/mock_uss/output
- name: Save USS qualifier reports as artifact
if: always()
uses: actions/upload-artifact@v5
with:
name: monitoring-test-${{ inputs.name }}-reports
name: monitoring-test-${{ inputs.name }}-${{ matrix.behaviour_activated_flights_editables }}-reports
path: |
monitoring/uss_qualifier/output
monitoring/prober/output
9 changes: 9 additions & 0 deletions monitoring/mock_uss/config.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,9 @@
KEY_DSS_URL = "MOCK_USS_DSS_URL"
KEY_BEHAVIOR_LOCALITY = "MOCK_USS_BEHAVIOR_LOCALITY"
KEY_CODE_VERSION = "MONITORING_VERSION"
KEY_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLES = (
"MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE"
)


import_environment_variable(
Expand All @@ -27,3 +30,9 @@
import_environment_variable(KEY_DSS_URL, required=False)
import_environment_variable(KEY_BEHAVIOR_LOCALITY, default="US.IndustryCollaboration")
import_environment_variable(KEY_CODE_VERSION, default="Unknown")

import_environment_variable(
Copy link
Contributor

@mickmis mickmis Nov 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BenjaminPelletier IIRC during the InterUSS weekly several weeks ago, when we talked about #1276, you mentioned something about having some structure to alter the behavior of the mock USS, and I believe you suggested an approach. If so, is that it?

Copy link
Member

@BenjaminPelletier BenjaminPelletier Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can think of a few ways to select different behavior for mock_uss:

  1. Have a different mock_uss instance for each behavior
  2. Change mock_uss behavior for each test (or particular tests) at runtime/test time
  3. mock_uss selects a different behavior automatically based on some characteristic of the interactions

Currently, I think we have some combination of 1 and 2. Some configuration parameters are set per instance; see all MOCK_USS_* values in docker-compose.yaml. Some configuration is set according to locality. Locality is essentially a collection of behaviors/configuration settings. It's called a locality because the largest normal source of USS behavior variations is typically between jurisdictions/localities (e.g., U-space in Switzerland versus UTM Implementation in US). We currently set locality via "dynamic configuration" (API call to change locality) which is why it's in bucket 2, but I think it would be far better to automatically select a locality based on the geographic area in which actions were occurring (bucket 3) since this is more stateless and more similar to how real USSs would behave.

I don't think bucket 1 is a very good idea because it's difficult to manage and keep track of more mock_uss instances. So, I'm not a huge fan of configuring via environment variable since that's effectively configuring via mock_uss instance.

"Locality" is perhaps not an optimal word for "bundle of configurable behaviors", but I think the idea of a single place where configurable behaviors are selected together is still a good one. And, since the strongest candidate for bucket 3 is selecting via geography (and that's the place configuration selection will most likely be done by real USSs), I think "locality" is probably still a decent name for a bundle of configurable behaviors.

In the long term, I think the ideal outcome would be that a mock_uss is brought up with a configuration that specifies multiple configuration bundles (renamed from "localities") and their geographic bounds. Then, tests are conducted in the appropriate geographic areas for the expected outcomes. There would be no need for changing locality at runtime and probably some (but not all) of the MOCK_USS_* parameters would be moved into configuration bundles (especially auth spec, DSS URL, and public key). In this case, we would have a variant locality that looks like another standard locality, but with the different editable-flight behavior.

I'm open to what should be done in the meantime, but I'm not a huge fan of going down the "configuration per instance" route as configuration via environment variable implies.

Copy link
Contributor Author

@the-glu the-glu Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using locality seems a good option, I do have a few questions:

I think we want to be able to also have different behaviors in a same 'geographical location', e.g. to validate that interactions with two different USS is producing expected results. Would that be doable with locality settings or this is something that need to be adapted?

I also think that having a 'bad uss', that don't produce expected result, allowing a (specific) test suite to verify that tests fails as expected to would be a good idea, would you also use a locality in that case?

KEY_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLES,
default="true",
mutator=lambda s: s.lower() == "true",
)
9 changes: 9 additions & 0 deletions monitoring/mock_uss/docker-compose.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ services:
- MOCK_USS_INTERACTIONS_LOG_DIR=output/scdsc_a_interaction_logs
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand Down Expand Up @@ -52,6 +53,7 @@ services:
- MOCK_USS_SERVICES=scdsc,versioning,flight_planning
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand All @@ -78,6 +80,7 @@ services:
- MOCK_USS_SERVICES=geoawareness
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand Down Expand Up @@ -109,6 +112,7 @@ services:
- MOCK_USS_RID_VERSION=F3411-22a
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand Down Expand Up @@ -141,6 +145,7 @@ services:
- MOCK_USS_RID_VERSION=F3411-22a
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand Down Expand Up @@ -173,6 +178,7 @@ services:
- MOCK_USS_RID_VERSION=F3411-19
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand Down Expand Up @@ -205,6 +211,7 @@ services:
- MOCK_USS_RID_VERSION=F3411-19
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand Down Expand Up @@ -240,6 +247,7 @@ services:
- MOCK_USS_SERVICES=tracer
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand Down Expand Up @@ -274,6 +282,7 @@ services:
- MOCK_USS_INTERACTIONS_LOG_DIR=output/scdsc_interaction_logs
- MOCK_USS_PORT=80
- MOCK_USS_PROXY_VALUES=x_for=1,x_proto=1,x_host=1,x_prefix=1,x_port=1
- MOCK_USS_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLE
expose:
- 80
ports:
Expand Down
4 changes: 4 additions & 0 deletions monitoring/mock_uss/scd_injection/__init__.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
from monitoring.mock_uss.app import require_config_value
from monitoring.mock_uss.config import KEY_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLES

require_config_value(KEY_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLES)
13 changes: 12 additions & 1 deletion monitoring/mock_uss/scd_injection/routes_injection.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,10 @@

from monitoring.mock_uss.app import require_config_value, webapp
from monitoring.mock_uss.auth import requires_scope
from monitoring.mock_uss.config import KEY_BASE_URL
from monitoring.mock_uss.config import (
KEY_BASE_URL,
KEY_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLES,
)
from monitoring.mock_uss.dynamic_configuration.configuration import get_locality
from monitoring.mock_uss.f3548v21 import utm_client
from monitoring.mock_uss.f3548v21.flight_planning import (
Expand Down Expand Up @@ -178,6 +181,14 @@ def unsuccessful(
except PlanningError as e:
return unsuccessful(PlanningActivityResult.Rejected, str(e))

if (
not webapp.config[KEY_BEHAVIOUR_ACTIVATED_FLIGHTS_EDITABLES]
and old_status == FlightPlanStatus.OkToFly
Copy link
Contributor

@mickmis mickmis Nov 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that rather we want to check whether the area (existing_flight.flight_info.basic_information.area) has not changed if the old status is OkToFly.

Copy link
Contributor Author

@the-glu the-glu Nov 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we? Because if that the case, I would rename the flag to ACTIVATED_FLIGHTS_AREA_EDITABLE then, would it be ok?

Copy link
Contributor

@mickmis mickmis Dec 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because a state change is still OK when the status is OkToFly (e.g. going contingent). From what I've seen, the USSs not supporting modifications don't support modification of the definition of the flight plan when it is in flight. But the status can still change.

I would rename the flag to ACTIVATED_FLIGHTS_AREA_EDITABLE then, would it be ok?

Sounds reasonable

):
return unsuccessful(
PlanningActivityResult.NotSupported, "Unable to modify an activated flight"
)

step_name = "performing unknown operation"
notes: str | None = None
try:
Expand Down
Loading