Here's how I would do this (would others check me on this?) This is my best attempt, but YMMV.
Start with capacity planning. Look at $JENKINS_HOME on the server you now have. Make sure that the new server can handle the size of that directory structure and the rate of growth it has. Your server probably won't take a lot of CPU, but it takes in all the job logs and HTTP hits, so you may need to worry about disk and network I/O. Make sure that your new server is at least as well connected as the old server was, and that its disks are as big and as fast. You may need more disk than you did before if you intend to keep the slaves running on the new server as well. While you're at it, "well-connected" implies that the new and old machines aren't on different sides of a firewall; if they are, make sure that slaves can still talk to the new machine the way they want to. If you're convinced that the new machine can handle the load, your next step is to look at your slave configurations and external jobs. Slaves that aren't launched by Jenkins (such as ones set up as Windows services or Unix daemons) expect the Jenkins server to be in a certain place, while slaves that are launched by Jenkins will have no problem being launched from a new machine. Also, if you have external jobs (which are launched without Jenkins and just report to it), their configuration tells them where the Jenkins server is. Compile a list of slaves and jobs that aren't launched by Jenkins. Fire up a Jenkins server on the new host, with no configuration, just to make sure it shows up where you expect it. When you have it in the right place, shut it down. Shut down the old Jenkins server. Remember, if you ask Jenkins to shut down gracefully, you'll have to wait for all running jobs to finish. Copy $JENKINS_HOME from the old server to the new one. Fire up the new Jenkins server. It should look like the old one. If not, you can either fix the configuration right away, or "roll back" by shutting down the new server and starting up the old one while you regroup. Go through that list of external jobs and servers, and reconfigure them to talk to the new server. Your downtime should roughly be the amount of time it takes to copy $JENKINS_HOME over (you can just copy it over once just to get an idea how long it will take), plus the time it takes for the old server to gracefully shut down, plus a few minutes to start up the new one and convert the externals. If you expect to have to move the server from host to host from time to time, ask your admins to make a DNS alias (or some other sort of secondary hostname) that can follow the server around. If you have an alias called "Jenkins", and can move it from box to box as you move the server around, you can tell all the external stuff and your users to connect to "http://jenkins:8080"; and have one less thing to worry about. -----Original Message----- From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Mehul Sanghvi Sent: Friday, April 27, 2012 3:37 PM To: jenkinsci-users@googlegroups.com Subject: Difficulty of converting an existing slave to a master ? We currently have a Jenkins slave server and were considering converting it to become a master server. How difficult is that process ? I have not done it before, and although I will be making backups, I just want to ensure that we do it properly and do not loose data. At the same time, I would like to be able to give a proper estimate to management about how long it will take, etc. cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.
