Closed Bug 412542 Opened 15 years ago Closed 15 years ago

Rename BuildBot buildmasters

Categories

(Release Engineering :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joduinn, Assigned: bhearsum)

Details

Attachments

(2 files, 3 obsolete files)

Can we rename the following:

staging-build-console --> staging-1.8-master
build-console --> production-1.8-master
staging-trunk-automation --> staging-1.9-master
production-trunk-automation --> production-1.9-master

This will make it less confusing going forward when we bring up moz2 buildmasters for "trunk". It also makes the various existing buildmasters more consistent.
(obviously, not tied to "master" in name, thats just a suggestion. However, I think the staging/production and the 1.8/1.9 portion really helps clarify things.)
I created CNAMES today so we can start using these names now. Once the VI client is healthy, let's change the vm and hostnames for consistency's sake.
Assignee: nobody → bhearsum
Status: NEW → ASSIGNED
Priority: -- → P3
Priority: P3 → P2
I had to make the following change to get production-1.9-master to pickup it's new hostname:
In the zone file:
production-1.9-master IN A 10.2.71.225
production-trunk-automation IN CNAME production-1.9-master

I also changed the hostname listed in dhcpd.conf and in the VI client.

I've made similar changes for the rest of the automation masters. I have to reboot the to get them to pick up their new hostnames, so keeping this bug open for now.
(In reply to comment #3)
> I had to make the following change to get production-1.9-master to pickup it's
> new hostname:
> In the zone file:
> production-1.9-master IN A 10.2.71.225
> production-trunk-automation IN CNAME production-1.9-master
> 
> I also changed the hostname listed in dhcpd.conf and in the VI client.
> 
> I've made similar changes for the rest of the automation masters. I have to
> reboot the to get them to pick up their new hostnames, so keeping this bug open
> for now 

All of the slaves use the old names for the masters, and the bootstrap.cfg does as well. We should fix these up too.
(In reply to comment #4)
> (In reply to comment #3)
> All of the slaves use the old names for the masters

Sorry, to clarify here I just mean the buildbot.tac
We also need to make sure to accept the SSH hostkey, as bootstrap is going to want to ssh from slave->master
FYI, nagios only works with the name that matches the A record for a host.  The nagios on bm-admin01 got broken by the DNS in comment 3 because it's still looking for production-trunk-automation, which is no longer an A record.  I changed it to production-1.9-master in the nagios config and it was happy again.
Thanks for catching that.

The other hosts listed in comment #0 have changed too, can you update them as well?
This patch shouldn't be checked in until we manually ssh to staging-1.8-master on all of the slaves so we don't hit any unaccepted host key errors.
Attachment #298314 - Flags: review?
Attachment #298314 - Flags: review? → review?(joduinn)
Attachment #298322 - Flags: review?(joduinn)
Attachment #298314 - Flags: review?(joduinn) → review+
Comment on attachment 298322 [details] [diff] [review]
change names in buildbot master.cfgs

Discussed [bots] list on IRC. Also, 'slavename': 'linux-1.8-console1' being changed to 'slavename': 'staging-1.9-master' wont work as linux-1.8-console1 is  a special slave running on same machine as 1.8 master.
Attachment #298322 - Flags: review?(joduinn) → review-
Attached patch fix staging 1.8 master.cfg (obsolete) — Splinter Review
Rob,

John and I were talking about about whether or not the slavename should be the same as the DNS name. I remember having this discussion before, but couldn't find it in my irc logs. Do you remember what we decided on?
Attachment #298322 - Attachment is obsolete: true
Attachment #298339 - Flags: review?(rhelmer)
Attachment #298339 - Flags: review?(joduinn)
Attachment #298339 - Attachment is obsolete: true
Attachment #298343 - Flags: review?(rhelmer)
Attachment #298343 - Flags: review?(joduinn)
Attachment #298339 - Flags: review?(rhelmer)
Attachment #298339 - Flags: review?(joduinn)
Comment on attachment 298343 [details] [diff] [review]
add all bots back into 1.8 configs

1) bhearsum & I chatted on IRC about using the same identical string (i.e. staging-1.8-master) to refer to two different buildbot processes (one slave, one master) running on the same machine. Its a style difference, which I personally find slightly confusing, but happy to follow bhearsum's preference here.

2) I see 'linux-1.8-console2' now becomes 'production-1.8-master', fixing the previous patch, where 'linux-1.8-console2' became 'production-1.9-master'.

Looks good!
Attachment #298343 - Flags: review?(joduinn) → review+
Comment on attachment 298343 [details] [diff] [review]
add all bots back into 1.8 configs

Looks good. I agree that the e.g. "staging-1.8-master" looks weird as a slavename, but it kind of makes sense :P

I think that the real fix is not to run slaves on the master server, which we're moving towards anyway.
Attachment #298343 - Flags: review?(rhelmer) → review+
Checking in production/master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/automation/production/master.cfg,v  <--  master.cfg
new revision: 1.13; previous revision: 1.12
done
Checking in production-1.9/master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/automation/production-1.9/master.cfg,v  <--  master.cfg
new revision: 1.7; previous revision: 1.6
done
Checking in staging/master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/automation/staging/master.cfg,v  <--  master.cfg
new revision: 1.20; previous revision: 1.19
done
Checking in staging-1.9/master.cfg;
/cvsroot/mozilla/tools/buildbot-configs/automation/staging-1.9/master.cfg,v  <--  master.cfg
new revision: 1.17; previous revision: 1.16
done
Attachment #298343 - Attachment is obsolete: true
Attachment #298718 - Attachment description: patch as landed (had to merge against recent changes) → [checked in] patch as landed (had to merge against recent changes)
Comment on attachment 298314 [details] [diff] [review]
[checked in] change hostnames in bootstrap configs

Checking in fx-moz18-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz18-bootstrap.cfg,v  <--  fx-moz18-bootstrap.cfg
new revision: 1.28; previous revision: 1.27
done
Checking in fx-moz18-nightly-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz18-nightly-bootstrap.cfg,v  <--  fx-moz18-nightly-bootstrap.cfg
new revision: 1.4; previous revision: 1.3
done
Checking in fx-moz18-staging-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz18-staging-bootstrap.cfg,v  <--  fx-moz18-staging-bootstrap.cfg
new revision: 1.14; previous revision: 1.13
done
Checking in fx-moz19-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz19-bootstrap.cfg,v  <--  fx-moz19-bootstrap.cfg
new revision: 1.9; previous revision: 1.8
done
Checking in fx-moz19-nightly-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz19-nightly-bootstrap.cfg,v  <--  fx-moz19-nightly-bootstrap.cfg
new revision: 1.5; previous revision: 1.4
done
Checking in fx-moz19-staging-bootstrap.cfg;
/cvsroot/mozilla/tools/release/configs/fx-moz19-staging-bootstrap.cfg,v  <--  fx-moz19-staging-bootstrap.cfg
new revision: 1.9; previous revision: 1.8
done
Attachment #298314 - Attachment description: change hostnames in bootstrap configs → [checked in] change hostnames in bootstrap configs
I'll be updating all of these machines today.
I've update the master.cfg and bootstrap.cfgs for production-1.8-master and production-1.9-master. All of the production masters/slaves have got updated buildbot.tac files.

Once the staging machines finish their current run I will be updating those.
the staging 1.8 hosts have been updated
OK. I've got the staging 1.9 environment set-up now, too. I did a final check on the buildbot.tac files on every machine; nothing is referencing the old masters' names anymore.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.