Ubuntu Wiki

Agenda

Items we will be discussing:

• Review ACTION points from previous meeting.

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

• Open Discussion.
• Agree on next meeting date and time.

Minutes

KVM backport in hardy

kirkland asked for some assistance testing a kvm-84 package that he prepared for hardy. It's available in ubuntu-virt PPA. The goal is to prepare an SRU for hardy. There was some discussions about the best way to conduct testing as the new version contains security fixes. It was suggested to go through the following workflow: ~ubuntu-virt PPA -> hardy-backports -> hardy-{proposed|security} -> hardy-updates.

ACTION: kirkland to write a blog post asking for testing of kvm 84 backport to hardy with specific instructions on how-to setup kvm 84 from the ubuntu-virt PPA

likewise-open 5 in jaunty

ttx reported that a FF Exception had been granted to likewise-open-5 and he had uploaded the package. He added that this was a new separate package from the likewise-open 4.1 packages as the upgrade from 4.1 to 5.0 required to leave the domain and rejoin it. So Likewise Open 5 will coexist with Likewise Open 4.1 in Jaunty. For the Karmic cycle we'll work with upstream to propose a seamless upgrade for all users to the latest version and phase out 4.1. There was some discussion about the best way to document that behavior: the Ubuntu Server Guide and the Debian.News file seemed to be the most appropriate locations.

screen-profiles by default

kirkland brought up the question of installing screen-profiles by default on EC2 instances and thus running screen by default when logging into an EC2 system. zul, soren and ehammond1 already discussed it and were against. There were some concerns about overlapping key bindings. The discussion was deferred to the next release cycle.

Agree on next meeting date and time

Next meeting will be on Tuesday, March 24th at 15:00 UTC in #ubuntu-server.

Log

[15:05] <mathiaz> #startmeeting
[15:05] <nealmcb> Agenda: https://wiki.ubuntu.com/ServerTeam/Meeting
[15:06] <mathiaz> nealmcb: thanks!
[15:06] <ScottK> Oh.  I guess I won't miss the meeting then.
[15:06] <nealmcb> :)
[15:06] <mathiaz> Last week minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20090310
[15:06] <kirkland> o/
[15:07] <ScottK> o-
[15:07] <mathiaz> I don't seen any specific items from last week
[15:08] <mathiaz> anyone has anything to add regarding topics discussed last week
[15:08] <mathiaz> ?
[15:08] <zoopster> Documentation for Eucalyptus in Ubuntu
[15:08] <kirkland> mathiaz: we delayed the screen-profiles talk until zul got back
[15:08] <mathiaz> kirkland: ok - I'll add to today's agenda
[15:09] <ttx> mathiaz: I would like to talk about likewise-open5
[15:09] <kirkland> mathiaz: i'd also like to discuss testing kvm-84 in hardy
[15:09] <zul> hi
=== scfh_ is now known as scfh
[15:09] <mathiaz> ttx: ok
[15:09] <mathiaz> kirkland: ok
[15:09] <ttx> so as an item from last week or an item for this week, your choice :)
[15:10] <mathiaz> [TOPIC] KVM backport in hardy
[15:10] <mathiaz> kirkland: ^^ ?
[15:10] <kirkland> mathiaz: i'd like to ask for some assistance testing a kvm-84 package that i've prepared for hardy
[15:10] <kirkland> mathiaz: its available in a PPA at https://edge.launchpad.net/~ubuntu-virt/+archive/ppa
[15:10] <kirkland> mathiaz: here's the basic premise ...
[15:11] <kirkland> mathiaz: hardy shipped with kvm-62
[15:11] <ScottK> kirkland: When you have a tested backport and you need it approved, feel free to ping me.
[15:11] <kirkland> ScottK: understood, thanks.
[15:11] <kirkland> ScottK: kvm is such an important package, i'm asking for a bit more extensive testing that what i can do alone
[15:12] <kirkland> also, we're talking about more than just applying a couple of bug fixes...
[15:12] <kirkland> we're talking about taking hardy's kvm from kvm-62 to kvm-84
[15:12] <kirkland> there's both a kernel piece, and a userspace element
[15:12] <ScottK> kirkland: +1 for lots of testing.
[15:12] <mathiaz> kirkland: ie the goal is to prepare an SRU for kvm in hardy?
[15:13] <zul> just a quesiton how are you going to backport the virtio stuff in the hardy kernel for kvm
[15:13] <kirkland> these can be upgraded independently, though I'm suggesting we backport both
[15:13] <kirkland> mathiaz: yes, SRU which actually provides a major version bump
[15:13] <kirkland> zul: kvm-source provides the kernel space bits
[15:13] <ScottK> Ah.  If it's SRU, then not mine to approve.
[15:14] <kirkland> zul: that package is a dkms-built kernel module
[15:14] <kirkland> i'm getting sidetracked here ....
[15:14] <zul> kirkland: heh ill talk to you about it after
[15:14] <kirkland> so the key points are that we believe that kvm-62 has become unsupportable
[15:14] <kirkland> there are a number of design flaws in that version of kvm that are fixed later versions
=== hessml|away is now known as hessml|away|away
[15:15] <kirkland> as such, these are major architectural changes that cannot be fixed with backported patches
[15:15] <kirkland> this information comes directly from the upstream maintainers
[15:16] <kirkland> so i propose that we either need to compose a lengthy list of 'won't fix' and 'can't do' items for hardy's kvm
[15:16] <kirkland> (such as SMP guests)
[15:16] <kirkland> or consider a major version bump
[15:17] <kirkland> i know that at least myself and mathiaz are running kvm-84 under hardy
[15:17] <kirkland> both kernel and userspace bits, right mathiaz ?
[15:17] <kirkland> (i'm running both)
[15:17] <mathiaz> kirkland: yes
[15:17] <zul> thats fine with me but if you do consider a major version bump then you will want to get the kernel team involved and get their opinon as well
[15:17] <kirkland> so there is some basic, measurable amount of success
[15:17] <kirkland> zul: absolutely, agreed.
[15:17] <kirkland> zul: or, we need to recommend that people use kvm-source for their kvm kernel module
[15:18] <kirkland> mathiaz: that's basically all....
[15:18] <zul> the virtio stuff that hardy has already concerns me a bit though
[15:18] <kirkland> mathiaz: i'll compose a blog post, asking for testing of those packages
[15:18] <kirkland> mathiaz: i'm quite hoping that some -server team members can do some early testing too
[15:18] <mathiaz> kirkland: ok - so the first step is to get more testing done from the ubuntu-virt PPA
[15:19] <sommer> kirkland: I can help test... is there a wiki page listing what to test?
[15:19] <mathiaz> kirkland: +1 on the blog post
[15:19] <kirkland> mathiaz: yes, i plan to start the SRU procedures when Jaunty hits beta
[15:19] <mathiaz> kirkland: as sommer mentionned documentation is very important too
[15:19] <kirkland> mathiaz: right
[15:19] <kirkland> sommer: i'll put those together in the blog post
[15:19] <mathiaz> kirkland: especially on how to setup the new kvm from the ubuntu-virt PPA
[15:20] <kirkland> mathiaz: okay
[15:20] <mathiaz> kirkland: I don't think we can really outline what to test (ie test multiple configuration etc...)
[15:20] <mathiaz> kirkland: but focus on how to install the new version of kvm
[15:20] <kirkland> mathiaz: well, right, that's part of the reason i can't do it all myself
[15:20] <kirkland> mathiaz: there are some crazy ways people use kvm and virtualization
[15:20] <kirkland> mathiaz: that i have not considered
[15:21] <mathiaz> kirkland: agreed.
[15:21] <kirkland> mathiaz: EOF
[15:21] <mathiaz> [ACTION] kirkland to write a blog post asking for testing of kvm 84 backport to hardy with specific instructions on how-to setup kvm 84 from the ubuntu-virt PPA
[15:22] <mathiaz> kirkland: thanks for the update.
[15:22] <mathiaz> anything else to add for kvm 84 on hardy?
[15:22] <mathiaz> I'm running it and it's faster
[15:22] <sommer> how does the kvm update affect the other tools, like libvirt?
[15:23] <kirkland> sommer: unknown
[15:23] <kirkland> sommer: unknown by me, at least
[15:23] <kirkland> sommer: i'm using kvm from command line,  i think mathiaz  is using virsh (which uses libvirt)
[15:23] <ScottK> I would appreciate it if we'd be clear about is this a backport or an SRU.  They land in different repos and have different approval mechanisms.
[15:24] <mathiaz> right - I'm using libvirt to manage all of my vms
[15:24] <kirkland> ScottK: there are actually 3 approaches on the table
[15:24] <ScottK> Using the terms interchangably is a recipe for confusion (mine if  no one elses).  OK
[15:24] <sommer> kirkland: gotcha, I can help test libvirt and such
[15:24] <kirkland> ScottK: the security team also want to fix a stack of CVE's
[15:24] <mathiaz> ScottK: the goal is an SRU.
[15:24] <kirkland> ScottK: which are all fixed in kvm-84
[15:24] <kirkland> ScottK: i need to evaluate the best place to land this
[15:24] <ScottK> kirkland: With clamav major updates I've put them in -backports first for extensive testing and then later -security/-updates
[15:25] <kirkland> ScottK: my original thinking was -backports, but the more we discussed this, -updates started to make more sense
[15:25] <kirkland> ScottK: as of yesterday, the security team was asking me to fix some CVE's
[15:25] <ScottK> You might start with -backports and then migrate.  It's worked well for the clamav migrations (which are pretty intrusive).
[15:25] <kirkland> ScottK: before i spent any effort trying to isolate and cherry pick fixes, i mentioned that i'm already investigating the possibility of an sru and/or a backport
[15:25] <mathiaz> kirkland: may be using the following approach would make sense: ubuntu-virt PPA -> hardy-backports -> hardy-updates?
[15:26] <kirkland> ScottK: mathiaz: i agree with that approach
[15:26] <kirkland> ScottK: mathiaz: what about -proposed?
[15:26] <kirkland> backports -> proposed -> updates ?
[15:26] <ScottK> mathiaz: Actually if there's CVEs fixed you want to go -backports ->-security ->-updates.
[15:26] <mathiaz> kirkland: it will go to -proposed before -updates
[15:26] <kirkland> ScottK: there are cve's
[15:26] <mathiaz> kirkland: -proposed is always part of the SRU process.
[15:27] <ScottK> -security to -updates is normal.
[15:27] <kirkland> backports -> security -> proposed -> updates ?
[15:27] <ScottK> kirkland: If it goes to security it'll go straight to updates from there.
[15:27] <mathiaz> kirkland: no - backports -> security -> updates
[15:27] <kirkland> ok
[15:27] <ScottK> that's normal for all security fixes.
[15:27] <mathiaz> kirkland: or backports -> proposed -> updates
[15:27] <ScottK> mathiaz: But if you're fixing CVEs this way you can't leave -security out.
[15:28] <kirkland> ScottK: well, my goal was to affect the fewest people first, more later
[15:28] <ScottK> Having CVEs fixed in -updates that aren't fixed in -security would run counter to how things normally work.
[15:28] <jdstrand> ftr, kirkland knows this already, but if it is destined for -security, please build without -update (or -backports)
[15:29] <ScottK> You might go -proposed to -security and -updates at the same time, but IME enough people run backports that's a sufficient testing ground.
[15:29] <kirkland> jdstrand: done!  in the latest https://edge.launchpad.net/~ubuntu-virt/+archive/ppa
[15:29] <mathiaz> ok - let's move on
[15:29] <kirkland> ScottK: mathiaz: thanks for the info
[15:29] <mathiaz> kirkland: I think the next step is defined (blog post)
[15:30] <mathiaz> kirkland: we'll discuss later whether it should go trough security or proposed
[15:30] <kirkland> mathiaz: okay
[15:30] <mathiaz> kirkland: thanks for the update on this topic.
[15:30] <mathiaz> [TOPIC] likewise-open 5 in jaunty
[15:30] <mathiaz> ttx: ^^?
[15:30] <ttx> yes, an Ffe has been granted to get likewise-open5 in Jaunty (thanks, ScottK !). I just uploaded the package and it's in the NEW queue right now
[15:31] <ScottK> Ah.  Good.
[15:31] <ttx> This is a separate package because the upgrade requires you to leave and rejoin the domain, which we consider unacceptable for our current likewise 4.1 users (or at least not our choice to make).
[15:31]  * ScottK was wondering.  Did you set the bug to fix committed?
[15:31] <ttx> I was about to. uploading can be long with sucky bandwidth.
[15:31] <ttx> So Likewise Open 5 will coexist with Likewise Open 4.1 in Jaunty.
[15:31] <ttx> For the Karmic cycle we'll work with upstream to propose a seamless upgrade for all users to the latest version, and phase out 4.1
[15:32] <ttx> We'll also make sure they work with pristine krb5 1.7 libraries to avoid maintaining a separate GSSAPI implementation there.
[15:33] <ttx> so as soon as it lands, please test it, given the late upload we'll not have much time for this.
[15:33] <ttx> From my testing it works better than 4.1... but I clearly didn't test all scenarios
[15:34] <ttx> since I don't have such a wide array of AD domains to test against.
[15:34] <ttx> eof
[15:34]  * ScottK considers the Server Guide ought to answer the question "Which do I use?"
[15:34] <ttx> yes, I was planning to discuss that with sommer
[15:35] <ScottK> Excellent.
[15:35] <ttx> I also have a couple of likewise-open bugs that are fixed in likewise-open5
[15:35] <mathiaz> ttx: what happens if you have a system with 4.1 installed and you install 5?
[15:35] <ttx> it removes likewise-open (resulting in domain leave) and installs 5
[15:35] <sommer> ttx: sure just ping me
[15:36] <ttx> mathiaz: it just won't happen automatically by upgrading to Jaunty. Losing domain membership in the upgrade is not really acceptable
[15:37] <mathiaz> ttx: ok - and joining the domain is not done during postinst?
[15:37] <ttx> mathiaz: you need the windows AD admin password to join.
[15:37] <ttx> which in most use cases the local admin won't have
[15:37] <sLaeYa> is there a way to restore your server to the initial install without reinstalling it ?
[15:38] <ttx> so no, it's not done in postinst.
[15:38] <mathiaz> ttx: ok.
[15:39] <mathiaz> ttx: I'm wondering if we should print a message to explain that the machine has been removed from the domain and should be rejoined (in the use case of 4.1 -> 5 upgrade)
[15:39] <mathiaz> ttx: doing this *pseudo* upgrade would leave the system unusable and providing as many hints as possible would be good
[15:39] <ttx> There is a message printed when the domain is left (when likewise-open is removed)... but that could appear more clearly.
[15:39] <ScottK> mathiaz: It should probably go in a Debian.NEWS for the package.
[15:40] <ttx> mathiaz, ScottK: noted.
[15:41] <mathiaz> ttx: and probably in the release notes
[15:42] <ttx> mathiaz: I'm not sure. Installing likewise-open5 is up to the user, it won't influence an existing setup just by upgrading
[15:43] <[HU]gnanet> Hi, i have a problem with my production system running ubuntu hardy: I run 3 xen servers where i have one hardy guest for mysql and one hardy guest for apache-php-lighttpd-squid. The webserver farm gets its data from a ocfs2 partition. My webserver guests are dying with kernel page faults, i heard of a kernel problem with the hardy xen kernel, so i thought of changing kernels, but the Intrepid kernel has OCFS2 1.5.0 modules, the hardy 1.3.3, an
[15:43] <ttx> so I wouldn't say it's release notes material.
[15:43] <ttx> not something you need to know before/after upgrading to Jaunty.
[15:43] <mathiaz> ttx: right
[15:43] <ttx> it's something you need to know if you plan to install that particular package.
[15:43] <mathiaz> ttx: the point here is that we need to get the word out
[15:44] <ttx> so Server Guide, Debian.NEWS...
[15:44] <mathiaz> ttx: but I agree that the release notes may not be the best place
[15:44] <nealmcb> it could go in the package description
[15:44] <ScottK> nealmcb: I think that's overkill.
[15:44] <mathiaz> ttx: what about a message in likewise-open 5 preinst?
[15:44]  * ttx agrees with ScottK
[15:45] <mathiaz> ttx: you should be able to detect wether 4.1 is around and get a message to the user
[15:45] <ScottK> mathiaz: When will that get seen that NEWS wouldn't?
[15:46] <ttx> I'm not sure that would increase visibility that much. Someone installing a new package should be ready for some change anyway.
[15:46] <mathiaz> hm - ok.
[15:46] <ttx> He needs to know he has to (re)join  the domain after install... but too much warning in advance might not be necessary
[15:47] <ttx> it's the same things he needs to do after installing likewise-open in the first place
[15:47] <mathiaz> ok - let's move on. It seems that we've identified places where the warning message should be put.
[15:47] <ttx> yes.
[15:47] <mathiaz> ttx: anything else to add on the likewise-open front?
[15:47] <ttx> no.
[15:48] <mathiaz> ttx: allright then. Thanks for the update
[15:48] <mathiaz> and we're looking for testers!
[15:48] <mathiaz> let's move on
[15:48] <mathiaz> [TOPIC] screen-profiles by default
[15:49] <mathiaz> kirkland: zul ^^?
[15:49] <zul> this is just for ec2 right?
[15:49] <mathiaz> zul: yes
[15:49] <kirkland> mathiaz: i'm proposing this, yes
[15:49] <mathiaz> screen-profiles by default in *EC2*
[15:49] <kirkland> mathiaz: in EC2 yes
[15:49] <zul> im against it, the goal of the ec2 is to behave exactly what we have now in the server
[15:50] <kirkland> mathiaz: ubuntu-server in ec2 is inherently console-less.  you attach, run something, perhaps detach, reattach later
[15:50] <zul> soren ehammond1 and I already discussed this and we were against it
[15:50] <kirkland> mathiaz: this lends itself very well to screen
[15:50] <zul> kirkland: i agree its nice to have its installed on the images but I dont think it should be enabled by default
[15:50] <kirkland> mathiaz: furthermore, i believe it's a great way to differentiate what are very similar servers in the ec2 space
[15:50]  * Brazen agrees with zul
[15:51] <mathiaz> kirkland: right - does running screen by default would have an impact on automated installation (via ssh)?
[15:51] <soren> kirkland: Do you feel you've overcome the concerns people have raised with screen?
[15:51] <soren> kirkland: Like, say, overlapping key bindings?
[15:52] <kirkland> soren: the outstanding issues i know about are: https://bugs.edge.launchpad.net/ubuntu/+source/screen-profiles
[15:52] <kirkland> and
[15:52] <kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/screen
[15:53] <kirkland> soren: i don't feel that any of these are blockers for adoption
[15:53] <ttx> I tend to agree screen is especially useful in the EC2 case... but I also agree that we should mimic what's in the default server install.
[15:53] <kirkland> mathiaz: if soren, zul, and eric are opposed, i withdraw my suggestion
[15:53] <soren> I can't spot the "hijacks application's keybindings" thing in there anywhere.
[15:54] <soren> I've never filed it as a bug. Perhaps because it's behaving as advertised or because I just don't see a clean way around it. I don't know. I just haven't :)
[15:54] <kirkland> soren: that was worked around by providing an option to disable and/or customize the keybindings applied by screen-profiles
[15:54] <mathiaz> kirkland: I think it's an idea worth exploring - however I'm not sure that using screen by default on *EC2* only is good.
[15:55] <soren> kirkland: Which means more work by default.
[15:55] <mathiaz> kirkland: we should investigate if we should enable screen by default *everywhere*
[15:55] <kirkland> mathiaz: i agree with you;  i though ec2 would be a perfect place to start
[15:55] <mathiaz> kirkland: true.
[15:55] <kirkland> mathiaz: these are machines that you are *never* physically sitting in front of
[15:55] <kirkland> mathiaz: in this case, they are very unique
[15:56] <kirkland> mathiaz: "they" being hosted servers of any kind, ec2 being the present example
[15:56] <zul> kirkland: i think its a good idea overall but its too soon
[15:56] <nealmcb> could it be in the motd for ec2?
[15:57] <soren> I must say that while screen-profiles surely solves a problem, I think it will annoy a rather large group of users. Me, for instance :) It's too in-my-face. I don't really want to know that screen is there until I want to do something with it.
[15:57] <Brazen> I think screen is just as useful, and maybe more so when physically at console (with no X, such as with servers), so I don't see the relevance of ec2 being remote-only
[15:57] <kirkland> mathiaz: i suppose we can revisit this in karmic
[15:58] <mathiaz> kirkland: right.
[15:58] <mathiaz> we're running out of time
[15:58] <mathiaz> even though we have the whole channel for us for *ever*
[15:59] <mathiaz> kirkland: thanks for bringing this up - we should definetly revisit this topic for karmic
[15:59] <mathiaz> kirkland: you could also send an email on ec2-beta
[15:59] <mathiaz> kirkland: to get some feedback there
[16:00] <mathiaz> [TOPIC] Open Discussion
[16:00] <mathiaz> anything else to add?
[16:01] <sommer> I think zoopster  mentioned eucalyptus documentation?
[16:02] <zoopster> I did.
[16:02]  * erichammond wakes up, scans the meeting log, nods, and heads out to an off-site meeting.
[16:02] <zoopster> but given time...I can take it offline
[16:02] <sommer> zoopster: okay
[16:03] <simplexio> hmm what is screen-profiles ? keybindings for screen
[16:05] <mathiaz> ok - let's wrap up
[16:05] <mathiaz> [TOPIC] Agree on next meeting date and time
[16:05] <mathiaz> so next week the TB is running at 15:00 UTC
[16:05] <mathiaz> at the same time as our currently scheduled meeting
[16:06] <mathiaz> so my proposal is to run the meeting at 15:00 UTC in #ubuntu-server
[16:06] <mathiaz> same as this week
[16:06] <mathiaz> (and last week)
[16:07] <mathiaz> so: same time, same place (#ubuntu-server), next week?
[16:09] <fevel> where does ubuntu server put the apache vhosts conf file please?
[16:10] <mathiaz> ok - I don't see any objections - so see you all next week, same time, same place (#ubuntu-server)
[16:10] <Brazen> fevel: /etc/apache2/sites-available/
[16:10] <mathiaz> thanks for attending and happy beta testing!
[16:10] <fevel> thanks
[16:10] <mathiaz> #endmeeting