ManageIQ - Next MovesOleg Barenboim

@chessbyte

Thank You Sponsors!

History

April 2006 - ManageIQ, Inc. founded

December 2012 - Red Hat Acquires ManageIQ, Inc.

April 2013 - CloudForms 2.0 released from ManageIQ code base

June 2014 - Red Hat open-sources ManageIQ

October 2014 - First ManageIQ Summit

June 2016 - Second ManageIQ Summit

ALL Key Engineers from Startup are still working on ManageIQ

Multiple Teams at Red Hat working on ManageIQ

Multiple Teams at other companies working on ManageIQ

Evolution of Focus and Message

Enterprise Virtualization Management

Hybrid Cloud Management

Cloud Management Platform

Open-Source

Cloud Management Platform

Open-Source

Management Platform

Open-Source Management Platform

Separate Repos

Many Provider Types

Many Providers

Provider Pluggability

User Interfaces

Automate

PostgreSQL Clustering

Metrics

Messaging

Componentization

Focus

Easier to dedicate person or team to specific repo

Expertise

Test Isolation

Allows for Different Build Combinations

ManageIQ for Public Cloud, for example

Separate Repos - Why?

User Interfaces

Provider Integrations

Logical Components to split off

Automate Engine

Separate Repos - What?

Cloud

Public

Private

Virtual Infrastructure

Containers

Configuration Managers

Network

Cloud Network

Storage

Applications (Middleware)

Many Provider Types

Microsoft Azure

Google Cloud Engine

Amazon Web Service

OpenStack

Microsoft System Center Virtual Machine Manager (SCVMM)

Red Hat Virtualization Manager (RHEV) / oVirt

VMware vSphere

OpenShift

Foreman

Providers - Working

Hawkular

Nuage

NetApp

Oracle Virtualization Manager

IBM SoftLayer

Providers - Being Built

Simplify Engineering of New Provider

Standardize Engineering of Each Provider

SQL Schema in Platform

Each Provider Integration in separate Repo (under ManageIQ organization)

Provider Pluggability

Inventory - Full, Targeted, Skeletal

Events

Metrics

Operations

Operations with Automate (e.g. Provisioning)

SmartState

Provider Pluggability - Interfaces

Should behave similarly for all providers of same type

Without significant code changes

Ask, Don’t Tell

UI

Gray Out/Hide/Change Functionality by asking Provider of its capabilities

Enable/Disable Functionality by asking Provider of its capabilities

Provider Pluggability - UI and REST API

Plural - More than 1!

If a ManageIQ UI can do something, so can you via REST

Will Push REST API to continuously improve

User Interfaces

Modern Architecture

https://en.wikipedia.org/wiki/Single-page_application

Fits on Single Web Page

Provides more fluid user experience

Self-Service UI

Future ManageIQ UIs

User Interfaces - Single Page Application

Move Classic UI into its own repo

Self-Service UI already in its own repo

Each additional UI in its own repo

User Interfaces - Separate Repos

Service Designer

Self-Service UI already in place

Adding Admin Capabilities

Will replace Services Tab in Classic UI

New Admin UI?

Zones, Appliances, Roles, Workers

Settings

Global (Authentication, eMail Servers)

Zonal

Appliance

User Interfaces - Future UIs

Methods over REST API (instead of DRb)

Methods via Docker Container

More Secure

Can restrict access to file system

Can restrict access to network

Separation of Gems for ManageIQ vs. User Method in Automate

Allow for Multiple Containers for Different Purposes

Datastore as Git Repo

Versioning

Each Run of Automate can go against specific Git SHA or tag

Automate

Failover

High Availability

Database Administration (e.g. Re-Indexing, Vacuum)

Crawl => Insight

Show how well PostgreSQL is running in ManageIQ installation

Walk => Control

Recommendations actionable by Admin

Run => Automate

Automated Recommendations (Admin needed for exceptions)

PostgreSQL Clustering

ActiveMetric Abstraction Layer

Support Multiple Backends

PostgreSQL (current)

Hawkular-metrics

InfluxDB

Prometheus

Metrics - Time Series Databases

May evolve over time

Technology front-runner changes

Licensing changes

Open Source => Open Core => Closed Source

We already did this with Database using ActiveRecord

MySQL

PostgreSQL

Microsoft SQL Server

Metrics - Time Series Databases - Default Backend

Message Routing and Job Processing all rolled into 1

Simplify MiqQueue to enable use of standards

Create ActiveMessage Abstraction Layer

MessageBus back ends

ActiveJob Abstraction Layer

Already standard in Rails

Stick with current worker architecture?

Pick simpler, standard Job processors?

MiqQueue

Monolithic Container near completion

Multiple Containers is next step

Better deployment architecture

Better upgrade architecture

Better security architecture

Will force separation and isolation of stateful vs stateless components

Containerizing ManageIQ

ManageIQ should introspect its appliances

Crawl => Insight

Report on current installation

Recommend potential improvements in deployment architecture

Walk => Control

Admin confirmed recommendation deployed by ManageIQ

Run => Automate

Automated monitoring

Admin needed to handle exceptions

Self-Managing Deployment Architecture

Modularization

Componentization

Extraction?

Rails was extracted from Basecamp in 2004

ManageIQ Platform

Open-Source

Management Platform

Vote on Name of E Release

Will Announce Winner Tomorrow!

Manage All the Things!

One More Thing

Chess Simul after Sessions Today

Anyone can try their luck!

@chessbyte