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.
Related
I am using cygwin under windows server 2008 to have linux capability (to some degree) and ssh and be able to run apps without using a gui.
On another server that is ubuntu 18.04 I use containers to some how isolate my apps so that when I run an app and it spawns child processes and probabley modifies file descriptors etc (and so now I can not keep track of which processes are running now) I can stop my app and all the mess that it has done, with just stopping the container.
Containers made starting and stopping an app a clean and simple way.
Is there any way to have such thing on windows (without using docker on windows)? by saying this I mean the file and process isolation and not network or other stuff.
Is it possible to only isolate processes so that i can get rid of them with a single command?
Is there any tool for that? particularly for cygwin under windows?
I don't know about other languages but if you're using Python, it has a feature called Virtual Environment and developer can create and run applications in isolated environments. you can learn more about it here.
I myself come to the conclusion that using services and creating a service in windows would be the only way to manage an app without using a container.
Torch is a scientific computing framework with wide support for machine learning algorithms. It is easy to use and efficient, thanks to an easy and fast scripting language, LuaJIT, and an underlying C/CUDA implementation.
Q:
Is there a way to install torch on MS Windows 8.1?
I got it installed and running on Windows (although not 8.1, but I don't expect the process to be different) following instructions in this repository; it's now deprecated, but wasn't deprecated few months ago when I built it. The new instructions point to torch/torch7 repository, but it has a different structure and I haven't been able to build it on Windows yet.
There are instructions on how to install Torch7 from luarocks, but you may run into issues on windows as well; I haven't tried this process. It seems like there is no official support for Windows yet, but some work is being done by contributors (there is a link to a pull request in that thread).
Based on my experience, compiling that deprecated repo may be your best option on Windows at the moment.
Update (7/9/2015): I've recently submitted several changes that fix compilation issues with mingw, so you may try the most recent version of torch7 and follow the build instructions in the ticket. Note that the changes only apply to the core lib and additional libraries may need similar changes.
This webpage hosted by New York University recommends installing a Linux virtual machine in order to run Torch7 on Windows through Linux. Another option would off course be to install a Linux dist in parallel with Windows 8.
Otherwise, if you don't mind running an older version of Torch, there is a Windows installer for Torch5 at SourceForge.
I think to use a GPU from inside the virtual machine, the processor and the motherboard should not only support VT-x , but VT-d should be supported too.
But the question is, if I use a CPU with VT-d supported, do you think there will be a significant loss in PCIe connections efficiency?
From what I understand,
VT-d is important if I want to give the virtual machines direct access to my hardware components (like PCI Express cards). Like directly attach graphics card to vm instead of host machine. Isn't that mean that the PCIe connections efficiency will be the same just like if it was the host?
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.
Hello I've been a Rails developer on Windows for quite some time now, but I recently completed my biggest project yet (it's quite extensive, took me over a year to build) but I am having trouble deploying it. The combination of it's size, complexity and a windows environment is making it needlessly complex to deploy. I am thinking about getting an old mac mini and using it just for rails development.
Either that or install unix on another box.
Is there any way I can port my app to this mac or linux machine, without having to start over? I can't find any resources on the internets about this.
Rails is designed to be fairly platform flexible. What gems are you using in your application that won't run on linux / OS X? Usually compatibility issues run the other way (as very few Rails professional developers run Windows). It is hard to debug when you don't include any of the errors you get, etc.
Unless you have very specific system calls in your app there shouldn't be any need to "port" anything as it should work as is on Linux or OS X. Out of curiosity, what kind of problems are you running into with deployment?
I am working on a Rails project and the Architect has asked me to investigate bundling CouchDB into to application so that it can be deployed by Capistrano across multiple platforms and managed by Rake.
My expectation was that I could set up the Erlang VM on the various environments and then distribute the CouchDB application with Capistrano. However I can't find any option to download CouchDB without the Erlang runtime. I can, however see an option to build CouchDB from source which I assume is platform dependent.
I am new to Erlang and CouchBD, am I missing something? Is there a way to bundle CouchDB into a Rails app and distribute it across multiple platforms?
Have a look at some of the tools for provisioning Rails services (such as passenger_stack). Passenger Stack will download, make and install the ancillary services for your Rails app ... might be something you can adapt or use as a base to install Erlang and CouchDB.
There are a bunch of alternatives to this as well. Deprec contains recipes for provisioning with Capistrano. Essential idea is the same though.
I think you will not find a silver bullet. Distributing Erlang is similar to distributing Ruby; however Ruby has the advantage of being included in many default OS installs.
I know ejabberd has pre-built binaries for many distros. You might investigate how they do it.
The correct solution probably depends on how many "multiple platforms" you are targeting. If it's "Ubuntu 8.04 plus Ubuntu 10.04" that is different from several Linux distros, plus OSX, plus FreeBSD. Typically only open source projects support those many platforms and ideally you can get patches from the community. For internal projects, I have seen teams standardize on a Linux build and use virtualization on Mac/Windows.
But back to your question:
Building from source is a reasonable option. You could build when you deploy, or pre-build for all platforms and then deploy the binaries. Both Erlang and CouchDB use Autoconf which means you can --prefix them to a dedicated location (more-or-less standalone apps). It will take some trial and error but your build script can
Platform-specific dependency setup: gcc, make, autoconf, everything you need. apt-get on Ubuntu, yum on RHEL, Macports, whatever you need to get a common platform on your development and deployment system
Compile and install the rest using the tools from step 1. Use configure --prefix=/opt/my_software to keep it all in one place. (You can totally uninstall with rm -rf.)
This is an medium-level challenge--mostly trial and error. If possible, work within a build framework such as Rake or Toby's suggestion passenger_stack. Good luck!