Difference between revisions of "Self-healing SIG"

Revision as of 10:06, 23 November 2017

Self-healing SIG

Status: Forming (please fill out the survey!)

Original proposal: http://lists.openstack.org/pipermail/openstack-sigs/2017-September/000054.html

Interim follow-up on survey: http://lists.openstack.org/pipermail/openstack-sigs/2017-October/000109.html

Mission

This SIG aims to coordinate the use and development of several OpenStack projects which can be combined in various ways to manage OpenStack infrastructure in a policy-driven fashion, reacting to failures and other events by automatically healing and optimising services.

Scope

The original proposal defined the SIG's scope as self-healing / optimization of cloud infrastructure, meaning it would primarily be of interest to developers and operators, not end users. However it would also be possible to extend the scope to self-healing / optimization of cloud applications (e.g. see https://www.openstack.org/videos/barcelona-2016/building-self-healing-applications-with-aodh-zaqar-and-mistral), in which case end users could also find the SIG useful. We have not yet reached consensus on this point, so please submit your opinion via the survey!

SIG name

We definitely want the scope to include not only self-healing of failures and service degradations, but also automatic optimization such as that performed by Watcher. However this raises the issue that the name "self-healing" is not perfect because "healing" implies something is sick/broken, and optimization occurs even when the cloud is perfectly healthy. As a result we have not yet reached consensus on the SIG's name, so please submit your opinion via the survey!

Background

One of the biggest promises of the cloud vision was the idea that all the infrastructure could be managed in a policy-driven fashion, reacting to failures and other events by automatically healing and optimising services.  Most of the components required to implement such an architecture already exist:

• Monasca: monitoring
• Aodh: alarming
• Congress: policy-based governance
• Mistral: workflow
• Senlin: clustering service
• Vitrage: root cause analysis
• Watcher: optimization
• Masakari: compute plane HA
• Freezer-dr: compute plane HA
• Heat: orchestration (normally used for cloud applications, but can also deploy cloud infrastructure via TripleO)
• Doctor: fault management and maintenance for NFV
• Fault Genes Working Group: Fault classification & Recovery Strategy
• Craton: Fleet management

However, there is not yet a clear strategy within the community for how these should all tie together. This SIG aims to address that.

Goals

• Document reference stacks describing what use cases can already be addressed with the existing projects. (Even better if some of these stacks have already been tested in the wild.)
• Document what integrations between the projects already exist at a technical level. (This was already started during the Denver PTG, by placing the projects into phases of a high-level flow, and then collaboratively building a Google Drawing to show that.)
• Collect real-world use cases from operators, including ones which they would like to accomplish but cannot yet.
• From the collected use cases, perform gaps analysis to help shape the future direction of these projects, e.g. through specs targetting those gaps.
• Perform overlap analysis to help ensure that the projects are correctly scoped and integrate well without duplicating any significant effort.
• Ensure that operators and developers are connecting on this topic on a regular basis, so that project development is steered in directions which will meet real-world requirements.

Audience

• Developers working on the OpenStack projects listed above
• Architects responsible for designing OpenStack deployments
• Operators responsible for deploying and managing OpenStack

Depending on the resolution of the scoping dilemma mentioned above, we may also want to include:

• Architects responsible for designing applications which run on OpenStack clouds
• Developers responsible for developing applications which run on OpenStack clouds
• End users of applications which run on OpenStack clouds

SIG Leads

TBD; Adam Spiers will volunteer if noone else does, but preferably we should have more than one lead to increase the bus factor.

Community Infrastructure

• Wiki: this page (but may be renamed)
• openstack-sigs mailing list; maybe [self-healing] for the tag, but this depends on the resolution of the naming issue mentioned above
• IRC channel: TBD; depends on the resolution of the naming issue mentioned above
• IRC meetings: TBD, #openstack-meeting-$somenumber; agenda / details to be linked on SIG page + meetings list

Upcoming events

• A session has been proposed for the Sydney Forum
• A session will be proposed for the Tokyo ops meetup

History

The idea for the SIG was born out of long-standing efforts to unify the OpenStack HA community around a single solution for instance HA, coupled with the realisation that this was just one of many self-healing use cases required in order for OpenStack infrastructure to be robust and performant.

The first meeting of the SIG happened at the Denver PTG, and was minuted in this etherpad.