In this technical session, we will talk about Graffiti, a new cloud capability project that HP and Intel have started working on and we invite your participation. The intent of Graffiti is for OpenStack users to be able to declare the capabilities and service level objectives they require at a higher, more portable way than they do today. The system will then guide the selection of lower level cloud resources that match the desired capabilities.
Various OpenStack services have introduced techniques to abstract some of the low level resource selection to one level higher (such as flavors or volume types). While powerful, a challenge that we’ve experienced with OpenStack is that the way resource types and resource instances get exposed and discovered across services makes usage and remapping across deployments a manual and error prone process. Graffiti provides a common methodology to describe resource capabilities in the cloud which we believe can then be leveraged by other projects such as Horizon, Nova, Heat, scheduling, reservation, and policy enforcement to enable better cross service collaboration and consistency.
We will be showing a proof of concept demo in Horizon that crosses Nova, Glance, and Cinder. We would then like to discuss with the community where Graffiti can best fit in to the ecosystem and how it may relate to other projects and use cases.
Mistral team completed a POC for the workflow service. This POC covers an initial version of Mistral DSL to define tasks and transitions between them and Mistral engine with its main concept implemented. There is a huge discussion in the community about the right set of technologies which should be used for workflows orchestration\execution. Using the POC code we want to show how customer use cases listed on Mistral wiki can be implemented with Mistral approach. Also we want to show requirements to engine raised during POC implementation. These requirements will be used to find out how the taskflow library can be used to implement Mistral engine functionality.
Refstack is a suite of interoperability verification test tools and a compliance test set for OpenStack service and product vendors.
Refstack provides official testing channels and hosted scorecards on refstack.org. In addition, RefStack includes a command line interface and a way to run a local copy of the RefStack website internally on your cloud installation. Private cloud builders can run the tests internally to generate scorecards for clouds that do not have API endpoints that refstack.org can reach.
Refstack uses the official OpenStack testing tool, Tempest, as its test engine. The definition of core and "must pass" criteria will be defined by the DefCore committee.
In this session, we will discuss RefStack, its purpose, architecture, operation and Q&A.
Rally started as a pure benchmark tool for OpenStack project.
During the last 8 months we grow from small script to quite a big testing tool, that allows you to produce clouds, verifies it (using tempest), benchmark it & generate reports.]
It seems like that we could build on this fundament an very interesting for Operators: 1) Verification 2) Health check 3) Track API performance 4) Track VMs performance (cpu/io/mem/network) 5) Periodic tasks 6) Analyze of ceilometer data 7) Integration with horizon + notifications (emails/sms) in case of something went wrong 8) Historical data reports
At this session the MagnetoDB project will be presented; architecture and usecases.
We will discuss OpenStack internal use cases and integration with other projects. - MagnetoDB as storage for OpenStack Celiometer - MagnetoDB as datasource for Sahara driven Hadoop analytic - Trove as database provisioning layer for MagnetoDB
It will be nice to discuss future of Climate project, that is currently located on Stackforge. This project aims to bring leasing and resource reservation opportunity to OpenStack, we need to find best solutions and practices for that.
Link to Climate's Launchpad: https://launchpad.net/climate
Related cross-project session: http://summit.openstack.org/cfp/details/45 - here we'll discuss common principles of where that should be placed
This session is dedicated to projects aimed at operations of OpenStack-based cloud. Operations is a very broad topic, including monitoring, discovery and validation of configuration and diagnostic of faults.
Contributors to such projects as StackTach, Rubick, Satori, Mistral and everyone interested are very welcome.
We would like to discuss main goals:
1. short-term goal of supporting OpenStack gate, including TripleO deployments with additional automated diagnostics of faults and cross-services validation of configuration;
2. long-term goal of providing tool set to diagnose clouds in operation, with configuration discovery and workflow- based inspections and problem determination in the cloud.
