Yes, please :).

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infradata/master-manager/+/238b797aa6e5274c9579f19dea8e7c761b4f9b54

commit 238b797aa6e5274c9579f19dea8e7c761b4f9b54
Author: Ryan Tseng <hinoka@google.com>
Date: Thu May 17 01:07:41 2018

A couple more things needs to happen:

* chromium.perf needs to build the installer target chrome/installer/linux
* chromium.perf builders need to build faster.

Michael, what are these builders used for and can we turn them down? Please share details and update. Thanks!

They are used to determine the best revisions to use for the nightly branches. We can't turn them down, but we should migrate them onto official.desktop.continuous.

We won't be migrating Officials for a while. To clean up this master, anyone opposed to moving these builders to the existing official.desktop.continuous buildbot master first?

Dirk/Michael, friendly ping. See #9 for context.

not opposed.

I assume the chromium.chrome slaves, most of which are bare metal, can't simply be copied over to the official master configs (different VLANs or whatever), so I think what we need to do is:

- Move some slaves from official.desktop to official.desktop.continuous. The official.desktop builders generally don't run more than 3 or 4 builds at a time (one each for stable/beta/dev/canary), but I think they all have 5 or more slaves, so as long as they keep at least 4, this shouldn't affect releases.

- Add the "Google Chrome *" builders to official.desktop.continuous, using the moved slaves.

- Point the best_revision script at the new official.desktop.continuous builders instead of the chromium.chrome builders.

- Delete master.chromium.chrome.

- Have labs move/rewire/whatever the chromium.chrome slaves to make them available in the official golo so they can be added to official.desktop.continuous. (+labs for heads up, and to determine if there's any issue with this)

In general, I'd like to move machines from bare metal to VMs unless there's a really compelling reason not to.

I don't know if it's a compelling reason, but all the other official builders are bare metal, so keeping them that way for now would be consistent, and we can wait to deal with VMs when we do the LUCI migration. But if it's too much hassle to keep these as bare metal, or if the machines can be put to better use elsewhere, I'm not really opposed to switching to VMs, as long as we can maintain reasonable cycle times (i.e. something much faster than the actual official builders).

Actually, I think this brings up another issue. The chromium.chrome builders use goma, but for historical reasons, the official builders don't (or couldn't). Will the migrated builders still be able to, or is the official VLAN walled off from goma?

I don't think there are technical reasons the official builders can't use goma.  They should be able to use goma on the official vlan.

It looks like we're probably ready to start migrating to LUCI internally, so maybe the thing to do is to move these straight to VMs on LUCI. We can discuss more next week.

mmoss@ - can you make this part of the prep work for the official migrations? 

Renamed bug. See comments for context. 

What's the concrete plan and timeline here? Comment 0 says "public waterfall that checks out src-internal.  We don't want this anymore." That sounds wrong to me. We'll need to have official build coverage on chromium.clang which is public, so losing official build coverage on the main waterfall won't have benefits and will make things either more difficult for sheriffs (now have to look at more than 1 waterfall) or releasers (sheriffs no longer watch official builds).

We should have the ability to put builders from private builders on public waterfalls now (they are hidden unless the user is logged in).  Making this move merely increases the security boundaries for builders that check out src-internal.

> What's the concrete plan and timeline here?

jbudorick and mmoss can speak to this more, but I'm hoping the answer is ASAP. We've largely been waiting to make sure that the LUCI UIs were ready for internal builders, and they should be now.

> We'll need to have official build coverage on chromium.clang which is public

This is not okay and hasn't been okay for quite some time (for either chromium.chrome or chromium.clang). The plan was always to address this via moving to LUCI.

As hinoka says, we can manage which builders show up on the UIs via authentication and so it should hopefully be possible to produce an acceptable UI now. If it isn't, we need to fix that, but we must not delay the move to LUCI in the mean time (i.e., sheriffs will need to do more work).

On a related note, we also want sheriffs to be watching the *actual* official builds (both the scheduled builds and the continuous builds), and that will change when those builds are also moved to LUCI.

> ability to put builders from private builders on public waterfalls now

That's cool.

> but we must not delay the move to LUCI in the mean time

Moving to LUCI and making the bots private is orthogonal though, right?

(If showing internal builders on public waterfalls when signed in already works, that's moot, but if not then switching just one thing at a time might be a better plan.)

> Moving to LUCI and making the bots private is orthogonal though, right?

Not really, if the way we were going to make the bots private was to move it to LUCI. In other words, I think we have these alternatives:

1) Stand up new private buildbot bots and turn off the public buildbot bots. We're not going to do this as it'd be a waste of effort at this point since we'd still need them to move to LUCI.

2) Stand up new public LUCI bots and turn off the public buildbot bots. We're not going to do this, because there should not be any publicly viewable LUCI bots that check out src-internal, i.e., this is one of the key things we fix by moving to LUCI from buildbot.

3) Stand up new private LUCI bots and turn off the public buildbot bots. This is what I would prefer to do, and I think it's basically the same work as 2).

4) For the chromium.clang bots, we could turn off any public buildbot bot now and figure this out later. We can do this, obviously, but I'm assuming you wouldn't want us to do so :). We can't do this for chromium.chrome, because that'd break some of our release scripts.

Does that make sense?

2 is imho an option given that we've had the chromium.chrome bots for a very long time, at least if the "show private bots on public waterfall if signed in" bit hasn't been tested before. I.e. I don't get the urgency in moving these bots off public waterfalls. (But I don't have a strong opinion. Changing two things at once is just inherently more risky.)

I also vote (3).

> "show private bots on public waterfall if signed in"
tested and it works. You can already see it in action on perf console:
https://ci.chromium.org/p/chromium/g/chromium.perf/console

> I don't get the urgency in moving these bots off public waterfalls.

There's no urgency, obviously, since as you say they've been public forever, but, conversely, we also should've fixed this long ago.

However, there's no need to replicate that mistake in the new system, and I'm not concerned about riskiness.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/src-internal.git/+/0c83cb6359b5b2f69518aa224c91fdde976543cd

commit 0c83cb6359b5b2f69518aa224c91fdde976543cd
Author: Michael Moss <mmoss@google.com>
Date: Mon Oct 29 19:33:27 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/581fb4ed1417b9dae9ce78df93cf97008b9ee31c

commit 581fb4ed1417b9dae9ce78df93cf97008b9ee31c
Author: chromium-internal-autoroll <chromium-internal-autoroll@skia-corp.google.com.iam.gserviceaccount.com>
Date: Tue Oct 30 01:25:04 2018

Roll src-internal b0874f87a68d..6cf33fa7deb4 (3 commits)

https://chrome-internal.googlesource.com/chrome/src-internal.git/+log/b0874f87a68d..6cf33fa7deb4


Created with:
  gclient setdep -r src-internal@6cf33fa7deb4

The AutoRoll server is located here: https://autoroll-internal.skia.org/r/src-internal-chromium-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.



BUG=chromium:790153,chromium:790158,chromium:790159,chromium:790163,chromium:843835
TBR=mmoss@chromium.org

Change-Id: I58ebb1c2f2fe16236c19a7d729727a99fda7d0df
Reviewed-on: https://chromium-review.googlesource.com/c/1306216
Reviewed-by: chromium-internal-autoroll <chromium-internal-autoroll@skia-corp.google.com.iam.gserviceaccount.com>
Commit-Queue: chromium-internal-autoroll <chromium-internal-autoroll@skia-corp.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#603720}
[modify] https://crrev.com/581fb4ed1417b9dae9ce78df93cf97008b9ee31c/DEPS