I am trying to upgrade Jenkins from version 2.176.1 to 2.375.2. I tried two methods and both of them failed.
Method-1: Download the jenkins.war and copy it into /usr/lib/jenkins/ directory by replacing the original one. After copying, when I restart Jenkins, it simply fails to restart.
Method-2: Upgrade Jenkins' RPM using yum update jenkins. This command runs successfully and process exists without any error. But, again when I restart Jenkins, it fails to start.
CentOS version: CentOS-7
First of all - I can only support opinion of Dmitriy Tarasevich about reading upgrade guides. You can find theme here: https://www.jenkins.io/doc/upgrade-guide/
Then - stick to the version upgrade process that you've used previously (or for the first time with installation). If you did install it via .*war, don¨t worry and use your Method-1. On the other hand, if you used yum, stick to that method-2.
Then - such a "big" upgrade at once from 2.176.1 to 2.375.1 is, I'd say, the reason it's failing for you as the version in between contain several major/breaking changes (our team has faced the same problem (we "just" wanted to bump the versions too much after a long time of no upgrading and we've faced several problems we weren't able to solve together). So it was necessary to split it into several independent upgrades which appeared to be doable and we managed to get to LTS 2.375).
To summarize recommended steps - I'd you need to:
1/ Split your upgrade into several steps and upgrade LTS more gradually: try to upgrade to first to some not-current LTS version. I believe something less than or precisely 2.303.3 could work and see if you can start it.
then actually run Jenkins and check administration page,
upgrade your plugins (if you want). FYI: this is recommended officially in Jenkins docs after every Jenkins core upgrade.
check Jenkins administration page and apply necessary changes / manage necessary decision that might appear there (if applicable).
2/ Try to upgrade to a higher LTS version (repeat step 1 with its sub-steps)
To be a very specific and give some examples (although I don't remember everything by hearth):
you skipped a gradually upgrade to version 2.319 LTS that brings a major change of working with master node --> built-in node that needs to be applied (confirmed) from within the administration section of Jenkins (see docs: https://www.jenkins.io/doc/book/managing/built-in-node-migration/ )
version 2.332.1 LTS brings an important change. I would say that you've hit exactly this issue (covered here): https://community.jenkins.io/t/jenkins-cant-find-java-after-update-running-on-centos-7/3615 - exact steps and more resources are within that thread and also here: https://www.jenkins.io/doc/upgrade-guide/2.332/#upgrading-to-jenkins-lts-2-332-1
from version 2.361 LTS Jenkins requires Java 11 or higher (see docs https://www.jenkins.io/doc/upgrade-guide/2.361/ ). So - you will need to ensure that you have a proper Java installed (you already might have it though). Including your agents!. Otherwise you would start your Jenkins but it would not connect any agent (usually undesired state).
Please, try to make some gradual progress and let us know where you managed to get
Related
Let's say I have old, unmaintained application that lives on a VPS (i.e. Symfony 3 PHP app that relies on PHP 5).
If some changes are needed I have to clone this app to my desktop, build it, change and re-deploy. As time goes, recreating desktop dev environment gets harder - in this example I can't simply build the app as I use PHP7 in my CLI that breaks building process.
I tried to dockerize the app, so I added Ubuntu 18 to my docker-compose file... and it doesn't work as latest Ubuntu that has PHP5 support is 14.04. 14.04 is also the oldest (official) version available on DockerHub. But will it be still available in 3 years? If not, Docker won't build a container.
So, my question is: is Docker a right tool to solve described problem at all?
If so, should I backup docker images described that my build relies on?
If not, beside proper maintenance, what tool is better?
You can install PHP5 in newer ubuntu versions, but it means adding an external repository.
You could also create your own docker image, containing only the libraries you want. If so, I'd advise to try and use alpine as a base image. There is a bit of a learning curve to adapt, but once you do it you'll have a small image tailored to your needs.
Given that containers allow you to isolate processus and conf with minimal footprint compared to a VM, I think it is the best option. Tailoring and maintaining your own image is not that expensive in terms of maintenance if you document it correctly, and it will allow you to always have a system 'maintaining' all your precise requirements.
I am current running version is 2.7.4 of Jenkins. However can I upgrade directly to 2.32.x or do I have to go through 2.19.x? The documentation does not specify that: https://jenkins.io/doc/upgrade-guide/
Once you are on 2.x Jenkins, you can upgrade to latest 2. But if this is important (which I'm guessing it is since you asked online before just trying it), backup your JENKINS_HOME first. Even though I trust this upgrade, we prepare rollback procedures for anything like this. For us we have a drive for the OS, and a drive for Jenkins data, which makes cloud/local backups/rollbacks easy.
I installed OpsCenter 6 on an EC2 Ubuntu 14 node.
I used OpsCenter to generate a 5-cluster DSE 5 cluster, one node for each type of workload. (I excluded hadoop since it is deprecated.)
I've got the cluster working.
Now, when I go back to OpsCenter, and go back into Lifecycle manager, I want to be able to edit the Config Profile so that I can use OpsCenter to maintain the cluster configs. When I click on Config Profiles, I see two clusters defined. When I click on my most recently built cluster, I don't see any config template files listed underneath Config Profile for my selected cluster?
OpsCenter Lifecycle Manager (aka LCM) developer here...
Your config-profile is almost certainly set to use DSE 5.0.0 as its version. Unfortunately, due to a serious bug (http://docs.datastax.com/en/latest-dse/datastax_enterprise/RNdse.html#RNdse__cfs10299), DSE 5.0.0 had to be pulled from distribution. As a result LCM config profiles for DSE 5.0.0 are no longer editable. It would be nice if we had a more obvious error message around this condition, but at this point the config-profile simply shows up as empty.
The workaround is described in https://support.datastax.com/hc/en-us/articles/211700063-Lifecycle-Manager-Deprecation-of-DataStax-Enterprise-5-0-0. In short, you need to manually upgrade your cluster to DSE 5.0.1 (using apt or yum), then re-create your config profile (either manually if its mostly defaults and re-creating is easy, or using the curl commands if you have heavily customized your CP and can't remember how to manually re-create it).
Removing support for existing versions of DSE is a very rare occurrence, and you shouldn't expect to see a problem like this again soon.
My question, is there a way to configure the InstallShield setup and deployment project so that when I attempt to install the service it will uninstall the previously installed version of the service.
I've created a Windows Service and an InstallShield setup and deployment project to be able to install it onto my machine. The process of installing and uninstalling the service all works fine. When I go to update the service, at the moment, I need to stop the service, uninstall the service manually, and then run the installer. What I am trying to get to is a point where I can run the installer and it will uninstall the previous version of the service before installing the current version.
I have seen this process of running the install and having the previous versions uninstalled work. Through creating a test project using a windows form application. I was able to install the application. Then I: incremented the product version, created a new product code, added a new upgrade entry in the upgrade path area, and configured that upgrade entry setting the min and max version. After doing this, I rebuilt the setup project and ran the installer and the upgrade from version A to version B was complete.
The only difference I believe from the original test project (where I saw the process work) and my Windows Service project is that my test project was a Windows Forms application versus a Windows Service. In all the research I have been doing I have seen people ask similar questions, but I have not seen any real suggestions on what actions to take. So if anyone knows if this is possible or has any suggestions that I could try to accomplish this task they would be greatly appreciated.
I was able to resolve this issue, so it is possible. The setting I mentioned above are the correct settings needed to allow the service to update. This was just a case of human error that was causing my problems.
We need to update Ranorex licence server from version 5.1 to version 5.3.
What is the proper approach to not break the running tests?
I searched on the Ranorex homepage for this issue yet, without finding anything.
Normally, a simple upgrade should work, but wouldn't it be safer to upgrade the license server when no tests are running?
The best way in order to upgrade the license server is uninstalling the old version, restart the machine and install the new version. Usually, it also works if you just run the setup file without uninstalling the old version, but I prefer the uninstall - restart - install approach.
The answer of user1982826 is good. As in meantime the official Ranorex Support has answered my request, I want share their answer:
Generally with the server upgrade the service will be reinstalled and restarted. Depending on how long that lasts (e.g. dependant on the computer), the connection on the client may time out and the test will break. So it would be safer to update the server, when no test is running.