Community
Participate
Working Groups
barnraising1 (br1) is currently running FC5 and has gotten severely stale. It was set up when we were first experimenting with virtualization. Virtualization has since matured and made its way into our SLES OS of choice. I'd like to take some time in July to completely format br1 and install the latest SLES so that we can provision shiny new vservers that are up-to-date. It is likely that the vservers currently being hosted on br1 will no longer work with the upgraded OS, and a new image must be provisioned. Mylyn, AJDT, ECF and EMFT are the only four projects hosted on br1.
That's great news! Mylyn would like to keep a vserver to run test repositories. We would happily migrate to a new vserver image which also give us an opportunity to do some house cleaning.
AJDT will require a new vserver. Will all the old data be transferred over, or will that have to be done manually?
Any chance we can run something other than SLES? Like, say, Fedora 11 or RHEL5? We still can't get UI tests to run correctly on 64-bit SLES (bug 253114), and YaST is a nightmare to use...
> AJDT will require a new vserver. Will all the old data be transferred over, or > will that have to be done manually? You will need to backup all your configurations and data. > Any chance we can run something other than SLES? Unfortunately not, sorry.
Can you be more specific about when you are planning on doing this? We have lots of old build artifacts that we would like to back up and we' need to plan a way to properly set this up. As a side note, can you recommend a good way of moving all this data off of the build machine? Will something like rsync work through the firewall?
> As a side note, can you recommend a good way of moving all this data off of the > build machine? Will something like rsync work through the firewall? rsync can be done over ssh to/from build.eclipse.org, which has a ton of space these days. rsync (again, over ssh) can also be done from the outside world into your vserver, provided that your vserver's firewall is open to accept ssh connections from that IP or hostname. For example, run this (as root on the vserver) to allow connections from foobarbaz.homelinux.net to yourvserver.eclipse.org on port 22 (ssh): /usr/sbin/iptables -I INPUT -p tcp -s foobarbaz.homelinux.net --dport 22 -j ACCEPT # Nick Boldt (home) (In reply to comment #4) > > Any chance we can run something other than SLES? > Unfortunately not, sorry. What if I can score you some RHEL 5 licenses? I know a guy who knows a guy... :)
'some time in July' is all I have for now, sorry. (In reply to comment #6) > What if I can score you some RHEL 5 licenses? I know a guy who knows a guy... That's a great offer, but there is tremendous value in having the same OS base across all our servers.
(In reply to comment #7) > 'some time in July' is all I have for now, sorry. > (In reply to comment #6) > > What if I can score you some RHEL 5 licenses? I know a guy who knows a guy... > That's a great offer, but there is tremendous value in having the same OS base > across all our servers. <religious flame mode on> There's tremendous value in having a *good* OS base across all your servers. ;P </flame off>
(In reply to comment #8) > <religious flame mode on> > > There's tremendous value in having a *good* OS base across all your servers. ;P > > </flame off> Hey, is the marketing department paying bonuses over there? ;) Seriously, though, we made this decision a long time ago, at which time I believe there was no RHEL that ran on the POWER5 boxes. Additionally at that time Novell gave us licenses and support. For various reasons we have some Fedora boxes and we've been fighting with the inconsistencies between the SLES boxes and few Fedora boxes as our custom tooling has to be modified to run on the Fedora boxes. Major pain.
(In reply to comment #9) > Hey, is the marketing department paying bonuses over there? ;) I wish. ;P > I believe there was no RHEL that ran on the POWER5 boxes. AFAIK RHEL 5 does play w/ ppc arch, but fair enough. /me puts down the sword and wanders off to find a new crusade...
Scheduling this for the week of July 13. I don't know which day yet, most likely Wednesday July 15. Please make sure you have backups before that, since I can almost guarantee your existing images will not work on the new setup.
Denis, please coordinate with us (ECF) before you take the old box down. Obviously we want to take the backup of the MySQL database of the Openfire XMPP server running on ecf.eclipse.org as late as possible and not lose any data. Thanks
This server will be put offline Wednesday July 15 at 9:00am ET for a fresh OS installation. Please make sure you have backups before that, since your current vserver images will not be compatible with the new environment.
(In reply to comment #13) > This server will be put offline Wednesday July 15 at 9:00am ET for a fresh OS > installation. Please make sure you have backups before that, since your > current vserver images will not be compatible with the new environment. Uh... where can I back up 27G of disk usage on emft.eclipse.org? build.eclipse? Or should I take this oppty to move everyone onto modeling.eclipse for once and for all, and make emft.eclipse obsolete?
We have used archive.eclipse.org for backups in the past with permissions set to non-world readable.
(In reply to comment #14) > Or should I take this oppty to move everyone onto modeling.eclipse for once and > for all, and make emft.eclipse obsolete? The current GEF builds do not work 100% on modeling.eclipse, if I remember correctly, only the JavaDoc issue remains? I will have to look. Other builds, such as GMF, EMF Transaction, etc. have not even ran before on modeling.eclipse, so I am a little concerned about the "lets get rid of emft.eclipse" statement. Can we do all this testing work in one week?
archive.eclipse.org is a sensible spot. build.eclipse:/shared is even better. BTW -- why not move the builds to build.eclipse.org?
(In reply to comment #16) > (In reply to comment #14) > The current GEF builds do not work 100% on modeling.eclipse, if I remember > correctly, only the JavaDoc issue remains? I will have to look. Sounds about right, and that's probably related to 32-bit vs. 64-bit assumptions in the shell script / ant tasks used to gen the javadoc. That hacktacular bit of crap predates the EMF build, and really needs to be thrashed, smashed and ultimately trashed. > Other builds, such as GMF, EMF Transaction, etc. have not even ran before on > modeling.eclipse, so I am a little concerned about the "lets get rid of > emft.eclipse" statement. Well, whether we resurrect it as a SLES 11 box called emft.eclipse w/ more space and ram or move 'em to modeling (which is also SLES 11 box) it's the same issue. I prefer to consolidate since we have lots of room on modeling.eclipse, and don't have the time/desire to set up yet another server - especially one that needs me to deal w/ YaST. /me shudders > Can we do all this testing work in one week? Unlikely - it's the summer, and I have two upcoming milestones for JBoss Tools to deal with this week too. Unless "we" means "you", in which case don't let me put words in your mouth. :) > BTW -- why not move the builds to build.eclipse.org? Because then we have to deal w/ PPC Eclipse and IBM JDKs, which may introduce different problems w/ UI tests or javadoc generation (or signing, or packing...). That said, GEF does build on build.eclipse.org using the Athena system via Hudson; however, javadoc is still not yet hooked up there either. Patches welcome - see bug 256211 and bug 269290. I guess you could go back to running GEF on emf.torolab in the short term, if you don't have cycles to look at how to fix the javadoc. Or we could beg, borrow, and please w/ Denis to delay things a little...
Because a number of people have asked "what do I do to migrate?" here's a quick write up of the steps and options. http://wiki.eclipse.org/Modeling_Project_Releng/Migrate_to_a_new_server
I can certainly delay this if you need more time. I just picked July 15 out of the blue. How about August 5?
(In reply to comment #20) > I can certainly delay this if you need more time. I just picked July 15 out of > the blue. How about August 5? > Given that we (TMF/Xtext) planned to release a minor update on July 17th it would be great if you could postpone this a bit. August 5th would be perfect! :-)
Ok, I have rescheduled this for Aug. 5. Don't say I never do anything nice for you guys... :-)
Aug 5 works for me. I'll be on vacation and very AFK from Aug 8-17, inclusive, so that gives us a couple days after the shutdown for freak outs. :) (On the subject of freak outs, I'd love to have someone other than me be root on modeling.eclipse.org - it's just not wise to have a single person with the keys to the Porsche. Anyone from Modeling want to share the responsibility here?)
(In reply to comment #23) > (On the subject of freak outs, I'd love to have someone other than me be root > on modeling.eclipse.org - it's just not wise to have a single person with the > keys to the Porsche. Anyone from Modeling want to share the responsibility > here?) I can help, but do we need anyone to know the root password? In an "emergency", can we simply ask the webmaster to add us to /etc/sudoers? I have found for the most part that everything is owned by the apache account and I sudo to that use to fix build related things.
(In reply to comment #24) > I can help, but do we need anyone to know the root password? > In an "emergency", can we simply ask the webmaster to add us to /etc/sudoers? Webmaster policy is that vservers are "owned and operated" by committers, not by webmaster. If we want to use a box for which webmasters have root, there's build.eclipse. modeling.eclipse is "owned" by me. I'll send you the root password separately by mail. Thanks for offering to back me up.
Would emft login (user/pass) work for modeling.eclipse.org, or need I a new one? If so who can create one for me? I need also permissions to run builds and promotions. (In reply to comment #25) > (In reply to comment #24) > > I can help, but do we need anyone to know the root password? > > In an "emergency", can we simply ask the webmaster to add us to /etc/sudoers? > > Webmaster policy is that vservers are "owned and operated" by committers, not > by webmaster. If we want to use a box for which webmasters have root, there's > build.eclipse. > > modeling.eclipse is "owned" by me. I'll send you the root password separately > by mail. Thanks for offering to back me up. >
(In reply to comment #26) > Would emft login (user/pass) work for modeling.eclipse.org, or need I a new > one? > If so who can create one for me? > I need also permissions to run builds and promotions. Chances are your permissions are already copied over - I ported most users ages ago, and anyone added since then has been added to both boxes (emft and modeling) in parallel. I've reset your password for modeling.eclipse - check your mail for details.
Just a reminder that you have 1 week to backup your data. -M.
mylyn.eclipse.org has recently disappeared. Webmasters, do you have an approximate ETA for access to the new vserver?
I'll guess early next week. Matt was having some issues with the boot disk yesterday.
Ok, everyone should now be back up. I've sent keys out to your 'new' vservers to the PLs involved. -M.
