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 Happy 10 Year Anniversary, 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 Containerizing ManageIQ Self-Managing ManageIQ Platform
Separate Repos - Why? 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 - What? User Interfaces Provider Integrations Logical Components to split off Automate Engine
Many Provider Types Cloud Public Private Virtual Infrastructure Containers Configuration Managers Network Cloud Network Storage Applications (Middleware)
Providers - Working 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 Ansible Tower
Providers - Being Built Hawkular Nuage NetApp Oracle Virtualization Manager IBM SoftLayer
Provider Pluggability 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 - UI and REST API 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
User Interfaces 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 - Separate Repos Move Classic UI into its own repo Self-Service UI already in its own repo Each additional UI in its own repo
User Interfaces - Future UIs Service Designer Self-Service UI already in place Adding Admin Capabilities Wil replace Services Tab in Classic UI New Admin UI? Zones, Appliances, Roles, Workers Settings Global (Authentication, eMail Servers) Zonal Appliance Introspection into Deployment Architecture New UI to validate REST API? Development, Test, Troubleshoot
Automate 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 Al ow for Multiple Containers for Different Purposes Datastore as Git Repo Versioning Each Run of Automate can go against specific Git SHA or tag Future integrations into IDEs
PostgreSQL Clustering 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)
Metrics - Time Series Databases ActiveMetric Abstraction Layer Support Multiple Backends PostgreSQL (current) Hawkular-metrics InfluxDB Prometheus
Metrics - Time Series Databases - Default Backend 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
MiqQueue 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?
Containerizing ManageIQ Monolithic Container near completion Multiple Containers is next step Better deployment architecture Better upgrade architecture Better security architecture Wil force separation and isolation of stateful vs stateless components
Self-Managing Deployment Architecture ManageIQ should introspect its appliances Crawl => Insight Report on current instal ation Recommend potential improvements in deployment architecture Walk => Control Admin confirmed recommendation deployed by ManageIQ Run => Automate Automated monitoring Admin needed to handle exceptions
ManageIQ Platform Modularization Componentization Extraction? Rails was extracted from Basecamp in 2004
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