[00:53] smoser: I'm here. [00:54] never mind. i thought you had opened the 'no ec2-tag command' bug [00:56] hey guys :) [01:02] smoser: Yeah, I just added a comment to it. [01:03] erichammond, i do want to get your package requests packaged. [01:03] iam is on top of my personal list [01:04] smoser: Cool. It seems right up Ubuntu's alley to package useful software :) [01:04] I'd love to have all of Amazon's software available a day or so after they release each new tool set or version. [01:05] This probably means a PPA since it takes more work to get it into official Ubuntu packages. [01:05] well,k i've kept up ok with api-tools [01:05] we used to maintain that ppa [01:05] I'd be willing to manage the PPA if I had help learning how to maintain it. [01:05] but i tihnk the -backports should be the real place [01:05] i could maintain a ppa for staging though i guess and then get into backports when they do [01:06] smoser: Is it possible to -backports a single package? I think I did something like this with "pinning" but it's been a long time. [01:06] erichammond, we can set up a team and share the amazon-tools ppa [01:06] erichammond, yeah... that part does suck, i agree. [01:06] there are ways to do it, but... [01:06] i'm not terribly familiar with it. [01:06] basically "backports is the place for backports" [01:07] its the most discoverable for people [01:07] that was the conclusion we came to in a meeting once [01:08] Ok, so PPA with fast updates, paced integration into +1 if the timing in the release cycle is right, and -backports for older releases? [01:08] yeah. [01:08] backports probably isn't that slow [01:08] if we had someone watching [01:09] it definitely would be slower than ppa, but if you have someone keeping on top of it, it wouldn't be so bad. its just more work. [01:09] (ie, have to file a bug and tap someone on backprots team) [01:10] In the Ubuntu way, is there ever a place for updating the software in a past release if it's primarily to gain access to new features? [01:11] This seems slightly contradictory to keeping the release constant and stable, but it sure would be nice for keeping up with Amazon's constant stream of features. [01:11] erichammond: SRU can be used for that [01:11] I'm ok with PPA personally, but it makes discoverability difficult for the masses. [01:12] erichammond: one of the critiria for Stable Release Update is if the services used by the progam change [01:12] erichammond: landscape-client is such an example [01:13] erichammond: new releases with new features of landscape-client are pushed as SRU [01:13] erichammond: in order to gain access to new features available in landscape [01:13] mathiaz: Thanks. AWS seems to fit in with that criteria. [01:13] erichammond: so landscape-client has an SRU exception with a documented plan for QA [01:13] erichammond: landscape-client was actually the first example for such a situation [01:14] erichammond: and should be looked as a model to handle the same situation [01:15] The one big risk is that the new version breaks old behavior, but in the case of Amazon's tools, they are *extremely* averse to breaking backwards compatibility, so it should fit in pretty well with Ubuntu. [01:15] erichammond: I agree that AWS commands could probably get an SRU [01:15] erichammond: yeah - that's the main critiria that need to be highlighted [01:16] erichammond: I'd recommend to talk about that at UDS to get the process started [01:16] i dont think theres a lot of value in getting into SRU over backports [01:16] erichammond: from a process POV the Technincal Board is the entity to engage with [01:16] for landscape, there is. i don't think for ec2. [01:16] smoser: is -backports enabled by default? [01:16] smoser: on the AMI? [01:16] no. [01:17] smoser: so how would you get the new versions of the tools? [01:17] but in most of these tools aren't needed in the ami. [01:17] they're client tools [01:17] but.. anyway, you'd enable backports and get them. [01:17] just as you do other places. [01:17] smoser: I'm not talking about AMIs. I simply use these tools on Ubuntu. [01:17] you very likely do not need them early in first boot [01:17] smoser: right - *enabling* backports is already a big step to take [01:17] bah. [01:17] smoser: especially if you're running desktop [01:18] mathiaz: Agreed (big step) [01:18] So: Amazon release -> PPA as soon as one of the team can get to it -> Ubuntu+1 update -> -backports update -> SRU process [01:18] smoser: where you'd get a lot of other non-related things [01:18] that part sucks. [01:18] smoser: yes - I think there will be some discussion about that at UDS as well [01:19] an SRU exception seems feasible to me [01:19] erichammond, similar thread to the "extremely stable" line: http://developer.amazonwebservices.com/connect/thread.jspa?threadID=53242&tstart=0 [01:19] i was very surprised to see that, if in fact they've just dropped stuff from the MD service. [01:19] mathiaz, i just dont think the sru is justified [01:19] there is risk for breaking old things [01:20] and not much gain, imho [01:20] mathiaz: If it is done, would the SRU be just for LTS releases or all active releases? [01:20] smoser: :/ - is the source code actually available? [01:20] erichammond: all active releases IMO [01:20] erichammond: there is no real difference in terms of SRU critiria between LTS and normal releases [01:20] smoser: I think it's a huge gain. For those of us running released versions of Ubuntu (not +1) it's nice to have access to all live AWS features with our standard installed software available from Ubuntu. [01:21] no source (for most things). [01:21] erichammond, i'm not arguing against the availability [01:21] i'm arguing against SRU [01:21] smoser: hm - that would probably make it harder for getting an SRU exception then [01:21] its not justified over backports or ppa [01:21] smoser: It's a matter of how widely you want the gain to be seen. Just people who know about how to access PPAs and -backports, or everybody. [01:22] you break things [01:22] and that should not be by default [01:22] and, seriously, you type it into google at some point [01:22] "ubuntu ec2-api-tools" [01:22] poof [01:22] If the risk is low (and so far it has been) then I'd vote for spreading the goodness. [01:22] the one break i'm aware of is requirement for '--name' in new ec2-register [01:22] which broke things [01:23] and they changed the behavior of the tools to show 'name' rather than manifest path [01:23] (this was when they added snapshots) [01:23] err... ebs root [01:24] smoser: Fair 'nuff. I'm not going to push for SRU as long as I can get PPA :) [01:24] landscape is different. it *has* to be in those images in a lot of cases, because landscape manages them. [01:26] smoser: The AWS tools have little to do with the AMIs as they aren't installed there and are often not used there. This is just about making AWS features easy to use from Ubuntu systems. [01:27] yeah, understood [01:27] i have to run [01:27] So what are the next steps for setting up the team PPA? [01:27] Or does this still need to be discussed at UDS? [01:29] erichammond: I don't think this needs to be discussed at UDS [01:30] erichammond: it's just a matter of creating a team in LP and that's it [01:30] erichammond: the name of the team may be discussed though [01:30] erichammond: not worth a UDS session IMO [01:34] mathiaz: Well, there is a session where I tacked on the request to have these AWS software tools released in Ubuntu. [01:34] https://blueprints.launchpad.net/ubuntu/+spec/cloud-server-n-webscale-tech [01:35] erichammond: good - seems like a good plan [01:35] erichammond: but don't wait for the UDS session - setting the team and the PPA may be sorted out sooner and faster with smoser [01:35] mathiaz: cool. [01:38] flaccid: 'lo [01:38] howdy [01:43] soon i'll find time to get debian going with pvgrub [01:43] erichammond, mathiaz you can discuss this , i'm not here. [01:43] but there is the ubuntu-on-ec2 team and ppa [01:43] where that *used* to be, before others (mathiaz included :) suggested that -backports was the correct place [01:43] :) [01:44] smoser: :) [01:44] smoser, mathiaz: This isn't really related to "ubuntu-on-ec2" since it doesn't relate to the AMIs. It's more "Using AWS with Ubuntu". [01:45] Perhaps "aws-tools" [01:45] It also expands beyond "EC2" into other AWS services. [01:46] We might even want to include software for working with AWS that is not released by Amazon. There's a lot of good stuff out there. [01:46] making it easy for folks to install those packages. [01:47] It's not important to me at this point, but perhaps the team/PPA could eventually support tools non-Amazon clouds. [01:47] So... "cloud-tools"? [01:47] Though this might start to blur into UEC stuff. [01:49] flaccid: The Debian crowd would be thrilled with this. It is now becoming clear that Debian squeeze runs with recent Ubuntu kernels on EC2, but if I understand correctly, pv would let Debian run with a Debian kernel. [01:50] erichammond: yeah i've been running with lucid kernel. actually a lot of distros boot and run fine with the ubuntu kernels. just a matter of finding time to do the debian pvgrub - i just need to add to my build template [01:57] after that is done, then it will be on to freebsd support with pvgrub [01:57] oooh. [01:58] You'll be famous :) [01:59] Those guys have been begging for 4 years. [02:00] yeah and i'm one of those guys hehe. its all a matter of finding time; but i got a feeling that bsd may still not run because of EC2's ancient xen. is still used with pvgrub or is it something else? [02:01] i mean 'is xen still used' [02:12] flaccid: smoser or jjohansen might know since Ubuntu 10.10 works with pv (I think). [02:14] okies thanks. the positive thing is that in theory at least would be able to get it up to init [02:38] flaccid, xen is still used with pv-grub [02:39] pv-grub is mostly just grub (0.97) that runs inside xen, loads the kernel off a filesystem it knows about , and goes. [02:39] but i dont know if it can read a bsd filesystem, you might have to hack around with getting a boot partition [02:40] the big benefit of pv-grub is that you (being someone other than me) can *try* a kernel. [02:40] ie, you dont hvae to register a aki [02:42] i think amazon mentioned bsd explicitly in the pv-grub announcemnt [02:46] Libvirt suddenly refuses to let me add a NIC to a bridge. It's always worked well, but now suddenly, it connects it to a virtual network instead. Is this a known issue? [02:46] any ideas? My VMs are no longer of any use, since they cannot be reached from the internet. It's incredibly frustrating. [02:47] smoser: thanks for the info. yeah i doubt UFS2 will go in the cloud, but bsd should be able to run on other filesystems. amazon did mention bsd in the announcement, this is typically because they have always turned it back to the community for implementing bsd support, yet in the past it certainly wasn't possible with their ancient version of xen [02:47] well, the version of xen didn't change [02:48] so, if you were screwed for that reason before, you are now. [02:48] but we boot paravirt-ops kernels and they work [02:48] so, it really is possible. [02:48] yes, which is basically what i suspect. the issue with xen 3.0.3 iirc was actually the boot, so its possible that it may be able to boot. see http://wiki.freebsd.org/FreeBSD/Xen [02:49] just because older xen is not supported by freebsd, doesn't mean necessarily that it doesn't work [02:49] with pv-grub its so infinitely more doable than before. [02:49] since you can actually start an instance, stop it, build a kernel on that voume, start again ... [02:50] i'm looking forward to finding some time to try it all out etc. might have to do it in xmas holidays.. [02:50] so much faster and saner to debug in that environment than in the one jjohansen and zul got to play in [02:50] (publishing aki, startin new instance...) [02:50] one thing you should b aware of [02:50] there are two pv-grub kernels [02:50] smoser: i have more grey hair now [02:51] one loads off of (hd0) (i think we use that one), one loads of (hd0,1) [02:51] i forget the details, but the one we don't use is so that you could basically register an instance store image that was a disk-image inside a partition [02:51] and then your root would be sda1p1 [02:52] ok. i just hope it plays nice with freebsd bios device names [03:45]

what I was wondering: are you guys patching the OS yourself or is that something the provider does for you? [03:47] depends how you define patching. its generally something up to you [11:27]

flaccid: I mean OS patching. [11:27]

as in kernel and packages update. === kim0_ is now known as kim0 === mathiaz_ is now known as mathiaz [14:49] smoser: what would it take to support kernel-upgrades on the Lucid EC2 AMI's (as supported in the Maverick AMI's)? [14:50] not a lot. [14:50] and i've been wanting to spend some time on it. [14:50] smoser: it would be great if we could update the Lucid AMI's then - being LTS and all... [14:50] largely the only thing you really need is grub-legacy-ec2 installed [14:50] alonswartz, its not really SRU [14:50] is the thing [14:51] we'll have to argue, because it is undeniably "feature" and not bug or security [14:52] smoser: not a security bug directly, but definately a security enhancement. Think production server running on EC2, kernel vulnerability disclosed. Sysadmin now needs to migrate his system to a new AMI [14:53] yeah.. [14:53] so, the one thing that *has* to happen is to get /boot/grub/menu.lst written in the image during creation [14:53] anyone who has ever migrated a production system knows what a PITA it is [14:53] then, the next thing is you have to manage /boot/grub/menu.lst [14:54] grub-legacy-ec2 does both of those. but its part of cloud-init in maverick. so need to rip it out, put it into lucid cloud-init. [14:55] smoser: if you don't get to it, I'll do it. As we want to support cloud-init in the new TurnKey 11.0 release (based on Lucid) [14:55] but, getting it supported in the official Lucid AMI's would be a win for ubuntu [14:56] being LTS [14:56] yeah, jib was pushing on that pretty ahrd. [14:56] and i mostly agree. [14:56] alonswartz, i put your thiknpad in my bag last night. [14:56] all ready to go [14:56] smoser: awesome, don't forget the SSD :) [14:56] darn [14:57] i was hoping you'd forgotten [14:57] :) [14:57] its in there too. [14:57] for the price I paid, and how much I want it, there is no way I'd forget it [14:57] what did that thing cost ? [14:57] $359 [14:57] wow [14:57] cheapest I could find [14:57] usually goes for $450+ [14:58] Lenovo sell it for $500 [14:58] i could sell you some mob style "insurance" on it, to make sure it got there. [14:58] :) [14:58] wait, you putting it in your carry-on luggage, right? [15:02] smoser: did the laptop/ssd come with receipts? please bring them as well. [15:03] yeah. i've got everything they sent. [15:03] the ssd didn't have any receipt that i know of. [15:03] its retail packaged though, sealed. [15:03] its in carry-on [15:05] excellent! just let me know your favourite brand of beer [15:05] smoser: btw, when do you arrive. you aren't listed on https://wiki.ubuntu.com/UDS-N/Attendees [15:07] i'm visiting some family in florida , so i'm driving in on sunday night. i have to return the car to the airport and then taxy over, but have to be at hotel ~ 5:00 or so [15:08] cool - so i'll see you then. My plane arrives in the morning [15:08] regarding the kernel-upgrade. Do we have an action item? I've added a note to the IdeaPool [15:10] smoser: one other thing, when you have a couple of minutes, could you take a look at Pymin. Maybe we can discuss it further at UDS. https://wiki.ubuntu.com/Pymin [15:11] ok, so when i scanned it before, the gist is a webmin like thing ? [15:12] nope, far from it [15:13] the better backend for editing files is something like augeas [15:13] the idea is to have a layer implementation, not necessarily a web interface on the actual server, but it's possible [15:13] yeah. [15:14] you could then manage it from a central server, similar to landscape [15:14] but could also be used for local configurations [15:14] integrating it with puppet would be great as well [15:19] mathiaz: did you get a chance to look over Pymin. I'd love your feedback considering your knowledge/experience with puppet. [15:26] alonswartz: I looked at it - it seems to be very high level for now [15:27] alonswartz: having user stories defined, outlining how it would work in the end would be helpful [15:28] mathiaz: You're correct. Its currently a dump of my notes, needs to be translated into spec form [15:28] mathiaz: if you think it would be beneficial, I'll try get it done before next week [15:28] alonswartz: it's better for a discussion if you plan to have a uds session about it [15:29] alonswartz: all previous attempts suffered from a lack of clear scoping [15:29] alonswartz: specific, targeted goal [15:30] mathiaz: OK, i'll see what I can do. Is there a deadline to propose a session (ie. register a blueprint) ? [15:30] alonswartz: the earlier the better [15:30] alonswartz: if you already you wanna have a discussion file it now [15:30] alonswartz: and ping ttx in #ubuntu-server for scheduling [15:31] mathiaz: thanks - I'll try get it all done asap [22:21] http://aws.amazon.com/free/ [22:23] Since you must use EBS volumes on t1.micro and they only give you 10GB EBS for free, running an official Ubuntu AMI on this "free" plan will cost at least $0.50/month :-) [22:23] Still a pretty cool idea to get folks to dip their toes in the water. [22:23] Hope they don't get scared by how weak a t1.micro is. [23:38] yeah people need to certainly understand the purpose/role of a micro