View source for RACK

= RACK (Real Application Centric Kernel) =


== Project Resources ==
{| border="1" cellpadding="2"
| '''Resource'''
| '''English '''
| '''Japanese'''
|-
| Wiki
| https://wiki.openstack.org/wiki/RACK
| https://wiki.openstack.org/wiki/RACK/ja
|-
| Source code
| https://github.com/openstack/rack
| 
|-
| Deployment guide
| https://github.com/openstack/rack/tree/master/tools/setup
| https://github.com/openstack/rack/blob/master/tools/setup/README_ja.md
|-
| Sample applications
|
* https://github.com/ctc-g/rack-sample-apps/tree/master/montecarlo
* https://github.com/ctc-g/rack-sample-apps/tree/master/shell-like
|
* https://github.com/ctc-g/rack-sample-apps/tree/master/montecarlo/README_ja.md
* https://github.com/ctc-g/rack-sample-apps/tree/master/shell-like/README_ja.md
|-
| Python RACK client
| https://github.com/openstack/python-rackclient
| 
|}


== The concept of RACK: "OpenStack Native Application" ==

OpenStack Native Application is the software, which uses OpenStack resource (eg. VM or VNET) directly from application.
Recent popular applications are designed before the cloud computing age, so affinity with cloud is not considered.
In order to make those applications work on OpenStack, tools such as Chef, Puppet and other tools are required, and it makes systems very complex in design.

RACK provides the mechanism to create “After the Cloud” applications.
Programmer can write codes that are scalable and migratable on OpenStack platform without cooperating with the external systems.

Concepts of RACK are as follows:
# RACK handles VM with "functions" as a single execution binary file. “Functions” here means OS, middleware and programs that are necessary for application to function. The programs here are made in such a way as to call and operate RACK API.
# When this execution binary is deployed onto OpenStack, the VM will behave like a Linux process and then finish its own task.
# This process is based on the descriptions in the program. It does things such as forking and generating a child process, communicating between processes.


Please take a look at the sample programs to experience RACK!
* https://github.com/ctc-g/rack-sample-apps/tree/master/montecarlo
* https://github.com/ctc-g/rack-sample-apps/tree/master/shell-like

[[File:RACK-Process-Image.png]]


== What is RACK? ==

RACK defines data structure in order for VM to behave like a "process".
It wraps Nova, Neutron and other APIs.
Also it provides API to control data communication and sharing.
Applications have to be scripted by order of calling the APIs.
The RACK also offers libraries [https://github.com/openstack/python-rackclient|python-rackclient] for using APIs.
It is very easy to write OpenStack Native Application codes by using the libraries.
The RACK may be recognized as framework for writing OpenStack Native Application.


== What we call "process" ==

When using RACK, you might often hear a word “process”.
This process is a virtual machine instance on Nova.
However, this instance is created in such a way as to perform some tasks when it is started.
This is similar to various execution files of Linux, which start to operate when "ls" command or "grep" command is executed.
In Linux, the started execution file will become a process on memory, it handles tasks, exits and disappears from memory at the end.
RACK reproduces this concept on OpenStack.
It deploys the glance image (with features) on Nova, and the deployed instance performs its task and then disappears at the end.
This is the reason why a virtual machine is called "process" in the RACK world.

The VM instance that is started as a process has a PID, possible to perform "Fork" and it has a parent-child relationship.
Additionally, it is possible to communicate without IP address and share data among these processes (VMs) that have such relationships.
The file system with the same name space is also available, and the programmer who creates this execution binary can describe the OpenStack Native Application as if programming a Linux.


== Architecture ==

RACK has a database defined with the data structure to handle VM as a process.
RACK provides Restful API to manipulate the data structure.
Once it receives an order from the application, it calls OpenStack API, and then writes the attribute info of the process into its own database.

[[File:RACK-Architecutre-Overview.png]]

=== Attibutes of a process ===
The attribute information of the process includes the followings;

* keypair, security-group, network
Each process holds above IDs as attribute information.

* GID (group ID)
Each process belongs to one group.
The process belongs to the same group has a benefit such as file sharing in the same name space.

* PID, PPID
Each process holds its own ID (PID) and the parent's IP (PPID).
These IDs represent the parent-child relationship between processes.

=== rack-proxy ===
There is a "rack-proxy" process in each group.
"rack-api" prodives the public API, and the "rack-proxy" on the other hand provides an accessible API only to the particular group.
File system and interprocess communication would be handled by "rack-proxy".

=== Deployment of rack-api and rack-proxy ===
"rack-api" is deployed in an independent network and it is accessible from public.
"rack-proxy", which exists in every group, is booted by calling the "rack-api" API.
"rack-api" and all "rack-proxy" share the same database.

[[File:RACK-Topology.png]]

Curretnly, "rack-api" and "rack-proxy" are booted as VM.
Our future plan includes followings:

* '''rack-api runs as Linux process in OpenStack controller node like nova-api.'''
* '''rack-proxy runs as Linux process in OpenStack network node like nutron-ns-metadata-proxy.'''


'''Since this area is closely related to the OpenStack core project, they are deployed as VM at the moment.'''


=== Interprocess communication support ===
RACK has the ability to support interprocess communication and data sharing as well as data structure manipulation, booting process and shutting down as described above.
They are realized by combining libraries.

[[File:RACK-Features.png]]

* File system
It provides a file system that is shared within the group.
Process can access to files with the same name space just like accessing to local file system. 

* Shared memory
This is a function for sharing simple data between processes.
It is usable when accessing the same data by multiple processes.

* Pipe
It provides Unix-pipe like functionality.
The result of process can be piped to the other process very easily.
No need to know the peer IP address or wait until the peer boots.

* Signal
It is a function that can send strings to any process only by specifying a PID.
It may send the strings to multiple processes by multicast.


== Use cases ==

You can use RACK in any ways.
Anything from adding/deleting process, data sharing and data notification among processes are describable by program.
Using RACK enables you to develop applications such as OpenStack Native and others easily.

As tips on how to use RACK, some sample applications are available.
We advise you to try these sample applications first and experience the OpenStack Native Application.
* https://github.com/ctc-g/rack-sample-apps/tree/master/montecarlo
* https://github.com/ctc-g/rack-sample-apps/tree/master/shell-like