I am trying to run a specific OTP release version built at server, but I have no idea how to do so.
In the releases directory, I have those releases:
releases/0.0.3
releases/0.0.4
releases/0.0.5
I have ssh through the server, but I don't how to can I start a specific release to start?
Give kerl a try. It's ideal for switching between different versions.
Related
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
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.
Some of modern infrastructure components such as Yaws and CouchDB can be installed on Ubuntu with
sudo apt-get install
and then they can be started with
{service_name} start or simply {service_name}
I wonder if there are any differences between this approach and the Erlang/OTP way, that is uploading an OTP release to the production server and then starting it with a rebar-generated script.
What is the industry standard? Install/start a repository-based binary or upload/start a rebar-generated release?
Also, do the repository-based binaries have all the OTP functionality in place, like OTP applications structure, supervision and the option to attach to the live application via console?
Every time, you are starting erlang, you are starting a release. Even, if you only type erl in terminal, it runs a release (you can find the .boot, .rel and .script files in erlang_rootdir/releases/name_of_release.
I think this answers your last question: packages installed from repository still have the OTP structure, supervision and all the goodies. There are just couple of bash scripts, that make starting and stopping them more friendly to someone used to service_name start. You should also be able to find a script similar to the one generated by rebar.
Check, where are those files and simply cat them. You should see, they simply start Erlang release.
The only thing, that you can't do with package managers, is hot code upgrade. Most package managers simply stop the running application, install new version and start it back. In Erlang, you can upgrade running release, but this is quite advanced stuff. Besides that - there are no disadvantages of using OS packages.
I have Erlang application running on R13 version of Erlang VM.
I want to upgrade VM to R14 without stopping the application.
How cay I do live migration of the application between
different versions of Erlang VM?
You need two things:
a) Lots and lots of planning.
b) An application that runs on several nodes.
The usual trick is to take down part of your node cluster and upgrade that to the new version. It should be able to talk to the older nodes. Then bump the older nodes when the new version of Erlang has taken over.
Erlang does not provide this kind of upgrade for free. It does make it much less painful though.
Short answer, you can not.
This is because applications compiled for the new version of the BEAM emulator (Erlang VM) would not run properly on older versions of the emulator.
Or in more details:
Upgrading an applications without stopping it can only be done using release handler. But release handler can only upgrade applications running in the VM, not the VM itself. You can still prepare a relup file but when systools:make_relup/3 notices that the new release uses a different version of the BEAM emulator it will add the instruction restart_new_emulator (Low-Level) to restart the node during the upgrade (see the description for restart_new_emulator on the page I mentioned earlier).
What you could do, however, is upgrading the Erlang VM without interrupting the service (assuming your application provides some service to an external party). But that very much depends on the architecture of your application and has no generic answer.