20091006

Agenda

  • Review ACTION points from previous meeting
  • Beta release postmortem
  • RC preparation
    • Further improvements to release process
    • Sweeping server bugs for release-critical and regression bugs
    • Staying on top of beta bugs: Triage days
  • Review progress made on the Roadmap:

    • Eucalyptus status, including review of open issues (kirkland, ttx)

    • UEC images, including review of active bugs (smoser)

    • EC2 AMIs, including review of active bugs (smoser)

    • Virtual appliance
      • Reference appliance plan (soren)
      • Image store status (niemeyer)
    • Other specs from the Roadmap

  • Assigned and to-be-assigned bugs: http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html

  • Weekly SRU review (mathiaz)
  • Open Discussion
  • Agree on next meeting date and time

Minutes

Review ACTION points from previous meeting

  • niemeyer to send mathiaz and nurmi a mail with details on how to test the image-store-proxy integration with fakestoreapi.py: Done, though not tested yet
  • ttx and smoser to review the automation of the image publication process: Done. Some automation steps are still in progress, should be completed by RC
  • smoser to open bugs to cover kernel/ramdisk GPL reqs and renaming: Done, bugs 444598 and 444605
  • ttx to test UEC images + UEC kernel/ramdisk on karmic UEC: Done for beta release
  • ttx to see if some bugs assigned to soren need urgent reassignment: Done but needs some update now
  • Daviey to setup a doodle poll and send the url to the ubuntu-server@ mailing list: Done, but suboptimal

Beta release postmortem

ttx reported that beta release went relatively ok, the main issue was lack of UEC testing capability, which made it difficult to confirm the bugs that were found. mdz pointed at a blind spot in testing with regard to the UEC kernel and initramfs, which might require some adjustments on the test plan. Further UEC feature testing should now use the UEC beta image, together with published kernel and ramdisk. The need for at least two complete UEC testing setups in different timezones was mentioned. mathiaz should investigate the possibility of using some hardware from the certification labs. A reference Canonical UEC setup running on 1.6 should be the right place to validate UEC images.

ACTION: ttx to review test plans and ensure they are aligned with 9.10

ACTION: kirkland to confirm that his test rig is fully operational

RC preparation

Status on a few actions:

  • Automate publishing of AMIs to EC2 [smoser]: in progress
  • Publish ec2-version-query in a more appropriate place, automation [soren]: now in smoser hands
  • mathiaz to set up OpenLDAP/sssd test infra on EC2: in progress
  • mathiaz to get help from Michael Vogt on bug 194140: mvo will look at it tomorrow
  • kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt: still todo, planned an OpenWeek session about it

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

With FinalFreeze coming up on October 15th, we need to quickly identify missing release-critical issues and regressions in server packages. mdz stressed again the importance of using the regression-potential tag in that process, see https://wiki.ubuntu.com/QATeam/RegressionTracking for more details. kirkland mentioned libvirt as one package requiring a complete triage effort, quickly organizing a bug day on that package could help. For other packages, zul and mathiaz will be coordinating the effort of sweeping through the bug lists: mathiaz will look at Confirmed/Triaged bugs, while zul will look after New/Undecided ones. Other team members should help in that effort, especially for the packages that they usually take care of. A server bug day should be organized to provide a framework for community participation.

ACTION: mathiaz to work with the QA team on a server bug day for Karmic

ACTION: mdz to follow up with marjo regarding general QA support in Karmic

Parallel to that effort is the need to stay on top of new bugs filed during Beta testing, to quickly identify the potential show-stoppers. A process has been defined to at least set the importance of NEW bugs, and a team member was assigned to each day (to take care of the bugs filed during the day before). The backlog should be taken care of progressively.

Eucalyptus status

kirkland uploaded a new eucalyptus yesterday, merge of an upstream bugfix revision that closes ~12 bugs. ttx tested it, autoregistration still needs another pass as it seems to work by accident in that version (bugs 443325,444504), and a deadlock bug still needs some investigation (444352). kirkland holds a UEC-hardening mini-sprint with mathiaz and nurmi in Austin this week, where bug 432154 and 436977 should be discussed.

UEC/EC2 images

Reviewing the UEC image bug list: smoser will target to release appropriately (bugs 444605 444598 440757), and will take some time to setup a UEC image testing environment. zul should make sure the last MIR gets completed, by fixing the testsuite.

ACTION: smoser to follow up with mdz regarding UEC image testing capability

ACTION: zul to fix m2crypto test suite and ensure that MIR is processed

Reviewing the EC2 images buglist: jjohansen has put up some kernels with tweaked configs (bug 428692). Note that it is possible to test UEC images in plain KVM by passing kernel parameter ec2init=0. ttx and kirkland will dedicate some of their UEC testing time testing the candidate UEC images on smoser's request.

Virtual appliance

The final design questions around the reference appliance need to be resolved ASAP.

ACTION: soren/niemeyer to arrange a meeting to discuss reference appliance plan of action

On the imagestore proxy side, niemeyer will provide mathiaz with an updated version with a couple of very minor changes today. Testing instructions are in mathiaz's hands, and need to be documented in a test plan, that the happy few with a UEC setup can help test.

ACTION: mathiaz to document test plan for image store

Assigned bugs

mdz pointed to importance-Undecided bugs on the list, mostly assigned to zul, that need to be cleared. The highest importance triaged bugs on that list are the vmbuilder ones, assigned to soren, which should dedicate some time to vmbuilder tomorrow.

ACTION: zul to triage his assigned bugs

Agree on next meeting date and time

Discussion over a better time for the team meeting should be held on the mailing-list. Everyone should answer there.

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

Log

[16:03] <mdz> #startmeeting
[16:03] <MootBot> Meeting started at 10:03. The chair is mdz.
[16:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:03] <mdz> [LINK] https://wiki.ubuntu.com/ServerTeam/Meeting
[16:03] <MootBot> LINK received:  https://wiki.ubuntu.com/ServerTeam/Meeting
[16:03] <mdz> [TOPIC] Review ACTION points from previous meeting
[16:03] <MootBot> New Topic:  Review ACTION points from previous meeting
[16:03] <mdz> [LINK] https://wiki.ubuntu.com/MeetingLogs/Server/20090929
[16:03] <MootBot> LINK received:  https://wiki.ubuntu.com/MeetingLogs/Server/20090929
[16:04] <mdz> ACTION: niemeyer to send mathiaz and nurmi a mail with details on how to test the image-store-proxy integration with fakestoreapi.py.
[16:04] <mathiaz> mdz: done
[16:04] <mdz> ACTION: ttx and smoser to review the automation of the image publication process.
[16:04] <mathiaz> mdz: haven't had time to conduct testing though
[16:04] <mdz> mathiaz: understood
[16:05] <mdz> ttx, smoser, status of the image publishing automation?
[16:05] <ttx> mdz: that was done prior to beta, and it showed quite a few things that still need manual interaction
[16:05] <ttx> especially ec2 publication
[16:05] <smoser> regarding review of automation, i'm working on that now.  the NamingConvention (https://wiki.ubuntu.com/UEC/Images/NamingConvention) was part of that.
[16:05] <mdz> smoser: is it on track to be sufficiently tested to be able to be used for RC?
[16:05] <smoser> i think it can be.
[16:06] <mdz> ok
[16:06] <mdz> ACTION: smoser to open bugs to cover kernel/ramdisk GPL reqs and renaming
[16:06] <smoser> i hope that by end of week we can have nightly builds being published.
[16:06] <smoser>  - bug 444598 : renaming
[16:06] <smoser>  - bug 444605 : gpl source
[16:06] <ubottu> Launchpad bug 444598 in vm-builder "rename uec kernel/ramdisk for automated downloading or easier doc" [Low,Confirmed] https://launchpad.net/bugs/444598
[16:06] <ubottu> Launchpad bug 444605 in vm-builder "make sure source is obtainable for uec kernel images" [Medium,New] https://launchpad.net/bugs/444605
[16:06] <mdz> smoser: great news, thanks
[16:06] <mdz> (done then)
[16:06] <mdz> ACTION: ttx to test UEC images + UEC kernel/ramdisk on karmic UEC
[16:06] <ttx> mdz: done for beta release
[16:06] <mdz> ACTION: ttx to see if some bugs assigned to soren need urgent reassignment
[16:07] <ttx> mdz: most of those were eucalyptus-related. The others are vmbuidler ones that are not critical
[16:07] <mdz> ttx: now that soren is back, it might be useful to review his bug list with him to make sure it's aligned with current tasking and release status
[16:07] <mdz> ACTION: Daviey to setup a doodle poll and send the url to the ubuntu-server@ mailing list.
[16:08] <Daviey> Ok, this was done - but the dates were suboptimal
[16:08] <ttx> mdz: sure, we'll review it when we arrive at the "assigned bug list review" item of the meeting
[16:08] <Daviey> soren mentioned that for many it wasn't a consistent week.
[16:08] <ttx> or off-meeting.
[16:08] <mdz> ttx: agreed
[16:08] <soren> Daviey: That's not the problem.
[16:08] <soren> Daviey: The problem is that the data we collect will only be good for three weeks.
[16:09] <mdz> the action from last week is completed; if there is further discussion needed, please take it off-meeting or add to the end of the agenda
[16:09] <smoser> that really stinks. doodle really needs time zone info.
[16:09] <soren> ...because that's when some of us switch from DST to "regular time".
[16:09] <mdz> [topic] Beta release postmortem
[16:09] <MootBot> New Topic:  Beta release postmortem
[16:09] <soren> One week later, other people switch.
[16:09] <Daviey> oh sure i see that, but it's a good "idea", and we can take daylight savings adjustments into account.
[16:09] <soren> Other people again don't switch at all.
[16:09] <soren> Some may swithc in the opposite direction at other times.
[16:09] <mdz> ttx: there was no name next to this, but I think you added it. how do you want to structure this discussion?
[16:10] <ttx> just a few comments on how beta release went, plus opportunity for anyone to chime in
[16:10] <ttx> Beta release went relatively ok, the main issue was lack of UEC testing capability
[16:10] <soren> Daviey: We can discuss it under the "# Agree on next meeting date and time " item.
[16:10]  * soren shuts up now
[16:11] <ttx> which made it difficult to confirm the bugs that were found
[16:11] <mdz> we also had a bit of a blind spot with regard to the UEC kernel and initramfs
[16:11] <ttx> mdz: that's linked to it. With more testers, we would have uncovered it before
[16:11] <ttx> I was busy validating UEC, so UEC image testing was delayed
[16:11] <mdz> ttx: I think it's a separate issue. our test plan simply didn't cover this: it instructed the user to copy the host kernel instead
[16:12] <ttx> another thing we need to adjust is the test plan, yes
[16:12] <mdz> I'm not sure why that happened, or if it's been corrected
[16:13] <ttx> we probably shouldn't validate UEC with a moving target UEC image
[16:13] <ttx> there are tests for the UEC images and tests for the UEC install, those need to be separated
[16:13] <mdz> we can do testing with the beta image now, and post-9.10 we can use the 9.10 image for smoke testing UEC
[16:13] <kirkland> mdz: it hasn't been corrected; it looks to me like the instructions are still geared toward using the host kernel/initrd
[16:13] <mdz> ttx: I believe they already are
[16:13] <mdz> http://testcases.qa.ubuntu.com/System/CloudImages is for testing the images
[16:13] <MootBot> LINK received:  http://testcases.qa.ubuntu.com/System/CloudImages is for testing the images
[16:14] <mdz> http://testcases.qa.ubuntu.com/System/Eucalyptus is for testing UEC
[16:14] <mdz> [action] smoser to update CloudImages test case to use the UEC and EC2 kernel+initramfs rather than the host's
[16:15] <kirkland> specifically: http://testcases.qa.ubuntu.com/Install/ServerEConfig
[16:15] <mdz> ttx: what do we need to do to solve the UEC testing bottleneck?
[16:15] <mdz> is anyone still waiting on hardware?
[16:15] <ttx> mdz: please action me on reviewing tests and making sure they are aligned
[16:15] <kirkland> ....  euca-bundle-image -i /boot/vmlinuz-$(uname -r) --kernel true ...
[16:15] <mdz> [action] ttx to review test plans and ensure they are aligned with 9.10
[16:15] <ttx> mdz: we need at least two test setups in different timezones
[16:15] <Moot2> LINK received:  http://testcases.qa.ubuntu.com/System/Eucalyptus is for testing UEC
[16:15] <mdz> hmm, I think mootbot is lagging
[16:15] <ttx> (that can reliably run UEC instances)
[16:15] <kirkland> ttx: that's you and me, right?
[16:16] <ttx> kirkland: now, yes.
[16:16] <kirkland> ttx: oh "reliably"
[16:16] <mdz> kirkland has also ordered some additional hardware
[16:16]  * kirkland puts his hand down
=== txwikinger2 is now known as txwikinger_work
[16:16] <kirkland> mdz: this hardware arrives tomorrow
[16:16] <mdz> kirkland: what do we need to do to fix the "reliably"?
[16:16] <kirkland> mdz: :-)  that was just a smartarse comment
[16:16] <ttx> kirkland: you cna run UEC instances alright, now ?
[16:16] <mdz> is this problem solved now that kirkland and ttx have spare hardware?
[16:17] <kirkland> ttx: i'm reinstalling with today's iso's now
[16:17] <Moot2> ACTION received:  smoser to update CloudImages test case to use the UEC and EC2 kernel+initramfs rather than the host's
[16:17] <kirkland> mdz: we have cloud testing setups now in the middle of France, and the middle of Tejas
[16:17] <Moot2> ACTION received:  ttx to review test plans and ensure they are aligned with 9.10
[16:17] <ttx> mdz: when kirkland says that he can run UEC images alright, I think we are covered
[16:17] <ttx> the more testers the better, obviously
[16:17] <mdz> [action] kirkland to confirm that his test rig is fully operational
[16:18] <smoser> verify, the url for above action is http://testcases.qa.ubuntu.com/Install/ServerEConfig
[16:18] <smoser> right ?
[16:18] <kirkland> mdz: sure, will do that today
[16:18] <Moot2> ACTION received:  kirkland to confirm that his test rig is fully operational
[16:18] <mdz> I believe it was also suggested that mathiaz could gain access to some cert hardware for this purpose
=== Moot2 is now known as MootBot
[16:18] <mathiaz> mdz: there isn't so much spare hardware in the cert lab
[16:19] <mdz> I've also thought about setting up an NC on my host while running the CLC/SC/CC/Walrus inside of KVM
[16:19] <kirkland> mdz: when can we expect Canonical IS to have an Ubuntu 9.10-based cloud?
[16:19] <mathiaz> mdz: and with release around the corner, most of the hardware is used on a daily basis
[16:19] <mdz> kirkland: that's RT #35519
[16:19] <mdz> I haven't checked it recently
[16:20] <mdz> mathiaz: ok
[16:20] <kirkland> mdz: okay, but sometime shortly after GA, roughly?
[16:20] <mdz> I should be able to arrange a bit of extra hardware for the release sprint but that will only help for the very final validation step
=== soren_ is now known as soren
[16:20] <mdz> kirkland: they started on it as soon as 1.6 landed, so yes, they're tracking toward having something in place soonish
[16:20] <kirkland> mdz: once we have that, i would think *that* would be the proper place for *image* verification
=== robbiew-afk is now known as robbiew
[16:21] <kirkland> mdz: with our local, distributed setups being the right place for actual cloud development and testing
[16:21] <mdz> ok, any other comments on beta, things we should fix before the next milestone?
[16:21] <mdz> kirkland: agreed
[16:21] <mdz> [topic] RC preparation
[16:21] <MootBot> New Topic:  RC preparation
[16:21] <mdz> # Further improvements to release process
[16:21] <mdz> # Sweeping server bugs for release-critical and regression bugs
[16:21] <mdz> # Staying on top of beta bugs: Triage days
[16:22] <mdz> re: release process, there were a few of these outstanding from alpha 6 which I haven't checked into since beta, if we could quickly review them
[16:22] <mdz>  * Automate publishing of AMIs to EC2 [smoser]: DEFERRED
[16:22] <mdz>  * Automate updating ec2-version-query [soren]: PENDING on previous item
[16:22] <mdz>  * Publish ec2-version-query in a more appropriate place [soren]:
[16:22] <mdz>    Thought to be in slangasek hands now, needs to be confirmed
[16:22] <mdz> the first item I think we covered, it's still WIP
[16:23] <mdz> soren, smoser, who is looking after ec2-version-query?
[16:23] <soren> I haven't looked at it since I got back.
[16:23] <smoser> i had kind of just left that off to soren, but when thinking of the naming convention stuff last night, i realized that s3 might be a good place to store this
[16:23] <soren> Should I?
[16:23] <mdz> smoser: do you have the necessary access to finish that off, or do you need soren?
[16:24] <smoser> i can probably find my way through it, but will likely need some help from soren along the way
[16:24]  * soren doesn't think he has special access for any of this
[16:24] <smoser> mostly, at the moment ican't write to ~soren on people.canonical.com so i'm sol
[16:24] <soren> smoser: I'm happy to provide any information you may need.
[16:24] <mdz> smoser: ok, let's consider it your task then, and you can ask for help as you need it
[16:25] <mdz>  * mathiaz to set up OpenLDAP/sssd test infra on EC2 - INPROGRESS
[16:25] <soren> Well, the first step of this is to move it /away/ from there anyway.
[16:25] <smoser> fair enough
[16:25] <mathiaz> mdz: in progress.
[16:25] <mdz> [action] mathiaz to set up OpenLDAP/sssd test infra on EC2
[16:25] <MootBot> ACTION received:  mathiaz to set up OpenLDAP/sssd test infra on EC2
[16:25] <mdz> mathiaz to get help from Michael Vogt on bug 194140 - PENDING
[16:25] <ubottu> Launchpad bug 194140 in cyrus-sasl2 "Dependency cycle prevents upgrade of libsasl2-2" [Low,Incomplete] https://launchpad.net/bugs/194140
[16:26] <mdz> mvo: ^^
[16:26] <mdz> kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt - TODO
[16:26] <kirkland> mdz: haven't started that one
[16:26] <kirkland> mdz: though I'm signed up for an OpenWeek session on the topic
[16:26] <mdz> [action] kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt
[16:26] <MootBot> ACTION received:  kirkland to adapt help.ubuntu.com VM recipe(s?) to use libvirt
[16:26] <kirkland> mdz: i'll update that documentation in prep for the OpenWeek session
[16:27] <mdz> I think the others are completed
[16:27] <mdz> ttx: Sweeping server bugs for release-critical and regression bugs?
[16:27] <ttx> mdz: so we need to get a more accurate picture of release-relevant bugs in packages others than eucalyptus
[16:28] <ttx> like you mentioned, it's strange that we don't have any regression bug so far
[16:28] <mdz> as I mentioned in email to some of you, it's important to tag regression bugs as such when you find them
[16:28] <kirkland> ttx: some qemu-kvm bugs have started trickling in
[16:28] <mdz> use the tag regression-potential
[16:28] <kirkland> ttx: i haven't had much time to look at them
[16:28] <mvo> mdz: uh, I'm very sorry, I will look at it tomorrow :/
[16:29] <mdz> further documentation on regressions at https://wiki.ubuntu.com/QATeam/RegressionTracking
[16:29] <ttx> everyone should help, obviously, but we need people to cover the packages that will slip in the holes
[16:29] <kirkland> ttx: libvirt needs a big hug; there are a ton of untriaged bugs against that very important package
[16:29] <mdz> mvo: no worries, thank you
[16:29] <ttx> zul and mathiaz should coordinate the effort
[16:29] <mdz> kirkland: bug day?
[16:29] <zul> ack
[16:29] <kirkland> mdz: not yet scheduled; but would be a good thing
[16:29] <mdz> ttx: is there an established plan for this that we can put into motion, or do we need to decide how it will work?
[16:29] <mathiaz> ttx: right - zul could you focus on the bugs that are in New,Undecided?
[16:30] <ttx> mdz: we need to decide
[16:30] <mathiaz> zul: I'll look at the Confirmed, Triagged
[16:30] <zul> mathiaz: okies
[16:30] <mdz> looks like mathiaz and zul have decided on a basic plan of action
[16:30] <mdz> zul,mathiaz: this is across all server team packages, right?
[16:30] <zul> mdz: correct
[16:31] <mathiaz> My proposal is that zul focuses on triagging/confirming bugs, while I'll have look at the triagged/confirmed for release critical things
[16:31] <ttx> mdz: we should still ahve a way for others to participate, like "hey, I'll look at tomcat6 and dnsmasq"
[16:31] <mathiaz> mdz: yes
[16:31] <mdz> zul,mathiaz: do you think it would be helpful to organize a server bug day on this?
[16:31] <ttx> since I usually triage this package anyway
[16:31] <mdz> ttx: a bug day would provide a framework for participation
[16:31] <zul> mdz: its based on this list https://bugs..launchpad.net/~ubuntu-server/+packagebugs
[16:31] <kirkland> mdz: what's the timeframe for such a bug day?
[16:31] <kirkland> mdz: we'd need to do it before RC, right?
[16:31] <mdz> kirkland: they happen all the time, someone just needs to get in touch with the QA team
[16:32] <kirkland> mdz: right, i'm just curious... before or after RC?
[16:32] <mdz> kirkland: ASAP, definitely before
[16:32] <mathiaz> zul: http://qa.ubuntu.com/reports/ubuntu-server-team/dailynewbugs.ubuntu-server.mon.html
[16:32] <kirkland> mdz: okay, right
[16:32] <mathiaz> zul: ^^ could you focus on the list of bugs above?
[16:32] <mdz> kirkland: RC is meant to be a dry run of the final bits; we should be ready to release at that point
[16:32] <zul> mathiaz: i have as well
[16:32] <mdz> mathiaz: could you take the action to ask about a bug day?
[16:33] <mathiaz> mdz: sure
[16:33] <mdz> [action] mathiaz to work with the QA team on a server bug day for Karmic
[16:33] <MootBot> ACTION received:  mathiaz to work with the QA team on a server bug day for Karmic
[16:33] <mdz> ttx: Staying on top of beta bugs: Triage days
[16:33] <mdz> is this something to do in addition to the bug day?
[16:33] <ttx> yes.
[16:33] <ttx> The idea is that server is only tested very late in the release process
[16:34] <ttx> so we need to stay on top of new bugs filed against server apckages
[16:34] <mdz> what action is needed to get started on this?
[16:34] <kirkland> mdz: mathiaz: would have to be Monday or Tuesday of next week
[16:34] <ttx> to quickly identify regressions/ critical bugs
[16:34] <mdz> [action] mdz to follow up with marjo regarding general QA support in Karmic
[16:34] <MootBot> ACTION received:  mdz to follow up with marjo regarding general QA support in Karmic
[16:34] <ttx> https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#Bug%20Triager%20resources
[16:35] <mdz> (note to myself)
[16:35] <ttx> describes bug lists that can be used
[16:35] <ttx> to make sure New,Undecided bugs are at least prioritized
[16:35] <ttx> ten we can assign a team member to each day
[16:35] <ttx> then...
[16:36] <ttx> mathiaz: you have been setting up the bug lists, any comment ?
[16:36] <mdz> mathiaz: how can I help?
[16:36] <mathiaz> ttx: not really - they're just ready for general usage
[16:37] <mathiaz> now it's a matter of getting people to use them
[16:37] <mathiaz> the goal is to have the list emptied every day
[16:38] <mathiaz> there is a backlog though
[16:38] <mdz> mathiaz: I'll mention this to marjo as well and see if he can provide any help
[16:38] <mathiaz> once the backlog is dealt with, it should be around 10/12 days a bug
[16:38] <mathiaz> hm bug <-> day
[16:38] <mdz> we need to move on to status
[16:38] <mdz> [topic] #
[16:38] <mdz> Eucalyptus status, including review of open issues (kirkland, ttx)
[16:38] <MootBot> New Topic:  #
[16:38] <kirkland> there is an external job posting for an Ubuntu Server QA Engineer
[16:38] <mdz> [topic]  Eucalyptus status, including review of open issues (kirkland, ttx)
[16:38] <MootBot> New Topic:   Eucalyptus status, including review of open issues (kirkland, ttx)
[16:39] <kirkland> mdz: uploaded a new eucalyptus yesterday
[16:39] <mdz> kirkland: yes, but we can't rely on much help there for 9.10 due to the timeframe involved
[16:39] <kirkland> mdz: merge of upstream code, closes ~12 bugs
[16:39] <ttx> I tested it, it's working correctly
[16:39] <ttx> I filed a series of bugs though
[16:39] <mdz> how about the installation+autoregistration?
[16:39] <kirkland> mdz: ah, okay; i thought we were disucssing bug triage in the long term, rather than the 9.10 timeframe
[16:39] <ttx> autoregistration works, but by accident
[16:39] <mdz> kirkland: both, but more urgently 9.10
[16:40] <ttx> we need to fix a few bugs to make it work by design
[16:40] <kirkland> i had just started the new ISO install when this meeting started
[16:40] <mdz> ttx: are those bugs assigned and targeted for Karmic?
[16:40] <kirkland> mdz: my upgrade testing from the previous package went very well
[16:40] <ttx> assigned - yes, targeted to karmic, i'll check and fix if needed
[16:40] <kirkland> mdz: ttx: nurmi arrives in Austin at 11pm tonight; we're spending the following two days hardening UEC
[16:41] <mdz> ttx: please mention the bug numbers here for tracking purposes
[16:41] <kirkland> ttx: if you can verify our work in your locale, that would be great
[16:41] <mdz> kirkland: excellent
[16:41] <kirkland> ttx: s/verify/test/
[16:41] <ttx> bug 444352 could use someone to reproduce it
[16:41] <ubottu> Launchpad bug 444352 in eucalyptus "DB deadlock on reboot prevents EMI from being started" [Medium,New] https://launchpad.net/bugs/444352
[16:41] <kirkland> i propose at this point that we cherry pick individual commits from upstream eucalyptus to solve bugs
[16:42] <kirkland> ie, i propose that we do no more wholesale merges
[16:42] <ttx> bug 443325 and bug 444504 are the ones that make autoregistration work, once combined
[16:42] <kirkland> for karmic
[16:42] <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/443325/+text)
[16:42] <ubottu> Launchpad bug 444504 in eucalyptus "Autoregistration is always attempted, whatever the post-start scripts return" [Low,Triaged] https://launchpad.net/bugs/444504
[16:42] <kirkland> ttx: when you say "once combined", you mean once both fixes are applied?
[16:42] <mdz> ttx: ok, thanks
[16:42] <mdz> anything else on eucalyptus?
[16:42] <mdz> https://bugs.launchpad.net/ubuntu/+source/eucalyptus
[16:43] <ttx> nothing from me
[16:43] <kirkland> mdz: not really from me
[16:43] <mdz> kirkland: are we nearer to a resolution for bug 432154?
[16:43] <ubottu> Launchpad bug 432154 in qemu-kvm "dynamic block device attach/detach not functional with karmic KVM" [High,In progress] https://launchpad.net/bugs/432154
[16:43] <ttx> I'm writing some blogposts about running UEC, they are getting good press coverage
[16:43] <kirkland> mdz: delayed that one until nurmi arrives
[16:43] <mdz> kees: any news on  bug 436407?
[16:43] <kirkland> mdz: that will be one of our top priorities
[16:43] <ubottu> Launchpad bug 436407 in eucalyptus/1.6 "if apache2 is using worker MPM, rampart causing periodic CC segfaults" [Critical,Fix committed] https://launchpad.net/bugs/436407
[16:44] <mdz> kees: er, 436977
[16:44] <mdz> bug 436977
=== fader_ is now known as fader|away
=== fader|away is now known as fader_
[16:44] <ubottu> Bug 436977 on http://launchpad.net/bugs/436977 is private
[16:44] <mdz> kirkland: ok, is that on the agenda that you sent me?
[16:44] <kirkland> mdz: absolutely
[16:44] <kirkland> mdz: i'll like to review that agenda with you briefly today
[16:44] <mdz> kirkland: ok, I'll hopefully be able to review that today
[16:44] <mdz> [topic] UEC images, including review of active bugs (smoser)
[16:44] <MootBot> New Topic:  UEC images, including review of active bugs (smoser)
[16:45] <mdz> [link] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=uec-images
[16:45] <MootBot> LINK received:  https://bugs.launchpad.net/ubuntu/+bugs?field.tag=uec-images
[16:45] <mdz> smoser: are you able to test these yourself in UEC?
[16:45] <mdz> there seems to still be an MIR pending
[16:45] <smoser> no. not at the moment.
[16:46] <smoser> yeah, the MIR is assigned to zul. not pointing fingers, just saying. i think he may know more.
[16:46] <smoser> i do have hardware for uec that i'd like to get up and running to help test with
[16:46] <smoser> its just time.
[16:46] <mdz> smoser: bug 444605 looks like it needs to be fixed for 9.10
[16:47] <ubottu> Launchpad bug 444605 in vm-builder "make sure source is obtainable for uec kernel images" [Medium,New] https://launchpad.net/bugs/444605
[16:47] <smoser> yes.
[16:47] <smoser> of the bugs listed there, those that will surely be fixed are:
[16:47] <smoser> bug 444605
[16:47] <smoser> bug 444598
[16:47] <ubottu> Launchpad bug 444598 in vm-builder "rename uec kernel/ramdisk for automated downloading or easier doc" [Low,Confirmed] https://launchpad.net/bugs/444598
[16:48] <mdz> smoser: I expect cjwatson would have good input on 444605, I suggest asking him about it
[16:48] <smoser> at this point i expect to fix bug 440757 also.
[16:48] <ubottu> Launchpad bug 440757 in vm-builder "ec2-images have ubuntu.canonical.com in /etc/hosts" [Medium,Triaged] https://launchpad.net/bugs/440757
[16:48] <smoser> i will copy cjwatson and pester him for input
[16:48] <mdz> smoser: anything on the "surely be fixed" list should be targeted for karmic + milestoned to ubuntu-9.10; please update LP accordingly
[16:48] <smoser> will do that now.
[16:49] <mdz> [action] smoser to follow up with mdz regarding UEC image testing capability
[16:49] <MootBot> ACTION received:  smoser to follow up with mdz regarding UEC image testing capability
[16:49] <mdz> [topic] EC2 AMIs, including review of active bugs (smoser)
[16:49] <MootBot> New Topic:  EC2 AMIs, including review of active bugs (smoser)
[16:49] <mdz> [link] https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=ec2-images
[16:49] <MootBot> LINK received:  https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=ec2-images
[16:49] <mdz> only one High there, and it's the (same) MIR
[16:49] <smoser> the plan-to-fix list is the same for ec2 as it is for uec.
[16:49] <smoser> right.
[16:49] <mdz> zul: is there anything blocking getting that MIR completed this week?
[16:50] <zul> mdz: just fixing the testusite
[16:50] <mdz> smoser: are you feeling confident about the UEC and EC2 kernels at this stage?
[16:51] <mdz> [action] zul to fix m2crypto test suite and ensure that MIR is processed
[16:51] <MootBot> ACTION received:  zul to fix m2crypto test suite and ensure that MIR is processed
[16:51] <smoser> well, the ones we have and have been using surely seem solid (no issues have been raised)
[16:51] <smoser> jjohansen has put up some others with tweaked configs (bug 428692)
[16:51] <ubottu> Launchpad bug 428692 in ubuntu "ec2 kernel needs CONFIG_BLK_DEV_LOOP=y and other config changes" [Medium,Confirmed] https://launchpad.net/bugs/428692
[16:52] <mdz> smoser: until recently, as noted earlier, we weren't testing the exact bits in the UEC kernel+initramfs, so we might want to test more thoroughly there
[16:52] <mdz> am I remembering correctly that the UEC image won't boot in plain KVM because it tries to contact the metadata service?
[16:52] <smoser> that is correct, however, now there is a workaround
[16:52] <smoser> you can pass kernel param ec2init=0
[16:53] <mdz> kirkland: ttx: meanwhile, could you spare some UEC cycles to help test the images this week?
[16:53] <smoser> or mount image and modify /etc/ec2-init/.... have to look it up
[16:53] <mdz> smoser: oh, good to know
[16:53] <ttx> mdz: sure.
[16:53] <mdz> [topic] Virtual appliance - reference appliance (soren)
[16:53] <MootBot> New Topic:  Virtual appliance - reference appliance (soren)
[16:53] <kirkland> mdz: yes, i can do that
[16:53] <kirkland> smoser: please PM me the url to the images you want tested
[16:53] <mdz> ttx, kirkland, thank you
[16:53] <ttx> smoser: same, ping me when you need one tested
[16:54] <mdz> soren: we seem to be in a tight spot with regard to the reference appliance; there is some disagreement on the exact requirements
[16:54] <soren> Oh, I didn't prepare for this.
[16:54] <smoser> i will verify, but i think that output of nightly build should have valid kernel/ramdisk now
[16:54] <soren> mdz: Yes, very much so.
[16:54] <mdz> it is critical that we get this resolved ASAP
[16:55] <soren> mdz: Yes. Who actually defines these requirements? Who is the authoritive person to ask?
[16:55] <mdz> niemeyer: soren: what do we need to do in order to resolve this? we don't have time to discuss here but I think you need to hold a separate meeting about this
[16:55] <mdz> soren: I'll do for the moment
[16:55] <soren> mdz: I'm feeling slightly wiser than yesterday on the subject, but there's still a lot of open questions.
[16:55] <soren> mdz: Ok.
[16:56] <soren> We can do a meeting tomorrow, perhaps?
[16:56] <mdz> [action] soren/niemeyer to arrange a meeting to discuss reference appliance plan of action
[16:56] <MootBot> ACTION received:  soren/niemeyer to arrange a meeting to discuss reference appliance plan of action
[16:56] <mdz> [topic] Image store status (niemeyer)
[16:56] <MootBot> New Topic:  Image store status (niemeyer)
[16:56] <soren> I believe I'm free all day (until 16:00 UTC)
[16:56] <mdz> niemeyer: how are we doing on this front?
[16:57] <niemeyer> mdz: I will provide mathiaz with an updated version with a couple of very minor changes today
[16:57] <niemeyer> mdz: I don't envision further changes at this point, except for any bug fixes we find necessary
[16:57] <mathiaz> niemeyer: did you rework the gpg integration?
[16:57] <mdz> niemeyer: is the version in karmic functional, to the point where it can be tested with the fake server?
[16:57] <niemeyer> mathiaz: "rework" as in "add the --homedir" option?
[16:58] <mathiaz> niemeyer: yeah :D
[16:58] <niemeyer> mdz: Yes, absolutely.. I've been testing it here
[16:58] <mathiaz> mdz: the next issue is - what should be put in the fakestore?
[16:58] <niemeyer> mdz: Mathiaz and Daniel have instructions to run it
[16:58] <mathiaz> niemeyer: do you have an appliance to put in the store?
[16:58] <niemeyer> mathiaz: Ok, "rework" is a little strong then.. :)
[16:58] <niemeyer> mathiaz: Yes, I've added the option with tests and all
[16:58] <mathiaz> niemeyer: great to hear that
[16:58] <mdz> mathiaz: are niemeyer's testing instructions in the testcases wiki yet?
[16:59] <mathiaz> mdz: not that I know of
[16:59] <mathiaz> mdz: I've got them in an email
[16:59] <mdz> [action] mathiaz to document test plan for image store
[16:59] <MootBot> ACTION received:  mathiaz to document test plan for image store
[16:59] <niemeyer> mathiaz: Yes, I haven an "appliance"
[16:59] <niemeyer> mathiaz: I have an image I downloaded from the Eucalyptus web site
[16:59] <mathiaz> mdz: and all this image-store testing depends on having a working UEC cloud
[16:59] <niemeyer> mathiaz: Any image which works with Eucalyptus should be good for testing the image store proxy
[16:59] <mathiaz> niemeyer: ok.
[17:00] <mdz> mathiaz: maybe you could ask kirkland or ttx to run the test plan and correct as necessary
[17:00] <kirkland> mdz: sure, i've edited it slightly almost every time I've run it
[17:00] <mathiaz> mdz: sure. I'll keep in touch with dustin here.
[17:00] <mdz> kirkland: after your sprint, will the new test rig be available? perhaps it could go back with mathiaz so we add an additional tester for karmic
[17:01] <mdz> kirkland: I mean the image store test plan, which isn't in the wiki yet
[17:01] <niemeyer> kirkland, mathiaz: Please ping me if you need any help with whatever
[17:01] <kirkland> mdz: Estimated Delivery Date:        10/19/2009  :-(
[17:01] <mdz> niemeyer: any other actions needed in the coming week?
[17:01] <mdz> kirkland: oh, never mind
[17:01] <kirkland> mdz: but i do have a 2-machine cluster already
[17:01] <mdz> we're over time and need to wrap up
[17:01] <niemeyer> mdz: As far as the image store proxy goes, I don't think so
[17:01] <kirkland> mdz: we'll run with the 2 systems we have here now
[17:01] <niemeyer> mdz: There's that other topic about the "Services" tab.. I don't know where to fit this
[17:02] <mdz> niemeyer: let's take that off-meeting
[17:02] <mdz> [topic] assigned bugs
[17:02] <MootBot> New Topic:  assigned bugs
[17:02] <niemeyer> mdz: Ok
[17:02] <mdz> there are a bunch of importance-Undecided bugs on this list
[17:02] <mdz> [topic] http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[17:02] <MootBot> New Topic:  http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[17:02] <mdz> mostly assigned to zul, and one to soren
=== MikeB is now known as Technoviking
[17:03] <mdz> [action] zul to triage his assigned bugs
[17:03] <MootBot> ACTION received:  zul to triage his assigned bugs
[17:03] <zul> mdz: ill go through that list today
[17:03] <mdz> the highest importance triaged bugs on that list are the vmbuilder ones, assigned to soren
[17:03] <mdz> both targeted to karmic
[17:03] <soren> I've got some VMBuilder time scheduled for tomorrow.
[17:03] <soren> I expet to be able to cover it there.
[17:03] <soren> expect, even.
[17:03] <mdz> soren: glad to hear it, thanks
[17:03] <mdz> [topic] AOB
[17:03] <MootBot> New Topic:  AOB
[17:04] <mdz> I'm going to be out of the office next week, please contact ttx in my absence
[17:04] <soren> Well, there's the meeting time thing, but that's an item of its own.
[17:04] <soren> Right?
[17:04] <mdz> soren: take it to email?
[17:05] <soren> I tried. Noone answered.
[17:05] <ttx> soren: I did ;)
[17:05] <soren> ttx: orly?
[17:05] <mdz> I don't see it in my inbox, but I'll follow up separately
[17:05] <soren> Oh, to the original one?
[17:05] <mdz> thanks, all
[17:05] <soren> right, right.
[17:05] <mdz> #endmeeting

MeetingLogs/Server/20091006 (last edited 2009-10-08 09:30:54 by ttx)