Fuel 9.0

Copyright © 2015 Mirantis, Inc. All rights reserved

www.mirantis.com

Fuel 9.0: LCM and Extensions

Vladimir KuklinPrincipal Deployment [email protected]


Agenda

● Fuel Overview● Fuel LCM Engine

● Day 1● Day 2

● Fuel Extensions Engine


Fuel: What it Does

Fuel convertsHigh-Level

(Bake me an OpenStack cluster)TO

Low-Level(Set keystone IP, install Galera, add Mongo/Ceph/etc.,

configure bonding, ….)AND EXECUTES IT ACROSS A CLUSTER OF NODES


Fuel Deployment Pipeline


Fuel Deployment Task

id: keystone-db

groups: [primary-controller]

cross-depends:

- name: /^(primary-)?database$/

type: puppet condition: changed($.keystone_conf)

required_for: [keystone]

requires: [primary-database]

Parameters:

puppet_manifest: keystone_db.pp

Puppet_modules: <modulepath>


What is LCM

A set of Day-2 Operations Including Those

LCM

Deployment and scale up/down

Package management of OpenStack and HostOS

Modification of reference architecture UpdatesUpgrades

Configuration management for OpenStack and HostOS


Main Issues With LCM

Scale-up/down requires Orchestration in general case● Ceph rebalance

Configuration management is simple in simplest cases (Puppet Master), requires orchestration for general case● Mysql reconfig

Reference architecture changes requires orchestration as well● Detach database

Upgrades and updates require workflow composition business logic● High probability of failure

Ansible/PE/PM/Salt do not entirely support all of these


Fuel LCM Engine

Fuel 9 provides foundation for efficient LCM of OpenStack clouds

Fuel LCM

LCM-ready deployment tasks and Puppet modules

Task-Based Deployment engine

Custom Workflow Management

Computable Workflow Params (e.g. dependencies)

Gracefully Stop/Restart Deployment

Control Deployment Flow - History, Debugging, etc.


Fuel LCM: Day 1 operations in Fuel


Fuel LCM: Day 1 operations in Fuel 9

Use cases1. Stop is non-graceful2. Full redeployment takes a lot of time and is not configurable3. A failure on a subset of nodes (incl. HW failures) blocks entire progress4. Hard to overview and debug the failure


Day 1 operations in Fuel 9: Features

Features:1. Graceful stop of the deployment

a. Wait for workers to finish

2. Separated deployment and provisioning of nodes on UI3. Task Based Deployment

a. More efficient deployment and fine-grained deployment

4. Fault Tolerance per rolea. fail on 1st controller failureb. tolerate 2% computes failures

5. Deployment tasks history


Task-based Benchmark on bare metal lab

Case #1. 3 controllers + 7 computes w/ ceph

~2 times faster

Task-based deployment takes ~38 minGranular deployment takes ~1h15m

Case #2.3 controllers + 3 mongo + 4 computes w/ ceph

~2.24 times faster

Task-based deployment takes ~41 minGranular deployment takes ~1h32m

The deployment time is average time for 10 runs


Fuel LCM: Day 2 operations in Fuel


Day 2 operations in Fuel 9: Use Cases

Use Cases1. Add Ceilometer/Murano/Sahara/etc. to the cloud2. Add a plugin to the cluster3. Change OpenStack/Networking/etc. settings4. Audit of changes

a. What actions were done (task history, control flow)b. What changes were delivered (data+configuration history, data flow)

5. Complex one-shot workflowsa. Security Updatesb. Doing Upgrades



Features: Part 11. Post-deployment plugins

a. Example: “Install Stacklight on an already deployed cloud”

2. Unlocked settings taba. Example: “Change cluster configuration on UI, hit “Deploy changes”

3. Deployment config and tasks historya. Example: “Show tasks that were executed during previous “Deploy changes” run with all the

input parameters”

4. Data driven deployment orchestration (YAQL-based)a. Example: “Run only necessary tasks (those whose input data changed), avoid unneeded

service restarts”

5. Dry-Run and simulation of graph execution


Features: Part 25. Custom Workflows

a. Example: “Rolling update - install new versions of package XYZ on every MOS Compute, reboot them one by one”

6. Advanced Settings v1.5a. Example: “Update Galera config gracefully with proper failover”



Fuel Extensions


Prior to 9.0● Plugins

● Deployment tasks■ Example: Config etckeeper

● Additional roles■ Example: Contrail

● Additional attributes and metadata■ Example: Partitioning■ Example: Cluster settings

Fuel Extendability


Added in 9.0● Extensions

● Stevedore-based● API● DB Models● Serializers (High level -> Low level)● CLI v2● YAQL Helpers (in Newton/9.1)● Callbacks on actions (e.g. reset/delete)

Fuel Extendability


● CI/CD flow● Mix deployment data with particular ‘master’ configuration in GIT● Run against a staging through API● Commit to production● Run against a production through API

● LDAP integration● Add a method to pipeline to mix LDAP data in● Run the deployment● Handle additional configuration through plugins

Fuel Extendability: Example


● Orchestration Finalization● Everything as a graph● Fully data-driven● Pluggable provisioning/network verification/…● Business Logic for Composition of Custom Workflows

● Scalable torrent-based provisioning● Better audit and reporting (noop actions and parsers)● UI for deployment tasks history● More fine-grained services allocation

Fuel Future: Some Plans


Questions?

[email protected]#fuel @ irc.freenode.net,

Openstack-dev ML (Use [Fuel] prefix)


Thank You

Fuel 9.0

Technology

Transcript of Fuel 9.0