GitLab

Closes #62 (closed)

changed milestone to %CB-2024W35

added Partner::NOC Project::MAS-DT Status::Sprint Priority Weight::3 labels

removed Status::Sprint Priority label

added Status::In Progress label

added 2 commits

• 1f8b9b01 - feat: instruction_set payload schema and example
• 16b4dd1a - chore: lint with black

Compare with previous version

added 2 commits

• 1701c174 - feat: add instructions to planning_configuration
• 158c7f72 - chore: lint with black

Compare with previous version

marked this merge request as ready

added 2 commits

• d2171080 - feat: add parameter values to instruction set
• e67d303e - chore: lint with black.

Compare with previous version

deleted the 70-refactor-geojson-loading-for-serving-from-nucleus branch. This merge request now targets the 67-mas-dt branch

added 34 commits

• e67d303e...52334de6 - 28 commits from branch 67-mas-dt
• 9717d7b8 - feat: instruction_set payload schema and example
• f5f01deb - chore: lint with black
• 41b3bbd9 - feat: add instructions to planning_configuration
• 50defa33 - chore: lint with black
• cd46d487 - feat: add parameter values to instruction set
• bc796ed1 - chore: lint with black.

Compare with previous version

added 1 commit

• 9f75c458 - refactor: update configuration with primitives

Compare with previous version

added 10 commits

• 9f75c458...795b55a6 - 3 commits from branch 67-mas-dt
• 5c3376af - feat: instruction_set payload schema and example
• 36e656e2 - chore: lint with black
• e13334ba - feat: add instructions to planning_configuration
• 8fc55010 - chore: lint with black
• f204618e - feat: add parameter values to instruction set
• 3a798223 - chore: lint with black.
• b2d333af - refactor: update configuration with primitives

Compare with previous version

added 1 commit

• 3d721254 - docs: add changelog for instruction set message

Compare with previous version

added 1 commit

• b0bea3fa - chore: update soar swagger compiled schema

Compare with previous version

added 14 commits

• b0bea3fa...eec6dc80 - 5 commits from branch 67-mas-dt
• a428a7c8 - feat: instruction_set payload schema and example
• bd027561 - chore: lint with black
• d962cb1c - feat: add instructions to planning_configuration
• 8c7e0a4a - chore: lint with black
• 2ef724e7 - feat: add parameter values to instruction set
• 096141f3 - chore: lint with black.
• d2d74785 - refactor: update configuration with primitives
• da17d70c - docs: add changelog for instruction set message
• 27ab11cb - chore: update soar swagger compiled schema

Compare with previous version

added 12 commits

• 27ab11cb...ee5e43ba - 3 commits from branch 67-mas-dt
• 370ed1a8 - feat: instruction_set payload schema and example
• 4c464dde - chore: lint with black
• d6da9ae8 - feat: add instructions to planning_configuration
• 43e19e45 - chore: lint with black
• 71fc6f3d - feat: add parameter values to instruction set
• e6fe49a8 - chore: lint with black.
• ca63ff17 - refactor: update configuration with primitives
• f0d0b460 - docs: add changelog for instruction set message
• b33bb4f7 - chore: update soar swagger compiled schema

Compare with previous version

added 1 commit

• 30e1c2bc - chore: update example planning_configuration

Compare with previous version

added 12 commits

• 30e1c2bc...95cfc66d - 3 commits from branch 67-mas-dt
• 0a22a2ac - feat: instruction_set payload schema and example
• 46d5c8b7 - chore: lint with black
• f06083bb - feat: add instructions to planning_configuration
• 521d103e - chore: lint with black
• 7fc0da98 - feat: add parameter values to instruction set
• ff28e576 - chore: lint with black.
• 5e33d5a4 - docs: add changelog for instruction set message
• aeea18c8 - chore: update soar swagger compiled schema
• da426240 - chore: update example planning_configuration

Compare with previous version

requested review from @trishna

resolved all threads

approved this merge request

mentioned in commit 4fd9f7f1

merged

Ah! I don't know how I missed this before, but there's no platform_ID in the payload like there is with mission plans! In testing I was adding my own platform_ID to the messages without thinking of the fact it's not there.......

It's implied from the destination topic, slocum.unit_111 -- so I can work around that in sfmc-adapter (extract from destination when platform_ID is missing) for now but I think these messages probably do need platform_ID

Oh crap yeah. That's not right is it? I was hoping that they could just send the instruction set payload from the planning_configuration unaltered which kinda makes sense for MAS-DT/MOGli where there is only one glider but doesn't work in the general case.

We could make the instruction_set a sub-schema within something like a platform_instruction_set message so they build the message payload with the platform_ID and then just attach the pre-defined instruction_set?

So:

{
 "payload": {
  "message_type": "platform_instruction_set",
  "platform_ID": "unit_111",
  "instruction_set": {...}
 }
}

?

That'd work. imo I think it's simpler to just add platform_ID to the instruction sets themselves, it's not onerous to add a field to a bit of JSON being sent. Plus they still need to build up the destination string when publishing the message, right? (So already doing the work of knowing what glider to send it to etc)

Up to you. If you stick to the structure above I can quickly add in some code on sfmc-adapter side to handle platform_instruction_set. Alternatively, if adding platform_ID to instruction_set as-is, I've already updated it to handle that, and falling back to getting platform ID from the destination topic when that doesn't exist. So it'll work as-is as long as they publish to the right channel.

I think the reason I was thinking about the sub-schema is that we can't specify the platform_ID in the version we send in the planning_configuration.instructions so if it's the same thing then the platform_ID can't be required. Whereas if I make it a section within the message payload then the platform_ID in the message can be a required field.