-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
oc: enable following deployment logs in deploy #9482
Conversation
[test] |
opts := deployapi.DeploymentLogOptions{ | ||
Follow: true, | ||
} | ||
readCloser, err := o.osClient.DeploymentLogs(config.Namespace).Get(config.Name, opts).Stream() |
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 assume this will wait till the logs are available (iow. the deployer pod is started).
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.
Currently it just wait until the replication controller is created. I will open a separate issue to make it wait for the deployer pod to come up.
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.
flaked on #9490, [test] |
@@ -126,10 +133,9 @@ func (r *REST) Get(ctx kapi.Context, name string, opts runtime.Object) (runtime. | |||
|
|||
// Get desired deployment | |||
targetName := deployutil.DeploymentNameForConfigVersion(config.Name, desiredVersion) | |||
target, err := r.rn.ReplicationControllers(namespace).Get(targetName) | |||
target, err := r.waitForExistingDeployment(namespace, targetName) |
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.
Timeout should come from opts, not a constant
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.
There is a separate issue about wiring a timeout.
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.
Can you link it here?
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.
@smarterclayton @mfojtik anything else here? |
const defaultTimeout time.Duration = 20 * time.Second | ||
const ( | ||
// defaultTimeout is the default time to wait for the logs of a deployment. | ||
defaultTimeout time.Duration = 20 * time.Second |
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 error code we return when this timeout is reached? can client retry getting the logs based on the return code?
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 error code we return when this timeout is reached?
Depends on where do we reach it. If we timeout while waiting for the replication controller to be created, we return a notFound error because we were polling on that error. If we reach this while waiting for the replication controller to become running then we return a timeout error.
can client retry getting the logs based on the return code?
It's possible. Do we want to do something for oc?
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.
We should return NewServerTimeout
On Jun 29, 2016, at 6:36 AM, Michal Fojtik [email protected] wrote:
In pkg/deploy/registry/deploylog/rest.go
#9482 (comment):
@@ -25,8 +26,12 @@ import (
deployutil "github.com/openshift/origin/pkg/deploy/util"
)-// defaultTimeout is the default time to wait for the logs of a deployment
-const defaultTimeout time.Duration = 20 * time.Second
+const (
- // defaultTimeout is the default time to wait for the logs of a deployment.
- defaultTimeout time.Duration = 20 * time.Second
what error code we return when this timeout is reached? can client retry
getting the logs based on the return code?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/pull/9482/files/53571d0332a00a9aa0df0515d34a867b65273f42#r68946411,
or mute the thread
https://github.com/notifications/unsubscribe/ABG_p6CAHrUsezCmTKGkRaQOC9fxrSlEks5qQnTJgaJpZM4I7sgr
.
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.
Hrm. Maybe. The client will actually retry ServerTimeout in most cases.
On Jun 29, 2016, at 3:33 PM, Michail Kargakis [email protected]
wrote:
In pkg/deploy/registry/deploylog/rest.go
#9482 (comment):
@@ -25,8 +26,12 @@ import (
deployutil "github.com/openshift/origin/pkg/deploy/util"
)-// defaultTimeout is the default time to wait for the logs of a deployment
-const defaultTimeout time.Duration = 20 * time.Second
+const (
- // defaultTimeout is the default time to wait for the logs of a deployment.
- defaultTimeout time.Duration = 20 * time.Second
what error code we return when this timeout is reached?
Depends on where do we reach it. If we timeout while waiting for the
replication controller to be created, we return a notFound error because we
were polling on that error. If we reach this while waiting for the
replication controller to become running then we return a timeout error.
can client retry getting the logs based on the return code?
It's possible. Do we want to do something for oc?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/origin/pull/9482/files/53571d0332a00a9aa0df0515d34a867b65273f42#r69040670,
or mute the thread
https://github.com/notifications/unsubscribe/ABG_p2fpUwlnuRCLLuZW7te7tmbk7kN-ks5qQvKlgaJpZM4I7sgr
.
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.
Updated to return a ServerTimeout error in case we are waiting for the deployment to transition to Running. PTAL
@Kargakis LGTM one more question/hint. |
[test] |
@smarterclayton anything else? |
Evaluated for origin test up to 11e813f |
continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6437/) |
LGTM |
[merge] |
secrets flake [merge] |
secrets [merge] |
[merge] |
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6727/) (Image: devenv-rhel7_4646) |
secrets, hung conformance, and appliedclusterresourcequota [merge] |
Evaluated for origin merge up to 11e813f |
Fixes #9423
@smarterclayton @fabianofranz @mfojtik @ironcladlou