20090908
Agenda
Items we will be discussing:
- Review ACTION points from previous meeting.
- Review status of projects for the current release
- UEC images (Scott)
- Bug management
- EC2 AMIs (Scott)
- Todo items for alpha 6
- Bug management
- Packaging and integration of Eucalyptus 1.6 (Soren)
- Alfresco appliance (Dustin)
- Appliance store (Gustavo)
- Canonical application support (Chuck)
- Directory (Mathias)
- CIM/WBEM (Mathias)
- UEC images (Scott)
- Followups from server team sprint (all)
Server developer team in LP for ArchiveReorganisation (Matt)
Assigned and to-be-assigned bugs: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html (all)
- Weekly SRU review (Mathias)
Review progress made on the Roadmap.
- Open Discussion.
- Agree on next meeting date and time.
Minutes
UEC images
There was a discussion on how to track bugs affecting UEC images. The outcome was to use the "uec-images" tag. ubuntu-bug and apport should also use it when filling bugs from an UEC image.
Test cases have been updated to include an EC2 test of the UEC images. That should be enough for now to make sure the UEC images are working correctly.
ACTION: smoser to tag existing UEC image bugs with "uec-images"
ACTION: mdz to follow up on ubuntu-bug/apport for uec images
EC2 AMIs
The release process for EC2 images was reviewed in view of Alpha6 scheduled for next week.
ACTION: soren to ensure that smoser can update the UEC publishing scripts
ACTION: smoser to add MD5SUMs for UEC images
ACTION: soren to add manifest files for UEC images
ACTION: smoser to open dialog with IS about automated publishing to EC2 and agree on a plan
ACTION: soren to automate updating of ec2-version-query
ACTION: soren to publish ec2-version-query in a more appropriate place
The state of the EC2 kernel was also discussed. zul reported that a 2.6.31-rc6 kernel based on the Xen patches had been successfully booted on ec2. Merging the patch into the karmic tree was under way.
ACTION: mdz to confirm ec2 kernel status for alpha 6
ACTION: smoser to add ec2-images tag to the relevant bugs
ACTION: mdz to see that bug documentation is updated for uec-images, ec2-images tags
ACTION: nijaba to fold #ubuntu-ec2 and #ubuntu-cloud into #ubuntu-server
Packaging and integration of Eucalyptus 1.6
As agreed with the Eucalyptus team relevant bugs should be tagged with 'eucalyptus'. soren announced that Eucalyptus 1.6 had landed in Karmic. The installer experience has been reviewed by the Eucalyptus team and bugs have been filed. cjwatson is looking at them.
ACTION: soren to triage all eucalyptus bugs, and use the 'eucalyptus' tag for bugs which should be escalated to the eucalyptus team
Alfresco appliance
The main blocker to produce an appliance was the dependency on Sun jdk. Its EULA needs to be accepted by the end user when deploying the appliance.
ACTION: kirkland to build a proof of concept alfresco appliance
Appliance store
niemeyer reported that most of the code had been written. The store UI has already been integrated in Eucalyptus 1.6.
ACTION: mathiaz to get niemeyer's proxy code packaged
Canonical application support
ACTION: zul to ensure rabbitmq-server gets reviewed and promoted
Directory items
2.4.18 has been released on Sunday and the FF Exception has been granted.
ACTION: mathiaz to upload openldap 2.4.18
CIM/WBEM
mathiaz reported the spec was implemented. More testing is welcome.
KVM-QEMU testing
kirkland noted that most of the bugs on kvm / qemu were reported after RC. He asked for ways to increase the testing of kvm in the development release.
ACTION: kirkland to speak with marjo about how to get qemu-kvm tested prior to release (and more generally server applications like it)
Server developer team in LP for ArchiveReorganisation
Package sets are available in Launchpad, and cjwatson was looking for the appropriate teams to have privileges on them. But there didn't seem to be an appropriate team for Server Edition. If the server team wants to take advantage of the ability to provide upload privileges for server bits without requiring core-dev, somebody will need to sort it out.
ACTION: mathiaz to get a server dev team set up in LP and work with cjwatson to get it set up for archive reorg
Assigned and to-be-assigned bugs
The list will be used to keep track of active bugs in the team. The list needs to be reviewed and kept up-to-date.
Progress on Roadmap
The ServerTeam Roadmap is not up-to-date.
ACTION: ttx to update server team Roadmap to reflect current projects
Asterisk
The Debian VOIP hasn't responded yet.
ACTION: Daviey to call for testing of Asterisk 1.6
SRU review
ACTION: mathiaz to produce a list of accepted bugs for packages related to the ubuntu-server team.
Agree on next meeting date and time
Next meeting will be on Tuesday, September 15th at 15:00 UTC in #ubuntu-meeting.
Log
[16:01] <mdz> #startmeeting [16:01] <MootBot> Meeting started at 10:01. The chair is mdz. [16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:01] <niemeyer> Yo [16:02] <mdz> mathiaz, here? [16:02] <mathiaz> mdz: sure [16:02] <mdz> zul, here? [16:02] <zul> yep sorry [16:02] <mdz> [link] https://wiki.ubuntu.com/ServerTeam/Meeting [16:02] <MootBot> LINK received: https://wiki.ubuntu.com/ServerTeam/Meeting [16:02] <mdz> has the agenda [16:03] <mdz> mathiaz, were there any actions from the previous meeting to review? [16:03] <mathiaz> https://wiki.ubuntu.com/MeetingLogs/Server/20090901 [16:03] <mdz> [topic] action items from 20090901 [16:03] <MootBot> New Topic: action items from 20090901 [16:03] <mathiaz> Asterisk [16:03] <mathiaz> Daviey: ^^?> [16:03] <mdz> ACTION: Daviey to follow up with the Asterisk Debian maintainers about adopting dkms for dahdi [16:04] <mdz> ACTION: Daviey to call for testing of Asterisk 1.6 [16:04] <Daviey> mdz: Been very quiet [16:04] <Daviey> i pinged debian-voip the other day, asking for more discussion.. but nobody has replied [16:04] <Daviey> the irc channel is often too quiet to get a discussion. [16:04] <mdz> Daviey, how about the CFT? [16:04] <Daviey> Apologies, CFT? [16:04] <mdz> call for testing [16:05] <mdz> you had an action to call for testing of asterisk 1.6 above [16:05] <Daviey> Oh, that hasn't been done yet. [16:05] <mdz> ACTION: mathiaz to produce a list of accepted bugs for packages related to the ubuntu-server team. === marjomercado is now known as marjo [16:05] <mathiaz> mdz: on my todo list [16:06] <mdz> ok [16:06] <mdz> [topic] Review status of projects for the current release [16:06] <MootBot> New Topic: Review status of projects for the current release [16:06] <mdz> so I'd like to sync up across the board on 9.10 projects [16:06] <mdz> the list on the agenda is not 100% complete, and doesn't necessarily map 1:1 to specs, but I think it will help us cover the territory [16:07] <mdz> [topic] UEC images (smoser) [16:07] <MootBot> New Topic: UEC images (smoser) [16:07] <smoser> - want to release hardy refresh (ideally this week, maybe next) [16:07] <smoser> - add more detail to Refresh Policy, send to ubuntu-devel ( https://wiki.ubuntu.com/ServerTeam/Meeting ) [16:07] <smoser> - update https://wiki.ubuntu.com/UEC/Images/Publishing with better instructions (and provide tools for all of it if possible) === swoody_ is now known as swoody [16:08] <smoser> - go through and triage bugs and tag which ones for alpha 6 (will do that today) [16:08] <smoser> - open bug and implement kernel/initrd publishing to uec-images [16:08] <mdz> smoser, how do we keep track of which bugs affect the UEC images presently? [16:09] <smoser> i dont know that there is a way specifically for euc images [16:09] <mdz> ok, I'd like to fix that straight away [16:09] <mdz> can we agree on a tag to use now? [16:09] <smoser> for ec2 (whihc ideally is identical) we mark them as affecting the ubuntu-on-ec2 project [16:09] <mdz> we should use a project for this purpose only if it is important to track the status separately in each place [16:09] <niemeyer> mdz, smoser: We have to create a process to integrate released images in the image store as wlel [16:10] <smoser> regarding a tag, i dont think i have enough launchpad experience to say. ttx and soren didn't want tag (i thought) [16:10] <mdz> soren, ? [16:10] <soren> I would have preferred if there was another way, but if not, a tag is fine. [16:10] <smoser> i think the main reason is that it is harder to tell someone to open a bug and add a tag. easier to say "open against this project" [16:10] <mdz> smoser, you can do that with a +filebug URL which automatically adds the tag [16:11] <mdz> smoser, we can also set it up so that running ubuntu-bug within a running instance does the right thing (like for UNR and the ubuntu-unr tag) [16:12] <mdz> it's important that we get to a point where we can ask Launchpad for all of the relevant bugs in one report so that we know where we stand [16:12] <mdz> tags are the simplest way to do that at the moment, I think [16:12] <smoser> mdz, i'm generally fine with whatever is the launchpad-best-practice for doing things. and yes, i'd like to get ubuntu-bug working, and provide a apport hook to collect data also [16:12] <mdz> ok, I suggest the tag "uec-images" [16:12] <mdz> which matches the download URL and should be reasonably unique [16:13] <soren> Fine with me. [16:13] <mdz> [action] smoser to tag existing UEC image bugs with "uec-images" [16:13] <MootBot> ACTION received: smoser to tag existing UEC image bugs with "uec-images" [16:13] <smoser> can-do [16:14] <mdz> [action] mdz to follow up on ubuntu-bug/apport for uec images [16:14] <MootBot> ACTION received: mdz to follow up on ubuntu-bug/apport for uec images [16:14] <mdz> [topic] EC2 AMIs (smoser) [16:14] <MootBot> New Topic: EC2 AMIs (smoser) [16:14] <mdz> presumably all of the UEC stuff applies here as well, but since there are EC2-specific bits, I thought it would be useful to cover it separately [16:15] <mdz> I sent out a todo list for EC2 for alpha 6 last week [16:15] <mdz> * Add signed MD5SUMS [Steve?] [16:15] <mdz> * Add manifest file for each image, including both the package versions [16:15] <mdz> inside the image (like the livefs does) and the version numbers of the [16:15] <mdz> relevant build tools (such as vmbuilder) [16:15] <mdz> * Automate publishing of AMIs to EC2 [Scott?] [16:15] <mdz> * Automate updating ec2-version-query [Soren?] [16:15] <mdz> * Publish ec2-version-query in a more appropriate place [Soren?] [16:15] <mdz> * Ensure inclusion of relevant news in release notes [Eric?] [16:15] <mdz> are any of these done already? [16:16] <smoser> well, MD5SUMs is written in https://wiki.ubuntu.com/UEC/Images/Publishing [16:16] <soren> mdz: "Automate updating ec2-version-query" /was/ done, but given Steve's feedback on directory structure, I'll have to rework that. [16:16] <smoser> but we should make the script that builds them do that, so they're automatically there for all nightlys [16:17] <mdz> smoser, do you have the access rights to make the changes to the scripts? [16:17] <smoser> i dont knwo if i can push to that bzr branch or not. soren ? [16:17] <smoser> it is something that i need to be able to do, so we'll get that figured out [16:17] <soren> smoser: I think you can. [16:18] <smoser> if not, i'll bother soren [16:18] <soren> smoser: If not, let's fix that today. [16:18] <soren> smoser: (I believe the ubuntu-on-ec2 team owns it.) [16:18] <mdz> [action] soren to ensure that smoser can update the UEC publishing scripts [16:18] <MootBot> ACTION received: soren to ensure that smoser can update the UEC publishing scripts [16:18] <mdz> [action] smoser to add MD5SUMs for UEC images [16:18] <MootBot> ACTION received: smoser to add MD5SUMs for UEC images [16:19] <mdz> [action] soren to add manifest files for UEC images [16:19] <MootBot> ACTION received: soren to add manifest files for UEC images [16:19] <mdz> smoser, is automatic publishing to EC2 doable for alpha 6? [16:20] <smoser> maybe.. [16:20] <mdz> I understand there's likely some IS work involved here, so we should at least get the ball rolling in RT [16:20] <soren> heh :) [16:21] <smoser> i absolutely want to improve it over what is there now, but fully automated might not make it. [16:21] <mdz> [action] smoser to open dialog with IS about automated publishing to EC2 and agree on a plan [16:21] <MootBot> ACTION received: smoser to open dialog with IS about automated publishing to EC2 and agree on a plan [16:21] <mdz> smoser, sound achievable for the coming week? [16:22] <niemeyer> mdz, smoser: We have to include the image store in these discussions too [16:22] <smoser> to open a dialog, yes. we dont 100% *need* anything changed, since we can just start an ec2 image that pulls from euc-images rather than pushing from data center to ec2 [16:22] <mdz> niemeyer, I think that's a separate discussion; we hadn't talked about putting dailies or alphas into the image store [16:23] <smoser> ie, without any IS changes, it can still be automated. [16:23] <mdz> smoser, I meant the "agree a plan" bit ;-) [16:23] <mdz> [action] soren to automate updating of ec2-version-query [16:23] <MootBot> ACTION received: soren to automate updating of ec2-version-query [16:23] <niemeyer> mdz: Oh, sorry, I thought it was about what to do in general [16:23] <mdz> niemeyer, this is about the release engineering process for the UEC images, what happens when we want to publish a new build [16:24] <mdz> soren, have you agreed with slangasek where to publish ec2-version-query? [16:24] <niemeyer> mdz: Ok, I guess the image store is a subset of this discussion then [16:24] <mdz> the thread went quiet over the US holiday I think [16:24] <soren> mdz: No. [16:24] <soren> mdz: It did. My fault, though, so not related to the holidays :) [16:24] <mdz> [action] soren to publish ec2-version-query in a more appropriate place [16:24] <MootBot> ACTION received: soren to publish ec2-version-query in a more appropriate place [16:24] * soren nods [16:25] <mdz> erichammond doesn't seem to be here; does he not usually attend these meetings? [16:25] <smoser> mdz, i can try. i'd like to get insight/thoughts from soren or anyone else if publish-from-amazon is not an acceptable solution. it actually is faster. [16:25] <mdz> smoser, I like the idea, but it depends on how much complexity/risk it would add to change the approach this late [16:26] <smoser> mdz, that is what i did for alpha 5 (i used amazon) [16:26] <mdz> what's happening with the EC2 kernel? [16:26] <smoser> for *publishing* not building [16:26] <mdz> smoser, oh [16:26] <smoser> building i think we keep in data cetner for now. but publishing just pulls from uec-images and runs through the upload-bundle, registher-image.... [16:27] <smoser> zul, you have ec2 kernel info ? [16:27] <soren> smoser: It's mostly an IS decision I think. (I.e. can we get the relevant credentials onto EC2 in a secure enough manner) [16:27] <zul> mdz: we have a 2.6.31-rc6 kernel working on ec2, jj was working on packaging before he left the sprint [16:27] <mdz> zul, working on packaging = merging it into the karmic kernel tree? [16:27] <soren> zul: Working in all zones? [16:27] <mdz> (I don't think we want a separate package) [16:28] <zul> mdz: yes he was merging it into the karmic kernel tree [16:28] <zul> soren: yep [16:28] <soren> zul: Based on the Xen patches or pv-ops? Sorry, you probably told me already, but I forgot. [16:28] <zul> soren: Xen patches :( [16:28] <soren> Ok. [16:28] <smoser> just for the record, major applause is due to zul and jjohansen. this was really a impossible task. [16:28] <zul> i havent had a chance to sync up with jj yet [16:28] <mdz> pgraner, could you follow up with jj regarding merging the ec2 kernel into the karmic tree and providing it as a package? we need that for alpha 6 [16:29] <mdz> zul, did we end up going with pv_ops or xen patches? [16:29] <pgraner> mdz: ack [16:29] <zul> mdz: xen-patches [16:30] <mdz> pgraner, I guess in that case, we need feedback on whether the patches can actually go into karmic or if they're problematic [16:30] <mdz> we have something which works, but it's unknown whether it's mergeable [16:30] <mdz> [action] mdz to confirm ec2 kernel status for alpha 6 [16:31] <MootBot> ACTION received: mdz to confirm ec2 kernel status for alpha 6 [16:31] <pgraner> mdz: we have our team meeting later today would be good to have some server reps there when we discuss. I'll add it to the agenda [16:31] <smoser> jj's thoughts friday were that it was not significant effort to go from 2.6.31-rc6 (what we have) to karmic-ified [16:31] <mdz> smoser, same question as for the uec images, how do we keep track of bugs which are specific to the AMIs? [16:32] <mdz> smoser, can you make it to (the relevant part of) the kernel team meeting later today? [16:32] <smoser> i've been doing 'also-effects-project' to the ubuntu-on-ec2 project [16:32] <smoser> time ? pgraner ? [16:33] <mdz> smoser, I'd like to ask that we use tags there as well, to keep things simple. having multiple status/importance/assignee is just noise unless they're being handled by separate people (which in this case they aren't) [16:33] <mdz> what would be a good tag to use? ec2? ec2-ami? [16:34] <pgraner> smoser: : 1700UTC [16:34] <mdz> (~90m from now) [16:34] <smoser> mdz, i dont like ec2-ami. as it indicates to me that kernel is not relevant [16:34] <smoser> ec2-images, corresponding to uec-images ? [16:35] <mdz> smoser, sounds good [16:35] <smoser> soren, anyone else, is that tag-based approach ok ? [16:35] <soren> smoser: Sure. [16:35] <mdz> it lets us get a very simple report out of launchpad of the open issues and their current status [16:35] <mdz> and it's a lot more lightweight (fewer clicks to add the tag) [16:36] <mdz> adding a task is pretty cumbersome just to group the bugs [16:36] * smoser makes no objection [16:36] <mdz> [action] smoser to add ec2-images tag to the relevant bugs [16:36] <MootBot> ACTION received: smoser to add ec2-images tag to the relevant bugs [16:36] <mdz> anything else on EC2? [16:36] <smoser> mdz, so should i just kill all tasks related to ubuntu-on-ec2 ? [16:37] <mdz> smoser, kill or ignore as you see fit [16:37] <mdz> I assume there's also documentation to be updated [16:37] <mdz> [action] mdz to see that bug documentation is updated for uec-images, ec2-images tags [16:37] <MootBot> ACTION received: mdz to see that bug documentation is updated for uec-images, ec2-images tags [16:38] <smoser> mdz, where does MootBot publish meeting minutes ? [16:38] <mdz> I'm wondering why we have a #ubuntu-ec2 IRC channel [16:38] <mdz> smoser, I'll email them out and add them to TeamReports on the wiki [16:39] <mdz> I've been hanging out in #ubuntu-ec2 lately, and it seems very dead [16:39] <mdz> when someone does come along with a question, there's nobody there to answer it [16:39] <nijaba> mdz: it is indeed now a bit rudundant with #ubuntu-cloud, which not very active as well [16:39] <mdz> since the amount of traffic is so low, I'd like to suggest that we fold it into #ubuntu-server [16:39] <kirkland_> mdz: there's also #ubuntu-virt [16:39] <mdz> aieee, irc fragmentation [16:40] <mdz> kirkland, nijaba, how many messages per day in those channels? [16:40] <nijaba> mdz: less than 10 on avg, apart for virt which can be more active [16:41] <Daviey> -cloud has had nothing since the 4th [16:41] <mdz> nijaba, if it's <10 messages per day, it would be beneficial to fold it into #-server where there are more people around and it's still on topic [16:41] <nijaba> mdz: agreed [16:41] <mdz> kirkland_, how about #-virt? [16:41] <mdz> nijaba, could you take care of obsoleting #-ec2 and #-cloud in favor of #-server, updating web pages etc.? [16:41] <soren> mdz: ubuntu-virt is very active at times. [16:42] <nijaba> mdz: can do [16:42] <kirkland_> mdz: wc says: 44437 525008 3627666 #ubuntu-virt.log since Apr 29, 2008 [16:42] <nijaba> mdz: should I just update the topic on the channel to invite people to go elsewhere? [16:42] <mdz> [action] nijaba to fold #ubuntu-ec2 and #ubuntu-cloud into #ubuntu-server [16:42] <MootBot> ACTION received: nijaba to fold #ubuntu-ec2 and #ubuntu-cloud into #ubuntu-server [16:42] <mdz> nijaba, yes [16:42] <nijaba> ok [16:42] <mdz> kirkland_, soren, is there anything in #-virt which would be unwelcome or off-topic in #-server? [16:43] <kirkland_> mdz: i don't think so; merely more traffic, IMO [16:43] <Daviey> it is worth noting that -server is increasingly being used for support, and some devel discussion. [16:43] <soren> mdz: Not per se, no. [16:43] <mdz> Daviey, #ubuntu-devel is available if folks need a place to go for devel discussion when #-server is too noisy [16:43] <nijaba> mdz: note that there re more 50p logged on #-virt [16:43] <soren> mdz: ...there are a bunch of people interested in virtualisation who don't care about servers, though. [16:43] <Daviey> mdz: agreed. [16:44] <mdz> soren, good point [16:44] <mdz> let's leave #-virt for now in any case [16:44] <mdz> [topic] Packaging and integration of Eucalyptus 1.6 (Soren) [16:44] <MootBot> New Topic: Packaging and integration of Eucalyptus 1.6 (Soren) [16:44] * Daviey suggests -cloud and -ec2 automatically redirects to -virt.. easy fix then [16:44] <Daviey> then no docs are really broken. [16:44] <mdz> I talked with the eucalyptus team yesterday and we agreed to use the 'eucalyptus' tag to track the bugs they care about [16:44] <mdz> [link] https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=eucalyptus [16:44] <MootBot> LINK received: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=eucalyptus [16:45] <soren> Oh, neat. [16:45] <mdz> I asked them to file all of their current issues as bugs so that we can track them [16:45] <soren> Right. Eucalyptus 1.6 has landed in Ubuntu, now. In main, even. I've been going through some of the bugs today, and hope to get through the list tomorrow and get it all triaged. [16:45] <mdz> soren, if there are bugs which we should discuss with the eucalyptus team, please add the tag to them [16:46] <mdz> then when we have our meeting with them, we'll just go over the list of tagged bugs [16:46] <soren> mdz: Makes sense. Will do. [16:46] <nurmi> i'll also be tracking these bugs in LP in case any discussions come up bug comments [16:46] <mdz> [action] soren to triage all eucalyptus bugs, and use the 'eucalyptus' tag for bugs which should be escalated to the eucalyptus team [16:46] <MootBot> ACTION received: soren to triage all eucalyptus bugs, and use the 'eucalyptus' tag for bugs which should be escalated to the eucalyptus team [16:46] <mdz> nurmi, oh, good, you're here. welcome! [16:46] <soren> mdz: Should I add them for eucalyptus bugs as well, so we get a complete list when querying for the tag? [16:47] <soren> mdz: Bugs in the eucalyptus source package itself, I mean. [16:47] <mdz> soren, I suggested we use the tag only for bugs which we're tracking together with eucalyptus [16:47] <mdz> maybe it would have been less confusing to use eucalyptus-systems or something [16:47] <soren> So.. "Yes"? :) [16:48] <mdz> soren, it's hard for me to say without having looked at many of the bugs [16:48] <soren> mdz: Ok. I think I'm on top of it. [16:48] <mdz> ok [16:49] <mdz> soren, if I made a bad guess at who to assign any of those bugs to, please fix them up for me [16:49] <soren> mdz: Already done. [16:49] <mdz> ttx is on holiday, or I would have sought his advice [16:49] <mdz> soren, thanks [16:49] <mdz> nurmi, is there anything you want to put on the agenda wrt eucalyptus 1.6 in karmic? [16:50] <nurmi> mdz: i think the bug list is pretty comprehensive thus far [16:50] <mdz> how is the installer side looking? [16:50] <nurmi> if we encounter new issues, should we be tagging them with the 'eucalyptus' tag if they effect the karmic package? [16:51] <mdz> nurmi, if the bug should be on the list when we look at bugs together, it should get the tag [16:51] <mdz> otherwise, no [16:51] <nurmi> mdz: we went through the install process yesterday, just a few issues that were encapsulated in the bug reports (post-install type questions for networking parameters, multiple interface configuration) [16:52] <mdz> if you want to always look at all bugs on the eucalyptus package, we can skip the tag for those and consider it implicit [16:52] <mdz> but we need to be able to tag the bugs which are not on the eucalyptus package itself anyway [16:52] <nurmi> mdz: got it, perfect [16:52] <mdz> soren, who is tracking uec installer issues on our side? [16:52] <soren> mdz: Colin. [16:52] <mdz> cjwatson, ping? [16:52] <soren> mdz: I've talked to him already. [16:52] <soren> ...and reassigned the bugs to him. [16:53] <mdz> soren, perfect, thank you [16:53] <mdz> [topic] Alfresco appliance (kirkland) [16:53] <MootBot> New Topic: Alfresco appliance (kirkland) [16:53] <mdz> kirkland_, how is this coming along? [16:53] <kirkland_> mdz: i first noticed that I was assigned this as of your edit of the wiki page yesterday [16:54] <kirkland_> mdz: i'll get some info from soren today about how he's creating appliances [16:54] <mdz> soren, kirkland_, is it doable to get this done in the next week? [16:54] <mdz> at least an alpha quality appliance? [16:55] <soren> mdz: I presume so. We need some changes to the alfresco package to get done. Other than that, we should be fine. [16:55] <kirkland_> mdz: on the alfresco side, it would help if it were in multiverse [16:55] <kirkland_> mdz: such that we could make changes and upload fixes to that package ourselves [16:55] <kirkland_> mdz: as it stands, it's in partner [16:55] <soren> mdz: It currently has a hard dependency on sun's java. [16:56] <mdz> I don't mind if we hand-hack it at this stage, so long as we have an image that we can try out [16:56] <soren> mdz: This makes it difficult to distribute, as the user is required to accept the EULA, afaiui. [16:57] <mdz> kirkland_, we're short on time. can you agree to give it your best shot? it doesn't need to be a clean build at this stage, something is way better than nothing [16:57] <kirkland_> mdz: yes, i'll have something alpha quality this week [16:57] <mdz> [action] kirkland to build a proof of concept alfresco appliance [16:57] <MootBot> ACTION received: kirkland to build a proof of concept alfresco appliance [16:57] <mdz> kirkland_, lovely, thanks [16:57] <mdz> [topic] Appliance store (niemeyer) [16:57] <MootBot> New Topic: Appliance store (niemeyer) [16:57] <mdz> niemeyer, how are we doing? [16:57] <kirkland_> mdz: note that the real issues will probably be licensings, non-technical ones [16:58] <niemeyer> mdz: Moving along [16:58] <niemeyer> mdz: Here are some status details I wrote down [16:58] <niemeyer> Image Store UI has been pushed upstream and is integrated into 1.6. [16:58] <niemeyer> Image Store UI depends on local proxy, which is being written at the moment. [16:58] <niemeyer> Proxy coding status: [16:58] <niemeyer> - Already done: full architecture, internal service and task dispatching infrastructure, frontend API, AWS signature checking, part of the storage mechanisms, proxying of API calls to the upstream API (e.g. get dashboard), etc. [16:58] <niemeyer> - Being written now: downloading of images. [16:58] <niemeyer> - To be written: checking of gpg signature, bundling of images, uploading into Eucalyptus, obtaining credentials through euca_conf. [16:58] <niemeyer> We have the following external dependencies thus far for the overall concept: images released by server team must be registered in the store, proxy must be packaged with Eucalyptus. [16:58] <niemeyer> We hope to have most of it done by the 14th. [16:59] <mdz> niemeyer, is the image store UI in the 1.6 packages in karmic today? [16:59] <niemeyer> mdz: It is [16:59] <mdz> great [16:59] <mdz> niemeyer, will the proxy be added to the eucalyptus package or shipped separately? [16:59] <niemeyer> mdz: There might be some minor CSS details to fix, but that's just a detail [16:59] <niemeyer> mdz: Either way works for us [17:00] <mdz> soren, what do you think? [17:00] <niemeyer> mdz: Might be easier to upgrade being separate [17:00] <niemeyer> mdz: But might be easier to package initially being integrated [17:00] <soren> mdz: It [17:00] <niemeyer> mdz: Whatever soren is happy with is great by us [17:00] <soren> It's hard to say. I'm not familiar with the code base. [17:01] <soren> If it's in a separate package, who will do the packaging= [17:01] <soren> ? [17:01] <niemeyer> soren: It's a python package, with a command for starting the proxy up, and a storage directory for cache and image work [17:01] <mdz> soren, could you look into it with niemeyer this week, decide what to do and help him get it packaged? [17:02] <soren> niemeyer: Separate package. [17:02] <niemeyer> soren: Rick originally told me "I'll keep someone on the line for packaging this when it's ready." [17:02] <cjwatson> mdz: responding to ping, although it looks like it's been dealt with [17:02] <niemeyer> soren: I understand it's not very helpful information now [17:02] <mdz> I think niemeyer can maintain the package [17:02] <mdz> once it's set up, if someone can get the initial packaging into place so he can stay focused on the proxy [17:03] <soren> niemeyer: I'd prefer it if you could do the packaging. It's hard to commit to packaging something within any timeframe when you haven't seen it yet. [17:03] <niemeyer> soren: I'm not great with deb packaging.. I'd be very happy to have someone's help with this [17:03] <mdz> mathiaz, do you think you could give niemeyer a hand getting it packaged? [17:03] <niemeyer> soren: I'll be on the line for any issues [17:03] <soren> niemeyer: Unless of course, you could give us the code before a last minute code drop? [17:04] <mathiaz> mdz: I can give it a shot - I have access to the code [17:04] <mathiaz> mdz: I can give it a shot - *if* I have access to the code [17:04] <niemeyer> soren: It's already the "last minute" in a way :( [17:04] <mdz> [action] mathiaz to get niemeyer's proxy code packaged [17:04] <MootBot> ACTION received: mathiaz to get niemeyer's proxy code packaged [17:04] <niemeyer> Either way, I'll be on the line for any issues with the code, or any questions related to building the package [17:04] <niemeyer> mathiaz: Thanks a lot [17:04] <mdz> niemeyer, is there any reason it can't be released publicly today? [17:04] <niemeyer> mdz: It is released publicly.. it's just not working yet [17:05] <mdz> ok [17:05] <soren> niemeyer: Oh? WherE? [17:05] <mathiaz> niemeyer: where? [17:05] <niemeyer> lp:~niemeyer/+junk/image-store [17:05] <mdz> niemeyer, is there anything else you need? [17:05] <mdz> we're running late, so I'd like to move on [17:05] <niemeyer> mdz: We need to sync up on the registration of images in the store, but nothing else I can think of now [17:06] <mdz> [topic] Canonical application support (zul) [17:06] <MootBot> New Topic: Canonical application support (zul) [17:06] <nurmi> niemeyer: re euca_conf get credentials - do you need just the query/access keys for 'admin'? [17:06] <niemeyer> mdz: Thanks [17:06] <niemeyer> nurmi: That and the certificates [17:06] <zul> mdz: rabbitmq-server hasnt been reviewed yet by the MIR team but kees said he was going to look at it today [17:06] <niemeyer> nurmi: Dmitrii had some working code in the Dublin sprint.. I'm not sure if it's been integrated [17:06] <mdz> zul, ok, sounds good [17:06] <nurmi> niemeyer: nod, i'll send you a note later [17:06] <niemeyer> nurmi: Do you know details about this? [17:07] <niemeyer> nurmi: Awesome, thank you [17:07] <mdz> [action] zul to ensure rabbitmq-server gets reviewed and promoted [17:07] <MootBot> ACTION received: zul to ensure rabbitmq-server gets reviewed and promoted [17:07] <zul> ack [17:07] <mdz> [topic] Directory items (mathiaz) [17:07] <MootBot> New Topic: Directory items (mathiaz) [17:07] <mathiaz> mdz: openldap 2.4.18 was released sunday [17:07] <mdz> mathiaz, openldap 2.4.18 is the only item outstanding, right? [17:08] <mathiaz> mdz: FFe granted last night [17:08] <mdz> excellent [17:08] <mathiaz> mdz: I'll upload the package today [17:08] <mdz> [action] mathiaz to upload openldap 2.4.18 [17:08] <MootBot> ACTION received: mathiaz to upload openldap 2.4.18 [17:08] <mdz> mathiaz, anything else in this area worth discussing? [17:08] <mathiaz> mdz: nope [17:08] <mathiaz> next step: more testing [17:09] <mdz> [topic] CIM/WBEM (mathiaz) [17:09] <MootBot> New Topic: CIM/WBEM (mathiaz) [17:09] <mathiaz> mdz: provider are available in the archive [17:09] <mathiaz> mdz: next step: more testing [17:10] <mdz> mathiaz, are all of the work items in the wiki completed? [17:10] <mdz> update wbem stack, package pywbem, package libopendrim, package opendrim providers? [17:10] <mathiaz> mdz: yes [17:10] <mdz> ok, perfect [17:11] <mdz> [topic] Followups from server team sprint [17:11] <MootBot> New Topic: Followups from server team sprint [17:11] <mdz> I'm sorry I missed the end of the sprint [17:12] <mdz> thierry sent me a summary and mentioned a few things we should follow up on [17:12] <mdz> one was testing procedures for the UEC images [17:12] <mdz> smoser, where does that stand? [17:13] <mathiaz> I've updated the test cases - http://testcases.qa.ubuntu.com/System/CloudImages [17:13] <smoser> regarding testing, we need to get to where the tests in iso tracker are fully automated (at least on ec2) [17:13] <mdz> ttx said we should add additional tests, because there was only one and it was dependent on a working UEC [17:13] <mathiaz> the main issue we had was that we didn't have access to a working UEC [17:14] <mdz> mathiaz, so the "bundle uec image for ec2" case should cover that now? [17:14] <smoser> once we get a reasonable framework down, adding additional tests should be fairly easy. for now, it is very error prone to run the tests. [17:14] <mdz> smoser, do you think that is achievable for alpha 6? [17:14] <mathiaz> mdz: hm - kind of. [17:15] <mathiaz> mdz: but yes - to test the UEC image delivrable rebundling to ec2 should cover it [17:15] <mdz> mathiaz, well, in that it should be possible to test without UEC if necessary [17:15] <smoser> mdz, it "should be" a reasonable thing to achieve. at least to get through the tests we have there. [17:15] <mathiaz> mdz: I still think that testing on UEC is important. [17:15] <smoser> given other things on my list, i don't really want to commit to it though [17:16] <mdz> mathiaz, I agree. the issue ttx raised was that we couldn't pass any tests for the UEC images unless UEC itself was passing tests [17:16] <mathiaz> mdz: right - with rebundle-to-ec2 with got another option for testing [17:16] <mdz> smoser, ok, we can survive with manual tests if necessary [17:16] <mathiaz> mdz: testing UEC images. which is better than nothing [17:16] <mdz> is there anything else which was an open issue at the end of the sprint? [17:17] <mathiaz> not that I can think of. [17:17] <mdz> kirkland_, there is some confusion over the image upgrade issue [17:18] <kirkland_> mdz: yes, i was wondering if we were going to get to that today [17:18] <mdz> kirkland_, I suggested that we defer it so that we can focus more on bug fixing and all of the infrastructure/process work we need to do [17:18] <kirkland_> mdz: i'd like some advice on how to proceed [17:18] <mdz> kirkland_, is that ok with you? [17:18] <kirkland_> mdz: that's fine with me, bug fixing sounds more important at this point [17:18] <kirkland_> mdz: my patch is tested, and posted in the bug, for posterity [17:18] <mdz> kirkland_, qemu-kvm is listed as a sprint agenda item which was not crossed off yet [17:18] <kirkland_> mdz: we can revisit at any time [17:19] <kirkland_> mdz: yes, i uploaded qemu-kvm-0.11~rc2 this morning [17:19] <kirkland_> mdz: upstream should GA qemu-kvm-0.11 just before our Beta [17:19] <kirkland_> mdz: these rc's are bug-fixes only, stabilizing the package [17:19] <kirkland_> mdz: we are in lock-step with upstream and Fedora on this particular package [17:19] <mdz> kirkland_, have you sent a call for testing? [17:19] <kirkland_> mdz: which is a very good thing, as we're sharing the testing/debugging burden [17:19] <mdz> I think I saw one from you [17:20] <kirkland_> mdz: http://blog.dustinkirkland.com/2009/09/qemu-kvm-011rc2-uploaded-to-karmic.html [17:20] <mdz> what is the next step we need to take? [17:20] <kirkland_> http://blog.dustinkirkland.com/2009/08/qemu-kvm-call-for-testing.html [17:20] <MootBot> LINK received: http://blog.dustinkirkland.com/2009/08/qemu-kvm-call-for-testing.html [17:20] <zul> kirkland_: i still dont understand why you need bochbios as a build dependency since it builds it own bios [17:20] <kirkland_> mdz: we need significant testing of kvm, itself, by our community [17:20] <kirkland_> mdz: soren and I have noticed that most kvm bugs don't get filed until after GA, sadly [17:21] <mdz> kirkland_, do you need help organizing that? maybe the QA team could help you run a testing day or something? [17:21] <kirkland_> mdz: and we always SRU several kvm fixes, most of which could have been caught earlier [17:21] <kirkland_> mdz: it's our theory that people just don't test servers until after we release [17:21] <kirkland_> mdz: i would welcome a QA bug day on kvm [17:21] <soren> I find the spike to be between RC and final. Annoyingly. [17:21] <mathiaz> kirkland_: it seems that you're more looking for a QA Testing day [17:21] <kirkland_> soren: ack, okay, just before GA, then [17:22] <kirkland_> mathiaz: agreed, Testing Day, not Bug Day [17:22] <Daviey> It is hard to test kvm boxes with production level burden, to be fair. [17:22] <mdz> [action] kirkland to speak with marjo about how to get qemu-kvm tested prior to release (and more generally server applications like it) [17:22] <MootBot> ACTION received: kirkland to speak with marjo about how to get qemu-kvm tested prior to release (and more generally server applications like it) [17:22] <kirkland_> Daviey: understood [17:22] <kirkland_> mdz: accepted [17:22] <mdz> kirkland_, please CC me in if you discuss it by email [17:22] <mdz> [topic] Server developer team in LP for ArchiveReorganisation (Matt) [17:22] <MootBot> New Topic: Server developer team in LP for ArchiveReorganisation (Matt) [17:23] <mdz> so we now have package sets in Launchpad, and cjwatson was looking for the appropriate teams to have privileges on them [17:23] <mdz> but there didn't seem to be an appropriate team for Server Edition [17:23] <Daviey> ~ubuntu-server is an open team.. [17:23] <mdz> right, which makes it incredibly inappropriate for this :-) [17:23] <cjwatson> yeah, it's clearly inappropriate here [17:24] <kirkland_> Daviey: yeah, too broad to dole out upload perms there [17:24] <mdz> I think what's needed is the creation of an ubuntu-server-dev team, but I would need help populating it [17:24] <mdz> can someone take the action to sort this out with cjwatson? [17:24] <mathiaz> mdz: I can look into this [17:24] <cjwatson> this isn't a blocker for archive reorg, but if the server team wants to take advantage of the ability to provide upload privileges for server bits without requiring core-dev, somebody will need to sort it out [17:24] <cjwatson> cool [17:25] <mdz> mathiaz, thanks [17:25] <mdz> [action] mathiaz to get a server dev team set up in LP and work with cjwatson to get it set up for archive reorg [17:25] <MootBot> ACTION received: mathiaz to get a server dev team set up in LP and work with cjwatson to get it set up for archive reorg === nxvl_ is now known as nxvl [17:25] <mdz> [topic] Assigned and to-be-assigned bugs: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html (all) [17:25] <MootBot> New Topic: Assigned and to-be-assigned bugs: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html (all) [17:25] <mdz> [link] http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html [17:26] <MootBot> LINK received: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html [17:26] <mdz> I don't know if this list was a regular part of your workflow previously, but I'd like to start using it to keep track of active bugs in the team [17:26] <mdz> it looks like there's a lot of noise on it at the moment [17:26] <kirkland_> mdz: i'm going to go through mine today [17:26] <mdz> including 3 old bugs which are assigned to me [17:26] <Daviey> mdz: previously this was where we discussed potential SRU acceptance. [17:27] <mathiaz> Daviey: not yet [17:27] <mdz> Daviey, we're following https://wiki.ubuntu.com/ServerTeam/Meeting [17:27] <Daviey> oh :) [17:27] <Daviey> <-- fail. [17:27] <mathiaz> Daviey: there is another section for SRU [17:27] <mdz> so please look at your list of assigned bugs, and make sure it's up to date [17:27] <mdz> that's all [17:28] <mdz> [topic] weekly SRU review (mathiaz) [17:28] <MootBot> New Topic: weekly SRU review (mathiaz) [17:28] <mathiaz> http://people.canonical.com/~mathiaz/buglists/fixedbugs.ubuntu-server.latest.html [17:28] <MootBot> LINK received: http://people.canonical.com/~mathiaz/buglists/fixedbugs.ubuntu-server.latest.html [17:28] <mathiaz> anything sru worthy on this list^^? [17:28] <zul> the net-snmp one [17:29] <mathiaz> zul: bug 406171 [17:29] <ubottu> Launchpad bug 406171 in net-snmp "COUNTER64 broken in NetSNMP::agent" [Undecided,Fix released] https://launchpad.net/bugs/406171 [17:29] <mathiaz> kirkland_: any of the kvm-qemu would apply to kvm? [17:29] <zul> mathiaz: and the samba one might be as well [17:29] <mathiaz> zul: bug 423854? [17:29] <ubottu> Launchpad bug 423854 in samba "Karmic: Multiple crashes in "net usershare list"" [Undecided,Fix released] https://launchpad.net/bugs/423854 [17:30] <zul> mathiaz: that has to be investiaged a bit more as well [17:30] * nurmi has another engagment to go to; thanks all - i'll be in touch [17:30] <mathiaz> zul: for hardy? jaunty? [17:30] <zul> mathiaz: jaunty [17:30] <Daviey> The mysql one was a regression in karmic mysql 5.1, so not relevant. [17:30] <mdz> maintenance on jaunty should be minimal at this stage [17:31] <mathiaz> zul: both bugs nominated for jautny [17:31] <mdz> unless it's a critical bug (and both of those are Undecided), I'd default to "no" [17:32] <mdz> mathiaz, ready to move on? [17:32] <mathiaz> sure [17:32] <mathiaz> there are 4 other lists to look at: [17:32] <mathiaz> http://us-dappernominated.notlong.com/ [17:32] <MootBot> LINK received: http://us-dappernominated.notlong.com/ [17:32] <Daviey> nice! [17:32] <mathiaz> nothing in there [17:32] <mathiaz> http://us-hardynominated.notlong.com/ [17:32] <MootBot> LINK received: http://us-hardynominated.notlong.com/ [17:32] <mdz> the dapper one is empty [17:33] <mdz> the hardy ones are all fix released [17:33] <mathiaz> kirkland_: ^^ any bugs worth accepting for hardy? [17:33] <mathiaz> kirkland_: they're all libvirt/kvm bugs? [17:34] <kirkland_> mathiaz: most of the kvm bugs have been solved in the hardy-backports package of kvm-84 [17:34] <kirkland_> mathiaz: i believe it unwise to waste any more time on kvm-62, unless we find data corruption issues [17:34] <mathiaz> kirkland_: so all the bugs should be declined for hardy? [17:35] <mathiaz> kirkland_: http://us-hardynominated.notlong.com/ [17:35] <kirkland_> mathiaz: i'll go through those, but yes, i'll decline then with a note to try kvm-84 in backports [17:35] <kirkland_> mathiaz: and the correspoding libvirt [17:35] <mathiaz> kirkland_: ok - same question for intrepid nominated [17:35] <mathiaz> kirkland_: http://us-intrepidnominated.notlong.com/ [17:35] <mathiaz> kirkland_: they're all libvirt/kvm bugs [17:35] <soren> Sorry, guys. The real world is calling. [17:36] <mdz> unless any of them are Critical importance, skip it [17:36] * soren runs off [17:36] <mdz> soren, understood [17:36] <kirkland_> mathiaz: ditto ... same thing. kvm-72 was also clearly beta-quality code [17:36] <mathiaz> kirkland_: ok - could go through them and decline them? [17:36] <mdz> as a general policy, we should focus maintenance almost exclusively on the current stable and current LTS [17:37] <mathiaz> kirkland_: and there is one bug in the jaunty list [17:37] <mathiaz> http://us-jauntynominated.notlong.com/ [17:37] <MootBot> LINK received: http://us-jauntynominated.notlong.com/ [17:37] <mathiaz> that's all for the SRU review [17:38] <mathiaz> I'll write up a script to review which bugs have been assigned [17:38] <mathiaz> and make sure they're not get stalled [17:38] <kirkland_> mathiaz: i don't think that's SRU-worthy [17:38] <mdz> mathiaz, thanks [17:38] <mdz> [topic] Progress on Roadmap [17:38] <MootBot> New Topic: Progress on Roadmap [17:38] <mathiaz> kirkland_: ok - I'll decline them [17:38] <mdz> I'm not sure how this section normally works; I find it a bit confusing because the wiki page doesn't list the projects that most of you are working on [17:38] <mathiaz> mdz: the Roadmap is not really up-to-date [17:38] <mathiaz> mdz: we should skip it [17:39] <mdz> mathiaz, we should also update the Roadmap, no? :-) [17:39] <mdz> I'll ask ttx to take care of that when he gets back from his holiday [17:39] <mathiaz> mdz: yes - that would be helpful [17:39] <mdz> [action] ttx to update server team Roadmap to reflect current projects [17:39] <MootBot> ACTION received: ttx to update server team Roadmap to reflect current projects [17:39] <mdz> [topic] AOB [17:39] <MootBot> New Topic: AOB [17:39] <mdz> anything else? [17:40] <mdz> canonical folks, remember there is a conference call immediately following this meeting [17:40] <Daviey> fortunes-ubuntu-server got MIR approval. [17:40] <Daviey> needs to be added to server seed. [17:40] <Daviey> (and a version bump, to reflect some MIR review changes) [17:41] <mdz> I've not been tracking that as a 9.10 feature [17:41] <Daviey> nijaba: ^^ ? [17:41] <nijaba> Daviey: MIR: bug #423667, FFe: bug #423678. MIR has been granted, nothing has happened on FFe. [17:42] <ubottu> Launchpad bug 423667 in ubuntu-server-tips "[MIR] fortunes-ubuntu-server" [Medium,Fix committed] https://launchpad.net/bugs/423667 [17:42] <ubottu> Launchpad bug 423678 in ubuntu-server-tips "[FFe] fortunes-ubuntu-server" [Medium,New] https://launchpad.net/bugs/423678 [17:42] <mdz> ok, so it's not actionable yet anyway [17:42] <mdz> can we wrap up? [17:42] <nijaba> mdz: it was not a tracked feature per say, more something that came along [17:42] <Daviey> sure. [17:43] <mdz> great, sorry for running so long, we had a lot to catch up on and this is my first server team meeting in a while [17:43] <mdz> thanks a lot, everyone [17:43] <mdz> [endmeeting] [17:43] <mdz> #endmeeting
MeetingLogs/Server/20090908 (last edited 2009-09-09 02:17:46 by dsl-67-230-144-181)