Following the recent first release of StarlingX, here’s a breakdown of the main components and how you can get involved.

image

If you’re ready to take flight with the OpenStack Foundation’s newest standalone project, StarlingX here’s what you need to know.

StarlingX, an open source project that offers users services for a distributed edge cloud, recently launched its first release. The project builds on existing services in the open source ecosystem by taking components of cutting edge projects such as Ceph, OpenStack and Kubernetes and complementing them with new services like configuration and fault management with focus on key requirements as high availability (HA), quality of service (QoS), performance and low latency.

“We needed to be able to support growing new technologies like edge, NFV, containers, and machine learning with the existing community we already had,” Jonathan Bryce, executive director of the OpenStack Foundation, told SDX Central.

When it comes to edge the debates on applicable technologies are endless and to give answers it is crucial to be able to blend together and manage all the virtual machine (VM) and container based workloads and bare metal environment which is exactly what you get from StarlingX.

Here’s a breakdown of the five main components:

Configuration Management

Users get node configuration and inventory management services with a highlight on supporting auto-discovery and configuration of new nodes, which are key when it comes to deploy and manage large number of remote sites, some of which might be in hard-to-reach areas. This component comes with a Horizon graphical user interface and a command line interface to manage an inventory of CPUs, GPUs, memory, huge pages, crypto/compression hardware and more.

Fault Management

This framework allows users to set, clear and query custom alarms and logs for significant events for both infrastructure nodes as well as virtual resources such as VMs and networks. Users can access the Active Alarm List and Active Alarm Counts Banner from the Horizon GUI.

Host Management

The service provides life cycle management functionality to manage host machines via a REST API interface. This vendor-neutral tool detects host failures and initiates automatic recovery by providing monitoring and alarming for cluster connectivity, critical process failures, resource utilization thresholds and H/W faults. The tool also interfaces with the board management controller (BMC) for out of band reset, power-on/off and H/W sensor monitoring and shares host state with other StarlingX components.

Service Management

The Service Manager provides life cycle management of services by providing high availability (HA) through redundancy models such as N+M or N across multiple nodes. The service supports use of multiple messaging paths to avoid split-brain communication failures as well as active or passive monitoring and allows users to specify the impact of a service failure with a fully data-driven architecture.

Software Management

This service allows users to deploy software updates for corrective content and also new functionality with a consistent mechanism applicable for all layers of the infrastructure stack – from the kernel all the way up to the OpenStack services. The module can perform rolling upgrades including parallelization and support for host reboot with moving workload from the node by using live migration. Access is available from Horizon, a REST API or CLI.

What’s next

At the upcoming Berlin Summit, the StarlingX community will be out in force. There are number of sessions focusing on StarlingX,  in addition to a project update and onboaring session include:

  • “Ask me anything about StarlingX” Moderated by Greg Waines of Wind River Systems.
  • “Comparing Open Edge Projects”  offers  a detailed look into the architecture of Akraino, StarlingX and OpenCord and compares them with ETSI MEC RA. Speakers include 99cloud’s Li Kai, Shuquan Huang and Intel’s Jianfeng JF Ding.
  • “StarlingX CI, from zero to Zuul” Intel’s Hazzim Anaya and Elio Martinez will go over how CI works and how to create new automated new environments to extend functionality and cover new features and test cases that are not covered inside the OSF.
  • “StarlingX Enhancements for Edge Networking” this session will cover the current state of the art as well as gaps in edge networks as well as go over StarlingX’s core projects, core networking features and enhancements for edge.

Get involved

Check out the code: Git repositories: https://git.openstack.org/cgit/?q=stx
Keep up with what’s happening with the mailing lists: lists.starlingx.io
There are also weekly calls you can join: wiki.openstack.org/wiki/StarlingX#Meetings
Or for questions hop on Freenode IRC: #starlingx
You can also read up on project documentation: https://wiki.openstack.org/wiki/StarlingX

// CC BY NC