Support multiple cohorts per AnyVLM node

[jennifer-bowser]

Feature description

We initially built AnyVLM to support one cohort per AnyVLM node for the sake of expediency in order to meet our MVP 1.0 deadline. However, we'd like to support multiple cohorts per node.

This will probably involve the following:

• Create a new table in our AnyVLM database to save cohort info. The info we need to capture includes the following fields defined in src/anyvlm/schemas/vlm.py:
  • HandoverType.id
  • HandoverType.label
  • BeaconHandover.url
  • Meta.beaconId <= As James pointed out below, this one actually is a node-level identifier rather than being specific to a data source, so we don't need to worry about this one here.
• Create HTTP endpoints + CLI handlers + underlying functions to ADD cohort info to the new table
• Create HTTP endpoints + CLI handlers + underlying functions to RETRIEVE cohort info from the new table
• Modify our CAF data ingestion to capture the above cohort information
• Modify our CAF data pull functionality to return the above cohort information
• Modify our logic that builds our VlmResponse objects so that the fields listed above are created dynamically instead of being pulled from environment variables.
  • Note that this will involve updating how the VlmResponse is constructed in build_vlm_response.py to allow for multiple BeaconHandover entries in the VlmResponse.beaconHandover list field.
    • This means we'll also need to update the tests in test_build_vlm_response.py accordingly

NOTE: We'll finalize exactly what needs to be done here when creating sub-tickets for this epic (which we'll do after our MVP release is complete)

Use case

Our Product Requirements Document and the VLM API spec require support for results from multiple cohorts.

Acceptance Criteria

• AnyVLM captures the required cohort information when ingesting CAF data (see above for the list of required fields)
• AnyVLM returns the required cohort information when retrieving CAF data

Proposed solution

No response

Alternatives considered

No response

Implementation details

No response

Potential Impact

No response

Additional context

No response

Contribution

None

[jsstevenson]

I (wrongly?) interpreted beaconID as representing something about the identity of the instance itself, and beaconHandover as describing something about some data that it contains. I would think the beaconID would be constant regardless of what kind of data happens to be returned for a request (i.e. maybe should be set per-instance via env var rather than live in a DB).

[jennifer-bowser]

Oh, good point! I've updated the ticket accordingly.