Create k8s_service_info library that replaces the SDI k8s-service interface

[DnPlas]

Context

The current implementation of the k8s-service relation interface for sharing Kubernetes Services info (svc name and port) is based on SDI. As we are moving away from SDI, a new library for handling this relation interface must be created and replaced where it is convenient.

NOTE: the documentation in the charm-relation-interfaces repository is incorrect, please refer to the SDI and the (archived) operator-schemas repositories for more information.

The proposal for tackling this task is to keep version 1 of the interface and work on a v2 that's handled entirely by a charm library, that way we are not forced to migrate all charms that use the old implementation all at once.

Old schema

v1:
  provides:
    type: object
    properties:
      service-name:
        type: string
      service-port:
        type: string
    required:
      - service-name
      - service-port

New schema

v2:
  provides:
    application-data:
      service-name:
        type: string
      service-port:
        type: string
    required:
      - service-name
      - service-port

Backwards compatibility

Although the schema will change slightly, the format of the shared data will be exactly the same to avoid compatibility issues. To keep things compatible with v1, we could have a decorator that shares the data in the old schema if we notice that the requirer charm is using the old version, that way it's easier to migrate.

What needs to get done

1. Write the library
2. Verify the upgrade story is covered for charms that will migrate from v1 to v2
3. Write unit and integration tests
4. Create a v2 in charm interface repo

Definition of Done

The library can be fetched and used in any provider/requirer charm.

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5304.

This message was autogenerated

[ca-scribner]

A few notes that came up while reviewing this/the PR:

The old schema cited above is correct in that thats how it is specified to SDI, but SDI nests the data a bit more in the relation. I think a more comparable v0 schema is this:

provides:
  application-data:
    data:  # <-- the attribute that SDI puts all its relation data in
      service-name
        type: string
      service-port:
        type: string

required:
  - service-name
  - service-port

A few places in the original issue here say v0 is the original (SDI) schema and v1 is the new one proposed, but others say v1 is SDI and v2 is the new one. We should settle on one numbering scheme to avoid confusion

[DnPlas]

A few places in the original issue here say v0 is the original (SDI) schema and v1 is the new one proposed, but others say v1 is SDI and v2 is the new one. We should settle on one numbering scheme to avoid confusion

I have change the description to correct this confusion. The current SDI version will be v1 and the newer implementation will be v2.