unfortunately my co-speaker couldn't make it today, so it's just me.

All right?

So forgive me if the talk's not as good as it would've been, but I'll do my best.

This is my Twitter handle, and this is our company's Twitter handle as well.

Feel free to drop a note if you feel like it.

We have these exact slides up on GitHub pages,

so if you wanna follow along, if you can't see right now, or if you

wanna look at them later, just point your browsers to Hastexo.GitHub.IO/2015.

All Right?

It's exactly what I'm gonna show here, sans the little pieces of demo.

Okay?

So without further ado, this is OpenStack for Open edX, inside and out.

What is this really about though?

What made us decide to use edX and OpenStack?

The motivation was this.

We are a consulting company, and we consult on OpenStack, and

we also do a lot of training.

Right? So we fly out to places, do training.

And we've discovered as all trainers do that training is time consuming,

and we'd rather develop the course once and have trainees and

students take it at their own pace.

Right? So,of course edX came to mind

as the MOOK of choice nowadays.

or the mooc platform of choice, nowadays.

The problem is on our training environments, when we give

trainings regularly, we give each and every student a training environment.

In other words, if we're teaching OpenStack or if we're teaching stuff,

we give students a cluster to play with, their own cluster so

they can deploy things, break things.

And then, we go in and fix them and so on and so forth.

How could we achieve the same thing in a self-pace massive online course?

Right?

So, this is the motivation.

How do we do that and not bankrupt anybody at the same time?

Okay?

I'm gonna assume a little bit of knowledge about OpenStack here, not too much.

Okay? So

I'm gonna use a couple of terms that I'm not gonna spend too much time to explain.

So you're gonna get the most of this if you know a little OpenStack.

You should know about edX configuration, or okay?

In other words, you should have probably deployed edX at least once so

you can understand what I say when I mean playbooks and roles.

Okay?

And you should probably have heard of XBlocks.

Has anybody not heard of XBlocks here.

Okay. Cool.

So you're gonna be fine.

Okay, so now, why?

Why did we choose OpenEdX?

Why did we choose OpenStack?

First of why OpenEdX?

Well, mostly, since we work from a background of open-source and

open-source consulting, we wanted to build our training on open-source platform.

And of course Open edX qualifies.

Now that's the only thing.

Being open source is not all it takes for an open source project to be good.

It needs to be alive as well.

Right? There needs to be leadership that

embraces the community and contributions.

And OpenEdX is, you know, top march on that, thanks to,

for instance, Singy Wolfboy here in the front.

[LAUGH] Or what's your real name again?

>> DB. >> DB?

>> Yeah.

>> Okay, so DB,

known as Singy Wolfboy on IRC, and

Netbat, also here in the room, which helped us a lot.

So this is what we think is a good open source project,

one that has people behind it that talk to you.

Okay so Open edX top marks on that, community and openness.

Technology.

Open edX is built on Python.

Right? And Python is

basically just English that a computer can understand.

Right? So it's awesome that you can go in and

read the code, okay, because of pep eight, right, thanks to Guido.

Right?

So the technology behind edX is rockable.

We can easily go in and understand it.

So that's another point.

The third and almost the most important point is extensibility.

We knew that no LMS platform out there would do what we wanted out of the box.

That's a given.

So we wanted something that we could use to build on.

Okay?

And Xblocks.

Right?

That's what caught our attention, and that's why I'm here, really.

And of course the coolness factor.

Right? Open edX is cool.

It's the cool kid on the block in LMS.

All right?

So we wanted to work with something that we would be glad to be

working with every day, and Open edX certainly qualifies.

Why OpenStack?

Well, openness in community, technology, extensibility, coolness factor.

Do you see the pattern here?

It's also an awesome open source project that has a great community around it.

The technology?

Well, it's written in Python as well.

So, right?

Awesome.

It's extensible by definition as all Cloud platforms should be.

You need to be able to build your own stuff in there.

Alright?

And it's also the latest,

greatest, coolest kid on the block as far as Cloud platforms go.

So bingo.

OpenStack, Open edX.

Yes. First problem we faced,

deploying Open edX on OpenStack.

So how do you go about doing that?

If we're just deploying a single node, it's pretty easy.

Right?

You take the sandbox.sh script in edX configuration,

port it to cloud-config, put it in a heat template, and

then use the edX send box playbook to fire up a single node.

Okay?

So that's pretty easy to do, really.

And it's very documented in the edX docs.

Okay? So we didn't have a lot of trouble there,

except with the fact that you do need eight gigs of ram to run a single VM.

A four gig VM won't, you know it'll crawl to its knees soon enough,

and we took a while to discover that.

Okay? So that's easy.

How about a cluster on OpenStack.

Right? that's the whole point.

And, you know, I sat with what's, your name again?

Sorry. >> Brandon.

>> Brandon.

I sat with Brandon over lunch, and

we discussed clusters on open second and otherwise.

Right? And

we all have our little stories to tell.

And doing clusters, anything, really, is not very easy.

Luckily, edX is not all that hard, either.

Okay? So, we'll get to that in a moment.

But the first question is, all right.

So these guys, these edX guys, they have an edX.org site, right, with edX.

And supposed with hundreds of courses in there, thousands of students.

So, they probably know what they're doing with edX [LAUGH].

Right? So how is open edX deployed on edX.org?

Luckily, last year there was a talk by a guy named Fenil Patel.

Is he here, by the way?

>> He's here today.

>> Is he in the room?

>> No.

>> That's too bad.

I wanted to shake his hand cuz that sort of,

that was our golden brick roads to what to do about it.

Okay. So if you had a really nice slides with,

if you're medium installation, you do this.

If you're bigger, you do that.

So that was awesome.

The only thing is, he didn't encode any technical details on how to do it, [LAUGH,

as he shouldn't really.

But anyway, we were still sort of in the dark as to exactly what to do, but

we have a way to design a cluster.

So now if you look, yeah,

it's gonna be kind of hard to understand here, but bear with me.

There's a user guy up here and an administrator guy here.

So, our cluster has a load balancer in front

of an arbitrary number of app servers, where an app server

is composed of an LMS the CMS and

everything that's not the mobile data store or

the bicycle store.

So everything resides on a scalable number or an arbitrary number of app servers.

That talk to three, or actually in our case exactly three nodes.

Why three?

Because that's the minimum number of nodes for Galera.

So Galera was our choice, of course,

based on the fact that there's a nice MariaDB role

in edX configuration for clustering MySQL.

There you go.

So we use that, and it requires at least three nodes to work.

So that's why we have three back-end servers here.

All of the app servers talk to one of the nodes for now.

It's an improvement to our cluster layer to have a load balancer between the two.

And the administrator, and this was key to how we did it.

The administrator gets a deployment node in the cluster

from which he runs the edX configuration roles, and deploys everything to the rest.

I'll get to how in a minute.

So we have a design for a cluster, how do we implement it?

Can we use examples from edX configuration?

For instance, the other US play books.

Or actually, it wasn't the play books, it was the call for information templates.

Can we use those?

No, because they were removed.

[LAUGH] Right?

And I talked to a couple of the guys here as to, okay,

so why did you guys remove these templates?

And the reason is nobody used them.

All right. So, all right.

Fine. We'll have to come up with something from

scratch.

How about pay books for clusters?

We come through edX configuration and we found something called vagrant cluster

YML, which is the sample cluster, I guess.

Sample cluster playbook, I guess.

And it gives us clues as to what to do about the point that's in a cluster.

Okay, so that was awesome.

Thanks to whoever wrote this.

Is he or she in the room?

>> [INAUDIBLE] >> Do you know who it is?

>> Carson. >> Oh, Carson.

Oh man, too bad, yeah.

I love Carson.

He did a lot of things that we ended up using.

Okay, so we have a playbook.

What variables do we set?

So we went on a quest for finding the proper variables to set so

that the cluster would work.

Okay, so for back end nodes you need to set vulnerable clusters,

elastic search clusters and OMDB clusters equals yes.

So awesome, that worked pretty well.

There are a couple more.

And for app servers you need to point all of the database variables and

backup variables to the database servers that you're deploying.

Okay, so this is kind of hard to read here, but we pulled a little Ansible

trick here, which is to say always point for MySQL, if your an app

server always look to the first back end server whatever its IP address is.

And for Mongo,

you just say use all of the back end servers that we have configured here.

I'll get to how this works in a minute and

this is the end result of a dynamic inventory generated,

which open stack helps us with.

All right, next we needed to write a heat template.

A heat is the equivalent of Amazon's cloud formation,

but it does basically the same thing.

You write a sort of recipe for the deployment of a whole cluster.

In our case, we needed the following shopping list, one security group,

one private network with a router, two cloud configs, a deploy node with an IP,

a load balancer with an IP, three back up servers,

and an arbitrary number of app servers.

So this is all coded in a heat template, and