V2

[gabor-lbl]

V2 changes. It's up to the facility handle putting and processing tasks on separate queues for v2 functionality.

[gabor-lbl]

Here it is running at NERSC: https://api.iri.nersc.gov/api/v2

[gabor-lbl]

I had to make docs_url and openapi_url unique so we could serve them at the same time. For some reason path rewriting in the ingress rules did not work for me.

[gabor-lbl]

The nersc implementation uses redis-queues for the MQ. For v2, the queue name is: QUEUE_NAME = f"worker_{config.API_VERSION_SHORT}" and the consumer is started with: rq worker worker_v2.

[juztas]

I think we need to rethink the directory structure for the Python reference implementation. As we might evolve soon from V1 -> V2 -> V3..., we need to split core functionality from semantics (and all versions should share the same implementation).

If we organize by version: api/v1 and api/v2 - we will end up breaking the "contract" for users, and force everyone to move soon. That might also lead to code duplication. This is where I think we need to change the Py directory structure. For example, current structure:

app/
  routers/
    account/
      account.py
      facility_adapter.py
      models.py
    compute/
      ...
    facility/...
    filesystem/...
    status/...
    task/...
  types/
  apilogger.py
  config.py
  main.py
  demo_adapter.py

While I think this would be cleaner solution:

app/
  routers/
    v1/
      account/
        account.py
        facility_adapter.py
        models.py
      compute/
        ...
      facility/...
      filesystem/...
      status/...
      task/...
    v2/   -> Only NEW V2 FEATURE GOES HERE
      compute/
        compute.py
        facility_adapter.py
        models.py
    v3/... -> Only NEW V3 FEATURE GOES HERE
    v4/... -> Only NEW V4 FEATURE GOES HERE
  types/
  apilogger.py
  config.py
  main.py
  demo_adapter.py

There will be some corner cases (like error_handler), and this would need to be dynamic (not static as is right now). Also, note an important caveat: v2 for compute does not clone all v1 functionality; it only adds new features. In this case v1 remains untouched, and v2/v3/v4 can be implemented on their own timelines and readiness level.

[juztas]

Here is vibe coded split: #84 for v1/v2

[gabor-lbl]

Similar to your #84, here is mine: #85

[gabor-lbl]

I think both approach has pros/cons. Where the common codebase fails is supporting the same api doing different things in different versions.

We also need to think about the swagger experience. Currently, docs are under / which doesn't support different versions. In my (#85) approeach I have docs under /api/v1 and /api/v2 and the super-app has no docs.