oc status does not elide duplicate deployment config

[smarterclayton]

When two services overlap a DC, it should only be printed in detail once:

service ab-example - 172.30.76.170:8080
  ab-example deploys deployment-example:latest 
    #2 deployed about a minute ago - 1 pod
    #1 deployed 6 minutes ago
  ab-example-b deploys deployment-example:latest 
    #2 deployed 58 seconds ago - 1 pod
    #1 deployed 3 minutes ago

service ab-example-b - 172.30.114.157:8080
  ab-example-b deploys deployment-example:latest 
    #2 deployed 58 seconds ago - 1 pod
    #1 deployed 3 minutes ago

Should be

service ab-example - 172.30.76.170:8080
  ab-example deploys deployment-example:latest 
    #2 deployed about a minute ago - 1 pod
    #1 deployed 6 minutes ago
  ab-example-b deploys deployment-example:latest 
    #2 deployed 58 seconds ago - 1 pod
    #1 deployed 3 minutes ago

service ab-example-b - 172.30.114.157:8080
  ab-example-b deploys deployment-example:latest ...

[deads2k]

I'm not crazy about that because it means that you can't see whether "service ab-example-b" has any pods fulfilling it. How do you feel about displaying only those deployments that have pods for the second service?

Actually, why is it important to know about old deployments without pods at all?

[smarterclayton]

On Jul 21, 2015, at 2:50 PM, David Eads notifications@github.com wrote:

I'm not crazy about that because it means that you can't see whether
"service ab-example-b" has any pods fulfilling it. How do you feel about
displaying only those deployments that have pods for the second service?

I meant the "..." To indicate that the item was already shown above (so you
scan up). It shouldn't be hard to pair them, but I don't want to show the
same info or warnings twice

Actually, why is it important to know about old deployments without pods at
all?

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

[smarterclayton]

Knowing when prior deployments happened is pretty critical - that's the
primary source of change in your environment, which is the primary source
of bugs.

On Jul 21, 2015, at 2:50 PM, David Eads notifications@github.com wrote:

I'm not crazy about that because it means that you can't see whether
"service ab-example-b" has any pods fulfilling it. How do you feel about
displaying only those deployments that have pods for the second service?

Actually, why is it important to know about old deployments without pods at
all?

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

[deads2k]

@smarterclayton I still don't like the .... Do you still like it?

[smarterclayton]

I don't particularly care what the indication is, just that we stop
repeating ourselves for redundant info. Terminal characters are precious -
we should spend them only on the things that truly matter. Once we've said
it once, we don't need to say it again. If there's a better way to
represent that than an ellipsis, I'm open to it.

On Mon, Nov 9, 2015 at 2:14 PM, David Eads notifications@github.com wrote:

@smarterclayton https://github.com/smarterclayton I still don't like
the .... Do you still like it?

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

[deads2k]

@jwforres @fabianofranz Any advice on presentation?

[fabianofranz]

Use ... and if it was used suggest -v|--verbose which would print the complete, redundant version?

[smarterclayton]

I don't know that suggesting is really that common. If i have multiple DCs
pointing to the same thing, I'm going to see the previous data above. Why
would I want to see the redundant data?

On Mon, Dec 14, 2015 at 12:53 PM, Fabiano Franz notifications@github.com
wrote:

Use .... and if it was used suggest -v|--verbose which would print the
complete, redundant version?

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

[deads2k]

I don't know that suggesting is really that common. If i have multiple DCs
pointing to the same thing, I'm going to see the previous data above. Why
would I want to see the redundant data?

I like the locality of information over terse output.

[smarterclayton]

I don't. The point of this output is to convey the important information
in minimal space. Being redundant wastes space and reduces comprehension.
Any user who has this setup is already someone trying to do something
specific - forcing them to see the data presented each time is misleading
(it may convince them they aren't coupled)

On Mon, Dec 14, 2015 at 1:04 PM, David Eads notifications@github.com
wrote:

I don't know that suggesting is really that common. If i have multiple DCs
pointing to the same thing, I'm going to see the previous data above. Why
would I want to see the redundant data?

I like the locality of information over terse output.

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

[fabianofranz]

Another idea but I still prefer the ellipsis

service ab-example - 172.30.76.170:8080
  ab-example deploys deployment-example:latest 
    #2 deployed about a minute ago - 1 pod
    #1 deployed 6 minutes ago
  ab-example-b deploys deployment-example:latest [1]

service ab-example-b - 172.30.114.157:8080
  ab-example-b deploys deployment-example:latest [1]

[1] #2 deployed 58 seconds ago - 1 pod
    #1 deployed 3 minutes ago

[smarterclayton]

Yeah, I think that's worse than either. If you had 5 of these it would be
a disaster.

On Mon, Dec 14, 2015 at 1:09 PM, Fabiano Franz notifications@github.com
wrote:

Another idea but I still prefer the ellipsis

service ab-example - 172.30.76.170:8080
ab-example deploys deployment-example:latest
#2 deployed about a minute ago - 1 pod
#1 deployed 6 minutes ago
ab-example-b deploys deployment-example:latest [1]

service ab-example-b - 172.30.114.157:8080
ab-example-b deploys deployment-example:latest [1]

[1] #2 deployed 58 seconds ago - 1 pod
#1 deployed 3 minutes ago

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

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close