Difficulty of converting an existing slave to a master ?

[Mehul Sanghvi]

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....@gmail.com

[Mandeville, Rob]

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.

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.

[Jan Seidel]

I'm a bit in a hurry so the straight forward no remorse strategy I would use is:
- Disable all the jobs running on the slave and keep the folder so you have always a fallback.
- Mark the slave as offline and stop the service
- Copy the folder of the master to your slave.
- on the slave: Delete the secret key file in the folders top level (optional but worth doing so)
- on the slave: Delete all obsolete jobs.
- on the slave: Create folders in the "jobs" folder if you have new jobs from other machines and copy the config.xml into it. Jenkins will the read the configs at startup and show them in the job list.
- Shutdown the orignal master and fire up the new master.
- Make all changes you want/need to do so the old and new master do not interfere (remove the slaves if you have more executors running on other machines)
- Start the old master and you should have two running masters.
- You will need to re-enter the credentials on the new machines as the secret key are missing/wrong.

have fun
Jan

[Mehul Sanghvi]

I realised I was not clear enough before.

I have an existing slave server and what I want to do is
convert it into a standalone Jenkins server that my group
can use on its own. Some of the jobs on the slave
would get deleted, but other then that, no jobs from
the existing master would get copied over as we have no
need for it

[Sami Tikka]

There is no way to convert a Jenkins slave to Jenkins master. All
installed software and configuration resides on the master. There is
nothing on the slave to convert.

If you want to use the slave server to run a Jenkins master, you are
basically talking about installing a new Jenkins master.

If you want to copy/move some jobs from the old master to the new one,
you can do it with the Jenkins cli (more info at $JENKINS_URL/cli).
However, it would be best if you had identical plugins installed on
both.

-- Sami

2012/4/30 Mehul Sanghvi <mehul....@gmail.com>: