score-compose
score-compose copied to clipboard
`service` resource type not supported
I have this score.file:
apiVersion: score.dev/v1b1
metadata:
name: store-front
containers:
store-front:
image: .
variables:
VUE_APP_ORDER_SERVICE_URL: "http://${resources.order-service.name}:3000/"
resources:
order-service:
type: service
But I'm getting this error while running score-compose generate:
Error: failed to provision: resource 'service.default#store-front.order-service' is not supported by any provisioner
I understand that service-port has been supported only for score-compose? But how to make sure that I have the same Score file compatible with score-compose and Humanitec?
In the meantime, like discussed with @astromechza, we could add a custom provisioner to support this:
- uri: template://static-service
type: service
outputs: |
name: <hostname>
This below is working:
- uri: template://service-provisioners/static-service
type: service
init: |
name: {{ splitList "." .Id | last }}
outputs: |
{{ $w := (index .WorkloadServices .Init.name) }}
name: {{ $w.ServiceName | quote }}
@astromechza, should we have this upstream in the default-provisioners?
@mathieu-benoit what is the definition of a "service"? does it just return a random hostname? What gets provisioned when we declare it?
The problem with the generic service is that we need to "match" it to a specific workload by name and convert that to the dns name for the workload. Then the port is more complicated because in score-compose we don't have a kube-proxy like in kubernetes so we can't use the service port, we have to translate the service port to a container port.
So in your example above, if the order service has:
service:
ports:
web:
port: 3000
targetPort: 9000
We need to actually translate your port 3000, into port 9000. This is why the "service port" exists in score-compose. In Humanitec, it targets Kubernetes, so it can use the port of the service, although no validation is done to check if the service actually has port 3000 declared.
(I'm converting this ticket to a feature request)
I think this service is to make sure we are compatible with Humanitec's behavior. As far as I understand it, it's doing "nothing", just echoing the name of the resource defined in the score file. The intent here is to make sure that 1 Score file could be used as-is for score-compose and humctl. If we could make another feature request internally for Humanitec to make this service more useful, let's chat about that internally?
Current thinking is that we're going to leave the service/service-port as they are and work towards a more general resource type to represent external service endpoints including any port or protocol information as needed. We'll work with Humanitec to include this as a default "resource definition" there.
Supported in the community provisioners: https://github.com/score-spec/community-provisioners, closing.