Ubuntu Wiki

Agenda

• Review ACTION points from previous meeting
• Karmic release last actions
  • RC bugs
  • ISO testing
  • Release Notes
  • Other
• Lucid Lynx brainstorm
• Weekly SRU review (mathiaz)
• Open Discussion
• Agree on next meeting date and time

Minutes

Review ACTION points from previous meeting

• kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt: in progress

ACTION: kirkland to finish adapting help.ubuntu.com VM recipe(s?) to use libvirt

• mathiaz to add test case for image store in testcases wiki: Done

• zul to write up server upgrade test case: Done

• nurmi to investigate bug 455625: TODO

ACTION: nurmi to investigate bug 455625

• soren to complete demo virtual appliance: Published and tested, could use some polish
• mdz to chase down details on production image store: Running and tested
• mathiaz to test UEC integration with production image store: Tested and working OK

Karmic release last actions

Remaining RC bugs:

• 458850: on track to be included on release cloud images

• 458576: is safe to fix and would get rolled in the same respin

ISO testing and mentioning relevant bugs in the release notes should be the focus of this week.

Release notes candidates are:

• 459101: Relay denied from eucalyptus registration emails

• 444352: DB deadlock on reboot prevents UEC from working, temporarily

kirkland will review the bug lists and mention anything else UEC-related that I think is worth release-noting.

We should also help where we can the Foundations team in solving 457767 (iSCSI boot). It now seems related to kernel issue so wee should update the documentation to reflect current support.

Lucid Lynx

mdz gathered requirements from Canonical stakeholders, with some more to come. Items are expected in the same broad categories as 9.10: UEC, EC2, appliances, enterprise deployment items. But we will aim to focus on stabilization and negotiate our commitments with regard to that. Opening the meeting to 10.04 suggestions, lots of ideas were discussed. A wikipage was created to followup on those suggestions (and allow to suggest more): https://wiki.ubuntu.com/ServerTeam/LucidIdeaPool

ACTION: ttx to create wiki page for 10.04 input from server team (Done)

Open discussion

kirkland mentioned that the new time slot for the meeting (Wednesdays at 1400 UTC) is difficult for him, so we might (again) change it. ttx asked about how the triage days were going, and updated the knowledge base to make information about them more accessible. mdz asked about release parties that the team plans to go to, as a great way to celebrate and let the pressure go. mathiaz plans to get free beers all night.

Agree on next meeting date and time

Next meeting will be on Wednesday, November 4th at 14:00 UTC in #ubuntu-meeting.

Log

[14:03] <mdz> #startmeeting
[14:03] <MootBot> Meeting started at 09:03. The chair is mdz.
[14:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:03] <mdz> ttx, my browser is acting up, do you have the agenda in front of you?
[14:03] <ttx> yes
[14:04] <mdz> ah, working now
[14:04] <mdz> [link] https://wiki.ubuntu.com/ServerTeam/Meeting
[14:04] <MootBot> LINK received:  https://wiki.ubuntu.com/ServerTeam/Meeting
[14:04] <ttx> [TOPIC] Review ACTION points from previous meeting
[14:04] <mdz> [topic] Review ACTION points from previous meeting
[14:04] <MootBot> New Topic:  Review ACTION points from previous meeting
[14:04] <mdz> [link] https://wiki.ubuntu.com/MeetingLogs/Server/20091020
[14:04] <MootBot> LINK received:  https://wiki.ubuntu.com/MeetingLogs/Server/20091020
[14:04] <mdz> ACTION: kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt
[14:05] <kirkland> https://help.ubuntu.com/community/KVM/VirtManager
[14:05] <mdz> kirkland, done?
[14:05] <kirkland> mdz: the VirtManager piece is pretty well done
[14:05] <kirkland> mdz: i could add a similar page for Virsh
[14:05] <kirkland> mdz: you can leave that action with me
[14:05] <mdz> kirkland, iirc what we wanted was to make sure that general recipes which used virtualization used libvirt tools instead of bare KVM
[14:05] <kirkland> mdz: i'll get an equivalent virsh page up too
[14:05] <mdz> ok, carried over
[14:05] <mdz> [action] kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt
[14:05] <MootBot> ACTION received:  kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt
[14:05] <mdz> ACTION: mathiaz to add test case for image store in testcases wiki
[14:05] <mathiaz> mdz: done
[14:06] <kirkland> mdz: hmm, yes, well, i did rework some of that documentation, but i feel that the command line stuff is valuable too
[14:06] <mdz> mathiaz, great, thanks
[14:06] <mdz> ACTION: zul to write up server upgrade test case
[14:06] <zul> done
[14:06] <mathiaz> mdz: http://testcases.qa.ubuntu.com/System/UECImageStore
[14:06] <mdz> zul, we discussed expanding it last week, is that also done?
[14:06] <soren> zul: Where can I see this?
[14:06] <mdz> [link] http://testcases.qa.ubuntu.com/Testing/Cases/ServerUpgrade
[14:06] <MootBot> LINK received:  http://testcases.qa.ubuntu.com/Testing/Cases/ServerUpgrade
[14:07] <mdz> soren, ^^
[14:07] <zul> mdz: yes I asked the user to install the lamp and openssh tasksel before upgrading
[14:07] <mdz> zul, I don't see that on the page
[14:07] <zul> mdz: grr..
[14:07] <mdz> ACTION: nurmi to investigate bug 455625
[14:07] <ubottu> Launchpad bug 455625 in eucalyptus "Eucalyptus Loses Public IP Address" [Medium,Incomplete] https://launchpad.net/bugs/455625
[14:07] <ttx> no news on that, note that the reporter failed to reproduce it on further testing. Anyone in the team testing long-running instances ?
[14:07] <zul> mdz: i need to bug ara then
[14:08]  * ttx only has one UEC setup and can't use it for that
[14:08] <mdz> nurmi, are you here?
[14:08] <soren> nurmi: It's quite early for him.
[14:08] <mdz> ACTION: soren to complete demo virtual appliance
[14:08] <soren> $ TZ=America/Los_Angeles date
[14:08] <soren> man okt 26 07:08:43 PDT 2009
[14:08] <mdz> soren, ah, right, I'm not sure randa took him into account when scheduling this meeting
[14:09] <mdz> soren, demo appliance?
[14:09] <jsalisbury> ttx:  I've been unable to reproduce after a week.
[14:09] <ttx> jsalisbury: not sure its good news or bad news
[14:09] <kirkland> ttx: and my issue was different
[14:09] <mdz> we talked with nurmi about it on the phone last week
[14:09] <mdz> no one has been able to reproduce it
[14:09] <soren> mdz: right.
[14:09] <mdz> I think we can safely reduce the importance
[14:09] <soren> I pushed out a mediawiki based appliance last week.
[14:10] <soren> It's available in the image store in the UEC console.
[14:10] <mdz> can you mention the URL here?
[14:10] <ttx> mdz: doen already
[14:10] <ttx> done, even
[14:10] <mdz> ttx, thank you
[14:10] <soren> People have tested it, and it seems to work as expected.
[14:10] <soren> There's still a few warts (the URL, the logo, and a few other tidbits), but as a proof-of-concept, it's ok.
[14:10] <soren> I'll be fixing up as much as I can before release.
[14:10] <mathiaz> soren: did you produce an amd64 version of the appliance as well?
[14:11] <mdz> soren, ttx had a problem getting it working; has that been resolved?
[14:11] <soren> mathiaz: No.
[14:11] <ttx> mdz: my fault
[14:11] <mdz> he mentioned it in the thread on ubuntu-devel
[14:11] <soren> mdz: I'll let him talk himself out of that one :)
[14:11] <mdz> pilot error? ;-)
[14:11] <ttx> mdz: I rebundled it today and it worked
[14:11] <mdz> ok, moving on then
[14:11] <mdz> ACTION: mdz to chase down details on production image store
[14:11] <mathiaz> mdz: it's up and running now
[14:11] <mdz> followed up on this by email, the production store is now live
[14:11] <ttx> mdz: well, maybe a eucalyptus bug when reregistering multiple times the exact same filenames
[14:11] <mdz> mathiaz, has it been tested with the final 9.10 eucalyptus bits?
[14:11] <mathiaz> mdz: I've been able to conduct a successfull test
[14:12] <mathiaz> mdz: yes
[14:12] <mdz> mathiaz, excellent, thank you
[14:12] <mdz> that takes care of the next action
[14:12] <mdz> ACTION: mathiaz to test UEC integration with production image store
[14:12] <mdz> and I think that's all
[14:12] <ttx> I tested that as well, its pretty neat.
[14:12] <mdz> [topic] Karmic release last actions
[14:12] <MootBot> New Topic:  Karmic release last actions
[14:12] <mdz> ttx, can you guide us through this one?
[14:12] <ttx> sure
[14:12] <mdz> I wasn't able to attend the meeting on friday so I am a bit out of th eloop
[14:13] <ttx> just a review of the remaining things for this week
[14:13] <ttx> the biggest part is the UEC image sfix
[14:13] <ttx> https://bugs.launchpad.net/bugs/458850
[14:13] <ubottu> Launchpad bug 458850 in ec2-init "UEC images do not mount ephemeral disk on /mnt at boot" [High,In progress]
[14:13] <mdz> smoser, update
[14:13] <mdz> ?
[14:14] <soren> Is he here?
[14:14] <ttx> After discussing with eriuc Hammond, it appears that the ephemeral disk automounted is a classic expectation of an EC2 user
[14:14] <smoser> i've not made much progress on this, only jsut got through mail and stuff this morning.
[14:14] <ttx> so even if it's presented by Eucalyptus in a wrong way, we shoudl work around it in the instance
[14:14] <smoser> my plan is to modify vmbuilder to not write that entry in /etc/fstab
[14:14] <soren> smoser: How would we mount it, then?
[14:15] <soren> ttx: Why do we not consider this a Eucalyptus bug?
[14:15] <smoser> and to have ec2-init modify /etc/fstab "once per ami" (ie on first boot), attempting to make sure that there is no existing entry before doing so
[14:15] <ttx> soren: we do, but its safer to fix it in the instance
[14:15] <soren> I see.
[14:16] <smoser> the issue is that the ephemeral storage is not consistently named.
[14:16] <smoser> on ec2, we got away with one /etc/fstab written for amd64, and one for i386
[14:16] <soren> Between i386 and amd64, you mean?
[14:16] <mdz> smoser, is this feasible to fix in the final 9.10 image or no?
[14:16] <ttx> We would fix https://bugs.launchpad.net/bugs/458576 in the same run
[14:16] <ubottu> Launchpad bug 458576 in ec2-init "ec2: ssh public key fingerprint in console output does not match EC2 standards" [Low,In progress]
[14:17] <smoser> mdz, i'd like some time to look at it further before stating one way or another.
[14:17] <mdz> soren, on EC2, they're different on i386 and amd64, and then they're also different in Eucalyptus
[14:17] <mdz> smoser, ok, can you follow up later today by email and let me know?
[14:17] <mdz> (CC thierry)
[14:17] <smoser> it definitely requires a change in how we've been doing things before.
[14:17] <soren> mdz: Right, I was just curious if they were more inconsistent than that. I mean... They're consistent on i386 and on amd64, just not between the two.
[14:18] <mdz> smoser, I'm sure I don't need to remind you that known bugs are preferable to unknown bugs at this point ;-)
[14:18] <mdz> ttx, anything else?
[14:18] <ttx> ok, any other release-critical issue on our plate ?
[14:18] <smoser> soren, i will look at the default settings. in uec, it is configurable
[14:18] <ttx> I don't think we have...
[14:19] <soren> smoser: It's configurable?
[14:19] <ttx> Next is ISO testing
[14:19] <mathiaz> ttx: did anyone test UEC on i386?
[14:19] <smoser> although i'm not sure if the first disk will always come up in a consistent location on a per-arch basis.
[14:19] <soren> smoser: Why do we not just change the default configuration then? That seems a whole lot safer than introducing new code?
[14:19] <ttx> mathiaz: I ran the tests
[14:19] <ttx> a 20091026 candidate is now up
[14:19] <smoser> soren, you can configure how many disks you get (and what size they are). i'm not sure if you can configure what partition they appear as
[14:19] <mathiaz> ttx: ok - I installed an i386 cloud on my two laptops on friday and it wasn't working at all
[14:19] <ttx> we should all know our part in that play now
[14:20] <smoser> which is the issue... well, actually on ec2 they're not a partition at all, on UEC they are (or vice versa, have to look)
[14:20] <mathiaz> ttx: I switched to amd64 and all was great
[14:20] <ttx> mathiaz: lets discuss that after the meeting
[14:20] <mathiaz> ttx: ok
[14:20] <smoser> anyway, the other thing on my plate is bug 458576 which has a fix ready to go
[14:20] <ubottu> Launchpad bug 458576 in ec2-init "ec2: ssh public key fingerprint in console output does not match EC2 standards" [Low,In progress] https://launchpad.net/bugs/458576
[14:20] <ttx> on the "Release Notes" side
[14:20] <ttx> We have the following bugs proposed:
[14:20] <ttx> https://bugs.launchpad.net/ubuntu-release-notes/+bug/459101
[14:20] <ubottu> Launchpad bug 459101 in eucalyptus "Relay denied from eucalyptus registration emails - source address is wrong." [Medium,Won't fix]
[14:20] <ttx> https://bugs.launchpad.net/ubuntu-release-notes/+bug/444352
[14:21] <ubottu> Launchpad bug 444352 in eucalyptus "DB deadlock on reboot prevents UEC from working, temporarily" [Low,Won't fix]
[14:21] <ttx> https://bugs.launchpad.net/ubuntu-release-notes/+bug/458163
[14:21] <ubottu> Launchpad bug 458163 in powernap "[regression] euca_rootwrap fixes affected eucalyptus power management (powerwake)" [High,Fix released]
[14:21] <ttx> kirkland: ^ that one is no longer needed, right ?
[14:21] <kirkland> ttx: correct
[14:21] <ttx> if you have other suggestions please let everyone know
[14:21] <kirkland> ttx: it appears that the powernap fix was accepted
[14:22] <kirkland> ttx: i tested that all weekend long
[14:22] <ttx> kirkland: could you invalidate the ubuntu-release-notes task on that bug ?
[14:22] <kirkland> ttx: with my UEC starting/stopping instances at random, putting my cloud hardware to sleep, and waking it up
[14:22] <kirkland> ttx: sure
[14:23] <ttx> anything else you think should be release notes material at this point ?
[14:23] <ttx> Any other thing we should take care before release ?
[14:24] <kirkland> ttx: hmm, i'll peruse the bugs, and mention to you in #ubuntu-server anything else UEC-related that I think is worth release-noting
[14:24] <ttx> kirkland: sounds good
[14:24] <ttx> In related news, we should take some time to help on https://launchpad.net/bugs/457767 where we can
[14:24] <ubottu> Launchpad bug 457767 in debian-installer "karmic: iSCSI root: boot hangs on starting iscsid" [High,Confirmed]
[14:25] <ttx> thanks to mathiaz for his analysis and reproduction recipes
[14:25] <mdz> pgraner has asked the kernel team to help with this, and update the bug
[14:25] <mdz> given it sounds like a kernel problem, it seems too late to fix
[14:25] <ttx> yes, it looks pretty low-level
[14:26] <mdz> ttx, so we need to update the documentation, right?
[14:26] <ttx> mdz: that'sthe fallback plan, yes
[14:26] <mdz> I've made a note to do a retrospective on it as well, to understand what went wrong and learn from it
[14:27] <mdz> ttx, anything else for 9.10?
[14:27] <ttx> n othing from me
[14:27] <mdz> anyone else?
[14:28] <mdz> ok
[14:28] <mdz> ttx, do you think we need to do the roadmap review, or shall we start talking about 10.04 instead?
[14:28] <ttx> talking about 10.04 sounds good
[14:29] <mdz> [topic] Progress on 9.10 roadmap
[14:29] <MootBot> New Topic:  Progress on 9.10 roadmap
[14:29] <mdz> I think the only outstanding item would be the image store, but it sounds like that is done now per mathiaz
[14:29] <mdz> soren is going to continue working on a persistent appliance, but that can trail 9.10 if necessary
[14:29] <mdz> [topic] Lucid Lynx
[14:29] <MootBot> New Topic:  Lucid Lynx
[14:30] <mdz> so we have received some requirements from Canonical stakeholders
[14:30] <mdz> and are expecting some more to come in yet
[14:30] <mdz> (they're late)
[14:31] <mdz> we're likely to have items in the same broad categories as 9.10: UEC, EC2, appliances, enterprise deployment items
[14:32] <mdz> but we will aim to focus on stabilization
[14:32] <mdz> and negotiate our commitments with regard to that
[14:32] <kirkland> mdz: is there anything that will fundamentally allow (force) us to focus on stabilization?
[14:32] <mdz> I also have a few notes here for small things which I think are worth looking at in a 10.04 context
[14:32] <ttx> there are also some cleanup tasks, i.e. try to get rid of things we don't want to do LTS support for
[14:32] <kirkland> mdz: as opposed to being hyper-feature driven?
[14:33] <mdz> kirkland, yes, we've got agreement on a general plan for LTS which includes that explicitly
[14:33] <mdz> signed off
[14:33] <mdz> so I'd like to hear from all of you what you're thinking about for 10.04
[14:33] <soren> Automatic testing.
[14:34] <soren> Lots and lots and lots of automated testing.
[14:34] <mathiaz> Automatic package testing
[14:34] <smoser> +1 on automatic testing (ec2 based)
[14:34] <zul> stablization/qa
[14:34] <mathiaz> More than lots and lots lots *and* *lots* of automated testing.
[14:34] <soren> I've got a bunch of things I'd like to improve in VMBuilder.
[14:34] <soren> mathiaz: Oh! /me concurs
[14:34] <zul> mathiaz: ditto
[14:34] <soren> mathiaz: I like your style.
[14:34] <ttx> Likewise 5.4 convergence, if that still falls on our plate
[14:34] <mdz> marjo and I have talked about this a bit
[14:35] <mdz> and we'll have some more QA resource to help with this
[14:35] <kirkland> reining in our bug lists, triaging, bugfixing, similar to the blitzes we made on eucalyptus in the last few weeks
[14:35] <smoser> there are 2 things that i'd like to investigate with regard to ec2: a.) making ec2 boot much more hookable, allowing user to completley take control via user-data.
[14:35] <kirkland> but attacking that (as a team) on some of our other critical server packages
[14:35] <mdz> smoser, we talked about seeing if we could eliminate the ramdisk on EC2
[14:35] <kirkland> with 2 or more people triaging bugs, reproducing, testing, and fixing
[14:35] <soren> mdz: The ramdisk? /dev/shm?
[14:35] <mdz> smoser, and I think we should provide a standard means to install updates at boot, along the lines of unattended-upgrades
[14:35] <mdz> soren, the initrd
[14:35] <smoser> b.) other cloud offerings (ie rackspace).
[14:36] <zul> i like to see some apport hooks for some server packages
[14:36] <soren> mdz: Ah, right.
[14:36] <mdz> kirkland, I think we should look at auto-registration of decentralized eucalyptus
[14:36] <soren> smoser: Big +1 on b)
[14:36] <mdz> e.g. auto-registering a walrus on a remote host
[14:36] <mdz> I think that should be reasonably contained in scope
[14:37] <kirkland> what about live migration?
[14:37] <kirkland> of vm's
[14:37] <soren> smoser: Also on the rackspace part. It's a small, nice, and clean API.
[14:37] <mdz> kirkland, that's dependent on upstream
[14:37] <smoser> mdz, regarding standard updates , i agree. regarding ramdisk... we can investigate it.  There are things I would like to do in the ramdisk (as part of 'a' above). i like ramdisks (i know that isn't popular opinion)
[14:37]  * soren likes ramdisks as well
[14:37] <mdz> smoser, no pressure, just a reminder that it's something we wanted to revisit. may or may not turn out to be the best course
[14:38] <mdz> we have some requirements around development and deployment of Java applications
[14:38] <smoser> soren, the issue with "multi-cloud" is just resources... trying to separate "generic cloud" from from "cloud specific", i only fear that it could result in less quality in UEC/ec2.
[14:38] <mathiaz> now that puppet is in main, I'd like to investigate better integration in the installer
[14:38] <mdz> much more concrete than what we've discussed in the past
[14:38] <mathiaz> and may be integration with UEC
[14:38] <mdz> mathiaz, ok
[14:38] <soren> mathiaz: puppet is in main?
[14:38] <mathiaz> soren: yes
[14:38] <soren> Wow. I didn't know.
[14:38] <mdz> (this is just a brainstorming session, please feel free to mention anything you're thinking about without worrying about whether it's doable or a good idea yet)
[14:38] <ttx> mdz: should we think about it and come up with a wikipage of 10.04 projects ?
[14:39] <mdz> ttx, yes, this is just to get the conversation started
[14:39] <soren> I'd like to spend a bit of time on OpenNebula again.
[14:39] <mathiaz> soren: this cyle - thanks to zul MIR work
[14:39] <mdz> ttx, maybe you could create that page and start organizing these ideas?
[14:39] <ttx> mdz: sure, action me
[14:39] <mdz> soren, that's worth looking at
[14:39] <soren> I think it's a shame it didn't get any attention at all this release. It's really a wonderful tool.
[14:39] <mdz> [action] ttx to create wiki page for 10.04 input from server team
[14:39] <MootBot> ACTION received:  ttx to create wiki page for 10.04 input from server team
[14:39] <soren> it also provides an implementation of the OCCI cloud API.
[14:39] <zul> soren: it did ;)
[14:39] <kirkland> mdz: i'd like to write a live-migrate-to-encrypted-home and recover-my-encrypted-home-from-a-live-cd pair of scripts; i have recipes in my blog; would be nice to get these into ecryptfs-utils and available on the LiveCD
[14:40]  * ttx wanted to properly package openvpn's easy-rsa (or provide another easy-pki option)
[14:40] <soren> zul: opennebula did?
[14:40] <soren> cobbler!
[14:40] <zul> soren: oh i thought you were talking about puppet,
[14:40] <soren> Well... It'd like cobbler in Ubuntu. I'm nt sure I want to work on it myself :)
[14:40] <zul> soren: I noticed that opennebula is on the motu ftbfs list
[14:40] <ttx> there is also lots of not-so-funny work to do on eucalyptus java dependencies, to clean them up *more*
[14:40]  * soren types very poorly today due to network lag :(
[14:40] <kirkland> mdz: i'm also planning on proposing yet again places where I think byobu would make a for some really nice branding and differentiation between Ubuntu and other linux servers
[14:40] <mathiaz> ttx: yes - an easy pki would be great
[14:41] <soren> zul: ah, thanks for pointing that out.
[14:41] <mdz> kirkland, ok, sounds good
[14:41] <ttx> mathiaz: at this point people are using easy-rsa from /usr/share/examples and its not working out of the box
[14:41] <kirkland> mdz: namely, in environments where running detached is the expectation (cloud VMs), and places where recovering from crashes would benefit from a screen session (the terminal on the Ubuntu desktop)
[14:41] <zul> mdz: calendaring has always been a big request from corporate users
[14:42]  * ttx wanted to integrate etckeeper more but tha's a lot of work
[14:42] <mathiaz> there is also some integration work to be done on the identity mgmt front - with openldap+krb5 integration
[14:42] <ttx> also might conflict with mathiaz's puppet efforts
[14:42] <mathiaz> ttx: well - not really - I can think of nice point of integration
[14:42] <mathiaz> ttx: put VCS in puppet+dpkg conffile+etckeeper
[14:43] <mdz> any ideas for the desktop or UNR?
[14:43] <zul> make likewise better?
[14:43] <kirkland> i think we should look at better ways of building and distributing vm appliances
[14:43] <mathiaz> mdz: there is the login experience - for corporate environement
[14:43] <kirkland> in contrast to the monolithic, stale, tarball approach
[14:44] <mathiaz> mdz: how does gdm scale with 10000 of users in a corporte environement
[14:44] <ttx> domain logging in gdm, yes
[14:44] <mdz> zul, it's on my list to establish some concrete user stories for likewise, i.e. decide what's most important for people to be able to do with it. then we'll know what to optimize for
[14:44] <mdz> mathiaz, ok
[14:44] <kirkland> i think it would be interesting to team with the Mobile guys and produce an Ubuntu Server ARM image
[14:44] <kirkland> as a subset of the UNR ARM work
[14:44]  * soren is still waiting for hardware for that
[14:44] <ttx> mdz: put a ubuntu desktop in a corporate AD environment and make it behave correctly (i.e. not force you to type MYAD\johndoe as the username)
[14:45] <soren> I want more stuff to Just Work.
[14:45] <ttx> soren +1
[14:45] <soren> Simple as that.
[14:45] <zul> i want things to suck less
[14:45] <ttx> I think a critical review of how things should work
[14:45] <soren> We ship a /lot/ of stuff with default configurations we don't expect anyone to use.
[14:45] <ttx> and try to reach that point
[14:45] <mdz> soren, for example?
[14:46] <soren> mdz: Mail server stack, for instance.
[14:46] <kirkland> pulse audio
[14:46] <mdz> kirkland, that's actually working great for me in 9.10
[14:46] <mdz> and for rickspencer3
[14:46] <kirkland> mdz: pulse audio + KVM
[14:46] <soren> mdz: They use /etc/passwd as their userdb by default, but for anything other than the smallest of installations, we expect people to use something else.
[14:46] <mdz> kirkland, ah
[14:46] <kirkland> mdz: pulse audio + KVM + libvirt
[14:47] <soren> ...instead, make them use something else by default and make sure it's as easy (or even easier) to use even for the people who don't need something big and fancy like an LDAP directory.
[14:47] <kirkland> mdz: i'm not sure yet where the bugs are, but they're somewhere in that complex stack
[14:47] <mdz> soren, like SASL?
[14:48] <soren> mdz: Yes, postfix should automatically speak sasl to dovecot.
[14:48] <mdz> does anyone have bugs in mind that they would especially like to plan to fix in lucid?
[14:48] <soren> and dovecot should use LDAP by default.
[14:48] <soren> bug #1?
[14:48] <ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
[14:48] <mathiaz> soren: and kerberos for authentication
[14:48] <soren> mathiaz: Quite probably, yes.
[14:49] <mathiaz> soren: with a nice user+group mgmt interface
[14:49] <mdz> soren, in 10.04 ;-)
[14:49] <soren> mdz: Hmm... right, point :)
[14:49] <soren> I've been ranting and raving about this for years, and got worked up again :)
[14:49] <zul> hehe
[14:50] <mdz> kirkland, should we try to do better than the 9.10 solution on euca_rootwrap?
[14:50] <soren> For 10.10, then. :)
[14:50] <kirkland> mdz: perhaps, using capabilities
[14:50]  * soren has not dared actually look at euca_rootwrap.
[14:50] <kirkland> mdz: although, the configurable rootwrap solution is pretty good
[14:50] <mdz> soren, linux is not so far off from windows in market share on the server ;-)
[14:51] <soren> I'm just trying to make my /own/ life easier. :)
[14:52] <soren> Hopefully, in doing so, I make everyone else's life easier as well and gain total world domination.
[14:52] <soren> Or something.
[14:52] <alexm> i guess that having VMs for HA would fall under the migration field, isn't it?
[14:52] <soren> I need to work out the details of that.
[14:52] <ttx> Braindump ground : https://wiki.ubuntu.com/ServerTeam/LucidIdeaPool
[14:53] <alexm> i.e. meaning that it also depends on upstream
[14:53] <mdz> ok, thanks for the input
[14:53] <mathiaz> soren: world domination? the devil is in the details ;)
[14:53] <mdz> please feel free to keep working on the wiki page as things come to mind
[14:53] <mdz> the assigned bug list is in OK shape, I've been reviewing it in our 1:1s
[14:53] <soren> mathiaz: Yeah, I'm assuming this will just sort of happen along the way somehow :)
[14:53] <mdz> [topic] weekly SRU review (mathiaz)
[14:53] <MootBot> New Topic:  weekly SRU review (mathiaz)
[14:54] <mathiaz> http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html
[14:54] <MootBot> LINK received:  http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html
[14:54] <mathiaz> any bugs worth looking at for an SRU ^^?
[14:55] <zul> bug 374537
[14:55] <ubottu> Launchpad bug 374537 in munin "Munin-node have a empty /etc/munin/plugins folder" [Undecided,Fix released] https://launchpad.net/bugs/374537
[14:55] <zul> thats it from me
[14:56] <mathiaz> zul: seems like worth for SRU
[14:56] <mathiaz> ttx: anything else?
[14:57] <mathiaz> the nomination lists for hardy/intrepid/jaunty/dapper are empty
[14:57] <ttx> mathiaz: nothing from me
[14:57] <mdz> ok
[14:57] <mdz> [topic] AOB
[14:57] <MootBot> New Topic:  AOB
[14:57] <mdz> anything else?
[14:57] <kirkland> the new time slot ...
[14:57] <ttx> I wanted to ask about TriageDays
[14:57] <ttx> is it going ok for everyone
[14:57] <mdz> does everyone have a 9.10 release party to go to?
[14:57] <zul> ttx: yap
[14:57] <soren> Nope.
[14:57] <ttx> mdz: no.
[14:58] <mdz> kirkland, this time slot is this week only; AIUI it's different from next week on
[14:58] <mathiaz> ttx: :(
[14:58] <zul> mdz: i was going to montreal but its not at a good time
[14:58] <kirkland> when this moves back to Wednesday, and the time changes, this hour is going to be bad for me, as it conflicts with my weekly marathon training run
[14:58] <mdz> ttx, oh dear
[14:58] <alexm> mdz: sure
[14:58] <mdz> I highly recommend lining up a release party...it's a good dose of positive vibes to start off the next cycle
[14:58] <soren> ttx: Uh... I honestly forgot about my TriageDay.
[14:58] <kirkland> http://blog.dustinkirkland.com/2009/10/austins-karmic-release-party.html
[14:58] <MootBot> LINK received:  http://blog.dustinkirkland.com/2009/10/austins-karmic-release-party.html
[14:58] <mathiaz> mdz: totally - and get free beer the whole night
[14:59] <mdz> mathiaz, well, not usually, but sometimes ;-)
[14:59] <alexm> http://wiki.ubuntu.com/CatalanTeam/KarmicKoala
[14:59] <ttx> soren: I know, I've been covering up for you
[14:59] <MootBot> LINK received:  http://wiki.ubuntu.com/CatalanTeam/KarmicKoala
[14:59] <soren> ttx: I guess thanks are in order. You must have picked up my slack the following day :)
[14:59] <soren> ttx: Good deal :)
[14:59] <mdz> ttx, soren, do we need to put some reminder system in place? perhaps google calendar?
[14:59] <smoser> i have release party and i can walk home.
[14:59] <mathiaz> ttx: triage day are working great IMO
[14:59] <mdz> smoser, nice one
[14:59] <mathiaz> zul: thanks for catching on the backlog
[14:59] <kirkland> mdz: so the timeslot on wednesday will be a problem for me, when it moves back to Wednesday, and Daylight Savings time comes
[14:59] <zul> mathiaz: np
[15:00] <mdz> kirkland, please speak to maria
[15:00] <kirkland> mdz: okay
[15:00] <soren> mdz: I've just added it to my calendar.
[15:00] <mathiaz> kirkland: I second you
[15:00] <mdz> we could create a server team calendar (if there isn't one already?) and add the triage days to it
[15:01] <soren> I don't think that would help much.
[15:01] <soren> If I get reminded about everyone else's triage days as well, I will begin ignoring reminders.
[15:01] <soren> I've added it to my own calendar.
[15:01] <mdz> soren, the way I do it is to add reminders (alarms)
[15:01] <mdz> so it is only for the things I need to be reminded about
[15:02] <mdz> but having them all on one calendar makes it easy to reschedule: just swap days with someone, and the reminders get updated
[15:02] <soren> mdz: I have reminders by default.. But I guess I don't for stuff from other calendars.
[15:02] <soren> You're right. Let's do that.
[15:02] <mdz> but anyway, sounds like this is good enough for now
[15:02] <mdz> soren, oh, wow
[15:02] <mdz> ok, we're out of time
[15:02] <mdz> thanks, all
[15:02] <mdz> #endmeeting