-
Notifications
You must be signed in to change notification settings - Fork 835
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
Add progress deadline support for SDeps #4235
Add progress deadline support for SDeps #4235
Conversation
Testing these changes was a bit of a convoluted process but did confirm the intended behaviour. For reference, I did the following:
|
Nice one @agrski ! Will test from branch and review. Seems executor test failed but we need to validate if its just the flaky one. /text integration |
From checking GHA, looks like both failures are flaky. Note this is still in draft as I also need to check in some changes to manifests -- just trying to fix my controller-gen setup as it's giving me a weird version and some changes I didn't expect. |
@@ -43,38 +29,6 @@ webhooks: | |||
path: /validate-machinelearning-seldon-io-v1-seldondeployment | |||
failurePolicy: Fail | |||
name: v1.vseldondeployment.kb.io | |||
{{- if semverCompare ">=1.15.0" .Capabilities.KubeVersion.GitVersion }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ I'm not sure how/why this no longer exists -- was I running the wrong Make commands or missing a step?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the version of your controller gen? That often tends to cause variations in the generated tokens
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's 0.7.0 -- I had to uninstall v0.4 and use the make
target to install v0.7, as it created a number of small differences. The generation of this file was purely with v0.7.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok that does sound like should be ok - could you try again using make -C operator/helm create
? That should use the docker image to create it so it should be the exact same output
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I did before - it's documented in this comment, near the top. I did notice it's using Docker to run some of the other commands in the Makefile
/test integration |
1 similar comment
/test integration |
/test integration |
8551f53
to
699b9a0
Compare
Force pushed after rebasing onto master |
/test integration |
Doesn't look like integration tests want to run -- I'm not seeing anything for this PR in JX Edit: the UI was lying. I can see the logs for the pod corresponding to this PR are progressing, but they're very slow and full of failed connections to endpoints, so I'm guessing things are a bit slow to spin up in the tests. |
Running integration for retest of CI |
I've stopped the pipeline manually with |
Generated content from 'make -C operator/ manifests'.
Generated content from 'make -C operator/helm/ create'.
699b9a0
to
97f4402
Compare
/test integration |
/test notebooks |
Failed test is |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: axsaucedo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
Currently, Seldon Deployments do not support setting
progressDeadlineSeconds
, which is an optional setting used to control when a deployment is marked as failed.This field is defined for deployments, not pods or containers, thus users cannot set this manually by overriding component specs in an SDep.
As
progressDeadlineSeconds
is optional in Kubernetes, with a default of 600 seconds, this change is backwards compatible -- any SDep not specifying this will use the Kubernetes default automatically.Which issue(s) this PR fixes:
Fixes #4224
Special notes for your reviewer: