Skip to content

GitLab

Closed
Created by Dan Jones@danjonOwner

MAS-DT Options for managing breaking changes in the schemas

As it stands we have:

  • in c2
    • backbone-plan-assistant (can be overridden with env var)
    • backbone-positions-adapter
  • in comms-backbone (the "homeless adapters")
    • ships-adapter
    • argo-adapter
    • hydrogen UI

all of which are currently pinned to the dev branch of the protocol.

The protocol is read when an instance of the adapter is created. I think that should mean it won't happen unless the containers are restarted but if it happens it will read the latest dev branch and will not be coded for the new messages should they exist.

Some of the MAS-DT proposed changes are significant breaking changes to the message structure.

Ultimately presumably we want to run MAS-DT on the /internal backbone sharing the same backbone with the other infra components.

In the short-term we could run a separate https://nucleus.noc.ac.uk/mas-dt backbone instance

Then do one of:

  1. Take a mas-dt branch of the protocol from dev and extend all changes from that branch
  • MAS-DT iterations would be branch names not versions
  1. Fork the backbone-message-format repo and version from there
  • This requires that we update the adapter classes to load the protocol from a different source
  1. Change the compiled path from projects/soar/swagger.json to something else
  • Same as option 2
  1. Make the code changes to pin all those things to v0.2.0
  • This stops them breaking with changes to the dev branch but doesn't mean we can run the new and old defs over the same backbone
  1. Make it clever enough to parse different messages using different versions of the schema.
  • This is a lot of work and the first thing we'd have to do is update the message header so the version field was a semver which would require updating all the current implementations to encode the semver into the messages
  1. Migrate
  • Make the changes to the c2 adapters and hydrogen.
  • Run a new instance of the backbone and hook up those things so we have old and new ingesting data
  • Build the new things against the new backbone
  • Migrate the old adapters over to the new backbone one by one
  • Switch off the old backbone

What else could we do:

  1. Not make any breaking changes to the schemas.
  • No semver in header (I suppose we could make it accept a float or a semver)
  • No GeoJSON
  • No primitive list (unless we leave region_of_interest and exclusion_zones and add the primitives list as well - making them all optional)
  • No action types
  1. Make the top-level message object a oneOf?
  • Requires a oneOf can have a default option if there's no discrimator present
  • We could do this as a temporary measure until all existing implementations have been migrated to the new schemas and then remove it.
  1. Do the work to pin all the running clients to a tagged version
  • Release current schema as v1.0.0
  • Make the schema changes on a mas-dt branch until all existing clients are pinned to v1.0.0
  • Make all the clients prefer a NUCLEUS_SCHEMA_VERSION env var
  • Make all the clients default to v1.0.0
  • Release MAS-DT changes as v2.0.0-beta.X
  • Release each changed message separately so refactoring clients to implement the new messages schemas can be done iteratively
  • Ultimately release all the reworked schemas for MAS-DT as v2.0.0
Edited by Dan Jones