15:00:57 <rbergeron> #startmeeting oVirt Weekly Sync Meeting
15:00:57 <ovirtbot> Meeting started Wed Jan 25 15:00:57 2012 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:57 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:04 <rbergeron> #meetingname oVirt Weekly Sync Meeting
15:01:04 <ovirtbot> The meeting name has been set to 'ovirt_weekly_sync_meeting'
15:01:21 <rbergeron> #chair quaid oschreib
15:01:21 <ovirtbot> Current chairs: oschreib quaid rbergeron
15:01:37 <rbergeron> #topic Agenda
15:01:57 <rbergeron> I don't have much of a plan, after being out last week - we should probably do some status updates, check in on events, and I think that's about it.
15:02:08 <rbergeron> I am not sure how much status we can get with TLV being down, but we can try.
15:02:16 <rbergeron> anyone else have anything they want to cover?
15:02:20 * steveg_afk is here
15:02:28 * quaid is here
15:02:37 * oschreib is herre
15:02:47 <zwu|away> zwu|away: here
15:02:47 <rbergeron> hey quaid :) do you have anything offhand that you know needs to be covered?
15:02:49 <oschreib> rbergeron: first release is in a week :)
15:02:49 <sgordon> >.>
15:03:00 <rbergeron> oschreib: yar, we'll get to that :)
15:03:07 <sgordon> yeah, which means i will probably complain about release notes shortly
15:03:10 <sgordon> ;p
15:03:14 <oschreib> lol
15:03:16 <quaid> rbergeron: just worth a mention (which here I am doing it) that jbrooks & I have been working on a generic slide presentation
15:03:19 <oschreib> normal sync meeting
15:03:36 <quaid> and we'll have a new version ready soon
15:03:45 <rbergeron> okay. :)
15:03:53 <rbergeron> #topic Release Status
15:04:01 <rbergeron> oschreib: want to give a quick update? :)
15:04:13 * rbergeron wonders if she can type a sentence without a smiley face, lol
15:04:15 <oschreib> release is next week
15:04:25 <oschreib> 31 JAN
15:04:37 <rbergeron> how are things looking for that?
15:04:46 <rbergeron> any blocking issues, etc?
15:04:50 <rbergeron> morning, mestery :)
15:05:01 * mestery yawns and sips his coffee.
15:05:03 * ovedo_wfh is here
15:05:10 <oschreib> rbergeron: looks promising, although we have few bugs that should be fixed
15:05:33 <rbergeron> oschreib: okay. do those bugs have a tracker against them?
15:05:43 <oschreib> we have http://www.ovirt.org/wiki/Releases/First_Release_blockers (hope that this isn't broken, I cant access it right now)
15:06:07 <oschreib> rbergeron: bug a bugzilla tracker would be nice.
15:06:42 <rbergeron> oschreib: there's nothing in the list on that wiki page
15:07:00 <oschreib> rbergeron: nothing? maybe it's not the right link
15:07:25 <rbergeron> http://www.ovirt.org/wiki/Releases/First_Release_Blockers
15:07:42 <oschreib> rbergeron: it should contain ~4 bugs
15:08:09 <oschreib> rbergeron: and about 3 more should be added
15:08:18 * ykaul is sorry for being late.
15:08:22 <oschreib> I hope that won't risk the first release date
15:08:25 * pmyers in a little late as well
15:08:31 <MarkBaker> ykaul, you and me both
15:08:36 <rbergeron> oschreib: okay. yeah, we should probably take a look at creating a tracker bug for release blockers
15:08:54 <rbergeron> oschreib: who's adding the bugs / deciding if they are blockers?
15:09:08 <rbergeron> is there any criteria or are we just coming to a general consensus
15:09:09 <oschreib> rbergeron: me / component owners
15:09:35 <mgoldboi> oschreib: please add me to the equation as well
15:10:05 <oschreib> rbergeron: I'm trying to follow the release criteria in the first_release page (maybe it should be updated)
15:10:13 <oschreib> and mgoldboi as well.
15:10:29 <oschreib> generally, we're trying to make the "basic steps" working
15:10:49 <rbergeron> oschreib: okay. at this point, we should really be tracking possible blockers closely, and making sure people aren't blocked on fixing blockers
15:11:13 <oschreib> rbergeron: we're
15:11:34 <oschreib> rbergeron: as things are pretty stable.
15:11:41 <oschreib> mgoldboi: any comments on ^^
15:11:41 <oschreib> ?
15:12:10 <mgoldboi> oschreib: i agree there are some things to take care of but on last build things are "stable"
15:12:50 <rbergeron> :) i know you guys are on top of it. just trying to make sure it is as transparent as possible to all involved
15:12:54 <rbergeron> (or interested, for that matter)
15:13:01 <sgordon> oo oo is it time for the release notes soap box?
15:13:01 <oschreib> rbergeron: sure
15:13:11 <oschreib> sgordon: in a minute
15:13:15 <sgordon> ;)
15:13:21 <rbergeron> oschreib: is there a plan next week for a day when we have a yes/no decision on if it's ready?
15:13:45 <oschreib> rbergeron: no, but I guess we should do such a plan
15:13:46 <rbergeron> it's usually helpful from the perspective of "make sure people announcing don't announce if it's not ready," etc.
15:14:03 <mburns> what's the timeframe for new vdsm packages being built?
15:14:11 <oschreib> rbergeron: Monday (30 JAN) sounds ok for everyone?
15:14:14 <sgordon> oschreib, where in the directory structure will be releasing the repo file / rpms for the release?
15:14:24 <rbergeron> oschreib: sure.
15:14:34 <oschreib> mburns: they're working on it ATM AFAIK
15:14:39 * mburns needs to know so he can rebuild ovirt-node
15:15:07 <oschreib> mburns: danken will be here in a minute
15:15:17 <mburns> oschreib: fyi, we're waiting on a kernel bug to support UEFI
15:15:34 <danken1> mburns: tonight I'll have a new build
15:15:36 <mburns> but we can release without that and spin an asynch node when the kernel update gets pushed
15:15:48 <mburns> danken1: final version? or possible respins?
15:15:53 <oschreib> mburns: do you think we should wait until it's in (in the cost of postponing the release)
15:16:19 * rbergeron wonders about the completeness of a "first release" without node
15:16:25 <danken1> mburns: currently deleting a snapshot is broken
15:16:34 <oschreib> rbergeron: the node is there, without UEFI support
15:16:36 <mburns> oschreib: UEFI has been our biggest blocker, but i *think* if it's the only thing still outstanding, then we should release without UEFI support
15:16:40 <danken1> and we know which patch broke it
15:16:57 <mburns> and i'll push out a new version ASAP after that with UEFI support
15:17:02 <danken1> for oVirt, I'll simply revert it
15:17:24 <danken1> mburns: so please, wait for vdsm-4.9.3.2
15:17:32 <mburns> danken1: ok, thanks
15:17:45 <danken1> unfortunately we have bad networking issues here
15:18:01 <mburns> danken1: yep
15:18:04 <danken1> so I cannot even fetch gerrit.ovirt.org to do the build now
15:18:09 <oschreib> mburns: depends if it's a matter of days or week from my perspective
15:18:20 <mburns> danken1: probably wouldn't build until tomorrow or friday at the earliest anyway
15:18:23 <oschreib> mburns: when do you think the UEFI will be ready?
15:18:27 <mburns> oschreib: let me dig up the bz number
15:18:42 <mburns> oschreib: our side is done, but we depend on a kernel patch
15:18:55 <mburns> i don't have a timeframe for that at the moment
15:19:00 <oschreib> mburns: ummmm
15:19:03 * oschreib wonders
15:19:19 <mburns> oschreib: https://bugzilla.redhat.com/show_bug.cgi?id=783211
15:19:38 <oschreib> mburns: no http here :)
15:20:13 <mburns> oschreib: bz is in post and apparently patch has some acks already
15:20:22 <oschreib> mburns:  rbergeron: what about releasing a "z-stream" for our first release?
15:20:27 <mburns> i'll ask for a timeframe for a new kernel including it
15:20:37 <oschreib> mburns: thanks, update me.
15:20:45 <oschreib> mburns: other than that, node is ready?
15:20:47 <mburns> oschreib: i'll add you as cc as well
15:21:05 <mburns> oschreib: we have a couple cosmetic things we're going to try to fix, but with new vdsm, we should be good to go
15:21:09 <rbergeron> whew. well... i'm really on the fence here about it
15:21:29 <oschreib> rbergeron: share your thoughts
15:21:56 <mburns> rbergeron: oschreib:  re: z-stream -- we should probably plan on having incremental builds of ovirt-node in between major releases anyway
15:22:00 <sgordon> if there is no timeframe for it at this stage, i would +1 going ahead and updating as a z-stream
15:22:02 <rbergeron> it's everyone else's call, since, you know, i can't actually do Technical Things, :) but I feel like with going after a rapid release schedule as is, it just introduces more complexity with "what's supported" and "who's got problems with us" and so on.
15:22:04 <mburns> to pick up other packages
15:22:10 <rbergeron> err, not with us, but with what.
15:22:33 <rbergeron> if we don't know when NextRelease will be, or have a target date in mind, then that makes things different.
15:22:34 <ykaul> mburns: builds are fine, you can have them nightly, but not releases. Unless there are some major issues (security?)
15:23:03 <oschreib> rbergeron: actually, we should talk about next release as well
15:23:27 <rbergeron> ideally part of what we're working towards here is having something easily consumable.
15:24:05 <rbergeron> and drawing hte line on what's critical and what's not - otherwise, we start having the downhill effect of "oh, this needs a last minute fix" and "this needs a z-stream" ...
15:24:41 <rbergeron> if it's critical enough that we need to do a z-stream....
15:24:58 <quaid> even though we're time-based, there is some value in slipping the schedule for a day or two (minor amount) if it helps the usability
15:25:10 <quaid> and if it helps reduce complexity :)
15:25:19 <oschreib> rbergeron: since it's the first release, and we WILL have problems, I thing releasing updates for once or twice won't kill us
15:25:42 <rbergeron> yeah. day, two, week.
15:26:00 <ykaul> quaid: HowTos on the wiki will be much more helpful than any fix.
15:26:01 <sgordon> i dont think we can make such a call to wait without the timeframe
15:26:08 <rbergeron> oschreib: and we also need to consider that releasing updates eventually means that we probably want to get each distro in sync, which means updating, etc.
15:26:09 <sgordon> we should have a go/no-go meeting next week imo
15:26:13 <rbergeron> sgordon: totally
15:26:28 <rbergeron> i think oschreib was proposing the 30th.
15:26:42 <sgordon> so for now proceed on the assumption that we are going ahead with a release on time, but if mburns comes back and says hey if you wait a week we can have UEFI
15:26:43 <rbergeron> i think we could probably also come up with a good list of "what needs to be in order at a go/no-go meeting to make the decision"
15:26:47 <sgordon> then we will evaluate that :)
15:27:12 <oschreib> rbergeron: we have that in the first release page, we should update it a bit
15:27:26 <quaid> I note that UEFI support is not on the MUST or SHOULD list for the release criteria :)
15:27:53 <rbergeron> oschreib: mind sending out an email with a time/location for a go/no-go, the link, etc?
15:27:54 <oschreib> quaid: well, I didn't thought of UEFI in the time I wrote that page
15:27:59 <oschreib> quaid: we can update it :)
15:28:03 <mgoldboi> oschreib: when do you want to have release build so we can go over it for a day or two?
15:28:04 <quaid> ah, ok then
15:28:15 <oschreib> rbergeron: I don't have any access to mail
15:28:21 <rbergeron> oschreib: ah, right
15:28:37 <sgordon> i think we could add UEFI as a SHOULD
15:28:38 <rbergeron> oschreib: can you do it when you can? assuming TLV isn't offline for a year
15:28:42 <rbergeron> ;)
15:28:49 <ykaul> oschreib: connect via wireless->VPN to AMS hub, and you can have email.
15:29:12 <oschreib> ykaul: I don't have VPN on my new laptop ATM
15:29:13 <oschreib> ykaul: nm
15:29:19 <ykaul> sgordon: I think UEFI is a MUST - we've heard way too many complaining about it.
15:29:24 <oschreib> I'll send this update tomorrow if it's not to late
15:29:36 * oschreib actually agrees with ykaul
15:29:57 <sgordon> well if that's the case then i think the previous discussion about going without it would be redundant no?
15:30:29 * mburns asked on BZ for a timeframe
15:31:09 <rbergeron> sgordon: pretty much
15:31:18 <oschreib> I don't think so
15:31:28 <oschreib> it's in the middle of MUST/SHOULD IMO
15:31:49 <sgordon> yeah, which in my mind is what makes it a SHOULD, sure we definitely want it if at all feasible
15:31:59 <sgordon> but would we postpone by more than a week or two for it?
15:32:10 <sgordon> if not, then it shouldnt be a MUST imo
15:32:10 <oschreib> sgordon: no
15:32:16 <oschreib> sgordon: i think
15:32:41 <ykaul> alternatively, I'd go with a patch for the installer that detects UEFI and issues a warning that it's not supported ATM. The current user experience is really bad.
15:33:37 <oschreib> bottom line, I think we might be smarter on Monday next week. (although it's pretty close to the release date)
15:33:53 <rbergeron> yeah.
15:34:04 <rbergeron> ykaul: you mean the user experience without UEFI?
15:34:21 <sgordon> yeah, if you have UEFI enabled and try installing you basically get no feedback
15:34:26 <sgordon> as to why it refuses to boot
15:34:42 * rbergeron wonders if anyone else has thoughts on how critical UEFI support is out of the box on the first release?
15:34:46 * rbergeron looks around
15:34:53 <sgordon> does anyone not? ;)
15:35:46 <jboggs`> uefi boxes *should* attempt legacy boot considering it did start the installer that way, cant detect uefi w/o being booted in uefi at this point either
15:36:15 <jboggs`> rhev should be much easier to fix uefi quicker than upstream node
15:38:00 * rbergeron looks for conclusions - i think sgordon probably had the best thought, just meet on monday, assess where we are at that point
15:38:09 <ykaul> jboggs`: so what's the bottom line? I see several options here: 1. Fix it 2. Patch the installer to refuse to install on UEFI for the time being - is that possible at all? 3. Ignore the issue for the time being (=release notes)
15:38:18 <mburns> rbergeron: +1
15:38:26 <oschreib> how bad would it be to delay the first release only on 30 JAN?
15:38:47 <yzaslavs> rgolan: ping
15:38:57 <yzaslavs> oschreib: still networking issues @ TLV?
15:38:59 <mburns> ykaul: 1 is done, but we have to wait for kernel build and push
15:39:04 <oschreib> yzaslavs: sure
15:39:06 <mburns> 2 is no possible
15:39:07 <yzaslavs> oschreib: oh
15:39:28 <mburns> 3.  is an option, but i think we can't decide for sure until we know the timeframe of #1
15:39:42 <mburns> s/no possible/not possible
15:40:02 <yzaslavs> mkolesni: ping
15:41:56 <mburns> ykaul: unfortunately no way to incorporate the kernel patch directly into the node as a workaround
15:42:34 <oschreib> any thought on the meaning of delaying the first release in the last second?
15:42:41 <ykaul> mburns: ok, so we need to have an ETA for 1, or go with 3.
15:42:48 <mburns> ykaul: yes
15:43:17 <mburns> oschreib: i think it's minimal impact if we slip a couple days
15:43:19 <ykaul> oschreib: "first impression last".
15:43:24 <mburns> bigger if we slip more than that
15:44:16 <mburns> oschreib: turn around once i get the kernel is a few hours+sanity testing
15:44:32 <oschreib> ok. lets wait to Monday.
15:44:54 <oschreib> anyone volunteers to send the mail about it? or I will have to do that tomorrow
15:45:07 <mburns> lets add it to the minutes
15:45:17 <mburns> and call it out specifically in the summary email
15:45:39 <mburns> then a separate email should be fine tomorrow
15:46:20 <sgordon> urgh
15:47:33 <mburns> ahh, we lost rbergeron at some point
15:48:13 <mburns> #chair
15:48:20 <mburns> #chair mburns
15:48:25 <mburns> bah...
15:48:30 <oschreib> #chair mburns
15:48:30 <ovirtbot> Current chairs: mburns oschreib quaid rbergeron
15:48:35 <mburns> ahh, thanks
15:48:58 <mburns> #info go/no-go meeting monday
15:49:08 <mburns> #info need info on UEFI status with node
15:49:19 <mburns> #link https://bugzilla.redhat.com/show_bug.cgi?id=783211
15:49:28 <mburns> ok, anything else for releases?
15:49:37 <sgordon> yup
15:49:45 <mburns> ahh, right, release notes
15:49:46 * sgordon gets on his soap box
15:49:58 <sgordon> so thankyou to those who have fleshed out their components in the last day or so
15:50:00 <sgordon> http://www.ovirt.org/wiki/Release_Notes
15:50:22 <sgordon> mainly i think i would additionally expect to see some info for node
15:50:37 <sgordon> and it might also be worth someone going over the engine section again
15:50:47 <mburns> sgordon: i know, hoping to get that done today
15:51:23 <mgoldboi> sgordon: what about some some documentation for the first version - i know we discussed about it on mail but at least extanding the wiki how tos
15:51:27 <sgordon> that said that still leaves no info in the page for: API, DWH, Packaging & Installer, Reports, Tools, User Portal, Web Admin Portal
15:51:44 <sgordon> my plan is to try produce a very quick publican generated install guide for something formal mgoldboi
15:51:50 <oschreib> sgordon: once again, I'll try to force component owners to do that (face to face)
15:51:57 <sgordon> which is why i was asking oschreib earlier where the RPMs are going in the tree
15:52:24 <oschreib> sgordon: tarbal under that stable/binary dir
15:52:44 <oschreib> sgordon: rpms under stable/fedora/16 directory
15:52:48 <ovirtbot> 14[[07Features/DBSchemaVersionCheck14]]4 !N10 02http://www.ovirt.org/w/index.php?oldid=1940&rcid=2008 5* 03Yair Zaslavsky 5* (+2742) 10Created page with "<!-- {{autolang|base=yes}} -->  == DB Schema version check ==  === Summary === This feature will allow checking if there is a parity between the DB schema version as calculated f..."
15:53:02 <sgordon> ok thanks, i will basically be taking the instructions from the wiki and modifying them for that
15:53:07 <sgordon> + adding a bit of a narrative
15:53:57 <mburns> tarballs should be under stable/src
15:54:00 <mburns> not binary
15:54:16 <oschreib> mburns: oh... mmm
15:54:17 <sgordon> oh yeah, additional action item
15:54:25 <sgordon> we probably should put checksums in the release notes?
15:54:43 <oschreib> sgordon: I'm putting md5sum file in the repo
15:54:51 <sgordon> fair enough, i can link that
15:55:14 <mburns> oschreib: binary should be for things like the node iso and/or engine *ar (war, ear, jar) that we release outside rpms
15:55:21 <oschreib> mburns: I'll create the src dir
15:55:22 <mburns> oschreib: at least IMO
15:55:28 <oschreib> mburns: you're right.
15:55:34 <ovirtbot> 14[[07Features/DBSchemaVersionCheck14]]4 !10 02http://www.ovirt.org/w/index.php?diff=1941&oldid=1940&rcid=2009 5* 03Yair Zaslavsky 5* (+107) 10
15:56:30 <mburns> sgordon: all set? or anything else to cover?
15:56:48 <sgordon> nope, that concludes my rant ;p
15:56:55 <oschreib> rbergeron: are you back?
15:56:56 <mburns> #info need release notes for API, DWH, Packaging & Installer, Reports, Tools, User Portal, Web Admin Portal
15:57:10 <mburns> #action oschreib to harass component maintainers for release notes
15:57:31 <oschreib> awesome.
15:57:46 <mburns> ok, so next topic...
15:57:51 <mburns> #topic events
15:58:04 <mburns> who has something to talk about w.r.t. events?
15:58:44 * mburns listens to crickets...
15:59:22 <mburns> #info nothing here...
15:59:24 <mburns> #topic Other Topics
15:59:29 <ovirtbot> 14[[07Features/DBSchemaVersionCheck14]]4 !10 02http://www.ovirt.org/w/index.php?diff=1942&oldid=1941&rcid=2010 5* 03Yair Zaslavsky 5* (+2222) 10
15:59:29 <mburns> anyone have other topics?
15:59:43 <xTs_w> (more crickets)
15:59:58 <quaid> where are we getting a wiki template with  in it?
15:59:59 * oschreib brrrr brrrrr brrrr
16:00:15 * mburns guesses all the talkative people got caught by the net split
16:00:40 <quaid> there is work going on for FOSDEM
16:01:17 * quaid meant <!-- {{autolang|base=yes}} --> in the wiki template
16:01:30 <quaid> that looks like something from fedoraproject.org/wiki
16:01:40 <quaid> anyway, about events ...
16:01:48 <quaid> FOSDEM needs an event page on the wiki
16:02:01 <quaid> so people who are talking about oVirt and related can coordinate anything
16:02:20 <quaid> I'll see if i can quickly work that up with jbrooks to be useful for the next event
16:02:24 <quaid> <eot>
16:02:24 <mburns> #info need wiki event page for FOSDEM
16:02:52 <mburns> #action quaid to work with jbrooks on event page for FOSDEM
16:03:06 <mburns> anything else?
16:03:18 * mburns starts countdown...
16:03:23 <mburns> 3...
16:03:31 <mburns> 2..
16:03:37 <mburns> 1.
16:03:43 <mburns> ok, thanks all
16:03:47 <mburns> #endmeeting