Closed Bug 392438 Opened 17 years ago Closed 16 years ago

upgrade community Windows machines to the new ref platform

Categories

(Webtools Graveyard :: Tinderbox, defect, P2)

Product:
Webtools Graveyard
Component:
Tinderbox
Platform:
x86
Windows Server 2003
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kairo, Assigned: mrz)

References

Details

This is the Windows version of bug 389426 ;-)

Now that we have a MSYS-based Windows ref platform with VC8SP1, we probably should upgrade the community tinderboxen for SeaMonkey and Sunbird to that one.
from offline discussion:

- we'll bring up a new VM on our internal build network and make sure community builds work on it
- shutdown existing community VM
- copy (not VMmotion) the new VM to the community build machine
- start new VM on community build machine.

Some discussion about how much of this should be done by build group rather then by community members.
Priority: -- → P3
This is blocked on new hardware for another community ESX box, as the current one is full (disk space).
Blocks: 394707
Blocks: 322568
We can try to make some progress on this later this week or early next week once 3.0b1 is out the door. 

As John mentioned, due to VM host capacity issues we'll be spinning up the replacement VMs on the Mozilla build network and then moving them out to the community VM host.
Assignee: build → ccooper
Still haven't found the perfect Moz VM host for this (we need to do some rebalancing), but I'm planning to set up a new SeaMonkey VM on (or before) next Tuesday, Feb. 19th.
Status: NEW → ASSIGNED
Priority: P3 → P2
Depends on: 420772
VM host is producing proper builds (according to KaiRo). Filed bug 420772 to get it moved to the community VM host, at which point we can clone it for Calendar.
ause: I assume Calendar wants a copy of the new ref platform too? Any objection to me cloning the SeaMonkey VM for you on Friday March 28th?
i would like to understand some details of the transition first. will try to reach you on irc
Re-assigning to IT so they can find the best VM host for this internally, since they have asked to regulate this process so that our internal VM hosts don't get accidentally overloaded.

IT: we need a new copy of the Windows ref platform VM for the Calendar team cloned onto the *internal* network. There is no room for a new VM on the community host. We'll have to do the old internal->community host dance again once the output has been verified. 

Host/VM name should be something to distinguish it from the current Windows tbox (sb-win32-tbox), e.g. sb-mozbuild-win32-tbox.
Assignee: ccooper → server-ops
Status: ASSIGNED → NEW
Assignee: server-ops → mrz
cb-vmware01 has plenty of disk space (300GB) - can I just clone it to there?
Box up as 10.2.71.213.
Assignee: mrz → build
Currently sb-win32-tbox is burning due to missing SDK upgrade (Bug 425974). Should this be fixed together with this bug? Is there an estimation when this would happen?
Blocks: 425974
Assignee: build → ccooper
ause: the new box, sb-mozbuild-win32-tbox, is up on the internal network. I've setup identical trees to those currently on sb-win32-tbox. If it survives the weekend, we can move it to the community network early next week.

The builds are reporting to the same trees as sb-win32-tbox, and the packages are headed to the experimental/ directory for each product.

Things to note for after we make the switch:
1) The tinderbox-config files are *not* being updated from cvs right now to prevent the changes (experimental/ and such) from being clobbered.
2) Change the mail profile for blat, or verify that the old still sends mail.
3) Start tinderbox using multi-tinderbox.pl from /e/builds/tinderbox (it's an MSYS thing).
Status: NEW → ASSIGNED
A little directory permission issue on stage prevented the builds from being uploaded over the weekend. Nick fixed the permissions this morning and I uploaded the builds that had failed. If someone can check them out for correctness, we'll move this machine into production ASAP so you can stop dealing with the cygwin box.

The l0n builds were failing due to a config typo. I've fixed it, and I'm running a one-off l10n series now to get some results into tinderbox for verification.
(In reply to comment #13)
> If someone can check them out for
> correctness, we'll move this machine into production ASAP so you can stop
> dealing with the cygwin box.

Sunbird build from ftp://ftp.mozilla.org/pub/calendar/sunbird/tinderbox-builds/SB-MOZBUILD-WIN-trunk/ and Lightning build from ftp://ftp.mozilla.org/pub/calendar/lightning/tinderbox-builds/SB-MOZBUILD-WIN-trunk/ work as far as I can say after a quick check.
(In reply to comment #13)
Packager can't find the VC8 runtime libraries. Maybe environment variable WIN32_REDIST_DIR is not set to the correct path.
(In reply to comment #15)
> (In reply to comment #13)
> Packager can't find the VC8 runtime libraries. Maybe environment variable
> WIN32_REDIST_DIR is not set to the correct path.

Added WIN32_REDIST_DIR to the .bash_profile on the VM and restarted tinderbox. 


(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #13)
> > Packager can't find the VC8 runtime libraries. Maybe environment variable
> > WIN32_REDIST_DIR is not set to the correct path.
> 
> Added WIN32_REDIST_DIR to the .bash_profile on the VM and restarted tinderbox. 

Stefan; did setting WIN32_REDIST_DIR fix the problem?

I'm just trying to figure out what remains to be done before we can move sb-mozbuild-win32-tbox from our internal network out to replace sb-win32-tbox on the community VMhost. 
(In reply to comment #17)
The Sunbird (2008042417) builds that can be found via the links in Comment #14 do contain the VC8 runtime libraries now. I don't know if there are additional things that remains to be done before the move.
Downgrading to p3, while coop is on leave.
Priority: P2 → P3
The calendar team is ready to have this new box (sb-mozbuild-win32-tbox, current has IP 10.2.71,213) moved from the build network to the community network. If we could also have it renamed to sb-win32-tbox at the same time, that would be great.
Assignee: ccooper → server-ops
Status: ASSIGNED → NEW
Assignee: server-ops → mrz
What do you want done with the existing sb-win32-tbox?  Delete it?
keep the image for a while until the new box has completely taken over and then delete it...
Can I power it off?
(In reply to comment #23)
> Can I power it off?
> 

Yes, please.
IP should be 63.245.210.13, gateway 63.245.210.1 , netmask 255.255.255.224.  Nameserver can be 64.127.100.12 and 64.235.225.10 .  I found login info and changed.  

Back to you.
Assignee: mrz → build
old box seems to be down now but new one not yet reachable from jumphost for me .
Assignee: build → ccooper
I'm getting tinderbox running now.
Status: NEW → ASSIGNED
Priority: P3 → P2
mrz: the box can't send mail via mail.build.mozilla.org like the other community boxes right now.
Assignee: ccooper → mrz
Status: ASSIGNED → NEW
Shouldn't be any difference - is it getting the right IP for mail.build.mozilla.org ?
(In reply to comment #29)
> Shouldn't be any difference - is it getting the right IP for
> mail.build.mozilla.org ?

It's not getting any IP, just "Non-existent domain."


It's reporting to the Sunbird tree now after some help from mrz.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
(In reply to comment #21)
> What do you want done with the existing sb-win32-tbox?  Delete it?
> 
the new box is up and running. no more need for the old image.
Component: Tinderbox Configuration → Tinderbox
Product: mozilla.org → Webtools
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.