[00:09] why won't channel #ubuntu let me send messages [00:14] what is this room for === 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 [13:10] 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] it? I was searching the internet, but nothing useful found. [13:10] StathisV: this is not a general support channel, try #ubuntu [13:10] !classroom [13:10] 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:12] head_victim ok :) thnx :) === AndroUser is now known as CloudAche84_droi [15:10] Test [15:12] hi === med_out is now known as medberry [15:50] * soren taps the microphone [15:50] * soren taps the microphone [16:00] Hello, everyone. Thanks for stopping by. === 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 [16:00] 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] I should mention I'm currently at OSCON, on the conference wifi, so I *might* disappear. [16:00] ...but so far the wifi has been ok, so here's hoping. [16:00] Anyways. [16:01] 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] Ok, so "Getting started with Openstack Compute". [16:01] I'm probably going to call it "Nova" at times, but it's the same thing. [16:02] 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] (Also, my shift key seems to be acting up.) [16:03] 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] Simple stuff, since we only have an hour :) [16:03] 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] If you're running 64 bit Ubuntu, grab this: [16:03] http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-amd64.tar.gz [16:04] I.e. just fire up a terminal and run: [16:04] wget http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-amd64.tar.gz [16:04] If you're runing 32 bit ubuntu, grab this instead: [16:04] http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-i386.tar.gz [16:04] 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:05] So, I'll just assume you're all downloading this now and move on. [16:05] OpenStack Compute consists of a number of "internal" and "external" components. [16:06] "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] RabbitMQ is a message queueing system. It's a core component of a Nova deployment. [16:06] It passes messages between the different components. [16:07] It's the only control communication mehcnaism we have. [16:07] mechanism, even. [16:07] Nova itself has 5 components that we'll work with today. [16:07] nova-api [16:07] nova-compute [16:07] nova-scheduler [16:07] nova-network [16:07] nova-objectstore [16:07] nova-api is the fronten server. [16:08] Whenever you -- as an enduser -- want to interact with Nova, this is the component you talk to. [16:08] It exposes the native OpenStack API (which is derived from the Rackspace Cloud Servers API) as well as the EC2 aPI. [16:08] Well, a subset of the EC2 API. [16:09] It receives your request over HTTP, authenticates and validates the request. [16:09] ...and turns it into a message and puts it on the message queue for someone else to consume. [16:10] You can have any number of these servers. [16:10] They all act the same: Verify the request and sends it on to some other component for processing. === Hugo is now known as Guest95592 [16:10] No failover or anything is involved, all components are "hot". [16:11] nova-compute is the component that actually runs your virtual machines. [16:12] It receives a request from the scheduler, which I apparently should have talked about first, but here we are :) [16:12] 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:13] 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:14] So, on the bulk of your servers in your cloud, this is the thing you run. [16:15] 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] It depends on the type of message. [16:16] Hm... Let me explain a bit more first, and get back to this. [16:16] The scheduler. [16:16] As you might have guessed, it schedules stuff. [16:16] When you ask the API server to run a virtual machine it sends the request to one of the schedulers. [16:17] The scheduler is (meant to be) smart. [16:17] It makes the decision about which compute node is meant to run the virtual machine. [16:18] When it has decided, it sends the message on to the chose compute node. [16:18] Ok, so rabbit. [16:18] The API server sort of broadcasts the request to all the schedulers. [16:18] Here, rabbitmq makes the decision about which scheduler gets the request. [16:18] ...and applies its usual logic about sending the request somewhere else if it doesn't get acked. [16:19] for the scheduler->compute message, it's different, of course. [16:19] ...since it's being sent directly to a specific node. [16:19] I'm not sure what the failure modes are there. [16:20] The scheulder doesn't just schedule VM's, though. [16:20] It's supposed to make decisions about which storage node is supposed to host your EBS-like volumes and so on. [16:20] nova-network is... the network component. [16:20] (surprise) [16:21] It hands out IP addressses and in certain network modes it acts as the gateway. [16:21] It also does NAT'ing for elastic IP's and a few other things. [16:21] It doesn't do firewalling. The compute nodes do that (in order to decentralise the firewall and spread the filtering load). [16:22] Finally, there's the nova-objecstore. [16:22] It's a simple ple implementation of the S3 API. [16:23] 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:24] kim0 asked: Is there any way to specify locality, like launch this VM besides that VM as close as possible to that EBS volume ? === Wilczek is now known as multivitamin [16:24] I'm not completely sure. [16:25] There's certainly been talk about supporting it, but I don't remember seeing code to do it. [16:25] That said, I've been on holiday and at conferences for a while, so maybe it landed recently. [16:25] It's definitely on the roadmap. [16:25] kim0 asked: Why does nova-objecstore exist? Why not just swift or mini-swift ? [16:26] If I didn't answer this already, can you rephrase this? [16:26] kim0 asked: Has openstack dropped the centralized DBs ? wasn't mysql used before? [16:26] We have not. [16:26] Yet. === bambee_ is now known as bambee [16:27] 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] Whatever sqlalchemy supports should be fine. [16:27] "should" being the operative word. [16:28] Data access works fine for all the different backends, but schema changes have only been tested with mysql, postgresql and sqlite. [16:28] This is a common theme, by th e way. [16:28] We can use a bunch of different DB backends. [16:29] We can also use a bunch of different hypervisors (kvm, Xen, LXC, UML, Xen Server, VMWare, Hyper-V). [16:29] Different storage backends (HP SANs, iSCSI, AOE) [16:30] Adding more drivers is meant to be reasonable easy, so if you want to use something else, that should be possible. [16:30] Let us know if that's the case. [16:30] kim0 asked: Is there code to accelerate certain operations via SAN (like clone volume, snapshotting ..etc) === multivitamin is now known as Wilczek [16:31] 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] Whether the drivers actually *do*... I don't know. [16:32] Alright then. [16:32] 16:32 < Guest95592> QUESTION : is there any docs talk about openstack with Hyper-V ? Or real use case ? [16:33] I'm not actually sure of the state of the Hyper-V support. We don't really have the means to test it. [16:34] 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] Ok, so let's get practical. [16:34] I assume you've all downloaded the image. [16:34] For those who just joined: [16:35] 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] 16:03 <+soren> If you're running 64 bit Ubuntu, grab this: [16:35] 16:03 <+soren> http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-amd64.tar.gz [16:35] 16:04 <+soren> I.e. just fire up a terminal and run: [16:35] 16:04 <+soren> wget http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-amd64.tar.gz [16:35] 16:04 <+soren> If you're runing 32 bit ubuntu, grab this instead: [16:35] 16:04 <+soren> http://cloud-images.ubuntu.com/releases/11.04/release/ubuntu-11.04-server-uec-i386.tar.gz [16:35] I'm assuming you're running Natty. [16:35] Is anyone not running Natty? [16:35] 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:36] kim0: A lot of it will be dictated by the network structure you want. [16:37] Hmm.. [16:37] This is a good question, really. I just write the software, I don't actually run it at scale. [16:37] It's not a strict hierarchy. [16:37] At all. [16:38] You have the message queue, which everything shares. [16:38] ...the database that everything shares. [16:38] "a number" of API servers. :) [16:38] I don't really know how many I'd set up. [16:38] Ideally, they'd run as instances on your cloud so that you could scale them as appropriate. [16:39] 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:40] Number of storage servers depends on how much storage you want to expose, really. [16:40] ...and how much you expect your users to use them. [16:40] Nova doesn't really add any overhead there. [16:40] 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:41] 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] I don't think there really are any good, general answers. [16:41] The architecture is really flexible, though, so if you discover that you need more store or bandwidth, you just add more. [16:42] Since the architecture is so flat. [16:42] Ok, so back to our demo. [16:42] Everyone runs natty. Great. [16:42] First: [16:42] sudo apt-get install rabbitmq-server unzip cloud-utils [16:43] This install rabbitmq and a few utilities that we'll need in a few minutes. [16:43] When that is done, do this: [16:43] sudo apt-get install nova-api nova-compute nova-scheduler nova-network nova-objectstore [16:43] 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] Ok, so next up, we create a user. [16:44] If your name is not "soren" you can specify something else where it says "soren" :) [16:44] sudo nova-manage user admin soren [16:44] This creates an admin user called "soren" [16:44] sudo nova-manage project create soren soren [16:44] This creates a "project" called "soren" with the user "soren" as the admin. [16:45] Next, we need to create a network. [16:45] If you can't use 10.0.0.0/8 (beacuse you already use it), make something else up. [16:45] sudo nova-manage network create 10.0.0.0/8 2 24 [16:45] This creates two networks of 24 IP's each in the 10.0.0.0/8 subnet. [16:46] sudo nova-manage project zipfile soren soren [16:46] This fetches a zipfile with from credentials in it for the user soren for the project soren. [16:46] Unpack it: [16:46] unzip nova.zip [16:46] Source the novarc file: [16:46] . novarc [16:46] Now we upload the image we downloaded earlier. [16:47] uec-publish-tarball ubuntu-11.04-server-uec-amd64.tar.gz ubuntu [16:47] 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] Next, we create a key: [16:47] euca-add-keypair mykey > mykey.priv [16:48] chmod 600 mykey.priv [16:48] uec-publish-tarball may take a while. [16:48] The last thing it outputs might look like: [16:49] emi="ami-3a0c3765"; eri="none"; eki="aki-279dfe6a"; [16:49] We need the first ID there (ami-3a0c3765). [16:49] Your id will be different. [16:49] Well, probably. [16:49] there's a 1 in 2^32 chance it'll be the same :) [16:50] Ok, next: [16:50] echo '#!/bin/sh' >> myuserdata [16:50] There are 10 minutes remaining in the current session. [16:50] echo "wget http://f.linux2go.dk:8080/$HOSTNAME/" >> myuserdata [16:50] And finally: [16:50] euca-run-instances -k mykey -t m1.tiny -f myuserdata "the ami ID we found a bit further up" [16:51] If this works, we'll be able to see your hostname on http://f.linux2go.dk:8080/ [16:51] ...and you'll also be able to ssh into the instance. [16:52] Is this working for everyone? [16:55] There are 5 minutes remaining in the current session. [16:55] I don't really anything more, I didn't know how long this demo thing would take. [16:57] Alright, thanks everyone for stopping by. === 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 [17:00] 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] hello there, glad to have you aboard for a session on UEC on Ubuntu 10.04 LTS [17:01] thanks to soren for providing us with info on openstack, a very interesting and recent development in cloud space [17:01] in the next hour I will write about UEC, Ubuntu Enterprise Cloud, as we find it in Ubuntu 10.04 LTS [17:01] most of you will already know that the LTS (Long Term Support) releases are quite important to the Ubuntu universe [17:02] with 5 years of support for servers, it is a good choice for deploying it in any datacenter [17:03] 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] so with regards to UEC, we find that the base is eucalyptus 1.6.2 [17:03] some of you might have attended nurmi's talk yesterday on euca 3 [17:04] 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] so the most useful document for getting started with it, is on the wiki: [17:05] https://help.ubuntu.com/community/UEC [17:05] it contains various info that to the best of my knowledge mostly still applies to 10.04 LTS [17:06] however, due to some problems with service discovery, one might need to manually set up a cloud when doing a packaged install [17:06] I've detailed the needed steps here, as I need them often when teaching the UEC class: [17:07] http://people.canonical.com/~tspindler/UEC-Jan/02-cloudPackagedInstall [17:07] typically it takes 10-20 minutes to set up a two node cloud with UEC [17:08] one node acting as the front-end, the other as the node controller [17:08] 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:09] 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] I prefer the later, so a $ sudo euca_conf --get-credentials admin.zip [17:09] will store the credentials for the admin user in the admin.zip file [17:10] next I save these credentials on a client system into ~/.euca-admin/ [17:10] 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:11] e.g. I then usually create a user 'spindler' that has non-admin privileges and store the credentials in ~/.euca-spindler [17:11] I think using multiple users for multi-tenancy in the cloud is a very nice feature, so I like to use it [17:12] once the credentials are available, I source the accompanying 'eucarc' file and we're ready to go [17:12] with euca-describe-availability-zones verbose I do a quick check if the cloud is operational [17:12] euca-describe-availability-zones verbose [17:12] AVAILABILITYZONE torstenCluster 172.24.55.253 [17:12] AVAILABILITYZONE |- vm types free / max cpu ram disk [17:12] AVAILABILITYZONE |- m1.small 0023 / 0024 1 192 2 [17:12] AVAILABILITYZONE |- c1.medium 0022 / 0022 1 256 5 [17:12] AVAILABILITYZONE |- m1.large 0011 / 0011 2 512 10 [17:12] AVAILABILITYZONE |- m1.xlarge 0005 / 0005 2 1024 20 [17:12] AVAILABILITYZONE |- c1.xlarge 0002 / 0002 4 2048 20 [17:12] hope I don't get kicked for flooding [17:13] 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] the lines below the first show how many instances of each instance type you can run [17:13] the instance types will look familiar to those having AWS background [17:14] basically the command tells me that there's a cluster controller operational and a node controller has been found as well [17:14] at least one node controller [17:14] 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:15] in theory a new node controller in the same subnet as my cluser controller would get picked up automatically [17:15] in practice it always worked for me, but I've read in bug reports that at times it didn't for other users [17:16] talking about the auto registration - there is one caveat [17:16] don't setup more than one UEC cloud in the same LAN [17:16] otherwise the auto registration will bring strange fruits [17:17] you can always turn off the auto registration agents in their upstart / init jobs, though, in case you need to [17:17] e.g. you want to setup a classroom with multiple clouds and one LAN [17:17] back to our cloud, the next thing to do is getting an image and uploading it to the cloud [17:17] the easiest way to do so is using the web interface [17:18] however, almost as easy is downloading a tarball from uec-images.ubuntu.com and provisioning that [17:18] thanks to the developers there are scripts that make this really easy [17:18] uec-publish-tarball is the one for publishing a tarball from uec-images in the cloud [17:19] once this is done, the image resides in /var/lib/eucalyptus/bukkits// on the front-end [17:19] cloud tech speaking we have stored a machine image in a bucket on S3 [17:20] we need to store it in a way the node controller can later download and execute the image file [17:20] and S3 is one such storage method in UEC [17:20] next step is to create a ssh keypair usually [17:21] this can be done with euca-add-keypair [17:21] best is to first check with euca-describe-keypairs which ones already exist [17:22] 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:23] once we have an image and a keypair, we can start an instance [17:23] when doing all of this on the command line, rather than using hybridfox or landscape or any other mgmt tool [17:23] I find it useful to save the identifiers in variables [17:23] for example [17:24] IMAGE emi-ACC617F6 maverick-2011-01-26/maverick-server-uec-amd64.img.manifest.xml admin available public x86_64 machine eki-14A41D03 [17:24] this is a maverick server image for 64bit from back in January [17:24] I store the emi identifier in a variable emi [17:24] emi=emi-ACC617F6 [17:25] so when I want to run an instance of that type, I state [17:25] euca-run-instances $emi -k -t [17:25] I usually neglect the instance type and make do with m1.small, but at times bigger instances are worth it [17:26] the euca-run-instances command returns another identifier, this time for the instance [17:26] I save that in the variable 'inst' or 'server-' or whatever else I like [17:26] so I can quickly check the status of the instance with $ euca-describe-instances $inst [17:27] 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] 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:28] once the instance is in state running, one can ssh to it [17:28] ssh -i ubuntu@ [17:28] the -i option we need to use the right private key file, the one that was returned by euca-add-keypair earlier [17:29] if we need the public or private ip depends on where our client sits [17:29] 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:30] 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] when you have done all the work needed by the instance, you can terminate it with 'euca-terminate-instances' [17:31] so that covered the basic operation of a UEC cloud [17:31] first install the systems, either by CD or by package [17:31] second get the credentials [17:31] third check if the cloud is operational [17:31] next make an image available [17:32] start an instance of that image [17:32] test via ssh or whatever other service the instance may provide [17:32] but you don't need to stop there, there's plenty to still explore [17:32] like attaching persistent storage devices to the instance [17:32] allocating public ip addresses to the instance [17:33] before we cover the persistent storage, let's see why we have the need for that [17:33] what happens when an instance is started? [17:34] a node controller sooner or later gets tasked by a cluster controller to run an instance [17:34] that instance is of a specific emi, eucalyptus machine image [17:34] 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:35] the node controller then copies the image to an instance directory [17:35] inside the instance directory the image is configured according to the start parameters of euca-run-instances [17:35] e.g. an ssh key is injected [17:35] e.g. a cloud init file is added to the boot sequence of the instance [17:36] some more magic happens and the once xen like image is now a kvm image [17:36] and kvm is used to boot the instance [17:36] so in a way eucalyptus and UEC is like kvm on steroids [17:37] when you want to get rid of an instance, you stop it with euca-terminate-instances [17:37] and what happens on the node controller is that the kvm process stops _and_ the runtime directory containing the image is deleted [17:37] this means that any state in the instance is gone forever [17:38] of course most services require to save some state somewhere. This could be an external database server, or a file server. [17:38] or, as we look at now, EBS, the elastic block storage service [17:39] in EBS a device appears on an instance that is mapped to a file on a storage server, the EBS server [17:39] 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:40] 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] as AoE does not route [17:41] with euca-create-volume we can create a new volume for storage on the EBS storage server [17:41] once this has finished, it can be assigned to an instance with euca-attach-volume [17:41] euca-attach-volume -i $inst [17:42] oops, there's -d missing [17:42] device would be sdb or sdc or anything [17:42] but to my finding the instance will just pick the next device name anyhow [17:43] with the device attached to the instance, one can create a partition table, filesystem and whatever on the device [17:43] just as with a regular device [17:44] the nice thing is, that you can snapshot these devices [17:44] e.g. you attach the device to an instance, put the needed data there, detach it and snapshot it [17:45] based on that snapshot you can create new volumes that are clones of the snapshot [17:45] might be nice if you have read only data that you need on all instances of your application [17:46] that's it pretty much for EBS [17:46] lastly I want to cover elastic IPs [17:46] with help of euca-describe-addresses you see which IPs are public in your UEC [17:46] you can either randomly get one or pick one with euca-allocate-address [17:47] then this ip can be assigned to a specific instance with euca-associate-address [17:47] 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:48] 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:50] There are 10 minutes remaining in the current session. [17:55] There are 5 minutes remaining in the current session. [17:59] can I type in here yet? [17:59] yes :) [17:59] ok, I'll go ahead and get started [18:00] Hi, I'm Mark M Mims (hence the m_3) === 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 [18:00] 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] On the Ensemble team working to build out the base set of formulas we have to work with in ensemble [18:01] I'd like to go into a little detail today about the different kinds of formulas ensemble can work with [18:01] at this point I hope that you've seen the earlier presentation on 'getting started with ensemble' [18:02] I'll be demoing stuff in byobu-classroom, where you can watch along [18:02] you can either open http://ec2-67-202-23-199.compute-1.amazonaws.com/ up in a browser [18:02] or ssh there directly as "guest" with password "guest" [18:03] So, how do you use ensemble to deploy a node.js app? [18:03] the short version (we'll go repeat in more detail) [18:03] is: [18:04] $ ensemble bootstrap [18:04] $ ensemble deploy --repository .. mynodeapp [18:04] ensemble deploy --repository .. mongodb [18:04] ensemble deploy --repository .. haproxy [18:04] to deploy all the services as we expect === basso_ is now known as basso [18:05] here, we have a simple (exposed) mongodb service [18:05] a node.js app that sits above the mongodb [18:06] and haproxy that faces the outside world [18:06] we deploy the services, then relate them: [18:06] ensemble add-relation mongodb mynodeapp [18:06] ensemble add-relation mynodeapp haproxy [18:06] then wait for the relation hooks to complete [18:07] the outcome of that is shown in ssh [18:08] The point of this talk is that there are two different kinds of services involved here: [18:08] 1.) "canned" services... like haproxy and mongodb [18:09] these are services you typically just configure and use [18:09] they're tailored to your infrastructure through configuration parameters [18:09] 2.) what I like to call "framework" formulas [18:10] these are formulas for services that you write [18:10] i.e., mynodeapp is an application that I keep under my own revision control system [18:11] a framework formula is a formula that helps you deploy such a service alongside other canned services [18:11] let's look at an example [18:12] mynodeapp is a _super_ simplistic node.js app [18:12] there's a basic http server listening on 0.0.0.0/8000 [18:13] that tracks hits to the page [18:13] and sticks them in a mongo database [18:13] easy peasy [18:13] it reads some information from a config file... [18:14] that's just simple json [18:15] I've written a basic ensemble formula to wrap the installation and deployment of that node.js application [18:15] the metadata.yaml shows where it fits within my overall infrastructure [18:15] this consumes a db, and provides a http interface [18:16] I can of course attach monitoring services, remote logging services, etc [18:16] there's a little cruft in here about formula config [18:17] that's a new feature that recently landed [18:17] so all of that should be replaced with 'config-get ' [18:17] the installation of node itself and npm are pretty straightforward [18:17] try to use packages when you can [18:18] when you're on HEAD or living closer to the edge, you can pull and install from source if you want [18:18] that's worth mentioning again... [18:18] packages are great for stability [18:18] and often what the ops guys want [18:19] developers want the bleeding edge all the time [18:19] ensemble formulas support either [18:19] so it becomes a policy decision within your group [18:19] but anyway... I'm pulling my node.js from github [18:20] you can use any number of other options [18:20] the key is to install the packages first for the VCS you use [18:21]