 Alright, so today I was going to give a talk about Eucalyptus and Debian and I was going to do a bit of a demonstration as I did with OpenState yesterday, but unfortunately as Jimmy pointed out to me earlier at breakfast, Eucalyptus was removed from Debian yesterday. So instead I'm going to give a little history on what the reason behind that was, why I'm here, where Eucalyptus and Debian are going forward. So about three years ago, four years ago, those of you familiar with Ubuntu and Canonical, they decided to rebrand Eucalyptus as Ubuntu Enterprise Cloud. So they made Debian packages out of it and they maintained them and then when their relationship kind of went awry with the Eucalyptus company in Canonical, Eucalyptus decided to abandon it, move with OpenState, so now they rebrand OpenState and call that Ubuntu Enterprise Cloud. So Eucalyptus was left to hustle trying to figure out who they were going to get the package Eucalyptus for Debian, so they hired me. So last year I finished packaging Eucalyptus for Debian and it got into unstable just after the freeze for Weezy, which in this case might have turned out to be a good thing because as of about a year ago, they decided, you know what, we just don't have enough QA resources to devote to Debian and Sentos, so they dumped Debian again. So I spent the last year trying to convince them, you know, Debian is important, I'm a Debian developer, you know, it's kind of a black eye that we keep doing this craziness and screwing with people in Debian community. So we've decided, I've decided to devote getting the next version in to Jesse. So in lieu of that, instead of giving a talk and a demonstration on it in Debian since it is not there, I decided to give a demo today and if the network will cooperate I will happily do that, but it looks like my VPN is down, so we may just have to have a quick little talk and y'all enjoy that because you'll get a lunch much sooner than you would have otherwise. That fucking network, it's just going a little slow. So as some of you may know, some of you may not, Eucalyptus is an official partner of AWS and Eucalyptus was basically the first ever private cloud. They basically took Amazon's web services at the time about five or six years ago when they were nascent EC2, S3, excuse me, the object storage and EBS, which is the block storage and they reinvented it on the private side so that customers such as government institutions, banks, whoever wants to keep their data private, they don't want it on a public cloud, they can use the same set of APIs there and it's expanded into companies who develop on AWS and they've run up a large bill on AWS, come to us to kind of retract some of their services off of the public cloud onto the private cloud and then they burst when they need to onto the public cloud. So we basically re-implemented their main services, like I said EC2, S3 and EBS, which is their block storage. We've also recently done their elastic load balancing, auto scaling and cloud watch. Finally, I think I may be able to show you something and quit yacking here. And some of you, most of you who aren't even familiar with Eucalyptus might have used this anyway. On the client side, we also have a set of tools called Eucatools, which are command line utilities that access BOTO, which is the Python implementation of the library to access AWS APIs. It works for both Eucalyptus and Amazon and I believe that James pointed out he actually uses some of its functionality to build the Debian image for Amazon. And please forgive me here, we're over at VPN in California, so it's not really this slow usually, I promise. So this is our user interface, if it's showing up and I'm going to compare and contrast that to the Amazon user interface, which in all of its mass of glory today, here in a second, and then show how Eucatools can be used to operate on both clouds. So here's the dashboard, basically gives you an overview of your cloud. These are your instances, which is the equivalent to EC2, except we use KVM instead of ZN on the back end for our virtualization. Here are your volumes, which are your EBS volumes, which is your block storage. Snapshots, which are backups of volumes that are stored in our S3 storage called Walrus. Security groups, key pairs, IP addresses, same thing you would find in Amazon for managing elastic IPs, accessing your instances, and determining the routing rules on those instances. So without further ado, let's do a demo instead of yakking. So as you can see now, we've got a big launch new instance button, so we'll start with that as that's what most people want to do. You'll notice here I have only a precise image, don't boo, because later I'm going to show you how to import your WN7 image. So you click on the type of instance you'd like to launch. We have just one here for the demonstration, but we support all variants of Linux as well as Windows. You then select your instance type, which I've limited to a few here, but we mapped to Amazon's nomenclature there as well, M1 micro, T1 micro, so on and so forth. You then select your security group and your key pair. Your security group defines which ports are open by default. As you can see here, and I've opened 80 for WebTraffic and 22 for SSH. And you select your key pair. This allows you to SSH into the machine, much like Google does, we inject the keys on instantiation so that there is no access via password. And then you launch the instance. And if all goes well within a little bit, that should pop up. And then, so that's just an instance store image, which means it just has ephemeral storage, which means when you write anything to it and you shut it down, it's going to die. That is going to go away. So a lot of people like to create boot from EBS images, or you can just create a volume to store your extra data on, which uses our block storage mechanism much like EBS. You just specify the size. We'll make one of two gigabytes. And I pre-canned one here in case my cloud doesn't wish to cooperate. And then you can attach that volume as you see it created here, it just popped up. We can then select that volume and attach it to an instance as such. That was an instance not up yet. What's up with my chromium here? Come on, chromium. There we go. And so as you can see, the state has changed over here to attaching. And it is now attached to that instance as block storage. So if we drop back to our command line here, I can show you how you can interact with that. So these are the command line tools I was talking about before. So if you're more command line oriented like a lot of WP people are, instead of using the UI, it would help if I source my credentials. And unfortunately, the data gets kind of munged together. And if you look closely, you can see that there's two instances running. One with the idea of I89 yada yada, we use the same type of nomenclature AWS does there as well. And you can SSH into these instances. By using the key pair you chose at launch time, I used debconf. And in this particular image, we have root enabled by default, but you obviously likely would want to do something with your image. Oh, would help if I gave it the right, fine name. The default Ubuntu image is obviously used by the Ubuntu user, not the root user. This is just one within our testing environment. I must have attached it to the other instance. Okay, so there she is. So the volume I created and then attached to the instance now shows up as a block device. And you can treat it like any block device. And we'll go ahead and format it, extend it for format. And then we'll mount her. And we're going to go into that mount point and show you that it is an empty volume. And we will echo a file here, we will mount it. Then we will go back in our interface here, and you can do it on the command line as well. I'm just trying to show you as much as possible. Click on the volume and detach it. So now that file is permanently stored in that volume. So if you ever need to access that data again, you can simply reattach it to any other instance you'd like. You can only attach to one instance at a time, obviously, though. Then we can go into our snapshot section. We already have one created here. But we can create a new snapshot based on what we just made there in the volume. So you choose your volume and then you click create. And what that does is takes that entire two gigabyte volume and saves it at that point in time in your S3 object storage. So that if you make further changes and you want to go back in time, you can make a new volume based on that snapshot. And I'll show you how to do that here. It's very simple. You just go back into your volumes again. As you can see, that other one's now detached. You got to create new volume. You choose the snapshot you'd like to create it from. And you just click create volume. Well, that looks like my run out of disk space on this test machine. But that's the general way to do it. So that's basically the three major services of Eucalyptus in a nutshell. Obviously, it gets much deeper than that when you go into auto scaling, setting up your monitoring services with CloudWatch, Elastic Load Balancing. But as far as the simple dev test use of Eucalyptus, it's much like that of AWS. You launch an instance. You attach your storage. You do your thing. You create your snapshots to back them up. And everybody's happy using the cloud at the end of the day. So as opposed to Amazon, now in our future release, I should say that our interface will actually work with Amazon as well. So it's going to be like a hybridization UI. You'll be able to select from a drop-down box, whether you'd like to spawn your instances in your local cloud, or if you'd like to spawn them in AWS. Unfortunately, right now, it doesn't work. So you have to use Amazon's interface, which is a little bit nicer anyway. Seven years had start, a few thousand more employees. But here's their interface for launching instances. We can click on instances and see that I should have one running here already. And I do, Debian 7 image running. And the only reason I wanted to highlight that is with Eucatools. I can very quickly switch. Oh, my instance got up. Losing my mind here. I can easily switch between my Amazon credentials and my Eucalyptus credentials. I can easily switch between the clouds and launch an instance in either or. So I'm going to show that now. So I'm going to source my Eucalyptus file. And I'm going to run an instance in Eucalyptus first. So I'm going to describe my images. And as you see here, here's that same precise image that we saw in the UI. And instead of the AMI nomenclature for AMI, we'll use AMI for Eucalyptus machine image. Otherwise, it's pretty much the same. This is the most common command anybody uses if they're using either of our clouds. You can run instances. You simply give it the ID and the key name you would like to use. And off she goes. If we'd like to then run one in AWS, we just source our AWS credentials. And I forget the AMI name, so let me look that up. I guess I'll have to go look it up with their lovely interface. So first you need the AMI ID, obviously, which I had one before. I don't know where it went. I tried using the one from your marketplace. And it gave me a URL to click on. And I accept it. And it still won't let me launch the darn thing. So it looks like it unfortunately. So let me go find another one here. Luckily, your search interface has improved immensely. It's much quicker. It used to take forever. So we'll use this guy, which is apparently a community provided, Debbie, in 7.1 Image. And just like we did before, simply specify the AMI name. And then we'll launch an image in AWS. So the benefit to this that probably isn't readily apparent from a simple demonstration like this is you can also pass both Amazon and Eucalyptus user data, which I believe you touched on yesterday, which is basically a script. You can pass it. So you can test your same workload. And you can live this locally and then deploy it later into Amazon, which is what most of our customers do. So instead of burning the bill that Amazon charges to test internally, people use Eucalyptus to do development testing. And then when they're ready, they provision it into the public cloud using the same set of tools and the same APIs. We also provide the same metadata service API within the instance. So if you need to query your IP or your instance ID, the same script can be used within Eucalyptus and Amazon. And that's really the selling point of Eucalyptus. Obviously, you've got OpenStack now, which is a massive force with HP and Rackspace behind them. But they've made it very clear that Amazon API support is not going to be part of their status quo. And with Google, I'm barely, I don't want to speak out of term, but I believe that's not really a focus of yours either. So basically, we wish to be in the niche of the private cloud provider for those who either use Amazon heavily now or wish to use Amazon in the future. So I wish I could have done a more Debian-centric thing for you, Dave. But unfortunately, my package has got removed yesterday. So it is what it is. One other thing I can show you is in Amazon, the way image management works, you can either upload your own image, I believe. But most people simply choose to use images that are already out there provided by Amazon. In our case, you don't have that because you've built your own cloud, right? So you need to get an image from somewhere. And that's where a utility we have called Ustore comes in. So let me switch back to Eucalyptus from Amazon here. And we provide as a very simple client called Ustore. And we provide a set of default images at emis.ucalyptus.com to where if you're just getting started with a cloud and you don't feel like building your own image yet or you don't even know how to build your own image yet. Let me grab a bit of it in here. You can just start with one of ours. So you do Ustore describe images to list them. And then Ustore install image, pass it the ID, the hypervisor type, which is usually KVM. We also support ZIN is not officially supported, but it works. And we officially support VMware as well. And then you specify where, which bucket, which is our object storage, where you'd like it to be stored in your cloud. We'll just store it in a bucket called Debian. And then automatically, as you can see, retrieve the image for you, unbundle it, upload it to your Eucalyptus cloud, and register it so that you can immediately launch it. So I'm obviously not going to make you wait 30 minutes to see it. But if you do, that's what happens. And obviously, you can host your own EMIs as well on your own EMI server. It's open source software. And that way, you don't have to retrieve them publicly from a slow connection. You can retrieve them internally from your own network. So that is Eucalyptus in a nutshell. And I'll open the floor for questions now if you have any. We have a mic anywhere. Any questions from anybody on Eucalyptus? Eucatools, anything? How it relates to AWS? That isn't, and am I right or wrong? The kernel there is 3.9 in 7.1. Correct. This is our own homegrown image, which goes back to that official question again. Yeah, yeah, exactly. You can see where I was going. What else goes into your images that are not in the standard Debian install? I believe we put SE Linux in this. I think App Armor that you can switch over to. I didn't make this particular one, but I think Cloudinit's in this one, and I believe that's it. OK. Clearly the same issues that you've been up into. We had a reason for the kernel. A client wanted it. But normally, we don't deviate even that much. It's usually just Cloudinit. We always add Cloudinit. Yeah. And oh, and SE Linux, because a lot of customers are requested to be able to lock down their instances. That's an interesting one. Correct, not in the base. Do you support ready days or do you get beyond days or from days? Just dev-ins, straight from dev-in. Like I said, the kernel is an abnormality. We wouldn't even usually do that. Most of the time, it's just stock installs with a default user like you did with Admin. We usually do very little to augment the, we don't want to. We just want to provide base images. And if you need to customize, do it on your own with Puffer or Shaffer, whatever. All right, any other questions? It looks like everybody's getting ready for food. So I'm not going to hold that against you. I appreciate you coming. Oh, we got one. Oh, is it that long? Oh, no. Now I'm upset. All right, guys, thanks for coming.