score-spec / spec Goto Github PK

Detailed description

It would be ideal to support the command, tcpSocket and grpc methods for livenessProbe and readinessProbe.

Context

Today, only the httpGet method for livenessProbe and readinessProbe is supported.

command is another very popular method, like illustrated here with grpc apps: https://github.com/GoogleCloudPlatform/microservices-demo/blob/main/release/kubernetes-manifests.yaml#L61.

So for example, today, this below is not supported:

apiVersion: score.dev/v1b1
metadata:
  name: adservice
containers:
  adservice:
    image: gcr.io/google-samples/microservices-demo/adservice:v0.6.0
    variables:
      PORT: "9555"
    livenessProbe:
      exec:
        command:
          - /bin/grpc_health_probe
          - '-addr=:9555'
    readinessProbe:
      exec:
        command:
          - /bin/grpc_health_probe
          - '-addr=:9555'

Possible implementation

Humanitec already supports tcpSocket and command in addition to httpGet.

Note: gRPC (only supported since Kubernetes 1.24+) is not yet supported in Humanitec. The alternative is to use the command method by using the grpc_health_probe binary.

Additional information

Configure Liveness, Readiness and Startup Probes in Kubernetes.

Problem

Humanitec services quite often use self-references in values substitution patterns.
For example ${modules.my-service.service.name}.

At present there is no proper way to express self-references in Score spec.

Proposed Solution 1

Add support for self-references in form of ${workload.name}.
Full set of available workload properties in to be discussed.

Proposed Solution 2

Introduce a notion of context that then could resolve different properties based on CLI implementation.
For example it could be ${context.service.name}.

Disadvantage is that it seems very confusing to the User where this context comes from.
Score file translated long before the deployment takes place, so any useful (dynamic) information, such as target environment name, is not available at this stage.

Proposed Solution 3

Reference any information available in metadata section: ${metadata.name}.
This could be useful for other properties and labels added into metadata section in the future too.

Possible Workaround 1

The value pattern can be escaped in sore spec. E.g. $${modules.service-name.service.name}.

While this would result in a valid value reference for Humanitec, e.g. ${modules.service-name.service.name}.

It would make no sense for other target platforms (Compose or Helm).

Possible Workaround 2

It is possible to declare a resource (of type: workload) with the same name as the workload itself, e.g. my-service.

score-humanitec could then convert resources references, such as ${resources.service-name.service.name} into proper values references, e.g. ${modules.service-name.property}.

However this would not work on other platforms. For example score-compose would create a dependency on my-service (self) which is an invalid circular dependency reference.

Implement an open-source GitHub action that adds a Score implementation CLI (such as score-helm) to a teams CI toolset. This allows to execute Score automatically and possibly trigger deployments directly from a CI pipeline.

This works and it shouldn't (look at the protocol)

apiVersion: score.dev/v1b1
metadata:
  name: frontend
containers:
  frontend:
    image: nginx:alpine
service:
  ports:
    www:
      port: 80
      protocol: Godzilla-growls-angry
      targetPort: 80

Translates with score-helm to:

containers:
  frontend:
    image:
      name: nginx:alpine
service:
  ports:
    - name: www
      port: 80
      protocol: Godzilla-growls-angry
      targetPort: 80
  type: ClusterIP

This also "works"

apiVersion: score.dev/v1b1
metadata:
  name: frontend
container-with-massive-angry-typo:
  frontend:
    image: nginx:alpine
service:
  ports:
    www:
      port: 80
      protocol: Godzilla-growls-angry
      targetPort: 80

Outputs this:

containers: {}
service:
  ports:
    - name: www
      port: 80
      protocol: Godzilla-growls-angry
      targetPort: 80
  type: ClusterIP

And it doesn't error at all, there is no validation as it exists with 0 status

Detailed description

Sometimes it is neccesary to specialise a resource beyond just the type. For example, one workload might need an externally accessible s3 bucket and another might require one that is encrypted and only accessible to specific riles to store sensitive information.

Context

The class property allows developers to specialise the resource type. The concept is modelled on Kubernetes Storage Classes and works similarly. For example the workload that needs an externally accessible workload might set the class to external while the workload that requires an encrypted bucket might have a class of sensitive.

Example:

...
resource:
  external-bucket:
    type: s3
    class: external

Possible implementation

The score spec needs to be updated to include a class property in the resource object. The value of the class must be a valid ID, i.e. satisfy this regex: ^[a-z0-9]+(?:-[a-z0-9]+)*$

Detailed description

Using an emptyDir Volume via my Score manifest is not supported today.

Context

Here is my Score manifest:

apiVersion: score.dev/v1b1
metadata:
  name: nginx
containers:
  nginx:
    image: nginxinc/nginx-unprivileged:latest
    volumes:
    - source: ${resources.tmp}
      target: /tmp
resources:
  tmp:
    type: emptyDir

I can deploy it in Humanitec, but there I'm getting this error attached:

Possible implementation

The associated Humanitec manifest generated has:

        "externals": {
          "tmp": {
            "type": "emptyDir"
          }
        }

I can see that there is a difference if I add this emptyDir via the UI where this section is instead under:

        "volumes": {
          "tmp": {
            "type": "emptyDir"
          }
        }

Additional information

Score specification reference - Reserved resource type.

Description

When an user is clicking on the in "https://score.dev/get-started" page, the mailing texts, it doesn't redirects us to mailbox, emailjs needs to be implemented.

Expected behavior

When an user is clicking on the in "https://score.dev/get-started" page, the mailing texts, it should redirect us to mailbox

Steps to reproduce

1. Go to the deployed site
2. Then move to "Get Started" Page -https://score.dev/get-started
3. Click on the Contact us texts
4. It doesn't redirect us

Screenshots

Context

I was trying to mail

Additional information

No response

Provide bash one-liner install script to simplify the installation of Score CLIs.

We need to come up with proper commands names for all CLI tools that would be also proper to the context. Currently we are using a single command named run.

Some suggestions could be:

• export or convert command to create a target compose YAML, Helm values file, or Humanitec deployment draft
• deploy to trigger Humanitec deployment
• lint to validate input SCORE file and all other settings. Or, may be, introduce --dry-run flag instead.

Some CLI tools to check for reference:

• https://docs.docker.com/engine/reference/commandline/compose/#child-commands
• https://helm.sh/docs/helm/

Detailed description

This is more of a “we should think about this” rather than a bug, an annoyance so low importance at this point

In score, if you’d like to configure files for your container you do

    files:
      - target: /etc/loki/loki-config.yaml
        mode: "644"
        content:
          - |
            auth_enabled: false
            xxx

This is good, however…

I have files that are 2-3k lines.

Could we possibly have the option to do:

files:
 - target: /etc/loki/loki-config.yaml
 mode: "644"
 source: files/loki-config.yaml

Provide the option to add resource inputs as hints for dependancies defined in score.yaml. These hints are optional and don’t have to be honoured. Depending on the use case, resource inputs can be consumed by the platform in a target environment. Example use cases: Define extensions in a Postgres database or specify the required replicas in a HPA resource.

What would you like to share?

Trying to join the Score slack. However the join link found both on the score website and the README of this repo just resolve to a page informing you that the invite link is no longer active. Would like to join the score slack!

Additional information

No

Detailed description

• Deprecate resource properties
• Remove from documentation

Context

Resource properties were added to the Score spec as an option for users to implement validation. Since they aren't utilised by any of the current CLIs and have caused confusion with users did we decide to deprecate them.

Possible implementation

Mark as deprecated

Additional information

No response

Allow to specify resource annotations as a way of adding additional meta data to a resource dependency. This can be used to specify whether a resource is shared in the context of score-humanitec for example

If I do the following:

apiVersion: score.dev/v1b1
metadata:
  name: frontend
containers:
  frontend:
    image: nginx:alpine
service:
  ports:
    www:
      port: 80
      protocol: TCP
      targetPort: 80

It translates to helm values correctly like so:

containers:
  frontend:
    image:
      name: nginx:alpine
service:
  ports:
    - name: www
      port: 80
      protocol: TCP
      targetPort: 80
  type: ClusterIP

How it does not translate correctly to compose:

services:
  frontend:
    image: nginx:alpine
    ports:
      - target: 80
        published: "80"
        protocol: TCP

Becuase in compose the protocol needs to be specified in lower case, otherwise it fails.

Detailed description

We want to implement an overrides flag which can be used as an alternative to the currently existing overrides file

Context

The feedback we received here was the following: "To specify overrides via your CI pipeline you need to create an overrides file which feels tedious given that in a lot of cases you just want to change the image."

Possible implementation

example: https://cosmosis.readthedocs.io/en/latest/reference/cosmosis_command_line.html#overriding-parameter-files

Additional information

No response

I'm interested as to how Score relates to the OAM (Open Application Model) specification? I've read the spec for both and can't help but notice the similarities and the paradox of both attempting to be the "One YAML to rule them all". I'm a big fan of the concept of having an application specification which is abstracted from the implementation (promise theory etc) but having multiple API specifications for this seems to be problematic from where I'm standing (please don't take the image the wrong way but it was the first thing which came to mind).

I'd be more than happy if you could explain why my initial observations are incorrect or how the nuances which I've missed make this less black and white? My current position on all of this is that I probably need to build my own abstraction as there isn't either a well established solution or a community consensus for establishing one (ironic given the image above right).

Set up Microsoft package manager (e.g. Chocolatey, Scoop) to simplify the installation and management of Score implementation CLIs.

Set up Mac package manager (e.g. HomeBrew) to simplify the installation and management of Score implementation CLIs.

Currently, if I write a bad flag - the CLI will complain about that, so I’ll fix it. Then I’ll rerun my command and the CLI will complain about the next error message. Is it possible to stack error messages? For example: Error: unknown flags: --org, --env, --deploy.

Description

In the score reference docs, containers section, the livenessProbe and readinessProbe doce do not match the example.

The spec section I refer to is as follows:

livenessProbe: ContainerProbeSpec
  scheme: string
  host: string
  port: int
  path: string
  httpHeaders:
      name: string
      value: string
readinessProbe: ContainerProbeSpec
  scheme: string
  host: string
  port: int
  path: string
  httpHeaders:
      name: string
      value: string

The description refers to an element called httpGet, which appears not to exist? It is almost like it is implicit, but if so, is there any value in mentioning it at all?

Also half of the other keys are not mentioned in the description. They might be self-explanatory, but it would be good to know which are optional and which are required.

Context

No response

Additional information

No response

Define JSON schema for the score spec to make sure that users are aware of which properties are supported and whether these are optional or required. This could be put into practice via a VS Code extension, a lint command line flag or similar.
Note: Should be stored in docs repo.