openstack/zaqar
Code Issues Proposed changes
b53ff5d12c
zaqar/doc/source/index.rst
Eva Balycheva b53ff5d12c Refactoring of docs during Mitaka cycle 
This patch improves Zaqar documentation and fixes currently existing
bugs.

Bugs this patch currently addresses and solutions:

Short names for documentation locations used in this commit message:
GitRepo - https://github.com/openstack/zaqar/
Contributor Docs - http://docs.openstack.org/developer/zaqar/
Wiki - https://wiki.openstack.org/wiki/Zaqar/

1. DRY violation and spreaded information for contributors bug.
The information for Zaqar contributors is spreaded/duplicated across
GitRepo, Contributor Docs and Wiki.
Examples of DRY violation are these three articles:
https://wiki.openstack.org/wiki/Zaqar/Give_Zaqar_a_try,
https://github.com/openstack/zaqar/blob/master/README.rst,
http://docs.openstack.org/developer/zaqar/development-environment.html

Example of spreaded information is: "zaqar/tests/functional/README.rst"
Normally the contributor want to see the information from this file in
"doc/source/running_tests.rst".

Solution: move useful missing information for contributors from Wiki and
GitRepo to Contributor Docs, then replace all contributor information in
Wiki and GitRepo with links to Contributor Docs.

2. Outdated information, missing new information and broken links bug.
Example is "test_suite.rst":
a. It still states that Zaqar test suite lives in two directories -
"tests" and "zaqar/tests", but now it's not true.
b. Doesn't contain information about how test invocation is organized,
what really happens when "tox -e py27" command executes.

Solution: replace outdated information with new, fix broken links if
possible, add useful missing information.

3. Style and formatting bugs.
The reference is http://docs.openstack.org/contributor-guide/.

Many documents in Contributor Docs have wrong line wrapping - some lines
are wrapped too short and some are wrapped too long.
Lines must wrap at 79 characters, exceptions are code and links.
Example is "first_review.rst" which lines are not wrapped at all.

Enumerated lists must be written using "#. " syntax.
Example with wrong enumerated list is "development.environment.rst".

Some inline elements must be styled according to:
http://docs.openstack.org/contributor-guide/rst-conv/inline-markups.html
Example with wrong styling of inline elements is
"development.environment.rst" where many paths and file names are not
marked with `` (double backticks).

By default code inserts are implicitly styled with python syntax.
There are many places in Contributor Docs where console (bash) code is
wrongly styled with python syntax.

Also there are some failed attempts to apply a formatting in Contributor
Docs. For example there is a broken list in "first_review.rst" at line
52.

Solution: fix broken formatting, apply proper style where it is needed.

Some of these bugs fixes closes few bug reports from:
https://etherpad.openstack.org/p/zaqar-mitaka-docs

Change-Id: Id668684248bdee03eb43b537dc2c6bb2a68ed23d
2016-01-07 17:05:09 +03:00

5.8 KiB
Raw Blame History

Welcome to the Zaqar Developer Documentation!

Zaqar is a multi-tenant cloud messaging and notification service for web and mobile developers.

The service features a REST API, which developers can use to send messages between various components of their SaaS and mobile applications, by using a variety of communication patterns. Underlying this API is an efficient messaging engine designed with scalability and security in mind. The Websocket API is also available.

Other OpenStack components can integrate with Zaqar to surface events to end users and to communicate with guest agents that run in the "over-cloud" layer.

Note

This documentation is generated by the Sphinx toolkit and lives in the Zaqar project source tree. Additional draft and project documentation regarding Zaqar and other components of OpenStack can be found on the OpenStack Wiki, as well as in the user guides found on docs.openstack.org.

Key features

Zaqar provides the following key features:

  • Choice between two communication transports. Both with Keystone support:
    • Firewall-friendly, HTTP-based RESTful API. Many of today's developers prefer a more web-friendly HTTP API. They value the simplicity and transparency of the protocol, it's firewall-friendly nature, and it's huge ecosystem of tools, load balancers and proxies. In addition, cloud operators appreciate the scalability aspects of the REST architectural style.
    • Websocket-based API for persistent connections. Websocket protocol provides communication over persistent connections. Unlike HTTP, where new connections are opened for each request/response pair, Websocket can transfer multiple requests/responses over single TCP connection. It saves much network traffic and minimizes delays.
  • Multi-tenant queues based on Keystone project IDs.
  • Support for several common patterns including event broadcasting, task distribution, and point-to-point messaging.
  • Component-based architecture with support for custom backends and message filters.
  • Efficient reference implementation with an eye toward low latency and high throughput (dependent on backend).
  • Highly-available and horizontally scalable.
  • Support for subscriptions to queues. Several notification types are available:
    • Email notifications.
    • Webhook notifications.
    • Websocket notifications.

Project scope

The Zaqar API is data-oriented. That is, it does not provision message brokers and expose those directly to clients. Instead, the API acts as a bridge between the client and one or more backends. A provisioning service for message brokers, however useful, serves a somewhat different market from what Zaqar is targeting today. With that in mind, if users are interested in a broker provisioning service, the community should consider starting a new project to address that need.

Design principles

Zaqar, as with all OpenStack projects, is designed with the following guidelines in mind:

  • Component-based architecture. Quickly add new behaviors
  • Highly available and scalable. Scale to very serious workloads
  • Fault tolerant. Isolated processes avoid cascading failures
  • Recoverable. Failures should be easy to diagnose, debug, and rectify
  • Open standards. Be a reference implementation for a community-driven

Concepts

glossary

Modules reference

Zaqar is composed of two layers:

transport storage/autoindex

The transport drivers are responsible for interacting with Zaqar clients. Every query made by clients is processed by the transport layer, which is in charge of passing this information to the backend and then returning the response in a format understandable by the client.

The storage drivers are responsible for interacting with the storage backends and, that way, store or retrieve the data coming from the transport layer.

In order to keep these layers decoupled, we have established that checks should be performed in the appropriate layer. In other words, transport drivers must guarantee that the incoming data is well-formed and storage drivers must enforce their data model stays consistent.

Setting up a development environment

devref/development.environment

Welcome new contributors

welcome first_patch first_review

Running and writing tests

running_tests test_suite

Reviewing

reviewer_guide

Running benchmark

running_benchmark

Other resources

launchpad gerrit jenkins

Internal API reference

api/autoindex

Indices and tables

  • genindex
  • modindex
  • search