status: Warn about transient deployment trigger errors

[0xmichalis]

@deads2k

I do think we should handle multiple bad triggers as markers for warnings and the separately mark a deployment that can't succeed on the same line. Something like " #1 deployment waiting on image or update (image stream doesn't exist)"

Separate marker for each warning means we traverse the graph and not follow the message set up by the dc controller. Or is it enough to break down the message into markers?

[0xmichalis]

@deads2k now that the dc controller changes are in, let's get this out of the way. What's the intention here, follow the deploymentconfig message set by the controller, or traverse the graph and report separately?

[0xmichalis]

Hmm, I have been working on this today and depending on the dc message (both the content and its format) is a mess. I think I'll just traverse the graph and report separately.

[0xmichalis]

Also @ironcladlou

[ironcladlou]

Should the controller be adapted to use this code?

[0xmichalis]

Should the controller be adapted to use this code?

You mean create a graph in the dc controller? Not sure how I feel about it but I would prefer if we weren't duplicating logic.

[ironcladlou]

Should the controller be adapted to use this code?

You mean create a graph in the dc controller? Not sure how I feel about it but I would prefer if we weren't duplicating logic.

Is there some reason using the graph library there would be inappropriate? It seems to provide the core analytics we're looking for in a variety of contexts (CLI, backend code trying to do analysis, etc).

[0xmichalis]

Is there some reason using the graph library there would be in appropriate? It seems to provide the core analytics we're looking for in a variety of contexts (CLI, backend code trying to do analysis, etc).

@smarterclayton ?

[smarterclayton]

Graphs should be used for graph type operations. Looking at resources is not a graph layer thing. If there is common code it should probably be in an API helper method (not util) that does a common transform.

[0xmichalis]

Not sure if it's possible for the graph stuff and the dc controller to share an api helper. It's either the one or the other I think.

[smarterclayton]

No graph library for now. If you have to refactor to do something common,
the common code should be in deploy/api/helpers.go, and both places should
use it.

On Mon, Oct 26, 2015 at 2:33 PM, Michail Kargakis [email protected]
wrote:

Not sure if it's possible for the graph stuff and the dc controller to
share an api helper. It's either the one or the other I think.

—
Reply to this email directly or view it on GitHub
#5085 (comment).

[0xmichalis]

That's what I'm saying, I cannot extract any common code.

Is it ok if oc status and the dc controller report separately? oc status is
reporting on the spot while the dc controller lags ~2 mins until it
reconciles a config.

On Mon, Oct 26, 2015 at 7:44 PM, Clayton Coleman [email protected]
wrote:

No graph library for now. If you have to refactor to do something common,
the common code should be in deploy/api/helpers.go, and both places should
use it.

On Mon, Oct 26, 2015 at 2:33 PM, Michail Kargakis <
[email protected]>
wrote:

Not sure if it's possible for the graph stuff and the dc controller to
share an api helper. It's either the one or the other I think.

—
Reply to this email directly or view it on GitHub
#5085 (comment).

—
Reply to this email directly or view it on GitHub
#5085 (comment).

[smarterclayton]

DC controller should report into the status of the deployment config.
Status should show that info as well.

On Mon, Oct 26, 2015 at 2:50 PM, Michail Kargakis [email protected]
wrote:

That's what I'm saying, I cannot extract any common code.

Is it ok if oc status and the dc controller report separately? oc status is
reporting on the spot while the dc controller lags ~2 mins until it
reconciles a config.

On Mon, Oct 26, 2015 at 7:44 PM, Clayton Coleman <[email protected]

wrote:

No graph library for now. If you have to refactor to do something common,
the common code should be in deploy/api/helpers.go, and both places
should
use it.

On Mon, Oct 26, 2015 at 2:33 PM, Michail Kargakis <
[email protected]>
wrote:

Not sure if it's possible for the graph stuff and the dc controller to
share an api helper. It's either the one or the other I think.

—
Reply to this email directly or view it on GitHub
<#5085 (comment)
.

—
Reply to this email directly or view it on GitHub
#5085 (comment).

—
Reply to this email directly or view it on GitHub
#5085 (comment).

[smarterclayton]

[test]

[0xmichalis]

I'm going to add tests for this.

[0xmichalis]

Tests added and passing locally.

[0xmichalis]

@openshift/team-project-committers

[0xmichalis]

@smarterclayton @liggitt this is low risk and useful since the reporting by the dc controller was disabled.

[jwforres]

agree with @liggitt this is 1.1.1 the bar for changes is pretty high right now

[0xmichalis]

@deads2k this needs reviewing if you have time.

[deads2k]

Can you hide this look inside of a function, so this reads more like:

if exists := doesImageStreamExist(isTag); !exists{
    // add marker
}

It would just help me reason about how many markers I might get.

[0xmichalis]

#5681 flake

re[test]

[deads2k]

This probably ought to be an info key

[0xmichalis]

updated

[deads2k]

nit, lgtm otherwise.

[openshift-bot]

Evaluated for origin test up to e4886ff

[deads2k]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/7079/) (Image: devenv-rhel7_2701)

[openshift-bot]

Evaluated for origin merge up to e4886ff

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/7079/)