Should deployment card expansion span envionments?

[qodfathr]

When expanding a deployment card, is there any reason to not expand the other environment deployment cards for the same app? The whitepace under the unexpanded deployment seems wasted, and there is a good chance if I'm looking at the deployment in one environment that I want to see it in the other environments (e.g. to compare mem usage between old and new versions of the app).

Regarding

#287
#2176

[aslakknutsen]

There is also a large chance that e.g. the memory usage is completely different and incomparable as it's highly dependent on the traffic that is hitting the env. Trends in certain metrics could be similar, but not sure comparing metrics to metrics has much value in a normal setup.

But yea, lots a 'white space'.

[qodfathr]

@aslakknutsen I agree that things could be incomparable, esp. for Stage and Run. But looking ahead, we'll have user defined environments, and those environments could represent, for example, two testing environments -- one with old version of app and other with new version -- whereby I'm running a load test simultaneously against both to see impact of a software change. In other words, they could be comparable. Like all data, needs to be consumed in context.

Perhaps more importantly, we need to continue to refine the kind of data we show here to ensure that it's actionable. These real-time charts are a great and semi-obvious first implementation, but we need to continue to ask ourselves -- do they provide value? Is there other data that would be more valuable? And is that data, in turn, more comparable between environments?

[joshuawilson]

we have talked about 2 additional types of data to add:

1. JVM metrics
2. metrics from Frank's monitoring efforts

[qodfathr]

There are also about 3-4 other "quota blocking" metrics. (e.g., you can only have 5 OSO "Services" in the free tier, there's a limit on total Routes, etc.) Knowing which apps are consuming these may be helpful, but certainly it's important to know the overall usage for these in the "Resource Usage" section. I think I have an issue for this already filed.

[jiekang]

@catrobson

[catrobson]

I agree that expanding all cards at once might be desirable since it is "lost space" otherwise. However, this would require an updated design with new expansion interactions probably at the application level over just "when I expand one, expand all" which does not feel like expected behavior with the current design. This will require a new design story for us to redefine how the expansion behavior acts I think. I'll create one and add it to our backlog.

[jiekang]

The developer issue tracking work for this is #3125

This question has been answered so closing.