Just like resources have metadata.annotations today, there is need to support the same concept formally on the workload metadata as well. This will allow us to pass kubernetes-style annotations through to the destination runtime.

For score-compose, these would be labels, while for score-helm and score-humanitec these would be annotations on the final deployment objects. Since this is just metadata it can also be ignored without affecting the functionality of the workload.

metadata:
  name: my workload
  annotations:
    example.com/my-annotation: value

This should carry the same specification as resource.metadata.annotations.

There are a number of locations in the schema where 'number' is used rather than 'integer' in the port bindings:

• service.ports.port
• service.ports.targetPort
• $defs.httpProbe.port

This usually doesn't show up as a problem but it might when validation allows port numbers like 33.3333 to pass validation, but may cause failures when converted into docker compose, helm, or other destination container types.

I'd like to propose that we change these to integers!

All implementations of score Service assume the port is required, and will default the targetPort if not provided. This is the same as both Humanitec and the underlying K8s implementation. Score-compose and score-humanitec do the same.

The score documentation also lists port as required and target port as optional.

However the spec lists this the other way around. To avoid breaking customers that have workloads defined with just port right now, we need to fix this in the spec.

The score website indicates

However the API spec does not support these fields.

"ports": {
  "description": "List of network ports published by the service.",
  "type": "object",
  "minProperties": 1,
  "additionalProperties": {
    "description": "The network port description.",
    "type": "object",
    "required": [
      "targetPort"
    ],
    "additionalProperties": false,
    "properties": {
      "port": {
        "description": "The public service port.",
        "type": "number"
      },
      <--- missing --->
      "targetPort": {
        "description": "The internal service port.",
        "type": "number"
      }
    }
  }
}

This means validators may reject these fields if provided, and implementation behavior or failure may be unpredictable. However hostIP is also not a real field used by any score implementations just yet so that should be removed.

I'd like to propose we fix this by adding protocol to the spec, and removing hostIP from the docs.