Closed Bug 1082771 Opened 11 years ago Closed 11 years ago

Add a static "Infrastructure" menu that links to existing dashboards

Categories

(Tree Management :: Treeherder, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: KWierso, Assigned: emorley)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Attached image infrastructure.png (obsolete) —
TBPL has a menu that lists the total counts of pending/running jobs on all trees, broken down by tree, along with links to the following pages: http://builddata.pub.build.mozilla.org/reports/pending/pending.html https://secure.pub.build.mozilla.org/buildapi/running http://builddata.pub.build.mozilla.org/reports/pending/running.html https://secure.pub.build.mozilla.org/buildapi/pending Would be nice to have access to this information from within Treeherder.
Blocks: 1072681
Priority: -- → P3
Blocks: treeherder-dev-transition
No longer blocks: 1072681
Keywords: regression
We could also add a few more links to the menu - eg some of the examples given in bug 1124059.
I'd argue this should be higher priority as we approach end of life for TBPL.
Priority: P3 → P1
Priority: P1 → P2
So the TBPL implementation works like this: * Load builds-{pending,running}.js client side * In addition to overlaying pending/running jobs on the currently visible pushes, count _all_ pending/running jobs from all repos & use those figures in the infra menu Now with Treeherder: 1) We don't load builds-{pending,running}.js in the client, it's server side. 2) The picture is a bit more complicated, since builds-{pending,running}.js only covers buildbot and not taskcluster. Plus how do we want to break this down? Should taskcluster even be lumped into the same display? 3) In order to get a total overview of pending/running jobs across all repos, we'd have to query many many DBs, since each repo has it's own DB - plus we'd have to query back N days/weeks, since there is no guarantee that the pending/running job is recent. Though I guess we could use the last_modified field to limit the query to as few rows as possible, to keep it performant. Plus for a true picture of the "current state of the infra", I think simple pending/running counts are no longer really that helpful. You really need: * Pending/running counts broken down by machine type and repo * Number of available machines of each type * Number of machines that have not completed a job in the last N minutes * AWS info (jacuzzi status/thresholds etc) * Age of the oldest job in the pending queue * Graphs to show trends over the last N hours, plus to compare to the same day last week etc etc I'm thinking that some of the above is maybe better served upstream (in taskcluster/buildbot) than by Treeherder. And even if we want to pull all that together in Treeherder, we'll still need better API support/datasources (or at least to figure existing ones out, if they are already in place) from upstream first. As such (and so we can get at least something to replace the infra menu for now), I think the first iteration should just be a bunch of links to buildbot/treeherder pages, with no live stats displayed within Treeherder. For me at least, the buildbot graphs provided much more value than the raw stats, such that I often jumped straight to those pages even when I was using TBPL - so hopefully this shouldn't be too much of an issue. Things we could link to: https://secure.pub.build.mozilla.org/buildapi/pending http://builddata.pub.build.mozilla.org/reports/pending/pending.html https://secure.pub.build.mozilla.org/buildapi/running http://builddata.pub.build.mozilla.org/reports/pending/running.html https://secure.pub.build.mozilla.org/builddata/reports/slave_health/ Already linked from slave_health (but would probably be good to link to directly): https://secure.pub.build.mozilla.org/builddata/reports/slave_health/build_trends.html https://secure.pub.build.mozilla.org/builddata/reports/slave_health/try_trends.html https://secure.pub.build.mozilla.org/builddata/reports/slave_health/test_trends.html https://secure.pub.build.mozilla.org/builddata/reports/slave_health/jacuzzis.html hg status: http://nigelbabu.github.io/hgstats/#hours/2 EC2 dashboard: https://www.hostedgraphite.com/da5c920d/grafana/#/dashboard/temp/5d509a54d0b496d184023bab35c17d0f41e6c607 Runner dashboard: https://stats.taskcluster.net/grafana/#/dashboard/db/runner We could also move things like the clobberer link from the tree info menu to infrastructure. @sheriffs: What are your preferences for the above? Which are the most useful? Any other links we should include?
OS: Windows 8.1 → All
Hardware: x86_64 → All
Summary: Add TBPL's "Infrastructure" menu to Treeherder → Add a static "Infrastructure" menu that links to existing dashboards
That would be sufficient for me, I think, at least in the short term.
@sherrifs: Which of the links to dashboards in comment 3 are useful to you? Are there any other things I should be linking to? Perhaps we could make this a general "Status" menu (ie status of not just the build infra, but say Treeherder New Relic too?)
Assignee: nobody → emorley
Status: NEW → ASSIGNED
I would say the following would be useful in there: https://secure.pub.build.mozilla.org/buildapi/pending http://builddata.pub.build.mozilla.org/reports/pending/pending.html https://secure.pub.build.mozilla.org/buildapi/running http://builddata.pub.build.mozilla.org/reports/pending/running.html https://secure.pub.build.mozilla.org/builddata/reports/slave_health/ Clobberer link could probably be moved to Infrastructure (the tree-specific links from the tree-info links don't actually seem to get the clobberer page to pre-select the specified tree, so just a generic link to the clobberer under Infrastructure would be enough). I don't really use anything beyond those, but I generally redirect to Releng if those don't let me figure out what's going on, so I don't know if the other links would be useful in there.
Wes' list looks good. An EC2 dashboard link would be nice as well.
Attachment #8580801 - Flags: review?(tojonmz)
Attachment #8580801 - Flags: feedback?(wkocher)
Attachment #8580801 - Flags: feedback?(ryanvm)
Attachment #8580801 - Flags: feedback?(cbook)
Attachment #8504942 - Attachment is obsolete: true
Attachment #8580801 - Flags: feedback?(wkocher) → feedback+
Attachment #8580801 - Flags: feedback?(ryanvm) → feedback+
Comment on attachment 8580801 [details] [review] Add an infra menu that links to dashboards/tools Lgtm, and any minor cosmetic tweaking we can do later :) So long this has been tested locally and it's behaving properly, all good on my end.
Attachment #8580801 - Flags: review?(tojonmz) → review+
Actually I just tried it locally also, and it's cool. The only thing I can note is some of the menu entries require LDAP/Level3 (I think): BuildAPI Pending BuildAPI Running Slave Health (kind of..) Clobberer versus the other Infra menu entries which don't. Perhaps there is visual differentiation we could provide in all menus (Infra, [i], resultset bar menu) to cue the user menus which are not accessible without the appropriate level-access (eg. disabled styling?, not sure). It's outside the scope of the fix here though. The only other fix observations are: 1) tree status(per repo) and clobberer(per repo) already in the little "[i]" icon adjacent to the current repo in the navbar, so I assume we are ok for having somewhat similar (but yes, differently addressed) menus in two places. 2) the case treatment and word-space style in the repo [i] menu is different, we could unify their appearance later in another bug. 3) the new Infra menu itself in the navbar is available when not logged in to the platform, just to confirm that is the intent? (makes sense to me, even with above Level-access issues). I stills stand by my r+, in any case :)
(In reply to Jonathan French (:jfrench) from comment #10) > Actually I just tried it locally also, and it's cool. The only thing I can > note is some of the menu entries require LDAP/Level3 (I think): Yeah this is unavoidable, and was the case with TBPL too. > versus the other Infra menu entries which don't. Perhaps there is visual > differentiation we could provide in all menus Good idea - let's do this in a followup :-) > 1) tree status(per repo) and clobberer(per repo) already in the little "[i]" > icon adjacent to the current repo in the navbar, so I assume we are ok for > having somewhat similar (but yes, differently addressed) menus in two places. Yeah the idea was that we can make the repo menu links be deep links and the ones on the infra menu be to the overview pages. TBH I think the best plan is just to add them to the infra menu for now and see over time which people prefer to use, and consider removing the other if appropriate. > 2) the case treatment and word-space style in the repo [i] menu is > different, we could unify their appearance later in another bug. Ah another good spot :-) Let's sort this with the other followup above. > 3) the new Infra menu itself in the navbar is available when not logged in > to the platform, just to confirm that is the intent? (makes sense to me, > even with above Level-access issues). Yeah this is intended - none of the links are any more accessible when people are logged into persona. Thank you for the review and testing! :-D
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to Ed Morley (Away 23rd March -> 1st April) [:edmorley] from comment #11) > > Ah another good spot :-) Let's sort this with the other followup above. Entered as bug 1145837 :)
Attachment #8580801 - Flags: feedback?(cbook)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: