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

oc: enable following deployment logs in deploy #9482

Merged
merged 2 commits into from
Jul 22, 2016
Merged

oc: enable following deployment logs in deploy #9482

merged 2 commits into from
Jul 22, 2016

Conversation

0xmichalis
Copy link
Contributor

@0xmichalis
Copy link
Contributor Author

[test]

opts := deployapi.DeploymentLogOptions{
Follow: true,
}
readCloser, err := o.osClient.DeploymentLogs(config.Namespace).Get(config.Name, opts).Stream()
Copy link
Contributor

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).

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xmichalis
Copy link
Contributor Author

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)
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xmichalis
Copy link
Contributor Author

@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
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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
.

Copy link
Contributor

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
.

Copy link
Contributor Author

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

@mfojtik
Copy link
Contributor

mfojtik commented Jun 29, 2016

@Kargakis LGTM one more question/hint.

@0xmichalis
Copy link
Contributor Author

[test]

@0xmichalis
Copy link
Contributor Author

@smarterclayton anything else?

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 11e813f

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6437/)

@mfojtik
Copy link
Contributor

mfojtik commented Jul 20, 2016

LGTM

@0xmichalis
Copy link
Contributor Author

[merge]

@0xmichalis
Copy link
Contributor Author

secrets flake [merge]

@0xmichalis
Copy link
Contributor Author

secrets [merge]

@0xmichalis
Copy link
Contributor Author

• Failure [207.665 seconds]
deploymentconfigs
/data/src/github.com/openshift/origin/test/extended/deployments/deployments.go:598
  generation
  /data/src/github.com/openshift/origin/test/extended/deployments/deployments.go:384
    should deploy based on a status version bump [Conformance] [It]
    /data/src/github.com/openshift/origin/test/extended/deployments/deployments.go:383

    Expected error:
        <*errors.errorString | 0xc8200ce130>: {
            s: "timed out waiting for the condition",
        }
        timed out waiting for the condition
    not to have occurred

    /data/src/github.com/openshift/origin/test/extended/deployments/deployments.go:352
------------------------------

[merge]

@openshift-bot
Copy link
Contributor

openshift-bot commented Jul 22, 2016

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6727/) (Image: devenv-rhel7_4646)

@0xmichalis
Copy link
Contributor Author

secrets, hung conformance, and appliedclusterresourcequota [merge]

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 11e813f

@openshift-bot openshift-bot merged commit f924e3b into openshift:master Jul 22, 2016
@0xmichalis 0xmichalis deleted the deploy-follow branch July 22, 2016 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants