| SuperMarioRocks | why won't channel #ubuntu let me send messages | 00:09 |
|---|---|---|
| SuperMarioRocks | what is this room for | 00:14 |
| === msnsachin12 is now known as msnsachin | ||
| === medberry is now known as med_out | ||
| === hugo is now known as Guest44721 | ||
| === daker_ is now known as daker | ||
| StathisV | Hello! Three weeks before I was installed the Ati Radeon HD 6670 in my computer under Ubuntu 10.04. I had a lot of problems with ati drivers and usualy my system in booting, message me "checking battery state" and then died . The problems were solved when I made upgraded to 11.04 with "radeon" vga driver. But suddenly yesterday the same message had rise. What should I do to fix | 13:10 |
| StathisV | it? I was searching the internet, but nothing useful found. | 13:10 |
| head_victim | StathisV: this is not a general support channel, try #ubuntu | 13:10 |
| head_victim | !classroom | 13:10 |
| ubot2 | The Ubuntu Classroom is a project which aims to tutor users about Ubuntu, Kubuntu and Xubuntu through biweekly sessions in #ubuntu-classroom - For more information visit https://wiki.ubuntu.com/Classroom | 13:10 |
| StathisV | head_victim ok :) thnx :) | 13:12 |
| === AndroUser is now known as CloudAche84_droi | ||
| CloudAche84_droi | Test | 15:10 |
| sorrell | hi | 15:12 |
| === med_out is now known as medberry | ||
| * soren taps the microphone | 15:50 | |
| * soren taps the microphone | 15:50 | |
| soren | Hello, everyone. Thanks for stopping by. | 16:00 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Cloud Days - Current Session: Getting started with OpenStack Compute - Instructors: soren | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/26/%23ubuntu-classroom.html following the conclusion of the session. | 16:00 |
| soren | I should mention I'm currently at OSCON, on the conference wifi, so I *might* disappear. | 16:00 |
| soren | ...but so far the wifi has been ok, so here's hoping. | 16:00 |
| soren | Anyways. | 16:00 |
| soren | Usually, I start with a run-down of the history of OpenStack and such, but seeing as there's a more general OpenStack session at 1900 UTC, I'll skip that this time. | 16:01 |
| soren | Ok, so "Getting started with Openstack Compute". | 16:01 |
| soren | I'm probably going to call it "Nova" at times, but it's the same thing. | 16:01 |
| soren | usually, i start with a run-down of the history of OpenStack and such, but seeing as there's a more general OpenStack session at 1900 UTC, I'll skip that this time. | 16:02 |
| soren | (Also, my shift key seems to be acting up.) | 16:02 |
| soren | Hopefully at the end of this session, you'll have a basic understanding of the components involved in an OpenStack Compute cloud, have a cloud running on your laptop and you'll be able to start and stop instances. | 16:03 |
| soren | Simple stuff, since we only have an hour :) | 16:03 |
| soren | Let's start by downloading an image. It'll probably take a while, so we'll save a bunch of time later on if you start downloading it now. | 16:03 |
| soren | If you're running 64 bit Ubuntu, grab this: | 16:03 |
| soren | http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-amd64.tar.gz | 16:03 |
| soren | I.e. just fire up a terminal and run: | 16:04 |
| soren | wget http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-amd64.tar.gz | 16:04 |
| soren | If you're runing 32 bit ubuntu, grab this instead: | 16:04 |
| soren | http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-i386.tar.gz | 16:04 |
| soren | If you hit any problem along the way, let me know, maybe we can solve them straight away, or at least we can keep track of the problems so that we can find solutions later. | 16:04 |
| soren | So, I'll just assume you're all downloading this now and move on. | 16:05 |
| soren | OpenStack Compute consists of a number of "internal" and "external" components. | 16:05 |
| soren | "External" components (a term I just came up with, so you probably won't find it in any docs or anything) are things that aren't part of Nova itself, but we need anyway. For our needs today this is just rabbitmq. | 16:06 |
| soren | RabbitMQ is a message queueing system. It's a core component of a Nova deployment. | 16:06 |
| soren | It passes messages between the different components. | 16:06 |
| soren | It's the only control communication mehcnaism we have. | 16:07 |
| soren | mechanism, even. | 16:07 |
| soren | Nova itself has 5 components that we'll work with today. | 16:07 |
| soren | nova-api | 16:07 |
| soren | nova-compute | 16:07 |
| soren | nova-scheduler | 16:07 |
| soren | nova-network | 16:07 |
| soren | nova-objectstore | 16:07 |
| soren | nova-api is the fronten server. | 16:07 |
| soren | Whenever you -- as an enduser -- want to interact with Nova, this is the component you talk to. | 16:08 |
| soren | It exposes the native OpenStack API (which is derived from the Rackspace Cloud Servers API) as well as the EC2 aPI. | 16:08 |
| soren | Well, a subset of the EC2 API. | 16:08 |
| soren | It receives your request over HTTP, authenticates and validates the request. | 16:09 |
| soren | ...and turns it into a message and puts it on the message queue for someone else to consume. | 16:09 |
| soren | You can have any number of these servers. | 16:10 |
| soren | They all act the same: Verify the request and sends it on to some other component for processing. | 16:10 |
| === Hugo is now known as Guest95592 | ||
| soren | No failover or anything is involved, all components are "hot". | 16:10 |
| soren | nova-compute is the component that actually runs your virtual machines. | 16:11 |
| soren | It receives a request from the scheduler, which I apparently should have talked about first, but here we are :) | 16:12 |
| soren | Ok, so this request has information about which image to run, how much memory and disk and whatnot to assign to the virtual machine. | 16:12 |
| soren | nova-compute makes this happen by creating virtual disk images, shoving the AMI image into it, setting up networking and running the virtual machine. | 16:13 |
| soren | So, on the bulk of your servers in your cloud, this is the thing you run. | 16:14 |
| ClassBot | kim0 asked: Does rabbitmq choose a node to deliver the message to? if that node fails, does it reroute to some other node ? | 16:15 |
| soren | It depends on the type of message. | 16:15 |
| soren | Hm... Let me explain a bit more first, and get back to this. | 16:16 |
| soren | The scheduler. | 16:16 |
| soren | As you might have guessed, it schedules stuff. | 16:16 |
| soren | When you ask the API server to run a virtual machine it sends the request to one of the schedulers. | 16:16 |
| soren | The scheduler is (meant to be) smart. | 16:17 |
| soren | It makes the decision about which compute node is meant to run the virtual machine. | 16:17 |
| soren | When it has decided, it sends the message on to the chose compute node. | 16:18 |
| soren | Ok, so rabbit. | 16:18 |
| soren | The API server sort of broadcasts the request to all the schedulers. | 16:18 |
| soren | Here, rabbitmq makes the decision about which scheduler gets the request. | 16:18 |
| soren | ...and applies its usual logic about sending the request somewhere else if it doesn't get acked. | 16:18 |
| soren | for the scheduler->compute message, it's different, of course. | 16:19 |
| soren | ...since it's being sent directly to a specific node. | 16:19 |
| soren | I'm not sure what the failure modes are there. | 16:19 |
| soren | The scheulder doesn't just schedule VM's, though. | 16:20 |
| soren | It's supposed to make decisions about which storage node is supposed to host your EBS-like volumes and so on. | 16:20 |
| soren | nova-network is... the network component. | 16:20 |
| soren | (surprise) | 16:20 |
| soren | It hands out IP addressses and in certain network modes it acts as the gateway. | 16:21 |
| soren | It also does NAT'ing for elastic IP's and a few other things. | 16:21 |
| soren | It doesn't do firewalling. The compute nodes do that (in order to decentralise the firewall and spread the filtering load). | 16:21 |
| soren | Finally, there's the nova-objecstore. | 16:22 |
| soren | It's a simple ple implementation of the S3 API. | 16:22 |
| soren | You can use OpenStack without using it, but in Ubuntu we still use it because that's how EC2 and Eucalyptus work, so we can reuse a bunch of documentation an tools and whatnot this way. | 16:23 |
| ClassBot | kim0 asked: Is there any way to specify locality, like launch this VM besides that VM as close as possible to that EBS volume ? | 16:24 |
| === Wilczek is now known as multivitamin | ||
| soren | I'm not completely sure. | 16:24 |
| soren | There's certainly been talk about supporting it, but I don't remember seeing code to do it. | 16:25 |
| soren | That said, I've been on holiday and at conferences for a while, so maybe it landed recently. | 16:25 |
| soren | It's definitely on the roadmap. | 16:25 |
| ClassBot | kim0 asked: Why does nova-objecstore exist? Why not just swift or mini-swift ? | 16:25 |
| soren | If I didn't answer this already, can you rephrase this? | 16:26 |
| ClassBot | kim0 asked: Has openstack dropped the centralized DBs ? wasn't mysql used before? | 16:26 |
| soren | We have not. | 16:26 |
| soren | Yet. | 16:26 |
| === bambee_ is now known as bambee | ||
| soren | So, if you're setting up a multi-machine cloud, you'll need a shared database. E.g. MySQL, PostgreSQL or whatever floats your boat. | 16:27 |
| soren | Whatever sqlalchemy supports should be fine. | 16:27 |
| soren | "should" being the operative word. | 16:27 |
| soren | Data access works fine for all the different backends, but schema changes have only been tested with mysql, postgresql and sqlite. | 16:28 |
| soren | This is a common theme, by th e way. | 16:28 |
| soren | We can use a bunch of different DB backends. | 16:28 |
| soren | We can also use a bunch of different hypervisors (kvm, Xen, LXC, UML, Xen Server, VMWare, Hyper-V). | 16:29 |
| soren | Different storage backends (HP SANs, iSCSI, AOE) | 16:29 |
| soren | Adding more drivers is meant to be reasonable easy, so if you want to use something else, that should be possible. | 16:30 |
| soren | Let us know if that's the case. | 16:30 |
| ClassBot | kim0 asked: Is there code to accelerate certain operations via SAN (like clone volume, snapshotting ..etc) | 16:30 |
| === multivitamin is now known as Wilczek | ||
| soren | I forget which operations are exposed in abstraciton layer, to be honest. I do believe the backend call to create a snapshot is just "create a snapshot", so if a particular backend has nifty shortcuts to do that, it should totally be possible. | 16:31 |
| soren | Whether the drivers actually *do*... I don't know. | 16:31 |
| soren | Alright then. | 16:32 |
| soren | 16:32 < Guest95592> QUESTION : is there any docs talk about openstack with Hyper-V ? Or real use case ? | 16:32 |
| soren | I'm not actually sure of the state of the Hyper-V support. We don't really have the means to test it. | 16:33 |
| soren | Guest95592: I'll make a note to dig up the docs and send it to you. I'm not sure where they are. | 16:34 |
| soren | Ok, so let's get practical. | 16:34 |
| soren | I assume you've all downloaded the image. | 16:34 |
| soren | For those who just joined: | 16:34 |
| soren | 16:03 <+soren> Let's start by downloading an image. It'll probably take a while, so we'll save a bunch of time later on if you start downloading it now. | 16:35 |
| soren | 16:03 <+soren> If you're running 64 bit Ubuntu, grab this: | 16:35 |
| soren | 16:03 <+soren> http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-amd64.tar.gz | 16:35 |
| soren | 16:04 <+soren> I.e. just fire up a terminal and run: | 16:35 |
| soren | 16:04 <+soren> wget http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-amd64.tar.gz | 16:35 |
| soren | 16:04 <+soren> If you're runing 32 bit ubuntu, grab this instead: | 16:35 |
| soren | 16:04 <+soren> http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-i386.tar.gz | 16:35 |
| soren | I'm assuming you're running Natty. | 16:35 |
| soren | Is anyone not running Natty? | 16:35 |
| ClassBot | kim0 asked: Would you explain how a large scale (1000?) server deployment may look like. Guidelines would be great. Is it also an inverted tree of a bunch of clusters like eucalyptus? | 16:35 |
| soren | kim0: A lot of it will be dictated by the network structure you want. | 16:36 |
| soren | Hmm.. | 16:37 |
| soren | This is a good question, really. I just write the software, I don't actually run it at scale. | 16:37 |
| soren | It's not a strict hierarchy. | 16:37 |
| soren | At all. | 16:37 |
| soren | You have the message queue, which everything shares. | 16:38 |
| soren | ...the database that everything shares. | 16:38 |
| soren | "a number" of API servers. :) | 16:38 |
| soren | I don't really know how many I'd set up. | 16:38 |
| soren | Ideally, they'd run as instances on your cloud so that you could scale them as appropriate. | 16:38 |
| soren | I'd be surprised if one or two of them wouldn't be sufficient, but if you find out that you need a bunch of them, just add more and point them at the same message queue and db and you should be golden. | 16:39 |
| soren | Number of storage servers depends on how much storage you want to expose, really. | 16:40 |
| soren | ...and how much you expect your users to use them. | 16:40 |
| soren | Nova doesn't really add any overhead there. | 16:40 |
| soren | If you expect to have a lot of I/O-intensive stuff going on on your cloud, you'd probably have a lot of servers with a lot of bandwidth. | 16:40 |
| soren | If you don't expect a lot of I/O-intensive stuff you might just spring for fewer servers with more disks in each. | 16:41 |
| soren | I don't think there really are any good, general answers. | 16:41 |
| soren | The architecture is really flexible, though, so if you discover that you need more store or bandwidth, you just add more. | 16:41 |
| soren | Since the architecture is so flat. | 16:42 |
| soren | Ok, so back to our demo. | 16:42 |
| soren | Everyone runs natty. Great. | 16:42 |
| soren | First: | 16:42 |
| soren | sudo apt-get install rabbitmq-server unzip cloud-utils | 16:42 |
| soren | This install rabbitmq and a few utilities that we'll need in a few minutes. | 16:43 |
| soren | When that is done, do this: | 16:43 |
| soren | sudo apt-get install nova-api nova-compute nova-scheduler nova-network nova-objectstore | 16:43 |
| soren | I'm not compltely sure this still needs to be two separate steps, but just to be safe, we do it this way. | 16:43 |
| soren | Ok, so next up, we create a user. | 16:43 |
| soren | If your name is not "soren" you can specify something else where it says "soren" :) | 16:44 |
| soren | sudo nova-manage user admin soren | 16:44 |
| soren | This creates an admin user called "soren" | 16:44 |
| soren | sudo nova-manage project create soren soren | 16:44 |
| soren | This creates a "project" called "soren" with the user "soren" as the admin. | 16:44 |
| soren | Next, we need to create a network. | 16:45 |
| soren | If you can't use 10.0.0.0/8 (beacuse you already use it), make something else up. | 16:45 |
| soren | sudo nova-manage network create 10.0.0.0/8 2 24 | 16:45 |
| soren | This creates two networks of 24 IP's each in the 10.0.0.0/8 subnet. | 16:45 |
| soren | sudo nova-manage project zipfile soren soren | 16:46 |
| soren | This fetches a zipfile with from credentials in it for the user soren for the project soren. | 16:46 |
| soren | Unpack it: | 16:46 |
| soren | unzip nova.zip | 16:46 |
| soren | Source the novarc file: | 16:46 |
| soren | . novarc | 16:46 |
| soren | Now we upload the image we downloaded earlier. | 16:46 |
| soren | uec-publish-tarball ubuntu-11.04-server-uec-amd64.tar.gz ubuntu | 16:47 |
| soren | ubuntu-11.04-server-uec-amd64.tar.gz is the filename, "ubuntu" is the name of the S3 bucket you want to use. | 16:47 |
| soren | Next, we create a key: | 16:47 |
| soren | euca-add-keypair mykey > mykey.priv | 16:47 |
| soren | chmod 600 mykey.priv | 16:48 |
| soren | uec-publish-tarball may take a while. | 16:48 |
| soren | The last thing it outputs might look like: | 16:48 |
| soren | emi="ami-3a0c3765"; eri="none"; eki="aki-279dfe6a"; | 16:49 |
| soren | We need the first ID there (ami-3a0c3765). | 16:49 |
| soren | Your id will be different. | 16:49 |
| soren | Well, probably. | 16:49 |
| soren | there's a 1 in 2^32 chance it'll be the same :) | 16:49 |
| soren | Ok, next: | 16:50 |
| soren | echo '#!/bin/sh' >> myuserdata | 16:50 |
| ClassBot | There are 10 minutes remaining in the current session. | 16:50 |
| soren | echo "wget http://f.linux2go.dk:8080/$HOSTNAME/" >> myuserdata | 16:50 |
| soren | And finally: | 16:50 |
| soren | euca-run-instances -k mykey -t m1.tiny -f myuserdata "the ami ID we found a bit further up" | 16:50 |
| soren | If this works, we'll be able to see your hostname on http://f.linux2go.dk:8080/ | 16:51 |
| soren | ...and you'll also be able to ssh into the instance. | 16:51 |
| soren | Is this working for everyone? | 16:52 |
| ClassBot | There are 5 minutes remaining in the current session. | 16:55 |
| soren | I don't really anything more, I didn't know how long this demo thing would take. | 16:55 |
| soren | Alright, thanks everyone for stopping by. | 16:57 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Cloud Days - Current Session: UEC on Ubuntu 10.04 LTS - Instructors: TeTeT | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/26/%23ubuntu-classroom.html following the conclusion of the session. | 17:00 |
| TeTeT | hello there, glad to have you aboard for a session on UEC on Ubuntu 10.04 LTS | 17:00 |
| TeTeT | thanks to soren for providing us with info on openstack, a very interesting and recent development in cloud space | 17:01 |
| TeTeT | in the next hour I will write about UEC, Ubuntu Enterprise Cloud, as we find it in Ubuntu 10.04 LTS | 17:01 |
| TeTeT | most of you will already know that the LTS (Long Term Support) releases are quite important to the Ubuntu universe | 17:01 |
| TeTeT | with 5 years of support for servers, it is a good choice for deploying it in any datacenter | 17:02 |
| TeTeT | drawback is of course, that you don't get the latest and greatest software on it, you pretty much have to live with what was there in April 2010 for Ubuntu 10.04 LTS | 17:03 |
| TeTeT | so with regards to UEC, we find that the base is eucalyptus 1.6.2 | 17:03 |
| TeTeT | some of you might have attended nurmi's talk yesterday on euca 3 | 17:03 |
| TeTeT | there's of course quite a lot of features missing in 1.6.2, but if you are in an LTS environment, or plan to set one up, you still can get started with UEC | 17:04 |
| TeTeT | so the most useful document for getting started with it, is on the wiki: | 17:04 |
| TeTeT | https://help.ubuntu.com/community/UEC | 17:05 |
| TeTeT | it contains various info that to the best of my knowledge mostly still applies to 10.04 LTS | 17:05 |
| TeTeT | however, due to some problems with service discovery, one might need to manually set up a cloud when doing a packaged install | 17:06 |
| TeTeT | I've detailed the needed steps here, as I need them often when teaching the UEC class: | 17:06 |
| TeTeT | http://people.canonical.com/~tspindler/UEC-Jan/02-cloudPackagedInstall | 17:07 |
| TeTeT | typically it takes 10-20 minutes to set up a two node cloud with UEC | 17:07 |
| TeTeT | one node acting as the front-end, the other as the node controller | 17:08 |
| TeTeT | while this is hardly sufficient for any serious deployment, it's good to get started and you can add more node controllers later on | 17:08 |
| TeTeT | once the cloud is up and running, you need to either download credentials for accessing i from the web ui or via the euca_conf command on the front-endt | 17:09 |
| TeTeT | I prefer the later, so a $ sudo euca_conf --get-credentials admin.zip | 17:09 |
| TeTeT | will store the credentials for the admin user in the admin.zip file | 17:09 |
| TeTeT | next I save these credentials on a client system into ~/.euca-admin/ | 17:10 |
| TeTeT | note that the wiki recommends saving it in ~/.euca, but if you have multiple users on one client system in one account, it's better to have several directories | 17:10 |
| TeTeT | e.g. I then usually create a user 'spindler' that has non-admin privileges and store the credentials in ~/.euca-spindler | 17:11 |
| TeTeT | I think using multiple users for multi-tenancy in the cloud is a very nice feature, so I like to use it | 17:11 |
| TeTeT | once the credentials are available, I source the accompanying 'eucarc' file and we're ready to go | 17:12 |
| TeTeT | with euca-describe-availability-zones verbose I do a quick check if the cloud is operational | 17:12 |
| TeTeT | euca-describe-availability-zones verbose | 17:12 |
| TeTeT | AVAILABILITYZONEtorstenCluster172.24.55.253 | 17:12 |
| TeTeT | AVAILABILITYZONE|- vm typesfree / max cpu ram disk | 17:12 |
| TeTeT | AVAILABILITYZONE|- m1.small0023 / 0024 1 192 2 | 17:12 |
| TeTeT | AVAILABILITYZONE|- c1.medium0022 / 0022 1 256 5 | 17:12 |
| TeTeT | AVAILABILITYZONE|- m1.large0011 / 0011 2 512 10 | 17:12 |
| TeTeT | AVAILABILITYZONE|- m1.xlarge0005 / 0005 2 1024 20 | 17:12 |
| TeTeT | AVAILABILITYZONE|- c1.xlarge0002 / 0002 4 2048 20 | 17:12 |
| TeTeT | hope I don't get kicked for flooding | 17:12 |
| TeTeT | so here you see a basic UEC in operation. The name of the cluster is 'torstenCluster', you see the private IP of the cluster controller | 17:13 |
| TeTeT | the lines below the first show how many instances of each instance type you can run | 17:13 |
| TeTeT | the instance types will look familiar to those having AWS background | 17:13 |
| TeTeT | basically the command tells me that there's a cluster controller operational and a node controller has been found as well | 17:14 |
| TeTeT | at least one node controller | 17:14 |
| TeTeT | if you only see 0 for free and max, registering the node controller didn't work and you probably need to repeat that step | 17:14 |
| TeTeT | in theory a new node controller in the same subnet as my cluser controller would get picked up automatically | 17:15 |
| TeTeT | in practice it always worked for me, but I've read in bug reports that at times it didn't for other users | 17:15 |
| TeTeT | talking about the auto registration - there is one caveat | 17:16 |
| TeTeT | don't setup more than one UEC cloud in the same LAN | 17:16 |
| TeTeT | otherwise the auto registration will bring strange fruits | 17:16 |
| TeTeT | you can always turn off the auto registration agents in their upstart / init jobs, though, in case you need to | 17:17 |
| TeTeT | e.g. you want to setup a classroom with multiple clouds and one LAN | 17:17 |
| TeTeT | back to our cloud, the next thing to do is getting an image and uploading it to the cloud | 17:17 |
| TeTeT | the easiest way to do so is using the web interface | 17:17 |
| TeTeT | however, almost as easy is downloading a tarball from uec-images.ubuntu.com and provisioning that | 17:18 |
| TeTeT | thanks to the developers there are scripts that make this really easy | 17:18 |
| TeTeT | uec-publish-tarball is the one for publishing a tarball from uec-images in the cloud | 17:18 |
| TeTeT | once this is done, the image resides in /var/lib/eucalyptus/bukkits/<bucket name>/ on the front-end | 17:19 |
| TeTeT | cloud tech speaking we have stored a machine image in a bucket on S3 | 17:19 |
| TeTeT | we need to store it in a way the node controller can later download and execute the image file | 17:20 |
| TeTeT | and S3 is one such storage method in UEC | 17:20 |
| TeTeT | next step is to create a ssh keypair usually | 17:20 |
| TeTeT | this can be done with euca-add-keypair <keyname> | 17:21 |
| TeTeT | best is to first check with euca-describe-keypairs which ones already exist | 17:21 |
| TeTeT | while the command nowadays blocks creation of another key with the same name as an existing one, this was not always the case in the past ... | 17:22 |
| TeTeT | once we have an image and a keypair, we can start an instance | 17:23 |
| TeTeT | when doing all of this on the command line, rather than using hybridfox or landscape or any other mgmt tool | 17:23 |
| TeTeT | I find it useful to save the identifiers in variables | 17:23 |
| TeTeT | for example | 17:23 |
| TeTeT | IMAGEemi-ACC617F6maverick-2011-01-26/maverick-server-uec-amd64.img.manifest.xmladminavailablepublicx86_64machineeki-14A41D03 | 17:24 |
| TeTeT | this is a maverick server image for 64bit from back in January | 17:24 |
| TeTeT | I store the emi identifier in a variable emi | 17:24 |
| TeTeT | emi=emi-ACC617F6 | 17:24 |
| TeTeT | so when I want to run an instance of that type, I state | 17:25 |
| TeTeT | euca-run-instances $emi -k <key name> -t <instance type> | 17:25 |
| TeTeT | I usually neglect the instance type and make do with m1.small, but at times bigger instances are worth it | 17:25 |
| TeTeT | the euca-run-instances command returns another identifier, this time for the instance | 17:26 |
| TeTeT | I save that in the variable 'inst' or 'server-<name>' or whatever else I like | 17:26 |
| TeTeT | so I can quickly check the status of the instance with $ euca-describe-instances $inst | 17:26 |
| TeTeT | if you're out on your own with a single user and a small cloud, it might not make much sense for restricting the output of euca-describe-instances | 17:27 |
| TeTeT | but if you have a class full of people, everybody starting and stopping instances, it is useful to only see info on the wanted instance | 17:27 |
| TeTeT | once the instance is in state running, one can ssh to it | 17:28 |
| TeTeT | ssh -i <identity file> ubuntu@<public or private ip> | 17:28 |
| TeTeT | the -i option we need to use the right private key file, the one that was returned by euca-add-keypair earlier | 17:28 |
| TeTeT | if we need the public or private ip depends on where our client sits | 17:29 |
| TeTeT | if we use the front-end as client, which a lot of people will initially do, the private ip is as good as any | 17:29 |
| TeTeT | if the client is on your laptop or any other system not hooked up to the clouds infrastructure, you need to use the public ip | 17:30 |
| TeTeT | when you have done all the work needed by the instance, you can terminate it with 'euca-terminate-instances' | 17:30 |
| TeTeT | so that covered the basic operation of a UEC cloud | 17:31 |
| TeTeT | first install the systems, either by CD or by package | 17:31 |
| TeTeT | second get the credentials | 17:31 |
| TeTeT | third check if the cloud is operational | 17:31 |
| TeTeT | next make an image available | 17:31 |
| TeTeT | start an instance of that image | 17:32 |
| TeTeT | test via ssh or whatever other service the instance may provide | 17:32 |
| TeTeT | but you don't need to stop there, there's plenty to still explore | 17:32 |
| TeTeT | like attaching persistent storage devices to the instance | 17:32 |
| TeTeT | allocating public ip addresses to the instance | 17:32 |
| TeTeT | before we cover the persistent storage, let's see why we have the need for that | 17:33 |
| TeTeT | what happens when an instance is started? | 17:33 |
| TeTeT | a node controller sooner or later gets tasked by a cluster controller to run an instance | 17:34 |
| TeTeT | that instance is of a specific emi, eucalyptus machine image | 17:34 |
| TeTeT | the node controller checks a local cache if the emi is there, and if not, the emi is transferred to the node controller via S3 | 17:34 |
| TeTeT | the node controller then copies the image to an instance directory | 17:35 |
| TeTeT | inside the instance directory the image is configured according to the start parameters of euca-run-instances | 17:35 |
| TeTeT | e.g. an ssh key is injected | 17:35 |
| TeTeT | e.g. a cloud init file is added to the boot sequence of the instance | 17:35 |
| TeTeT | some more magic happens and the once xen like image is now a kvm image | 17:36 |
| TeTeT | and kvm is used to boot the instance | 17:36 |
| TeTeT | so in a way eucalyptus and UEC is like kvm on steroids | 17:36 |
| TeTeT | when you want to get rid of an instance, you stop it with euca-terminate-instances | 17:37 |
| TeTeT | and what happens on the node controller is that the kvm process stops _and_ the runtime directory containing the image is deleted | 17:37 |
| TeTeT | this means that any state in the instance is gone forever | 17:37 |
| TeTeT | of course most services require to save some state somewhere. This could be an external database server, or a file server. | 17:38 |
| TeTeT | or, as we look at now, EBS, the elastic block storage service | 17:38 |
| TeTeT | in EBS a device appears on an instance that is mapped to a file on a storage server, the EBS server | 17:39 |
| TeTeT | there are two methods by which EBS is transported, ata over ethernt (AoE) or iscsi. In Ubuntu 10.04 LTS we only have AoE | 17:39 |
| TeTeT | this implies a restriction when using 10.04 LTS, as the EBS server has to reside on the same LAN as the node controllers it serves | 17:40 |
| TeTeT | as AoE does not route | 17:40 |
| TeTeT | with euca-create-volume we can create a new volume for storage on the EBS storage server | 17:41 |
| TeTeT | once this has finished, it can be assigned to an instance with euca-attach-volume | 17:41 |
| TeTeT | euca-attach-volume <vol id> -i $inst | 17:41 |
| TeTeT | oops, there's -d <device> missing | 17:42 |
| TeTeT | device would be sdb or sdc or anything | 17:42 |
| TeTeT | but to my finding the instance will just pick the next device name anyhow | 17:42 |
| TeTeT | with the device attached to the instance, one can create a partition table, filesystem and whatever on the device | 17:43 |
| TeTeT | just as with a regular device | 17:43 |
| TeTeT | the nice thing is, that you can snapshot these devices | 17:44 |
| TeTeT | e.g. you attach the device to an instance, put the needed data there, detach it and snapshot it | 17:44 |
| TeTeT | based on that snapshot you can create new volumes that are clones of the snapshot | 17:45 |
| TeTeT | might be nice if you have read only data that you need on all instances of your application | 17:45 |
| TeTeT | that's it pretty much for EBS | 17:46 |
| TeTeT | lastly I want to cover elastic IPs | 17:46 |
| TeTeT | with help of euca-describe-addresses you see which IPs are public in your UEC | 17:46 |
| TeTeT | you can either randomly get one or pick one with euca-allocate-address | 17:46 |
| TeTeT | then this ip can be assigned to a specific instance with euca-associate-address | 17:47 |
| TeTeT | in this way you can make sure that a certain service is always reachable by the same IP, minus the time it takes to do the associate dance | 17:47 |
| TeTeT | well, that was all I wanted to cover. Thanks for following. If you have any questions, either use the classbot or you can reach me as TeTeT on #ubuntu-cloud usually | 17:48 |
| ClassBot | There are 10 minutes remaining in the current session. | 17:50 |
| ClassBot | There are 5 minutes remaining in the current session. | 17:55 |
| m_3 | can I type in here yet? | 17:59 |
| nigelb | yes :) | 17:59 |
| m_3 | ok, I'll go ahead and get started | 17:59 |
| m_3 | Hi, I'm Mark M Mims (hence the m_3) | 18:00 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Cloud Days - Current Session: Node.js/Mongo with Ensemble - Instructors: m_3 | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/26/%23ubuntu-classroom.html following the conclusion of the session. | 18:00 |
| m_3 | On the Ensemble team working to build out the base set of formulas we have to work with in ensemble | 18:00 |
| m_3 | I'd like to go into a little detail today about the different kinds of formulas ensemble can work with | 18:01 |
| m_3 | at this point I hope that you've seen the earlier presentation on 'getting started with ensemble' | 18:01 |
| m_3 | I'll be demoing stuff in byobu-classroom, where you can watch along | 18:02 |
| m_3 | you can either open http://ec2-67-202-23-199.compute-1.amazonaws.com/ up in a browser | 18:02 |
| m_3 | or ssh there directly as "guest" with password "guest" | 18:02 |
| m_3 | So, how do you use ensemble to deploy a node.js app? | 18:03 |
| m_3 | the short version (we'll go repeat in more detail) | 18:03 |
| m_3 | is: | 18:03 |
| m_3 | $ ensemble bootstrap | 18:04 |
| m_3 | $ ensemble deploy --repository .. mynodeapp | 18:04 |
| m_3 | ensemble deploy --repository .. mongodb | 18:04 |
| m_3 | ensemble deploy --repository .. haproxy | 18:04 |
| m_3 | to deploy all the services as we expect | 18:04 |
| === basso_ is now known as basso | ||
| m_3 | here, we have a simple (exposed) mongodb service | 18:05 |
| m_3 | a node.js app that sits above the mongodb | 18:05 |
| m_3 | and haproxy that faces the outside world | 18:06 |
| m_3 | we deploy the services, then relate them: | 18:06 |
| m_3 | ensemble add-relation mongodb mynodeapp | 18:06 |
| m_3 | ensemble add-relation mynodeapp haproxy | 18:06 |
| m_3 | then wait for the relation hooks to complete | 18:06 |
| m_3 | the outcome of that is shown in ssh | 18:07 |
| m_3 | The point of this talk is that there are two different kinds of services involved here: | 18:08 |
| m_3 | 1.) "canned" services... like haproxy and mongodb | 18:08 |
| m_3 | these are services you typically just configure and use | 18:09 |
| m_3 | they're tailored to your infrastructure through configuration parameters | 18:09 |
| m_3 | 2.) what I like to call "framework" formulas | 18:09 |
| m_3 | these are formulas for services that you write | 18:10 |
| m_3 | i.e., mynodeapp is an application that I keep under my own revision control system | 18:10 |
| m_3 | a framework formula is a formula that helps you deploy such a service alongside other canned services | 18:11 |
| m_3 | let's look at an example | 18:11 |
| m_3 | mynodeapp is a _super_ simplistic node.js app | 18:12 |
| m_3 | there's a basic http server listening on 0.0.0.0/8000 | 18:12 |
| m_3 | that tracks hits to the page | 18:13 |
| m_3 | and sticks them in a mongo database | 18:13 |
| m_3 | easy peasy | 18:13 |
| m_3 | it reads some information from a config file... | 18:13 |
| m_3 | that's just simple json | 18:14 |
| m_3 | I've written a basic ensemble formula to wrap the installation and deployment of that node.js application | 18:15 |
| m_3 | the metadata.yaml shows where it fits within my overall infrastructure | 18:15 |
| m_3 | this consumes a db, and provides a http interface | 18:15 |
| m_3 | I can of course attach monitoring services, remote logging services, etc | 18:16 |
| m_3 | there's a little cruft in here about formula config | 18:16 |
| m_3 | that's a new feature that recently landed | 18:17 |
| m_3 | so all of that should be replaced with 'config-get <param>' | 18:17 |
| m_3 | the installation of node itself and npm are pretty straightforward | 18:17 |
| m_3 | try to use packages when you can | 18:17 |
| m_3 | when you're on HEAD or living closer to the edge, you can pull and install from source if you want | 18:18 |
| m_3 | that's worth mentioning again... | 18:18 |
| m_3 | packages are great for stability | 18:18 |
| m_3 | and often what the ops guys want | 18:18 |
| m_3 | developers want the bleeding edge all the time | 18:19 |
| m_3 | ensemble formulas support either | 18:19 |
| m_3 | so it becomes a policy decision within your group | 18:19 |
| m_3 | but anyway... I'm pulling my node.js from github | 18:19 |
| m_3 | you can use any number of other options | 18:20 |
| m_3 | the key is to install the packages first for the VCS you use | 18:20 |
| m_3 | note there's a need for some idempotency guards | 18:21 |
| m_3 | this is most important for long lifecycle services | 18:21 |
| m_3 | let me pause for a sec for questions... | 18:22 |
| m_3 | ok, so to summarize the first part of what we're looking at... | 18:22 |
| m_3 | this is a formula to deploy my node.js app right alongside all the 'canned' service formulas | 18:23 |
| m_3 | this is the 'install' hook that gets called upon service unit deployment | 18:23 |
| m_3 | this install hook: | 18:23 |
| m_3 | loads some configuration | 18:24 |
| m_3 | then goes about installing | 18:24 |
| m_3 | node | 18:24 |
| m_3 | npm | 18:24 |
| m_3 | and then my application (pulled from github) | 18:24 |
| m_3 | and then delays any further startup/config until we have the right parameters to fill in from the mongodb server | 18:25 |
| m_3 | s/server/service/ | 18:25 |
| m_3 | so that's simple enough | 18:25 |
| m_3 | now, the real magic of ensemble | 18:25 |
| m_3 | are relations | 18:26 |
| m_3 | this sets ensemble apart | 18:26 |
| m_3 | the lines of demarcation between what's specific to a service | 18:26 |
| m_3 | and what's really specific to the relations between the services | 18:27 |
| m_3 | here, we see the mongodb-relation-changed hook | 18:27 |
| m_3 | this isn't called until the mongodb service is related to our mynodeapp service | 18:28 |
| m_3 | start at the bottom... | 18:28 |
| m_3 | note that we don't actually start the "mynodeapp" service | 18:28 |
| m_3 | until we've set the relation parameters | 18:28 |
| m_3 | this makes sense | 18:28 |
| m_3 | if we look at the config.js again for the app | 18:28 |
| m_3 | the default paramters the node.js app is using expect mongodb to be local | 18:29 |
| m_3 | ok, if you noticed during the install hook, I _do_ have it installed locally | 18:29 |
| m_3 | but that was just for testing | 18:29 |
| m_3 | in general, the mongodb service is external | 18:30 |
| m_3 | so the node.js app would barf if we started it with this inf | 18:30 |
| m_3 | info | 18:30 |
| m_3 | so, the code before starting the service is just to get the right connection information from the db | 18:30 |
| m_3 | when a relation is created | 18:31 |
| m_3 | ensemble opens a two-way comms channel between the services through the use of 'relation-get' 'relation-set' | 18:31 |
| m_3 | the particular mongodb service we're using is pretty simplistic | 18:31 |
| m_3 | let's look at the other end of this relation | 18:32 |
| m_3 | that's it! | 18:32 |
| m_3 | when a service connects to the mongodb service, mongodb just sends it's connection point | 18:33 |
| m_3 | a more mature version of this would have access control, ports specified, etc | 18:33 |
| m_3 | but that's enough info for a first pass at understanding ensemble relations | 18:34 |
| m_3 | the mynodeapp service just grabs the relation information (here just the host) | 18:34 |
| m_3 | and crams it in the config file | 18:35 |
| m_3 | we can go out to the live service and see what the config file looks like | 18:35 |
| m_3 | first notice the relation status between the mongodb and the mynodeapp services | 18:36 |
| m_3 | I can ssh directly to one unit | 18:36 |
| m_3 | and see that the relation hook filled in the ec2 internal address for the mongodb service | 18:37 |
| m_3 | and the port's just default | 18:37 |
| m_3 | cool... questions so far? | 18:37 |
| m_3 | ha, ok... I continue | 18:38 |
| m_3 | next, let's look at what happens when we fire up additional units | 18:38 |
| m_3 | ec2's been quite slow today, so we'll wait a bit | 18:39 |
| m_3 | notice as this comes up that the services 'mynodeapp' and 'mongodb' are already related | 18:40 |
| m_3 | all we did with ensemble add-unit was to add an additional service unit for the mynodeapp service | 18:40 |
| m_3 | (horiz scaling) | 18:40 |
| m_3 | so ensemble spins up a new instance | 18:41 |
| m_3 | runs the install hook we saw before | 18:41 |
| m_3 | let's look again for a sec... | 18:41 |
| m_3 | notice there's nothing in here that would depend on another service unit | 18:41 |
| m_3 | we piulled some config from the formula | 18:42 |
| m_3 | we installed stuff that's going to be in common with all instances of our node.js app | 18:42 |
| m_3 | the relation is the only real information that the node.js app "nodes" or units would share | 18:43 |
| m_3 | ensemble just calls the relation hooks after installing the new service unit | 18:43 |
| m_3 | so then this new service unit should get the same relation-specific configuration that the first one had | 18:44 |
| m_3 | (and cram it in config.js for the app) | 18:44 |
| m_3 | ugh... I thought for sure I rambled enough for ec2 to catch up | 18:45 |
| m_3 | well anyway, while we're waiting, we can test a couple of things | 18:45 |
| m_3 | note that you can hit the first mynodeapp service unit | 18:46 |
| m_3 | "mynodeapp/0" | 18:46 |
| m_3 | on machine 2 | 18:46 |
| m_3 | or ec2-72-44-35-213.compute-1.amazonaws.com | 18:46 |
| m_3 | and see the node.js app in action | 18:46 |
| m_3 | (remember we're on port 8000) | 18:46 |
| m_3 | you can try http://ec2-72-44-35-213.compute-1.amazonaws.com:8000/ | 18:47 |
| m_3 | as well as http://ec2-72-44-35-213.compute-1.amazonaws.com:8000/hits | 18:47 |
| m_3 | should give us some additional traffic in the db | 18:47 |
| m_3 | this is open in this case | 18:48 |
| m_3 | it wouldn't be in real life | 18:48 |
| m_3 | ensemble has features to control ec2 security groups | 18:48 |
| m_3 | so we'd have this webservice exposed on port 8000 only on the internal ec2 interface | 18:48 |
| m_3 | you'd have to go through haproxy for public access | 18:49 |
| m_3 | hey, ok, our new mynodeapp service unit is up | 18:49 |
| m_3 | mynodeapp/1 on machine 4 | 18:49 |
| m_3 | note that you can hit that one independently too | 18:49 |
| m_3 | http://ec2-184-72-92-144.compute-1.amazonaws.com:8000/ | 18:50 |
| ClassBot | There are 10 minutes remaining in the current session. | 18:50 |
| m_3 | SpamapS: asks "how do we get to the port if I haven't exposed that port" | 18:50 |
| m_3 | answer is it's all open at the moment for the class | 18:50 |
| m_3 | ok, so let's check out the config file in the new node and make sure that the relation added the right info | 18:51 |
| m_3 | boom | 18:51 |
| m_3 | so when we hit either node, they're writing the hits into the common external mongodb datastore | 18:52 |
| m_3 | sorry, I keep using bash aliases... | 18:52 |
| m_3 | es='ensemble status' | 18:52 |
| m_3 | ok, so what's missing here? | 18:52 |
| m_3 | notice that we have a haproxy service up | 18:53 |
| m_3 | but no relations | 18:53 |
| m_3 | this will call hooks to relate the webservice http interface provided by each mynodeapp to the haproxy balancer | 18:54 |
| m_3 | really it just tells haproxy its hostname and port (8000 here) | 18:54 |
| m_3 | the haproxy service is written so that when a webservice joins, it adds it to the roundrobin queue | 18:55 |
| ClassBot | There are 5 minutes remaining in the current session. | 18:55 |
| m_3 | ok, almost done | 18:55 |
| m_3 | now, we can hit ec2-174-129-107-151.compute-1.amazonaws.com on port 80 | 18:55 |
| m_3 | and it's balancing between the node.js nodes | 18:56 |
| m_3 | our nodes | 18:56 |
| m_3 | ok, so to wrap up | 18:56 |
| m_3 | two types of formulas | 18:56 |
| m_3 | 1. canned formulas | 18:56 |
| m_3 | 2. "framework" formulas | 18:56 |
| m_3 | mongodb and haproxy are examples of canned ones | 18:57 |
| m_3 | mynodeapp is a framework one | 18:57 |
| m_3 | the intended use is to fork an example and tailor to your needs | 18:57 |
| m_3 | thanks all... | 18:57 |
| m_3 | questions? | 18:57 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Cloud Days - Current Session: OpenStack: An open cloud infrastructure project - Instructors: ttx | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/26/%23ubuntu-classroom.html following the conclusion of the session. | 19:00 |
| ttx | hey! | 19:00 |
| ttx | Hi everyone | 19:00 |
| ttx | My name is Thierry Carrez, I'm the release manager for the OpenStack project | 19:01 |
| ttx | Raise your hand in #ubuntu-classroom-chat if you're here for the OpenStack Project intro session ! | 19:01 |
| ttx | I'm also an Ubuntu core developer, working on Ubuntu Server, time permitting | 19:01 |
| ttx | In this session I'd like to introduce what OpenStack is and how you can participate | 19:02 |
| ttx | You can ask questions in #ubuntu-classroom-chat, like this: | 19:02 |
| ttx | QUESTION: what is OpenStack ? | 19:02 |
| ttx | I'll review them periodically. | 19:02 |
| ttx | So, what is OpenStack ? | 19:03 |
| ttx | It's an open source project that creates software to run a cloud infrastructure. | 19:03 |
| ttx | It allows you to be an IaaS (infrastructure as a service) provider | 19:03 |
| ttx | In short, it's software you can run to create a competitor to Amazon Web Services or the Rackspace Cloud | 19:03 |
| ttx | But it also scales down so that you can use it to manage your private SMB computing resources in a cloudish way. | 19:04 |
| ttx | The project is built around 4 "open": | 19:04 |
| ttx | Open source: The software is Apache-licensed, and the whole project is open source | 19:04 |
| ttx | So no "enterprise edition" that keeps the tasty features | 19:04 |
| ttx | Open design: We have open design summits, much like UDS, every 6 months | 19:04 |
| ttx | (The next one is in Boston, October 3-5 !) | 19:05 |
| ttx | Also everyone can propose a feature, we use Launchpad for blueprints... but be ready to implement it if you do :) | 19:05 |
| ttx | Open development: We use DVCS (bzr and git) with merge proposals and public comments, so you know why a particular piece of code is accepted or not | 19:05 |
| ttx | The code is written in Python, which makes it easier for everyone to read the code, understand it, investigate why it fails and propose patches | 19:06 |
| ttx | Open community: We have community-elected project leaders and seats on the project policy board, we do meet weekly on IRC | 19:06 |
| ttx | (next meeting in 2 hours in #openstack-meeting !) | 19:06 |
| ttx | We have about 100 different developers that have committed code, from more than 20 different companies | 19:06 |
| ttx | Questions so far ? | 19:06 |
| ttx | No questions, so everyone knows OpenStack already, good good | 19:07 |
| ttx | OpenStack is made of several subprojects | 19:07 |
| ttx | We have "core projects", that follow all our rules and are part of the official OpenStack release | 19:07 |
| ttx | We also have "Incubated" projects, that learn the process and should become core projects one day | 19:08 |
| ttx | Finally we have "Related" projects, that are created in the OpenStack community but should not become core projects for one reason or another | 19:08 |
| ttx | We used to have a 3-month release cycle, but at the last design summit we decided to switch to a 6-month release schedule, with monthly milestones | 19:09 |
| ttx | Milestones can be used to evaluate new features as they land in the projects. | 19:09 |
| ttx | (For example we'll release the diablo-3 milestone Thursday !) | 19:09 |
| ttx | The 6-month release is aligned with the Ubuntu release cycle, so that you can get the latest OpenStack release in the latest Ubuntu release. | 19:09 |
| ttx | Therefore OpenStack 2011.3 (also known as "Diablo") should be released on September 22, and included in 11.10. | 19:10 |
| ttx | Questions ? | 19:10 |
| ClassBot | rwh asked: does Canonical have plans to launch an AWS competitor based on this? | 19:10 |
| ttx | I'm not part of Canonical (anymore) but I don't think so. | 19:10 |
| ttx | If there are no other questions on the project itself, let's go into more details in the 3 current core subprojects | 19:11 |
| ttx | The first one (and most mature) is Swift (OpenStack Object storage) | 19:12 |
| ttx | You can use it to run a raw cloud storage provider, very much like Amazon S3. | 19:12 |
| ttx | It allows your users to PUT and GET small or very large binary files, and get them properly replicated and available. | 19:12 |
| ttx | It's very mature. It's actually the code that runs Rackspace "Cloud files", but also Internap or Nephoscale "Cloud storage". | 19:12 |
| ttx | It scales horizontally using a share-nothing architecture, so you can add up hosts to cope up with the load | 19:13 |
| ttx | You deploy it using commodity hardware, and Swift replication takes care of the redundancy of your data | 19:13 |
| ttx | So you don't need expensive SANs or RAID setups. | 19:13 |
| ttx | Questions ? | 19:13 |
| ClassBot | koolhead17 asked: any duration for support cycle? like ubuntu? | 19:13 |
| ttx | OpenStack is being distributed through downstream distributions, like Ubuntu | 19:14 |
| ttx | They all have their own support cycles, we don't have a particular one | 19:15 |
| ttx | At this point we don'"t backport anything but critical issues and security issues into past releases | 19:15 |
| ttx | for for long term support I advise that you opt for one of those distributions of OpenStack. | 19:15 |
| ttx | If there are no more questions, we'll switch to Nova | 19:16 |
| ttx | Nova (Cloud Compute) is the biggest of the three current core projects. | 19:17 |
| ttx | A few hours ago soren gave you the keys to it, I'll repeat the essentials now | 19:17 |
| ttx | You can use it to run a cloud compute provider, like Amazon EC2 or Rackspace Cloud Servers | 19:17 |
| ttx | It allows your users to request a raw virtual machine (based on a disk image from a catalog) | 19:17 |
| ttx | So for example users can request a VM with Ubuntu Server 11.04 on it, then access it using SSH, customize and run things on it. | 19:18 |
| ttx | The architecture is a bit complex. We have several types of nodes, and you can run any number of each of them to cope with load | 19:18 |
| ttx | We have API nodes that receive requests, Scheduler nodes that assign workers... | 19:18 |
| ttx | Network nodes that handle networking needs, Compute and Storage workers than handle VMs and block storage. | 19:18 |
| ttx | Everything communicates using a RabbitMQ message queue | 19:19 |
| ttx | It's *very* modular, so you have to choose how you want to deploy it. | 19:19 |
| ttx | For example it supports 8 different virtualization technologies right now: | 19:19 |
| ttx | QEMU, KVM, UML, LXC, Xen, Citrix XenServer, M$ HyperV and VMWare vSphere | 19:19 |
| ttx | Ubuntu by default should concentrate on two of those: KVM and LXC | 19:19 |
| ttx | Nova is still fast-moving, but it's used in production at NASA Nebula cloud | 19:20 |
| ttx | and it will be deployed this year to replace current Rackspace Cloud Servers software | 19:20 |
| ttx | Questions ? | 19:20 |
| ClassBot | koolhead17 asked: how feasible it is to use openstack in production environment due to the nature of rapid change in architecture/feature every new release? | 19:20 |
| ttx | Depends on the component. | 19:21 |
| ttx | Swift is very mature and slow moving now, you can certainly easily deploy it in production | 19:21 |
| ttx | Nova is still changing a lot, though that will calm down after Diablo. At this point running it in production requires a good effort to keep up | 19:22 |
| ttx | Some deployment options are more tested, and therefore more stable than others | 19:22 |
| ttx | So it is feasible... and will become more feasible as time passes | 19:22 |
| ttx | Any other question on Nova before we switch to Glance ? | 19:23 |
| ttx | ok then | 19:24 |
| ttx | Glance (OpenStack Image service) is the latest addition to the core projects family | 19:24 |
| ttx | It's a relatively-simple project that handles VM image registration and delivery | 19:24 |
| ttx | So your users can use it to upload new disk images for use within Nova | 19:24 |
| ttx | It supports multiple disk formats and multiple storage backends | 19:24 |
| ttx | So disk images end up being stored in Swift or S3 | 19:25 |
| ttx | (or locally if you can't afford that) | 19:25 |
| ttx | As far as stability is concerned, I'd say it's on par with Nova, and maturing fast. | 19:25 |
| ttx | Questions on Glance ? | 19:25 |
| ttx | hah! crystal clear, I see | 19:26 |
| ttx | So, what can *you*, Ubuntu user, do with it ? | 19:26 |
| ttx | You can try it. We provide several distribution channels... | 19:26 |
| ttx | Starting with 11.04, the latest OpenStack version is released in Ubuntu universe | 19:26 |
| ttx | (And the "Diablo" release should be in main for 11.10) | 19:27 |
| ttx | If you need something fresher (or running on LTS), you can use our PPAs: | 19:27 |
| ttx | We have release PPAs (with 2011.2 "Cactus") for 10.04 LTS, 10.10, 11.04 and Oneiric | 19:27 |
| ttx | We also have "last milestone" PPAs and "trunk" PPAs for the same Ubuntu releases | 19:28 |
| ttx | (The "trunk" PPA contains packages built from the latest commit in the trunk branch !) | 19:28 |
| ttx | See http://wiki.openstack.org/PPAs for more details | 19:28 |
| ttx | You don't need a lot of hardware to test it | 19:28 |
| ttx | You can actually deploy Nova + Glance on a single machine | 19:29 |
| ttx | It's easier to use a real physical machine to be able to test virtualization correctly | 19:29 |
| ttx | Swift would prefer a minimum of 5 servers (to handle its redundancy)... | 19:29 |
| ttx | but you can fake it to use the same machine, or you can (ab)use virtual machines to test it | 19:29 |
| ttx | That's about all I had in mind for this presentation, so we can switch to general Q&A | 19:30 |
| ttx | Feel free to join our community: test, report bugs, propose branches fixing known issues | 19:30 |
| ttx | The best way to ensure it's working for *your* use case is actually to try it and report bugs if it doesn't :) | 19:30 |
| ClassBot | _et asked: I am confused by the flow of control in the architecture diagram here http://ur1.ca/4sni7. can you shed more light on how each component interacts with each other and how comm to and from outside flows? | 19:31 |
| * ttx looks | 19:31 | |
| ttx | aw | 19:31 |
| ttx | ok, let's take an example | 19:31 |
| ttx | A call to create a server | 19:32 |
| ttx | run_instance in EC2-talk | 19:32 |
| ttx | You use a client library or CLI that will talk the EC2 or the OpenStack APi | 19:32 |
| ttx | your request will be received by a nova-api node | 19:32 |
| ttx | You can run any number of those, in order to cope with your load | 19:33 |
| ttx | nova-api will place your request in the queue | 19:33 |
| ttx | nova-scheduler pick up requests in the queue | 19:33 |
| ttx | again, you can run any number of them in order to cope with your load | 19:33 |
| ttx | scheduler looks at your request and determines where it should be handled | 19:34 |
| ttx | here, it determines which nova-compute host will actually run your VM | 19:34 |
| ttx | scheduler places back on the queue a message that says "compute node X should run this query | 19:34 |
| ttx | " | 19:34 |
| ttx | nova-compute node X picks message in the queue | 19:35 |
| ttx | it retrieves disk image from Glance, starts your VM | 19:35 |
| ttx | updated DB so that if you run describ_instances you can see it's running, etc | 19:36 |
| ttx | all the other arrows are for other types of requests | 19:36 |
| ClassBot | _et asked: scheduler decides based on wat the load balancer says? | 19:36 |
| ttx | no, scheduler decides based on the scheduler algorithm you use | 19:36 |
| ttx | there are multiple scheduler algorithms available, and you can easily plug your own | 19:37 |
| ttx | the default ChanceScheduler is just a round robin | 19:37 |
| ClassBot | BuZZ-T asked: are there any possibilities to automatically scale instances (e.g. by load) | 19:37 |
| ttx | That would be the role of tools above the IaaS layer | 19:38 |
| ttx | ScalR, Rightscale, etc all provide tools that monitor your IaaS and react accordingly | 19:38 |
| ttx | but then you tread into PaaS territory | 19:38 |
| ttx | and OpenStack is already very busy trying to cover the IaaS space | 19:39 |
| ttx | http://wiki.openstack.org/ is a good starting point for all things | 19:39 |
| ttx | We also hang out in #openstack (support) and #openstack-dev (development) on Freenode ! | 19:40 |
| ttx | Any other question ? Or let me know if any of my answers was incomplete or confusing | 19:40 |
| ClassBot | _et asked: how are IPs assigned? does compute do it thru scheduler? or is it the scheduler all by itself? ( if u ve time ) | 19:41 |
| ttx | You define networks with scores of available IP addresses, and the network node just picks one that is available | 19:41 |
| ttx | There is an ambitious project to separate the network components into a set of projects | 19:42 |
| ttx | to achieve complete and complex network virtualization | 19:42 |
| ttx | Check out Quantum, Melange and Donabe in Launchpad | 19:42 |
| ttx | If there are no other questions, I'll close this online event, since this is the last session | 19:43 |
| ttx | kim0 is not around, but asked me to thank all attendees | 19:44 |
| ttx | For further questions, feel free to hit #ubuntu-cloud | 19:44 |
| ttx | where most of the people that presented hang out anyway :) | 19:44 |
| ttx | Thank you all for making Ubuntu the best platform for the cloud, and on the cloud | 19:45 |
| ClassBot | There are 10 minutes remaining in the current session. | 19:50 |
| ClassBot | There are 5 minutes remaining in the current session. | 19:55 |
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/26/%23ubuntu-classroom.html | 20:00 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || | ||
| === koolhead17 is now known as koolhead17|afk | ||
| === yofel_ is now known as yofel | ||
| === MO is now known as Guest83118 | ||
| === medberry is now known as med_out | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!