Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Readiness probes for endpoints #168

Closed
sleshchenko opened this issue Oct 13, 2020 · 1 comment
Closed

Readiness probes for endpoints #168

sleshchenko opened this issue Oct 13, 2020 · 1 comment
Labels
area/api Enhancement or issue related to the api/devfile specification

Comments

@sleshchenko
Copy link
Member

sleshchenko commented Oct 13, 2020

Is your feature request related to a problem? Please describe.
Devfile component's is able to describe an endpoint that is supposed to expose some service.
A user may be interested in the endpoints state ( if services behind them) are available or not to:

  • do not open plugin's endpoint (Theia) when it's not available;
  • do not open container endpoints, after command which lauch server is run but before server is fully started;

Describe the solution you'd like
The plugin is able to declare a readiness probe for its endpoints. So, the implementation (odo, devworkspace operator) is able to evaluate endpoint info and expose it if needed.

components:
  - name: "mycontainer"
    container:
      image: "busybox"
      memoryLimit: "128M"
      mountSources: true
      endpoints:
        - name: term-websockets
          exposure: public
          protocol: ws
          attributes:
            type: terminal
          targetPort: 4000
          readinessProbe:
            path: /readiness
            periodSeconds: 3 # ?
            failureThreshold: 3 # ?
            # ?something else?

If it's the main devworkspace endpoint - workspace is not going to be marked as Running until that endpoint readiness probe passed.

It even may make sense to introduce liveness probe as well, if endpoint lifecycle bound to container lifecycle, user may want to have container automatically restarted when liveness is failed.

Describe alternatives you've considered
Probably one probe per container can be enough, if so - we can reuse K8s interface here:

  containers:
  - name: cache-server
    image: cache-server/latest
    readinessProbe:
      httpGet:
        path: /readiness
        port: 8888
      initialDelaySeconds: 300
      periodSeconds: 30

Additional context
N/A

@michael-valdron
Copy link
Member

The readinessProbe can now be set with container-overrides:

attributes:
    container-overrides:
        readinessProbe:
            httpGet:
                path: /readiness
                port: 8888
            initialDelaySeconds: 300
            periodSeconds: 30

With this being the case, I feel that this issue can be closed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Enhancement or issue related to the api/devfile specification
Projects
Status: Done ✅
Development

No branches or pull requests

3 participants