OpenStack - User contributions [en]

RACK/ja

2015-10-22T01:06:18Z

Tetsuya-oikawa:

= 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
|
|-
| DevRACK
|
| https://github.com/ctc-g/devrack/blob/master/README_ja.md
|}

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

OpenStack Native Application とは、OpenStackのリソース（たとえば、VMやVNET）を、アプリケーションの中から直接利用して動作するソフトウェアの事です。
現在主流のアプリケーションは、"クラウド以前"にデザインされており、クラウドとの親和性が考慮されていません。
そのため、これらのアプリケーションがOpenStack上で動作するには、ChefやPuppetといったツールと連携する必要があり、システムが複雑化しています。

RACKはOpenStack上で直接動作するソフトウェア、"After the Cloud" アプリケーションを簡単に作成するための仕組みです。
プログラマはRACKを使うことで、外部との連携を必要とせずに、OpenStack上でスケールし、移植可能なアプリケーションを記述し動作させることができます。

RACKの概念は以下になります。

# 機能を持たせたVMを1つの実行バイナリファイルとして扱う。"機能"とは、アプリが動作するために必要なOS、ミドル、プログラムの事を指します。ここでのプログラムはRACKのAPIを呼び出して動作するように作ります。
# この実行バイナリを、OpenStack上に展開することで、このVMはLinuxプロセスのように振る舞い、何らかの仕事をします。
# このプロセスは、プログラムの中で記述に基づき、Forkして子プロセスを生成したり、プロセス間で通信を行います。

手っ取り早くRACKを体験するには、サンプルプログラムを見てください
* 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

DevRACKという簡単にサンプルアプリケーションを実行するためのツールも開発しています。
* https://github.com/ctc-g/devrack/blob/master/README_ja.md

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

== What is RACK? ==

RACKは、NovaやNeutron等のAPIをラッピングし、VMがプロセスのように振る舞うためのデータ構造を定義します。
そして、このプロセスとして扱われるVM間で、通信やデータ共有を行うためのAPIを提供します。
アプリケーションはこのAPIをコールすることで動作するように記述していきます。
更にRACKはこのAPIを利用するためのライブラリ[https://github.com/openstack/python-rackclient|python-rackclient]も提供しています。
このライブラリを使うことで、簡単にOpenStack Native Applicationが記述できます。
RACKは、OpenStack Native Applicationを記述するためのフレームワークとも言えます。

== What we call "process" ==

RACKではプロセスという単語がよく出てきます。
このプロセスの実態はNova上の仮想マシンインスタンスです。
しかしこのインスタンスは、起動すると何かの仕事をするように作られています。
これは、Linuxの各種実行ファイル、たとえば lsコマンドやgrepコマンドが起動されると仕事をするのと似ています。
Linuxでは起動した実行ファイルはメモリ上のプロセスとなり、仕事を行い、最後には終了してメモリ上から消えます。
RACKはこの考え方をOpenStack上で再現します。
機能を持たせたglanceイメージをNova上で展開し、展開されたインスタンスが何か仕事を行い、最後に消えます。
そのため、RACKでは仮想マシンインスタンス＝プロセスと呼んでいます。

プロセスとして起動されるVMインスタンスは、PIDを持ち、Fork可能で親子関係を持ちます。
また関係性を持ったプロセス間（VM間）では、IPアドレスを意識しないプロセス間通信やデータ共有、同一名前空間を持ったファイルシステムが利用可能で、この実行バイナリを作成するプログラマは、Linuxのプログラムを作る感覚で、OpenStack Native Applicationを記述できます。

== Architecture ==

RACKはVMをプロセスとして扱うためのデータ構造を定義したデータベースを持ち、このデータ構造を操作するためのRestfulなAPIを提供します。
アプリケーションから命令を受けると、OpenStackのAPIをコールし、プロセスの属性情報を自身のデータベースに書き込みます。

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

=== Attibutes of a process ===
プロセスの属性情報には下記のようなものがあります。

* keypair, security-group, network
Nova、Neutronによって提供されるリソースです。
プロセスの属性情報としてそれぞれのリソースIDを保持しています。

* GID (group ID)
各プロセスは一つのグループに所属します。
同じグループに所属するプロセスは、同一名前空間でファイル共有できるなどのメリットがあります。

* PID, PPID
各プロセスに付与されるIDおよびその親のIDです。
これによりプロセス間の親子関係が表現されています。

=== rack-proxy ===
各グループにはそれぞれrack-proxyというプロセスが存在します。
rack-apiがパブリックなAPIなのに対し、rack-proxyはそのグループだけがアクセス可能なAPIを提供します。
プロセス間通信やファイルシステムといった機能は、rack-proxyが提供します。

=== Deployment of rack-api and rack-proxy ===
rack-apiは単独のネットワークに配置され、パブリックにアクセス可能とします。
グループごとに存在するrack-proxyは、rack-apiのAPIをコールすることで起動します。
rack-apiおよびすべてのrack-proxyは、同じデータベースを共有します。

[[File:RACK-Topology.png]]

現状、rack-apiとrack-proxyはVMとして起動しますが、将来的には以下の構成になることを目指します。

* '''rack-apiはnova-apiなどのように、OpenStackコントローラノード内の一プロセスとして動作します。'''
* '''rack-proxyはneutron-ns-metadata-proxyのように、OpenStackネットワークノード内の一プロセスとして動作します。'''

'''これらはOpenStackのコアプロジェクトと密接に関わる範囲のため、現段階ではVMとして起動するようにしています。'''

=== Interprocess communication support ===
RACKはプロセスのデータ構造操作、起動停止に加え、プロセス間での通信、データ共有を支援する機能を持っています。
これらはライブラリと組み合わせて実現されています。

[[File:RACK-Features.png]]

* ファイルシステム
グループ内で共有されるファイルシステムを提供します。
プロセスは同じ名前空間でファイルにアクセスすることができ、あたかもローカルのファイルシステムにアクセスしているかのごとく利用できます。

* 共有メモリ
簡単なデータをプロセス間で共有するための機能です。
複数のプロセスで同時に同じデータを参照したい場合などに利用できます。

* パイプ
Unix-pipeライクな機能を提供します。
あるプロセスで処理した結果を別のプロセスに渡すということが簡単にできます。
相手のIPアドレスを知る必要はなく、相手が起動するまで待つ必要もありません。

* シグナル
PIDの指定だけで任意のプロセスに文字列送信ができる機能です。
使い方によって複数のプロセスにマルチキャスト送信することも可能です。

== Use cases ==

RACKの使い方に制限はありません。
プロセスの追加・削除、プロセス間のデータ共有、データ通知などはすべて、プログラムによって記述可能です。
RACKを使えば、OpenStack Nativeなアプリケーションを簡単に開発することができます。

RACKの使い方のヒントとして、いくつかのサンプルアプリケーションを用意しています。
まずはサンプルアプリケーションを動かしてみて、OpenStack Native Applicationとはどのようなものか体験してください。
* 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

RACK

2015-10-19T07:10:44Z

Tetsuya-oikawa:

= 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

Stackforge Namespace Retirement

2015-09-28T02:11:17Z

Tetsuya-oikawa: /* Active Projects to Move */

=== Background ===

The stackforge/ git namespace is being retired, and active projects are being moved to the openstack/ namespace. See this mailing list post for [http://lists.openstack.org/pipermail/openstack-dev/2015-August/071816.html full background]. These changes are scheduled to occur on October 17, 2015.

There are two lists below, one for active projects that should be moved, and a second for inactive projects that should become read-only. Please update them to add your project to the correct list.

=== Active Projects to Move ===
Active stackforge projects that wish to move into the openstack/ namespace should be added to this list. Projects in this list will be automatically moved by the Infrastructure team to openstack/ on October 17. Please note that no other renames can happen during this move -- projects will strictly be moved from stackforge/ to openstack/ with their existing names.

* aeromancer
* anvil
* bansho
* blazar
* blazar-nova
* ceilometer-powervm
* ceilometer-zvm
* cl-openstack-client
* cloud-init
* cloudbase-init
* clouddocs-maven-plugin
* cloudkitty
* cloudkitty-dashboard
* cloudpulse
* cognitive
* compass-adapters
* compass-core
* compass-specs
* compass-web
* compute-hyperv
* doc8
* dox
* drbd-devstack
* driverlog
* ec2-api
* faafo
* freezer
* freezer-api
* freezer-web-ui
* fuel-agent
* fuel-astute
* fuel-dev-tools
* fuel-devops
* fuel-docs
* fuel-library
* fuel-main
* fuel-mirror
* fuel-nailgun-agent
* fuel-octane
* fuel-ostf
* fuel-ostf-plugin
* fuel-plugin-calamari
* fuel-plugin-calico
* fuel-plugin-ceilometer-redis
* fuel-plugin-cinder-netapp
* fuel-plugin-cisco-aci
* fuel-plugin-contrail
* fuel-plugin-dbaas-trove
* fuel-plugin-detach-database
* fuel-plugin-detach-keystone
* fuel-plugin-detach-rabbitmq
* fuel-plugin-elasticsearch-kibana
* fuel-plugin-external-emc
* fuel-plugin-external-glusterfs
* fuel-plugin-external-zabbix
* fuel-plugin-glance-nfs
* fuel-plugin-ha-fencing
* fuel-plugin-influxdb-grafana
* fuel-plugin-ironic
* fuel-plugin-ldap
* fuel-plugin-lma-collector
* fuel-plugin-lma-infrastructure-alerting
* fuel-plugin-mellanox
* fuel-plugin-midonet
* fuel-plugin-neutron-fwaas
* fuel-plugin-neutron-lbaas
* fuel-plugin-neutron-vpnaas
* fuel-plugin-nova-nfs
* fuel-plugin-nsxv
* fuel-plugin-opendaylight
* fuel-plugin-saltstack
* fuel-plugin-solidfire-cinder
* fuel-plugin-swiftstack
* fuel-plugin-tintri-cinder
* fuel-plugin-tls
* fuel-plugin-vmware-dvs
* fuel-plugin-vxlan
* fuel-plugin-zabbix-monitoring-emc
* fuel-plugin-zabbix-monitoring-extreme-networks
* fuel-plugin-zabbix-snmptrapd
* fuel-plugins
* fuel-provision
* fuel-qa
* fuel-specs
* fuel-stats
* fuel-tasklib
* fuel-upgrade
* fuel-web
* gce-api
* gerrit-dash-creator
* git-upstream
* golang-client
* group-based-policy
* group-based-policy-automation
* group-based-policy-specs
* group-based-policy-ui
* intel-nfv-ci-tests
* merlin
* monasca-agent
* monasca-api
* monasca-ceilometer
* monasca-common
* monasca-log-api
* monasca-notification
* monasca-persister
* monasca-statsd
* monasca-thresh
* monasca-ui
* monasca-vagrant
* monitoring-for-openstack
* namos
* nerd-reviewer
* networking-6wind
* networking-hyperv
* networking-ovs-dpdk
* networking-zvm
* nova-docker
* nova-powervm
* nova-solver-scheduler
* nova-zvm-virt-driver
* ops-tags-team
* osprofiler
* ospurge
* packstack
* puppet-autossh
* puppet-ceph
* puppet-n1k-vsm
* puppet-setproxy
* puppet-surveil
* python-blazarclient
* python-cloudkittyclient
* python-cloudpulseclient
* python-cognitiveclient
* python-fuelclient
* python-group-based-policy-client
* python-jenkins
* python-monascaclient
* python-openstacksdk
* python-rackclient
* python-senlinclient
* python-surveilclient
* python-tackerclient
* rack
* requests-mock
* senlin
* senlin-dashboard
* shaker
* sqlalchemy-migrate
* surveil
* surveil-specs
* stackalytics
* swift3
* tacker
* tacker-horizon
* tacker-specs
* tap-as-a-service
* telcowg-usecases
* terracotta
* third-party-ci-tools
* tricircle
* vmtp
* wsme
* xenapi-os-testing
* xstatic-d3
* xstatic-angular-sanitize
* xstatic-bootstrap-datepicker
* xstatic-angular-gettext
* xstatic-bootswatch
* xstatic-angular-cookies
* xstatic-bootstrap-scss
* xstatic-angular-smart-table
* xstatic-angular-fileupload
* xstatic-angular-bootstrap
* xstatic-angular
* xstatic-angular-mock
* xstatic-angular-lrdragndrop
* xstatic-roboto-fontface
* xstatic-jquery.quicksearch
* xstatic-mdi
* xstatic-rickshaw
* xstatic-magic-search
* xstatic-font-awesome
* xstatic-hogan
* xstatic-spin
* xstatic-jasmine
* xstatic-jquery-migrate
* xstatic-jquery-migrate
* xstatic-jsencrypt
* yaql

=== Inactive Projects to Retire ===
Inactive projects that should be retired should be added to this list. These projects will have a commit merged removing their content and replacing it with a message indicating the project is no longer maintained and will become read-only in Gerrit.

* compass-monit
* fuel-plugin-availability-zones
* mercador-pub
* mercador-sub
* MRaaS
* networking-portforwarding
* openstackdroid
* python-mercadorclient
* rubick
* sahara-guestagent
* libra
* logaas
* python-libraclient
* python-rallyclient
* cookbook-pacemaker
* puppet-openstack_dev_env
* puppet_openstack_builder
* puppet-openstack-cloud
* tripleo-ansible