Bright OpenStack’s Cluster Management GUI (CMGUI) is optimized for performing daily OpenStack Management operations.  Several capabilities distinguish Bright’s GUI from open source and other versions.

Single pane of glass.
 Bright OpenStack’s GUI is a single pane of glass solution. It gives the cloud admin full management and monitoring access to OpenStack resources as well as all of the components around OpenStack. This includes physical hardware, switches, PDUs, operating system services, hypervisors, virtualized hardware, and virtualized operating systems, various auxiliary software (HAProxy, RabbitMQ, etc.), etc. All from within a single window.


3.jpgLifecycle management.  With CMGUI, you can easily modify the underlying OpenStack deployment as your requirements change. This can be done using the concept of roles.

Need more nova-api nodes? Simply assign the “OpenStack Compute API” role to a node or a group of nodes, maybe change some defaults if needed, and you’re done.  The Bright cluster management daemon will take care of writing out the nova.conf configuration file, starting (and monitoring) the openstack-nova-compute service, and registering the new endpoint with HAProxy.  

Need more Ceph OSD nodes?  Follow the same steps. Simply pick a disk, journal location, and Bright will reconfigure ceph.conf and bring the ceph-osd service up and running.


4.jpgOpenStack management.  Managing OpenStack objects (networks, subnets, routers, VMs, users etc), is straightforward with CMGUI.  Admins always have direct access to all of the OpenStack objects associated in one way or the other with the currently selected object. This makes for very intuitive navigation.

To give an example, click on a Project (top part of the screenshot), to immediately see servers, domain, IPs, networks, routers, and other items associated with that project (bottom part of the screenshot).

Or, click on a network, to immediately see all the ports, IPs, routers, subnets and project associated with it. Then simply select one of those related objects, and immediately see all the objects associated with the selected server. Once you’ve found what you want, just double click to open a window to edit the properties.

5.jpgGlobal search.  OpenStack users frequently cite the need to conduct searches across all OpenStack objects, e.g. “all OpenStack objects (regardless of type) that have been disabled,” or, “VMs that were created 2 weeks ago between 1pm and 4pm.”  This type of search is a snap with CMGUI’s built-in search function.


Managing complexity with filtering.  In production, cloud admins often have to deal with thousands of objects.  With CMGUI, users can easily filter out objects of interest by applying filters to their individual fields. It’s easy to show, for example, all volumes of a specific size, owned by specific tenant, and created on specific date.


6.jpgBatch object edit.  So an API endpoint server has changed and you have to change the URLs of all the endpoints in your Keystone endpoint listing. Now what? Normally you would have to perform 20-30 property updates, one for each single endpoint entry.

Traditionally that takes time and is very error-prone. Not with CMGUI, which offers a batch-edit functionality. Simply select the endpoints you want to edit, and change only the host. All the other properties (port, URL path) will remain as they were.

Monitor the entire stack.  
Bright’s unique CMGUI monitoring view gives admins full monitoring access to the entire stack. Starting with monitoring physical hardware, physical switches, operating system, OS services, the hypervisor service, all the way through virtualized hardware, virtualized operating system and services, up to virtualized userspace programs running inside of those VMs. All from within the same window.

This makes it very easy to correlate events taking place in the virtual layer (for example, slow virtual disk I/O) with the events taking place in physical hardware (like provider network bottlenecks). 


Easy customization of configuration files
  Need to customize nova.conf across several hundred compute nodes? Easy. Just configure which parts of which file you want to edit, and on which nodes you want apply those changes.