OpenStack and Rackspace AN AUST RAL IA P ERS P EC T IVE

2

Who am I?

•  New to OpenStack •  Not new to Open Source

•  Project Team Lead (PTL) for the OpenStack Stable Branch Maintenance –  I make sure that a released version of OpenStack doesn’t regress!

3

Our team

4

Who are we?

•  In numbers – 15 Upstream developers

– 2 Project Team Leads (PTL)

– 10 ‘core’ contributors across 10 projects and many more repositories

– 1 ‘infra-root’ team member

•  More than numbers – Simply put we are 15 developers that are committed Open Source, OpenStack

and our partnerships with our customers and the community

Translating commitment into action

 

6

The conversat ion

•  Initial interest in our Rackspace Private Cloud (RPC) product

•  Needed to support OnMetal (ironic) deploys

•  Wanted Continuous Deployment (CD) of the control plane

•  Needed a simple and safe rollback strategy

•  Installation of the control plane itself is out of scope

•  Application/workload can sustain a degraded state temporarily.

7

What we did

•  Got very excited 😃 •  Partnered with the customer •  Developed a semi-automated

Continuous Deployment tool •  Side-by-Side - Blue/Green •  Rolling Upgrade

•  Open test infrastructure (CI) that doesn’t require ironic •  We’re in the process of modifying

this infrastructure to augment to OpenStack CI gate

•  From scratch under and Open (Apache) license.

8

The scenar io

•  A running workload which can’t be interrupted •  A running OpenStack Control Plane (CP1) “in charge” of the nodes

•  A deployed the new OpenStack Control Plane (CP2) waiting for nodes

9

What i t does – i t ’s s imple said out loud

The ‘fork-lift’

1.  Notify workload manager that a node will vanish

2.  Wait for workload on that node to complete

3.  Save the meta-data about node 4.  De-enroll node from ironic in CP1 5.  Enroll node in CP2 with the meta-

data saved previously

6.  This will reboot the node 7.  Notify workload manager that a

node is available 8.  Monitor application/workload

stability 9.  Repeat

10

A few considerat ions

•  Add/Remove Control planes •  Automated ‘one click’ migrate

Control plane now •  Viewing the progress of the whole

process •  We need to be able to ‘lock‘ the

system to prevent any fork-lifts •  We need to be able to pause the

system to address application/stability

•  The level of parallelism is limited by the application/workload

•  The workload is upgraded outside of the fork-lift

•  All using OpenStack APIs not product APIs

•  Which endpoints do the OpenStack APIs target?

11

Summar y

•  Introduced our team and culture •  Showed how we translate that culture into value for our customers

•  Described the OpenStack new tool we created – The tool is destined for the OpenStack ‘big tent’

– Built using OpenStack principles and paradigms

– Built for OpenStack by an OpenStack team

Thank you

© RAC K S PAC E LT D . | RAC K S PAC E® AN D FAN AT I C AL S U P P ORT ® ARE S ERV I C E M ARK S OF RAC K S PAC E U S , I N C . REG I ST ERED I N T HE U N I T ED STAT ES AN D OT HER C OU N T RI ES . | W W W.RAC KS PAC E .C OM

ANZ

L E V E L 1 , 37 P I T T S T R E E T, S Y D N E Y N S W 2 0 0 0 , A U S T R A L I A

A N Z S A L E S : 1 8 0 0 7 2 2 5 7 7 | U S S U P P O R T: 1 8 0 0 4 2 1 2 6 7 | W W W . R A C K S PA C E . C O M