Jump to: navigation, search

Difference between revisions of "Namos"

m (Introduction)
m (Problem)
Line 50: Line 50:
 
* Which are OpenStack services components such as nova-compute, cinder-volume, etc. consume these devices
 
* Which are OpenStack services components such as nova-compute, cinder-volume, etc. consume these devices
 
* What are the OpenStack device drivers used for each of the devices.
 
* What are the OpenStack device drivers used for each of the devices.
* What are the different Openstack device drivers are loaded each of the Services.
+
* What are the different OpenStack device drivers are loaded each of the Services.
* When a device is added into the Openstack deployment, its not verified until the corresponding device driver is loaded while service is starting up. But this should be verified when its get added in to Openstack deployment
+
* When a device is added into the OpenStack deployment, its not verified until the corresponding device driver is loaded while service is starting up. But this should be verified when its get added in to OpenStack deployment
  
 
==== Use case ====
 
==== Use case ====

Revision as of 20:23, 15 May 2015

Introduction

OpenStack provides the platform by means of different services and device drivers to setup a cloud in a given datacenter with appropriate devices such as hypervisor, Storage devices, network switches. All these services, drivers (and devices) constitute the 'cloud operating system' and there is no service exist to provide the 'device manager' functionality like in any traditional operating system like Linux and windows. Here So a new Stackforge project called 'Namos' is created to provide these functionalities, in which all those devices, device drivers are represented and controlled by means of REST API and CLI. Namos also enables the auto-discovery of deployed service components such as nova-compute, nova-api, cinder-volume, etc. This is being enabled for nova, cinder, glance, neutron and heat. It will be enabled for other services as well in future.

Here Devices, Drivers and Services are all together could be termed as 'OpenStack Infrastructure'

Openstack-software-diagram.png

It just binds OpenStack deployment and its eco-system in a programmatic manner where operators and developers are facilitated to fine-tune the device/service control and develop any feature based on those devices

NAMOS IS

For Operator

It acts as boundary between OpenStack and its eco-system where operator has complete control on it, such as:

  • Setting maintenance mode for a given device, where all device drivers could subscribe to 'Namos' for setting the device to maintenance mode.
  • Add/update/remove Device from OpenStack deployment. For example, operator can directly add a VMWare cluster, 3PAR CPG. When a device is added, Namos will facilitate to choose the right driver.
  • By making OpenStack device drivers to update the status of the device to Namos, operator could monitor the device status from single RESTful service, Namos.

For Developer

As 'Namos' provides the Restful representation for complete infrastructure,

  • OpenStack developer could develop any feature such as 'tenancy at device level'
  • Other service could consume ‘devices’ and 'services' details from Namos. For example, ceilometer can use Namos to get the service and device details for monitoring them.


NAMOS IS NOT FOR

  • It does neither any of existing OpenStack functionality nor datacenter device management such as VMWare cluster provisioning, KVM provisioning, Physical server provisioning, auto device discovery, etc
  • It does not manage the life-cycle of the OpenStack Service nodes and devices.
  • It just bind OpenStack deployment and its eco-system in programmatic manner where operator and developers are facilitated to fine-tune the device/service control and develop any feature based on it.

Complements Keystone

  • A Region based service in Openstack
  • Complements Keystone by means device and service management per region

Keystone-like-namos.png

Keystone for user management, Namos for device management

Business use cases

Device Management

Problem

In any enterprise datacenter, in one side, datacenter admin uses the different datacenter software for managing their devices and on the other side these devices are being consumed in the OpenStack by configuring them in the right configuration files such as nova.conf, cinder.conf, etc. There is no way for admin to track these devices consumption in the Openstack other than configuration files, which are installed on different nodes across OpenStack deployment. This will brings the following overheads

  • What are the devices consumed in the OpenStack
  • Which are OpenStack services components such as nova-compute, cinder-volume, etc. consume these devices
  • What are the OpenStack device drivers used for each of the devices.
  • What are the different OpenStack device drivers are loaded each of the Services.
  • When a device is added into the OpenStack deployment, its not verified until the corresponding device driver is loaded while service is starting up. But this should be verified when its get added in to OpenStack deployment

Use case

  • As a cloud admin, I want to add/update/remove a device.
  • As a cloud admin, I would like to manage the device driver stack for a given service.
  • As a cloud admin, I would like to manage device drivers stack for a given device.
  • As a cloud admin, I would like to track the Openstack infrastructure devices and associated Openstack service drivers such as compute driver, volume driver, object driver, etc.
  • As a cloud admin, I want to put a device in maintenance mode.


Tenancy at resource level (SLA management)

Problem

In a cloud, the datacenter resource such as hypervisors, storage devices, network switches are being consumed across the projects and users. But there are scenarios where cloud providers want to restrict the projects to a given set of datacenter resources due to various reason such as security, technology limitations, and SLA, etc. Similarly the given project users wants to create their cloud entities like instances, volume, etc. from the given set of cloud datacenter resources which they don't want to share with other projects in the cloud. These scenarios are not handled in the OpenStack.

Use case

  • As a cloud admin, I would like to maintain the tenancy at the device level.
  • As a cloud admin, I want to allocate devices for a tenant based on SLA such as Disaster recovery support, backup support, QoS. (like availability zone in nova)


Stackforge project (under development)