Ubuntu Wiki

Agenda

Items we will be discussing:

• Review ACTION points from previous meeting.

• Review progress made on the specification listed on the Roadmap.

• Discuss packages that require kernel modules of the same version as userland tools - ivoks
• Open Discussion.
• Agree on next meeting date and time.

Minutes

Agree on next meeting date and time

Next meeting will be on Tuesday, April 14th at 15:00 UTC in #ubuntu-meeting.

Log

[16:07] <mathiaz> #startmeeting
[16:07] <MootBot> Meeting started at 10:07. The chair is mathiaz.
[16:07] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:07] <ttx> o/
[16:07] <sommer> yo
[16:07] <mathiaz> Today's exciting agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[16:07] <mathiaz> Last week minutes:
[16:07] <mathiaz> https://wiki.ubuntu.com/MeetingLogs/Server/20090609
[16:08] <mathiaz> [TOPIC] Merges
[16:08] <MootBot> New Topic:  Merges
[16:08] <mathiaz> so I've updated the list of easy-merges for the ubuntu-server team
[16:08] <mathiaz> it's on the Roadmap
[16:08] <mathiaz> Have people found this list useful?
[16:08] <ivoks> iirc, amavisd-new is on that list
[16:09] <mathiaz> ivoks: yes
[16:09] <ivoks> merge diff for it was reported before uds
[16:09] <mathiaz> ivoks: bug number?
[16:09] <ivoks> a sec
[16:09] <ivoks> bug #379979
[16:09] <ubottu> Launchpad bug 379979 in amavisd-new "Please merge amavisd-new (1:2.6.3-3) from debian unstable(main)" [Undecided,Confirmed] https://launchpad.net/bugs/379979
[16:10]  * ivoks hides :)
[16:10] <dholbach> there's a few server related packages on here: http://people.ubuntu.com/~dholbach/sponsoring/
[16:10] <dholbach> might be worth checking that before doing a merge :-)
[16:11] <mathiaz> ivoks: ok - I've updated the wiki page
[16:11] <mathiaz> ivoks: to list the bug number
[16:11] <mathiaz> dholbach: hm - I have to check this list too
[16:12] <mathiaz> dholbach: is there a way to filter by packages?
[16:12] <dholbach> mathiaz: I'm afraid, not yet, no
[16:12] <mathiaz> dholbach: hm ok.
[16:12] <dholbach> but we need to get the list down to 0 anyway, which would help with scanning it
[16:13] <mathiaz> dholbach: right - the list isn't too long so I don't think filtering is necessary for now
[16:13] <dholbach> rock on!
[16:13] <dholbach> mathiaz: please poke all server people about it :-)
[16:13] <mathiaz> dholbach: but when any lists gets too long finding filters to narrow it down helps a lot
[16:13]  * dholbach shuts up now
[16:13] <ivoks> i'll look at universe packages
[16:14] <mathiaz> ivoks: awesome. Thansk.
[16:15] <mathiaz> The list of merges has slightly shrunk from last week
[16:15] <mathiaz> However there is still a long list of packages waiting to be merged in karmic.
[16:15] <mathiaz> Merge-O-Matic is there to help out: https://merges.ubuntu.com
[16:16] <mathiaz> Any questions related to merges?
[16:16] <mathiaz> [TOPIC] Heartbeat 2.99 in Karmic
[16:16] <MootBot> New Topic:  Heartbeat 2.99 in Karmic
[16:17] <mathiaz> RoAkSoAx isn't around
[16:17] <ivoks> i'm reading the log...
[16:17] <mathiaz> ivoks: any insight on the ACTIONS from last week?
[16:17] <ivoks> yeah... well, heartbeat 2.99 just shares the name with previous versions of heartbeat
[16:17] <mathiaz> I haven't seen a call for testing for heartbeat related packages in his PPA
[16:18] <ivoks> they are almost completly different things
[16:18] <ivoks> heartbeat 2.99 doesn't work as a standalone app
[16:18] <ivoks> it's being utilized by pacemaker
[16:18] <ivoks> and ubuntu-ha decided that pacemaker-openais is the way to go
[16:18] <mathiaz> ivoks: right.
[16:18] <ivoks> still, -heartbeat version of pacemaker will be provided in universe
[16:18] <ivoks> without any support
[16:18] <mathiaz> ivoks: is this the same solution as the one adopted by debian?
[16:19] <ivoks> since heartbeat is dead project
[16:19] <ivoks> mathiaz: yes, i contact debian devs daily
[16:19] <ivoks> and one of them is member of ubuntu-ha
[16:19] <mathiaz> ivoks: great - how is their testing in experimental going?
[16:19] <ivoks> some upstream people are also members of ubuntu-ha
[16:20] <ivoks> they are doing new packages of openais
[16:20] <ivoks> and corosync and, we are helping with packaging
[16:21] <ivoks> we've been supplied with debian/ dirs from upstream
[16:21] <mathiaz> ivoks: ok - so the plan is to replace heartbeat with openais+corosync+pacemaker?
[16:21] <ivoks> mathiaz: no, it's very complicated :)
[16:21] <ivoks> mathiaz: at the moment corosync and openais aren't API stable
[16:22] <zul> is ubuntu-ha going to be supporting rhcs as well?
[16:22] <ivoks> so, redhat cluster suite 3.0rcX depends on corosync and openais with the same timestamp
[16:22] <mathiaz> ivoks: is there a wiki page to outline the problem and the proposed solution?
[16:22] <ivoks> zul: plan is to degrade rhcs to universe
[16:22] <zul> ivoks: excelent
[16:23] <ivoks> mathiaz: i've sent an email to ubuntu-ha mailing list, but i could do a wiki page with some clearification
[16:23] <ivoks> but, the point is...
[16:23] <ivoks> corosync and openais should get 1.0 release in next 2 weeks
[16:23] <nijaba> ivoks: and upgrade pacemaker and friend to main?
[16:23] <ivoks> then pacemaker will be ported to those versions
[16:23] <ivoks> nijaba: yes
[16:23] <nijaba> ivoks: way cool, thanks
[16:24] <ivoks> linux cluster stack became joint effort of all distros and vendors
[16:24] <mathiaz> ivoks: ok - does this mean everything should be ready by FeatureFreeze?
[16:24] <ivoks> mathiaz: it depends on upstream
[16:24] <mathiaz> ivoks: which is end of august
[16:25] <ivoks> i would suggest keeping rhcs in main and in good shape untils pacemaker gets compiled with corosync/openais 1.0
[16:25] <ivoks> then do the switch
[16:25] <mathiaz> ivoks: ok - so if you could write up a short wiki page with the different issues
[16:25] <ivoks> basicaly, atm ubuntu-ha needs to suport both platforms
[16:25] <mathiaz> ivoks: so that we know we are and where we're heading at
[16:25] <ivoks> sure
[16:26] <mathiaz> ivoks: it doesn't need to be a full blown spec
[16:26] <ivoks> i know, but spec should clearify this
[16:26] <ivoks> https://wiki.ubuntu.com/ClusterStack
[16:26] <mathiaz> ivoks: just a list of packages that should be moved to main, an small overview of the new architecture, and what are the blocker for now
[16:27] <mathiaz> ivoks: great that's a good start
[16:28] <mathiaz> anything else related to the Cluster stack and HA?
[16:28] <ivoks> testing packages are on ubuntu-ha ppa :)
[16:29] <zul> ivoks: does heartbeat need to be updated in the kernel again?
[16:29] <ivoks> zul: kernel? no
[16:29] <ivoks> forget heartbeat
[16:29] <ivoks> it's dead
[16:29] <zul> ivoks: okies
[16:29] <mathiaz> ok - let's move on then
[16:30] <mathiaz> ivoks: thanks for taking care of the cluster stack in Ubuntu and cooperating with the rest of the distros
[16:30] <ttx> ivoks: if you forget your heartbeat, you may become dead as well.
[16:30] <mathiaz> That's all I had from last week meetings
[16:31] <mathiaz> anything else to add related to last week discussions?
=== jdo_ is now known as jdobrien
[16:31] <mathiaz> nope - let's move on then
[16:32] <mathiaz> [TOPIC] kernel modules and userspace tools synchronisation
[16:32] <MootBot> New Topic:  kernel modules and userspace tools synchronisation
[16:32] <ivoks> right...
[16:32] <mathiaz> ivoks: are you talking about drbd and iscsi?
[16:32] <ivoks> kvm, everything...
[16:32] <ivoks> providing new version of drbd, for example, is hard
[16:32] <ivoks> cause we have to upload new kernel
[16:33] <ivoks> i was thinking about dkms
[16:33] <ivoks> would it be a problem to utilize dkms as a default way for those kind of things?
[16:33] <mathiaz> kirkland: what's your take on that?
[16:33] <ivoks> in case of drbd, it would help a lot since i would have to sync drbd source in kernel and in userspace tools
[16:33] <zul> ivoks: dkms probably wouldnt be a problem for drbd
[16:34] <mathiaz> kirkland: I know you've used dkms for kvm to provide a backport to hardy
[16:34] <mathiaz> ivoks: how hard is it now to get a new version of drbd in the kernel?
[16:34] <ivoks> we have to upload new kernel
[16:34] <ivoks> and new userspace at the same time
[16:35] <ivoks> probably the same as kvm
[16:35] <mathiaz> ivoks: also IIRC drbd will be included into the mainline kernel soon
[16:35] <ivoks> well, 'soon' :)
[16:35] <ivoks> i don't expect it to be there before 10.04
[16:35] <mathiaz> ivoks: is the issue that the transition needs to be tracked
[16:36] <ivoks> transition?
[16:36] <mathiaz> ivoks: or that sometimes the kernel team updates the drbd module and that userspace is broken
[16:36] <ivoks> that happens too, but only during development
[16:36] <mathiaz> ivoks: well - by transition I mean that both kernel and userspace have to be in sync
[16:36] <ivoks> it would like to provide ppa for drbd
[16:36] <ivoks> where users would get newer versions of drbd
[16:36] <ivoks> wich otherwise wouldn't get into -updates
[16:37] <mathiaz> ivoks: that's a good plan - but we also need to take care of the stable release
[16:37] <mathiaz> ivoks: the primary goal is to get a version of drbd that works in stable releases
[16:37] <ivoks> of course
[16:37] <ivoks> but SRU won't be accepted
[16:37] <mathiaz> ivoks: PPA can be a good options for backports ( kirkland does something similar with kvm)
[16:37] <ivoks> cause new drbds bring only new functionality
[16:38] <mathiaz> ivoks: right - so a PPA seems a good option
[16:38] <ivoks> but, let's look fruther than drbd
[16:38] <ivoks> that's just an example
[16:38] <mathiaz> ivoks: right - kvm doesn't really fall in the same category IIRC
[16:39] <mathiaz> ivoks: as there isn't such a strong dependency between kernel and userspace
[16:39] <mathiaz> ivoks: the other module that I know of is open-iscsi
[16:39] <mathiaz> ivoks: apparmor is also similar
[16:40] <ivoks> well, is apparmor a module or built-in?
[16:40] <mathiaz> ivoks: it's build-in now
[16:40] <ivoks> built-in
[16:40] <mathiaz> ivoks: but there is version dependency on the parser
[16:40] <mathiaz> ivoks: IIRC you can use an old parser to load profile into a new kernel
[16:41] <mathiaz> ivoks: this is where things tend to break in open-iscsi and drbd too
[16:41] <ivoks> well, my concern is drbd
[16:41] <mathiaz> ivoks: right
[16:41] <ivoks> i think we could get more out of it
[16:41] <mathiaz> ivoks: so what's the current process to update drbd in the development release?
[16:42] <mathiaz> ivoks: send a git pull to the kernel team
[16:42] <mathiaz> ivoks: 1. send a git pull to the kernel team
[16:42] <mathiaz> ivoks: 2. wait for the new kernel to be uploaded
[16:42] <ivoks> as it turns out, they pull it automaticaly
[16:42] <ivoks> so, i never send them a patch
[16:42] <ivoks> they just do it
[16:42] <mathiaz> ivoks: 3. then upload the matching userspace version
[16:42] <ivoks> and then we keep up with userspace
[16:42] <ivoks> right
[16:43] <mathiaz> ivoks: how do you keep up with userspace? manually?
[16:43] <ivoks> yes
[16:43] <mathiaz> ivoks: just by change you happen to notice there is a new drbd module?
[16:43] <mathiaz> ivoks: just by chance you happen to notice there is a new drbd module?
[16:43] <ivoks> i look from time to time what's in kernel
[16:43] <ivoks> and atm there's the latest version
[16:43] <mathiaz> ivoks: that drbd is broken *again* and you upload a new userspace version
[16:43] <ivoks> i also know when drbd releases new version
[16:44] <ivoks> mathiaz: that never happened
[16:44] <ivoks> drbd has slow release cycle
[16:44] <ivoks> mostly kernel team does the inital pull
[16:44] <ivoks> and then i send patches for newer version, if any
[16:45] <ivoks> wait for new kernel, and then rebuild userspace
[16:45] <mathiaz> ivoks: ok - so is there any improvement that could be made for handling drbd in the development release?
[16:45] <ivoks> dkms :)
[16:45] <mathiaz> ivoks: or is wait for new kernel, rebuild userspace a good enough process?
[16:45] <ivoks> dkms would make me happier man; i would have to look only on one file in kernel git
[16:45] <mathiaz> ivoks: with dkms you'd have control over the kernel module *and* the userspace at the same time
[16:46] <ivoks> yes
[16:46] <mathiaz> ivoks: right - I understand the advantage of dkms for backports
[16:46] <mathiaz> ivoks: I'm trying to figure out whether it would be usefull to handle stable releases as well
[16:46] <ivoks> well, desktop already does it
[16:47] <ivoks> for ati/nvidia stuff, iirc
[16:47] <mathiaz> ivoks: right - so it seems that it could be a good option
[16:47] <mathiaz> ivoks: the next step would be to talk to the kernel team
[16:47] <ivoks> kvm-source in jaunty depends on dkms
[16:47] <ivoks> of course
[16:47] <mathiaz> ivoks: and ask them what they think about it
[16:47] <ivoks> i planed to send an email to -server and -kernel
[16:47] <ivoks> but it was better to discuss it here first
[16:48] <mathiaz> ivoks: you may also talk to kirkland to see how he built the dkms version of kvm for hardy
[16:48] <mathiaz> ivoks: great.
[16:48] <kirkland> mathiaz: sorry, stepped away, back now
[16:48] <mathiaz> [ACTION] ivoks to send an email to -server and -kernel about turning drbd into a dkms based module
[16:48] <MootBot> ACTION received:  ivoks to send an email to -server and -kernel about turning drbd into a dkms based module
[16:49] <mathiaz> kirkland: that's ok - I think that ivoks would like to talk to you later
[16:49] <kirkland> mathiaz: ivoks: cool
[16:49] <mathiaz> kirkland: about dkms and kvm
[16:50] <mathiaz> let's move on if there is nothing else to this topic (drbd)
[16:50] <mathiaz> [TOPIC] Open discussion
[16:50] <MootBot> New Topic:  Open discussion
[16:50] <mathiaz> Anything else to add?
[16:52] <ivoks> anyone interested in hadoop packaging? :)
[16:52] <ttx> ivoks: :)
[16:53] <ttx> ivoks: I can tell soren is interested in having it packaged, but that doesn't really help you.
[16:53] <ivoks> hehehe
[16:53] <ivoks> i got couple of emails that people are interested... why does everybody looks at me first? :)
=== MaWaLe is now known as MosquitoOo
[16:53] <ivoks> bed inglish
[16:54] <sommer> cause you only have one shoe on? :)
[16:54] <mathiaz> ivoks: are there some packages already? is there an ITP for it?
[16:54] <ivoks> http://cloudera.com/hadoop-deb
[16:54] <MootBot> LINK received:  http://cloudera.com/hadoop-deb
[16:55] <mathiaz> ivoks: so these packages could be a starting point
[16:55] <ivoks> i haven't looked at them
[16:55] <ivoks> so i would say 'big maybe'
[16:55] <mathiaz> ivoks: has someone tried to build them on karmic and pushed them to a PPA
[16:55] <mathiaz> ivoks: ?
[16:56] <ivoks> mathiaz: all hadoop packages i've seen were binary files, no source
[16:56] <ivoks> maybe these aren't...
[16:56] <mathiaz> ivoks: oh well - that doesn't help at all then
[16:56] <ttx> mathiaz: and they might be FHS-adverse as well
[16:56] <ivoks> but i won't judge anyone, until i look at them
[16:57] <ivoks> ttx: well, looking at the link
[16:57] <ttx> ivoks: I'll have a look at them, maybe tomorrow
[16:57] <ivoks> Hadoop wrapper script                  /usr/bin/hadoop
[16:57] <ivoks>  Hadoop Jar and Library Files           /usr/lib/hadoop
[16:57] <ivoks> ttx: great
[16:57] <ivoks> it's a cloud thing, you guys should be interested in that :D
[16:57] <ttx> :P
[16:58] <ttx> It's prio 1 on my CrackOfTheDay list
[16:58] <mathiaz> [ACTION] ttx to look at cloudera hadoop debian packages
[16:58] <MootBot> ACTION received:  ttx to look at cloudera hadoop debian packages
[16:58] <ttx> argh :)
[16:58] <ivoks> ttx: hahaha nailed
[16:58] <mathiaz> let's move on and wrap up
[16:58] <mathiaz> [TOPIC] Agree on next meeting date and time
[16:58] <MootBot> New Topic:  Agree on next meeting date and time
[16:58] <mathiaz> next week, same place, same time?
[16:59] <ivoks> sure
[16:59] <ttx> wfm
[17:00] <sommer> :)
[17:00] <mathiaz> awesome then
[17:00] <mathiaz> thanks for attending and see you all
[17:00] <mathiaz> same time, same place, next week
[17:00] <mathiaz> #endmeeting
[17:00] <MootBot> Meeting finished at 11:00.