DOCSEARCHbyAlgolia
Submit Docs

OpenStack Nova

repository·master·Indexed 25 days ago

https://github.com/openstack/nova

A core OpenStack component and cloud computing fabric controller responsible for managing compute resources. It provides a RESTful API for provisioning servers, flavors, and images, and manages specialized services including nova-osapi_compute, nova-metadata, nova-scheduler, nova-conductor, and nova-compute.

Tokens
187K
Snippets
314
Records
1.4K
Agent score
84%

What's inside openstack-nova

  1. Overview of Nova Compute Services

    master

    The OpenStack Compute service (Nova) manages Infrastructure-as-a-Service (IaaS) by controlling instances, networks, and access via users and projects. It uses drivers to interact with underlying virtualization mechanisms. The service consists of several persistent daemon processes (nova-*):

    • Compute API: A WSGI application serving the Nova OpenStack Compute API.
    • Metadata API: A WSGI application serving the Nova Metadata API.
    • nova-compute: Manages virtual machines and exposes methods on ComputeManager via RPC.
    • nova-conductor: Provides database-access support for compute nodes to reduce security risks.
    • nova-scheduler: Dispatches requests for new virtual machines to the appropriate node.
    • nova-novncproxy: Provides a VNC proxy for browser-based VNC console access.
    • nova-spicehtml5proxy: Provides a SPICE proxy for browser-based SPICE console access.
    • nova-serialproxy: Provides a serial console proxy for accessing a virtual machine's serial console.

  2. Overview of OpenStack Compute components

    master

    OpenStack Compute is an Infrastructure-as-a-Service (IaaS) component used to host and manage cloud computing systems. It relies on several key services and integrations:

    Core Services

    • Compute API: The entry point for end-user calls. It enforces policies and initiates orchestration activities like running instances.
    • Metadata API: Handles metadata requests originating from within running instances.
    • nova-compute: A worker daemon responsible for the lifecycle of virtual machines (creation and termination) via hypervisor APIs (e.g., libvirt with KVM or QEMU).
    • nova-scheduler: Selects the specific compute server host for a virtual machine instance request.
    • nova-conductor: Acts as a mediator between nova-compute and the database to prevent direct database access by compute services. Note: Do not deploy nova-conductor on the same nodes where nova-compute is running.
    • nova-novncproxy: A proxy for VNC-based access to running instances, supporting browser-based noVNC clients.
    • nova-spicehtml5proxy: A proxy for SPICE-based access to running instances, supporting browser-based HTML5 clients.

    Infrastructure Dependencies

    • Message Queue: A central hub for inter-daemon communication, typically implemented using RabbitMQ.
    • SQL Database: Stores build-time and run-time states (instance types, active instances, networks, projects). Supported databases include any compatible with SQLAlchemy (e.g., SQLite3, MySQL, MariaDB, PostgreSQL).
    • Integrations: Interacts with OpenStack Identity (authentication), OpenStack Placement (resource tracking), OpenStack Image service (disk images), and OpenStack Dashboard (UI).

  3. Overview of OpenStack Nova

    master

    Nova is the OpenStack project responsible for provisioning compute instances (virtual servers). It supports virtual machines, baremetal servers (via Ironic), and has limited support for system containers. Nova operates as a set of daemons on Linux servers.

    Core Dependencies

    For basic functionality, Nova requires the following OpenStack services:

    • Keystone: Identity and authentication.
    • Glance: Compute image repository (all instances launch from Glance images).
    • Neutron: Virtual or physical network provisioning.
    • Placement: Resource inventory tracking and provider selection.

  4. Enable PCI device tracking in Placement

    master
    Nova supports scheduling flavor-based PCI device requests via the Placement API. This feature is disabled by default. Enabling it allows the nova-scheduler to better handle flavors that use PCI (non-Neutron related) resources, reducing reschedules and improving candidate selection.

  6. Limitations of shared storage modeling in Pike

    master
    In the Pike release series, the scheduler does not support shared storage modeling in Placement. Operators cannot model a shared storage pool between two or more compute hosts using the Placement service for scheduling and resource tracking. Support for this functionality is planned for the Queens release.

  8. Understand Block Device Mapping (BDM) in Nova

    master

    Nova uses Block Device Mapping (BDM) to organize and manage the various block devices attached to a cloud instance. BDM is used in two primary ways:

    1. API/CLI Specification: Defining block devices during an instance boot request.
    2. Internal Data Structure: How Nova records and persists device information in the block_device_mapping database table.

    There are three distinct formats used within Nova:

    • API BDMs: The raw key-value pairs received from an API client.
    • Driver BDMs: The format used by virtualization drivers (defined in nova.virt.block_device), which mimics a Python dictionary interface.
    • BlockDeviceMapping objects: Objects that mirror the database schema.

    Note: The maximum number of disk devices allowed per server is controlled by the compute.max_disk_devices_to_attach configuration option.

  9. Understand database migrations in Nova

    master
    Nova uses alembic to manage migrations for its main database. alembic is a lightweight database migration tool designed to work with SQLAlchemy. If you are performing manual database maintenance or developing extensions that require schema changes, you should familiarize yourself with the alembic command-line interface.

  10. Understand Nova REST API Policy Enforcement

    master

    Nova uses a policy enforcement system to manage access control for its REST APIs. The system is designed to handle both end-user and operator-level functionality. Key architectural goals include:

    • Granular Control: Breaking down API permissions into specific actions (e.g., compute:foobar:create, compute:foobar:list) rather than a single CRUD policy for an entire resource.
    • System Scoping: Utilizing Keystone's system scope (available since the Queens release) to distinguish between project-scoped requests and system-level requests. This prevents the need for overloaded roles like system-admin on a per-project basis and protects system-specific information (like hypervisor data) from being accessed via project tokens.
    • Standardized Roles: Leveraging default Keystone roles such as admin, member, and reader to ensure interoperability across deployments.
    • Configuration-Driven Access: Moving away from hard-coded permission checks in the code toward a configurable policy system that can be managed via oslo.policy.

  12. Nova Interaction and Development Goals

    master

    The Nova development process is guided by several interaction goals to ensure stability and community involvement:

    • Open Design Review: Blueprints and designs must be open for review by everyone, including operators and all user types.
    • Scope Management: Avoid expanding Nova's scope unnecessarily and focus on the core to maintain stability and flexibility.
    • API Longevity: Nova aims to support released APIs approximately forever. Since every commit is released, getting the API design right initially is critical.
    • Prioritization: Avoid low-priority blueprints that stall high-priority work. Optimize for completed blueprints rather than a high volume of half-completed work.
    • User Experience: Prioritize a consistent experience for users over ease of development.
    • Design-First Approach: Discuss designs for non-trivial work before implementation to prevent expensive late-stage design changes.
    • Review Efficiency: Set realistic expectations for review cycles to avoid long rebase loops and focus reviewer efforts on a subset of patches to increase productivity.