611 lines
24 KiB
YAML
611 lines
24 KiB
YAML
---
|
||
name: OpenStack Components
|
||
tabs:
|
||
|
||
- name: OpenStack services
|
||
map-bucket: openstack
|
||
prelude: >
|
||
An OpenStack deployment contains a number of components providing
|
||
APIs to access infrastructure resources. This page lists the various
|
||
services that can be deployed to provide such resources to cloud
|
||
end users.
|
||
categories:
|
||
|
||
- category: Compute
|
||
components:
|
||
|
||
- name: nova
|
||
title: Compute Service
|
||
desc: >
|
||
To implement services and associated libraries to provide
|
||
massively scalable, on demand, self service access to compute
|
||
resources, including bare metal, virtual machines, and
|
||
containers.
|
||
project-team: nova
|
||
since: Austin
|
||
dependencies:
|
||
- cinder
|
||
- neutron
|
||
- glance
|
||
see-also:
|
||
- ironic
|
||
|
||
- name: zun
|
||
title: Containers Service
|
||
desc: >
|
||
Zun provides an OpenStack API for launching and managing
|
||
containers backed by different container technologies.
|
||
Different from Magnum, Zun is for users who want to treat
|
||
containers as OpenStack-managed resource. Containers managed
|
||
by Zun are supposed to be integrated well with other OpenStack
|
||
resources, such as Neutron network and Cinder volume. Users
|
||
are provided a simplified APIs to manage containers without
|
||
the need to explore the complexities of different container
|
||
technologies.
|
||
project-team: zun
|
||
since: Pike
|
||
|
||
- name: qinling
|
||
title: Functions Service
|
||
desc: >
|
||
Qinling provides a platform to support serverless functions
|
||
(like AWS Lambda).
|
||
project-team: qinling
|
||
since: Rocky
|
||
|
||
- category: Bare metal
|
||
components:
|
||
|
||
- name: ironic
|
||
title: Bare Metal Provisioning Service
|
||
desc: >
|
||
To implement services and associated libraries to provide
|
||
massively scalable, on demand, self service access to compute
|
||
resources, including bare metal, virtual machines, and
|
||
containers.
|
||
project-team: ironic
|
||
since: Kilo
|
||
dependencies:
|
||
- glance
|
||
see-also:
|
||
- nova
|
||
|
||
- name: cyborg
|
||
title: Accelerators resource management
|
||
desc: >
|
||
Cyborg provides a general purpose management framework for
|
||
acceleration resources (i.e. various types of accelerators such
|
||
as GPU, FPGA, ASIC, NP, SoCs, NVMe/NOF SSDs, ODP, DPDK/SPDK and
|
||
so on).
|
||
project-team: cyborg
|
||
since: Rocky
|
||
dependencies:
|
||
- nova
|
||
|
||
- category: Storage
|
||
components:
|
||
|
||
- name: swift
|
||
title: Object store
|
||
desc: >
|
||
Swift is a highly available, distributed, eventually consistent
|
||
object/blob store. Organizations can use Swift to store lots of
|
||
data efficiently, safely, and cheaply. It's built for scale and
|
||
optimized for durability, availability, and concurrency across
|
||
the entire data set. Swift is ideal for storing unstructured
|
||
data that can grow without bound.
|
||
project-team: swift
|
||
since: Austin
|
||
see-also:
|
||
- storlets
|
||
|
||
- name: cinder
|
||
title: Block Storage
|
||
desc: >
|
||
Cinder is a Block Storage service for OpenStack. It virtualizes
|
||
the management of block storage devices and provides end users
|
||
with a self service API to request and consume those resources
|
||
without requiring any knowledge of where their storage is
|
||
actually deployed or on what type of device. This is done through
|
||
the use of either a reference implementation (LVM) or plugin
|
||
drivers for other storage.
|
||
project-team: cinder
|
||
since: Folsom
|
||
see-also:
|
||
- nova
|
||
|
||
- name: manila
|
||
title: Shared filesystems
|
||
desc: >
|
||
Manila provides coordinated access to shared or distributed file
|
||
systems.
|
||
project-team: manila
|
||
since: Liberty
|
||
|
||
- category: Networking
|
||
components:
|
||
|
||
- name: neutron
|
||
title: Networking
|
||
desc: >
|
||
OpenStack Neutron is an SDN networking project focused on
|
||
delivering networking-as-a-service (NaaS) in virtual compute
|
||
environments.
|
||
project-team: neutron
|
||
since: Folsom
|
||
see-also:
|
||
- nova
|
||
|
||
- name: octavia
|
||
title: Load balancer
|
||
desc: >
|
||
Octavia is an open source, operator-scale load balancing solution
|
||
designed to work with OpenStack. Octavia was borne out of the
|
||
Neutron LBaaS project, and starting with the Liberty release of
|
||
OpenStack, Octavia has become the reference implementation for
|
||
Neutron LBaaS version 2. Octavia accomplishes its delivery of
|
||
load balancing services by managing a fleet of virtual machines,
|
||
containers, or bare metal servers —collectively known as
|
||
amphorae— which it spins up on demand. This on-demand, horizontal
|
||
scaling feature differentiates Octavia from other load balancing
|
||
solutions, thereby making Octavia truly suited “for the cloud.”
|
||
project-team: octavia
|
||
since: Pike
|
||
|
||
- name: designate
|
||
title: DNS service
|
||
desc: >
|
||
Designate provides DNS-as-a-service for OpenStack.
|
||
project-team: designate
|
||
since: Liberty
|
||
|
||
- category: Shared services
|
||
components:
|
||
|
||
- name: keystone
|
||
title: Identity service
|
||
desc: >
|
||
Keystone is an OpenStack service that provides API client
|
||
authentication, service discovery, and distributed multi-tenant
|
||
authorization by implementing OpenStack’s Identity API. It
|
||
supports LDAP, OAuth, OpenID Connect, SAML and SQL.
|
||
project-team: keystone
|
||
since: Essex
|
||
|
||
- name: glance
|
||
title: Image service
|
||
desc: >
|
||
Glance image services include discovering, registering, and
|
||
retrieving virtual machine images. Glance has a RESTful API
|
||
that allows querying of VM image metadata as well as retrieval
|
||
of the actual image. VM images made available through Glance
|
||
can be stored in a variety of locations from simple filesystems
|
||
to object-storage systems like the OpenStack Swift project.
|
||
project-team: glance
|
||
since: Bexar
|
||
see-also:
|
||
- nova
|
||
- swift
|
||
|
||
- name: barbican
|
||
title: Key management
|
||
desc: >
|
||
Barbican is the OpenStack Key Manager service. It provides secure
|
||
storage, provisioning and management of secret data, such as
|
||
passwords, encryption keys, X.509 Certificates and raw binary
|
||
data.
|
||
project-team: barbican
|
||
since: Liberty
|
||
|
||
- name: karbor
|
||
title: Application Data Protection as a Service
|
||
desc: >
|
||
Karbor deals with protecting the Data and Meta-Data that
|
||
comprises an OpenStack-deployed application against loss/damage
|
||
(e.g. backup, replication) - not to be confused with Application
|
||
Security or DLP. It does that by providing a standard framework
|
||
of APIs and services that enables vendors to introduce various
|
||
data protection services into a coherent and unified flow for
|
||
the user.
|
||
project-team: karbor
|
||
since: Pike
|
||
|
||
- name: searchlight
|
||
title: Indexing and Search
|
||
desc: >
|
||
The Searchlight project provides indexing and search capabilities
|
||
across OpenStack resources. Its goal is to achieve high
|
||
performance and flexible querying combined with near real-time
|
||
indexing. It uses Elasticsearch, a real-time distributed indexing
|
||
and search engine built on Apache Lucene, but adds OpenStack
|
||
authentication and Role Based Access Control to provide
|
||
appropriate protection of data.
|
||
project-team: searchlight
|
||
since: Liberty
|
||
|
||
- category: Orchestration
|
||
components:
|
||
|
||
- name: heat
|
||
title: Orchestration
|
||
desc: >
|
||
Heat orchestrates the infrastructure resources for a cloud
|
||
application based on templates in the form of text files that
|
||
can be treated like code. Heat provides both an OpenStack-native
|
||
ReST API and a CloudFormation-compatible Query API. Heat also
|
||
provides an autoscaling service that integrates with the
|
||
OpenStack Telemetry services, so you can include a scaling group
|
||
as a resource in a template.
|
||
project-team: heat
|
||
since: Havana
|
||
|
||
- name: senlin
|
||
title: Clustering service
|
||
desc: >
|
||
Senlin is a clustering service for OpenStack clouds. It creates
|
||
and operates clusters of homogeneous objects exposed by other
|
||
OpenStack services. The goal is to make orchestration of
|
||
collections of similar objects easier.
|
||
project-team: senlin
|
||
since: Mitaka
|
||
|
||
- name: mistral
|
||
title: Workflow service
|
||
desc: >
|
||
Mistral is a workflow service. Most business processes consist
|
||
of multiple distinct interconnected steps that need to be
|
||
executed in a particular order in a distributed environment.
|
||
One can describe such process as a set of tasks and task
|
||
relations (via YAML-based language) and upload such description
|
||
to Mistral so that it takes care of state management, correct
|
||
execution order, parallelism, synchronization and high
|
||
availability.
|
||
project-team: mistral
|
||
since: Liberty
|
||
|
||
- name: zaqar
|
||
title: Messaging Service
|
||
desc: >
|
||
Zaqar is a multi-tenant cloud messaging service for web and
|
||
mobile developers. The service features a fully RESTful API,
|
||
which developers can use to send messages between various
|
||
components of their SaaS and mobile applications. Underlying
|
||
this API is an efficient messaging engine designed with
|
||
scalability and security in mind. 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.
|
||
Cloud operators can leverage Zaqar to provide equivalents of
|
||
SQS and SNS to their customers.
|
||
project-team: zaqar
|
||
since: Liberty
|
||
|
||
- name: blazar
|
||
title: Resource reservation service
|
||
desc: >
|
||
Blazar is a resource reservation service for OpenStack. Blazar
|
||
enables users to reserve a specific type/amount of resources for
|
||
a specific time period and it leases these resources to users
|
||
based on their reservations.
|
||
project-team: blazar
|
||
since: Queens
|
||
|
||
- name: aodh
|
||
title: Alarming Service
|
||
desc: >
|
||
Aodh's goal is to enable the ability to trigger actions based
|
||
on defined rules against sample or event data collected by
|
||
Ceilometer.
|
||
project-team: Telemetry
|
||
since: Liberty
|
||
|
||
- category: Workload provisioning
|
||
components:
|
||
|
||
- name: magnum
|
||
title: Container Orchestration Engine Provisioning
|
||
desc: >
|
||
Magnum makes container orchestration engines such as Docker
|
||
Swarm, Kubernetes, and Apache Mesos available as first class
|
||
resources in OpenStack. Magnum uses Heat to orchestrate an OS
|
||
image which contains Docker and Kubernetes and runs that image
|
||
in either virtual machines or bare metal in a cluster
|
||
configuration.
|
||
project-team: magnum
|
||
since: Mitaka
|
||
dependencies:
|
||
- heat
|
||
|
||
- name: sahara
|
||
title: Big Data Processing Framework Provisioning
|
||
desc: >
|
||
The sahara project aims to provide users with a simple means
|
||
to provision data processing frameworks (such as Hadoop, Spark
|
||
and Storm) on OpenStack. This is accomplished by specifying
|
||
configuration parameters such as the framework version, cluster
|
||
topology, node hardware details and more.
|
||
project-team: sahara
|
||
since: Juno
|
||
|
||
- name: trove
|
||
title: Database as a Service
|
||
desc: >
|
||
Trove is a database-as-a-service provisioning relational and
|
||
non-relational database engines.
|
||
project-team: trove
|
||
since: Icehouse
|
||
|
||
- category: Application lifecycle
|
||
components:
|
||
|
||
- name: masakari
|
||
title: Instances High Availability Service
|
||
desc: >
|
||
Masakari provides Instances High Availability Service for
|
||
OpenStack clouds by automatically recovering failed Instances.
|
||
Currently, Masakari can recover KVM-based Virtual Machine(VM)s
|
||
from failure events such as VM process down, provisioning process
|
||
down, and nova-compute host failure. Masakari also provides an
|
||
API service to manage and control the automated rescue mechanism.
|
||
project-team: masakari
|
||
since: Rocky
|
||
|
||
- name: murano
|
||
title: Application Catalog
|
||
desc: >
|
||
Murano enables application developers and cloud administrators
|
||
to publish various cloud-ready applications in a browsable
|
||
catalog. Cloud users -- including inexperienced ones -- can then
|
||
use the catalog to compose reliable application environments
|
||
with the push of a button. Murano uses OpenStack Heat to
|
||
orchestrate infrastructure resources for the application.
|
||
project-team: murano
|
||
since: Kilo
|
||
dependencies:
|
||
- heat
|
||
|
||
- name: solum
|
||
title: Software Development Lifecycle Automation
|
||
desc: >
|
||
To make cloud services easier to consume and integrate with
|
||
your application development process by automating the
|
||
source-to-image process, and simplifying app-centric deployment.
|
||
project-team: solum
|
||
since: Mitaka
|
||
|
||
- name: freezer
|
||
title: Backup, Restore, and Disaster Recovery
|
||
desc: >
|
||
Freezer is a distributed backup, restore and disaster recovery
|
||
as a service platform. It is designed to be multi OS (Linux,
|
||
Windows, OSX...), focused on providing efficiency and flexibility
|
||
for block based backups, file based incremental backups,
|
||
point-in-time actions, jobs synchronization (i.e. backup
|
||
synchronization over multiple nodes) and many other features.
|
||
It is aimed at being useful for all environments, including
|
||
large ephemeral Clouds.
|
||
project-team: freezer
|
||
since: Mitaka
|
||
|
||
- category: API proxies
|
||
components:
|
||
|
||
- name: EC2API
|
||
title: EC2 API proxy
|
||
desc: >
|
||
Provides an EC2-compatible API to OpenStack Nova.
|
||
project-team: ec2api
|
||
since: Rocky
|
||
dependencies:
|
||
- nova
|
||
|
||
- category: Web frontend
|
||
components:
|
||
|
||
- name: horizon
|
||
title: Dashboard
|
||
desc: >
|
||
Horizon is the canonical implementation of OpenStack's dashboard,
|
||
which is extensible and provides a web based user interface to
|
||
OpenStack services.
|
||
project-team: horizon
|
||
since: Essex
|
||
|
||
- name: Operations services
|
||
map-bucket: openstack-operations
|
||
prelude: >
|
||
Those services deliver APIs primarily targeted to cloud admins and
|
||
deployers, to help with cloud operations.
|
||
categories:
|
||
|
||
- category: Monitoring tools
|
||
components:
|
||
|
||
- name: ceilometer
|
||
title: Metering & Data Collection Service
|
||
desc: >
|
||
Ceilometer's goal is to efficiently collect, normalise and
|
||
transform data produced by OpenStack services. The data it
|
||
collects is intended to be used to create different views
|
||
and help solve various telemetry use cases. Aodh and Gnocchi
|
||
are two examples of services extending Ceilometer data.
|
||
project-team: Telemetry
|
||
since: Havana
|
||
see-also:
|
||
- aodh
|
||
|
||
- name: panko
|
||
title: Event, Metadata Indexing Service
|
||
desc: >
|
||
Panko is designed to provide a metadata indexing, event storage
|
||
service which enables users to capture the state information of
|
||
OpenStack resources at a given time. Its aim is to enable a
|
||
scalable means of storing both short and long term data for use
|
||
cases such as auditing and system debugging.
|
||
project-team: Telemetry
|
||
since: Newton
|
||
|
||
- name: monasca
|
||
title: Monitoring
|
||
desc: >
|
||
Monasca is a open-source multi-tenant, highly scalable,
|
||
performant, fault-tolerant monitoring-as-a-service solution
|
||
that integrates with OpenStack. It uses a REST API for high-speed
|
||
metrics processing and querying and has a streaming alarm engine
|
||
and notification engine.
|
||
project-team: monasca
|
||
since: Mitaka
|
||
|
||
- category: Optimization/policy tools
|
||
components:
|
||
|
||
- name: watcher
|
||
title: Optimization Service
|
||
desc: >
|
||
Watcher provides a flexible and scalable resource optimization
|
||
service for multi-tenant OpenStack-based clouds. Watcher provides
|
||
a complete optimization loop—including everything from a metrics
|
||
receiver, optimization processor and an action plan applier.
|
||
project-team: watcher
|
||
since: Newton
|
||
|
||
- name: vitrage
|
||
title: RCA (Root Cause Analysis service)
|
||
desc: >
|
||
Vitrage is the OpenStack RCA (Root Cause Analysis) service for
|
||
organizing, analyzing and expanding OpenStack alarms & events,
|
||
yielding insights regarding the root cause of problems and
|
||
deducing their existence before they are directly detected.
|
||
project-team: vitrage
|
||
since: Newton
|
||
|
||
- name: congress
|
||
title: Governance
|
||
desc: >
|
||
Congress is an OpenStack project to provide policy as a service
|
||
across any collection of cloud services in order to offer
|
||
governance and compliance for dynamic infrastructures.
|
||
project-team: congress
|
||
since: Liberty
|
||
|
||
- name: rally
|
||
title: Benchmark service
|
||
desc: >
|
||
Rally is a benchmarking and performance analysis tool for
|
||
OpenStack that can be used to automate measuring and profiling
|
||
focused on how new code changes affect OpenStack performance,
|
||
detect scaling and performance issues, and investigate how
|
||
different deployment architectures and hardware affect OpenStack
|
||
performance. It can be used as a basic tool for an OpenStack
|
||
CI/CD system that would continuously improve its SLA, performance
|
||
and stability.
|
||
project-team: rally
|
||
|
||
- category: Billing / Business logic
|
||
components:
|
||
|
||
- name: cloudkitty
|
||
title: Billing and chargebacks
|
||
desc: >
|
||
CloudKitty is a rating-as-a-service project designed to translate
|
||
metrics to prices. CloudKitty supports multiple collectors,
|
||
multiple rating policies and multiple outputs.
|
||
project-team: cloudkitty
|
||
since: Mitaka
|
||
|
||
- category: Multi-region tools
|
||
components:
|
||
|
||
- name: tricircle
|
||
title: Networking Automation for Multi-Region Deployments
|
||
desc: >
|
||
Tricircle provides networking automation across Neutron in
|
||
multi-region OpenStack deployments. Use cases include application
|
||
high availability, dual ISPs for internet link redundancy,
|
||
east-west traffic isolation, cross Nuetron L2 network for NFV,
|
||
and cloud capacity expansion.
|
||
project-team: tricircle
|
||
since: Ocata
|
||
|
||
- name: Add-ons to services
|
||
prelude: >
|
||
This software runs as an add-on or plug-in into other OpenStack
|
||
services.
|
||
categories:
|
||
|
||
- category: Swift add-ons
|
||
components:
|
||
|
||
- name: storlets
|
||
title: Computable object storage
|
||
desc: >
|
||
Openstack Storlets is an extension to Openstack Swift with the
|
||
ability to run user defined computations - called storlets -
|
||
inside the object store in a secure and isolated manner through
|
||
the use of Docker containers. A storlet is a compiled and
|
||
packaged code (e.g. a .jar file) that can be uploaded to Swift
|
||
as any other object. Once uploaded the storlet can be invoked
|
||
over data objects in Swift.
|
||
project-team: storlets
|
||
since: Queens
|
||
dependencies:
|
||
- swift
|
||
|
||
- category: Neutron plug-ins
|
||
components:
|
||
|
||
- name: dragonflow
|
||
title: Distributed SDN controller
|
||
desc: >
|
||
Dragonflow is a distributed SDN controller for OpenStack Neutron
|
||
supporting distributed Switching, Routing, DHCP and more.
|
||
project-team: dragonflow
|
||
dependencies:
|
||
- neutron
|
||
|
||
- name: Bridges for adjacent tech
|
||
prelude: >
|
||
Software in this section facilitates integration of OpenStack components
|
||
in adjacent open infrastructure stacks.
|
||
categories:
|
||
|
||
- category: Containers
|
||
components:
|
||
|
||
- name: kuryr
|
||
title: OpenStack Networking integration for containers
|
||
desc: >
|
||
Bridge between containers frameworks networking models to
|
||
OpenStack networking abstraction
|
||
project-team: kuryr
|
||
dependencies:
|
||
- neutron
|
||
|
||
- name: fuxi
|
||
title: OpenStack Storage integration for containers
|
||
desc: >
|
||
Fuxi focuses on enabling Docker container to use Cinder volume
|
||
and Manila share, thus Docker volume can reuse the advance
|
||
features and numerous vendor drivers in Cinder and Manila.
|
||
With Fuxi, Cinder and Manila can be used as the unified
|
||
persistence storage provider for virtual machine, baremetal
|
||
and Docker container.
|
||
project-team: kuryr
|
||
see-also:
|
||
- cinder
|
||
- manila
|
||
|
||
- category: NFV
|
||
components:
|
||
|
||
- name: tacker
|
||
title: NFV Orchestration
|
||
desc: >
|
||
Tacker provides a generic VNF Manager (VNFM) and an NFV
|
||
Orchestrator (NFVO) to deploy and operate Network Services
|
||
and Virtual Network Functions (VNFs) on an NFV infrastructure
|
||
platform like OpenStack. It is based on ETSI MANO Architectural
|
||
Framework and provides a functional stack to Orchestrate Network
|
||
Services end-to-end using VNFs.
|
||
project-team: tacker
|
||
since: Mitaka
|