Go performance dashboard feels abandoned

[pavel....@gmail.com]

It looks like the dashboard is completely abandoned.

There is nothing useful here:
http://build.golang.org/perf

Graphs return 500 status code:
http://build.golang.org/perfgraph

Is that intentional? Do you need any help with performance dashboard?

[Brad Fitzpatrick]

They are abandoned.

That's why we moved the links to them from http://build.golang.org/

I don't have time to do any more builder-related reviews at the moment. Maybe Andrew does.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Gerrand]

It's broken because a bug caused the perf data to become corrupted, and neither Dmitry nor I have had occasion to fix it.

It's not something that can be easily fixed by someone who doesn't have access to the build dashboard app. 

[Pavel Paulau]

Got it.

Anyways, let me know if something that can be fixed externally appears.

[murillo...@gmail.com]

It looks like that should be fixed, since someone volunteered to help...

[Brad Fitzpatrick]

See Andrew's reply.

It's not easy to fix. And the people with access don't have time.

If somebody wants to submit a proposal on how they'd fix it, we're all ears.

[murillo...@gmail.com]

What I intended to say that should be fixed is the part where (I guess) few people have access.

My apologies if I didn't make it clear.

[Brad Fitzpatrick]

A prerequisite for us giving out access is somebody creating a plan.

We're not going to blanket grant out access to everybody. It's time consuming and the resources either cost money (VMs) or are limited and require hands-on maintenance. We're not going to bear the cost unless there's expected reward.

[Pavel Paulau]

What we know so far is that "a bug caused the perf data to become corrupted".
I don't think that any kind of planning is possible in this situation.

[Brad Fitzpatrick]

That's all we know too. Plus go read the old emails and bugs about this during the time of the hg to git transition.

If it were trivial we'd have fixed it already.

[Andrew Gerrand]

On 14 November 2015 at 23:09, Brad Fitzpatrick <brad...@golang.org> wrote:

We're not going to blanket grant out access to everybody

Actually, I can't give anyone outside Google access to the dashboard project for policy reasons. So we're really in a stalemate here.

[murillo...@gmail.com]

Just wondering 'Do you Googlers feel that* should need fixing?'

I know it affects really minor areas, but those areas may be important to someone who uses and depends on the project (and/or limiting the ability to help)

* and by that I mean the part where access and control are still tightly attached to Google

[Brad Fitzpatrick]

We control our machines, yes. You control your machines. Feel free to fire up some VMs or physical hardware and fix the problem.

[murillo...@gmail.com]

Wow!

I guess that ends the conversation.

I just wanted to know your (personal) opinions; that was needlessly aggressive and just in case you forgot this was motivated because someone wanted to help.

[Brad Fitzpatrick]

My personal opinion is that many things are broken or not ideal and there's limited time and people to fix them all immediately.

Perf dashboard was nice but wasn't invaluable. We run all out benchmarks regularly enough as is before major changes and before releases, so it's not like we've lost visibility into performance. It just doesn't happen for everywhere single commit anymore. Oh well.

Dmitry cares a lot (and he happens to work for Google) but he also doesn't prioritize it. Limited time, and bigger impact things to work on.

The whole system needs a redesign anyway. The old one was fragile, which is why it broke.

So if you're motivated, what I'm saying is write a design doc, write some code, fire up some VMs, try it out.

This is a manpower and time issue, not a Googler or ACL problem.

[Andrew Gerrand]

On 16 November 2015 at 20:27, <murillo...@gmail.com> wrote:

Just wondering 'Do you Googlers feel that* should need fixing?'

I know it affects really minor areas, but those areas may be important to someone who uses and depends on the project (and/or limiting the ability to help)

* and by that I mean the part where access and control are still tightly attached to Google

I do believe that the ACL to the Google Cloud Project that serves golang.org should be kept very short.

While it's inconvenient in this situation, I understand and agree with the policy that only Google employees should have access to infrastructure that serves Google services.

If/when I leave the company, my access will be revoked also.

Andrew

[Pavel Paulau]

Apparently reading other related threads (including the initial proposal from Dmitry) helped a lot. At least it's clear that ACL is the smallest problem.

Re-designing and re-implementing the whole system with UI, builders, database, and benchmarks will take several productive days. And it's quite possible that we will end up with the same issues. Somebody needs to maintain this system anyway.

Time has proven that "nice to have" things remain "nice to have". Perhaps a simpler benchmarking suite, indeed, has more chances to survive.

It would be helpful to have a retrospective view on this problem. Did the dashboard help to build a better piece of technology? Are cross-platform builders really required? Are existing benchmarks stable and consistent? Does anyone care about fancy UI?

[Andrew Gerrand]

On 18 November 2015 at 16:49, Pavel Paulau <pavel....@gmail.com> wrote:

Did the dashboard help to build a better piece of technology?

Not sure.

 

Are cross-platform builders really required?

Builders? Yes. But for running benchmarks? Maybe. 

  

Are existing benchmarks stable and consistent?

I believe so, yes.

 

Does anyone care about fancy UI?

I think it's a matter of "nice to have".

Andrew