|
|
| Line 1: |
Line 1: |
| − | == Introduction ==
| |
| − |
| |
| − | Openstack is made of Openstack services, Openstack device drivers and its echo-system is made of Datacenter devices such as Hypervisor, Storage devices, network switches. And all these together could be named as 'OpenStack infrastructure' on which operator setup the cloud. Openstack is termed as 'cloud operating system' and 'namos' provides infra manager to provide 'device manager' and 'service manager' functionalists similar to the traditional operating system such as Ubuntu. To accomplish these functionalists, 'namos' provide the RESTful representation for complete OpenStack infrastructure which includes devices, device drivers and OpenStack services.
| |
| − |
| |
| − | Also it provides the RBAC for the different actions performed on the devices and services.
| |
| | | | |
| − | [[file:Openstack-software-diagram.png]]
| |
| − | Namos binds Openstack platform with data-center devices
| |
| − |
| |
| − |
| |
| − | == 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 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 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 want to add/update/remove a device via a common service CLI where the connection to device is validated.
| |
| − | * As a cloud admin, I want to put a device in maintenance mode
| |
| − |
| |
| − |
| |
| − | === Service Management ===
| |
| − |
| |
| − | ==== Problem ====
| |
| − |
| |
| − | In the Openstack cloud, once all the services are deployed, there is no way to figure out the deployment architecture of these services. Take the example of the Heat service, once heat-api, heat-cfn, heat-engine(s) are installed, there is no way to figure out where these service components are installed. In a scale-out deployment, it becomes an overhead.
| |
| − |
| |
| − | ==== Use case ====
| |
| − | * As a cloud admin, I would like to track the Openstack service and it's components deployment and its consumption of cloud datacenter devices.
| |
| − | * As a cloud admin, I would like to monitor the performance of Openstack components such as memory, RAM and number of messages from the given queue. So service like icinga/ceilometer can use namos to get the service deployment topology.
| |
| − | * As cloud admin, I want the service components to register itself to the Namos service and thereby I can use the Namos service as the central service discovery portal.
| |
| − | * As a cloud admin, I want to put a service in maintenance mode
| |
| − |
| |
| − |
| |
| − | === Tenancy at resource level (Quota 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, 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 consumer and admin scenarios are handled in the OpenStack Juno release
| |
| − |
| |
| − | ==== Use case ====
| |
| − | * As a cloud admin, I would like to maintain the tenancy at the infrastructure device level. As well, I want to allocate devices for a tenant based on its capabilities such as Disaster recovery is supported or not, backup is supported or not, etc, (like availability zone in nova)
| |
| − |
| |
| − | == Different Roles perspectives ==
| |
| − | === For Operator ===
| |
| − | It act as boundary between OpenStack and its echo-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 functionalists nor data-center 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 echo-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==
| |
| − | * First Region based service in Openstack
| |
| − | * Complements Keystone by means device and service management per region
| |
| − |
| |
| − | [[file:Keystone-like-namos.png]]
| |
| − | Keystone for user management, Namos for device management
| |
| − |
| |
| − | == Stackforge project (under development) ==
| |
| − |
| |
| − | * Namos project is created in the Stackforge https://github.com/stackforge/namos
| |
| − | * Currently under development.
| |
| − |
| |
| − | == Other references ==
| |
| − | * In Kilo, Namos was selected as alternate session and presentation is available at https://www.openstack.org/vote-paris/Presentation/namos-openstack-infrastructure-manager
| |
