14:06:41 <mburns> #startmeeting oVirt Weekly sync 14:06:41 <ovirtbot> Meeting started Wed Oct 9 14:06:41 2013 UTC. The chair is mburns. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:06:41 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:06:49 * mburns apologizes for being late 14:07:00 <mburns> #topic agenda and roll call 14:07:06 * danken is here 14:07:08 * sbonazzo here 14:07:17 <mburns> #info 3.3 updates 14:07:17 * orc_orc is here 14:07:24 <mburns> #info 3.4 planning 14:07:25 * sahina here 14:07:31 <mburns> #info conferences and workshops 14:07:34 <mburns> #info infra update 14:08:42 <mburns> #topic 3.3 updates 14:08:54 <mburns> #info 3.3.0.1 vdsm packages are posted 14:08:59 <mburns> #undo 14:08:59 <ovirtbot> Removing item from minutes: <MeetBot.items.Info object at 0x9b815cc> 14:09:04 <mburns> #info 3.3.0.1 vdsm packages are posted to updates-testing 14:09:15 <mburns> sbonazzo: any update on 3.3.0.1 engine packages? 14:09:47 <sbonazzo> tracker bug shows still 1 bug in assigned 14:10:09 <sbonazzo> but I'm not sure it should be still blocking 14:10:16 <sbonazzo> since it seems to be a centos bug 14:10:33 <sbonazzo> https://bugzilla.redhat.com/show_bug.cgi?id=1009100 14:10:36 <danken> Bug 1016461 - [vdsm] engine fails to add host with vdsm version 4.13.0 14:10:48 <danken> engine 3.3.0.1 should have it. 14:11:10 <danken> without it, engine-3.3.0.1 won't accept ovirt-3.3.1 nodes. 14:12:29 * danken is adding it to the tracker, with your permission. 14:12:41 <mburns> danken: that bug is against vdsm -- is there an equivalent bug against engine? 14:12:56 <mburns> (and also, that's a rhev bug, not an ovirt bug) 14:13:57 * danken is moving the component 14:15:45 <mburns> ok, so there are 2 bugs that are blocking 3.3.0.1 14:15:46 <danken> mburns: I do not see how cloning the bug to ovirt is helpful, but I'm sure that it can be done. 14:16:02 <mburns> danken: more for tracking purposes 14:16:12 <mburns> fsimonce`: ping -- any updates on 1009100 ? 14:16:43 <mburns> danken: but i'm not overly concerned either way 14:18:04 <mburns> sbonazzo: how much time do you need to turn around 3.3.0.1 builds once you have the patches acked? 14:18:16 <itamar> mburns, do we need cloning or just blocking the tracker? 14:18:20 <fsimonce`> mburns, no I have no news on that one yet 14:18:22 * fabiand is here 14:18:33 <mburns> itamar: in general, a clone is better 14:18:45 <mburns> because a bug can be POST in RHEV, but on_qa in ovirt 14:19:10 <fsimonce`> mburns, he needs qemu-kvm-rhev 14:19:22 <itamar> also, the only way to fix 3.3.0.1 engine to get 3.1 node it to upgrade it. but when we do 3.3.1, engine would probably be upgraded to 3.3.1 engine by then. so not sure worth fixing for 3.3.0.1? 14:19:34 <mburns> fsimonce`: ok, so it's an el6 issue with missing features 14:19:34 <sbonazzo> mburns: the time to make the tarball, post it to the jenkins job and wait for its completion. Then I'll have to do a basic sanity test. I think it may take ~4 hours testing included 14:19:40 <dneary> mburns, I don't want community members to have to know about the inner workings of our product bug workflow 14:19:43 <fsimonce`> mburns, yes 14:20:12 <mburns> ok, that's not a real blocker 14:20:17 <mburns> dneary: i agree 14:20:28 <mburns> i'm backtracking off my "no overly concerned either way" 14:20:37 <mburns> s/no/not 14:21:12 * lvernia here 14:22:22 <mburns> itamar: only question on my mind is whether someone will be impacted by not fixing it in 3.3.0.1 14:22:45 <mburns> itamar: if someone is running 3.3.0.1 engine and testing 3.3.1 vdsm on a single node, it won't work 14:22:47 <danken> itamar: don't you think some people would like to upgade their nodes first 14:22:52 <danken> then their Engine? 14:23:09 <mburns> iiuc, it's a small, low risk patch 14:23:34 <mburns> so i would think that including it would be fine 14:24:07 * mburns wonders why logic isn't vdsm >= X.Y.Z for certain cluster levels 14:24:15 <mburns> would solve this in the future 14:25:36 <itamar> they would need to upgrade their engines. the patch is a one liner (actually, its a config change), i don't mind either way. lets just get 3.3.0.1 out and 3.3.1 for testing... 14:26:13 <mburns> itamar: agreed, but if it's a one liner, let's get it merged and then get 3.3.0.1 built 14:26:21 * mburns removes assigned bug from list 14:26:33 <mburns> it's due to missing features in qemu-kvm in centos 14:27:23 <danken> heh, we've just been talking about feature reporting in vdsm-devel.... 14:27:51 <mburns> sbonazzo: i think we can merge the one fix for vdsm version 14:27:55 <mburns> and then build 3.3.0.1 14:28:14 <sbonazzo> mburns: so it remains only to clone https://bugzilla.redhat.com/show_bug.cgi?id=1016461 to ovirt and merge that patch right? 14:28:29 <mburns> sbonazzo: yes, i think that's it 14:28:57 <sbonazzo> mburns: it's ok if I'll build it tomorrow morning? 14:29:14 <mburns> sbonazzo: no issue from me 14:29:18 <sbonazzo> itamar: ? 14:29:22 <mburns> just send me links to the jenkins build when it's done 14:29:35 <mburns> #info 2 open bugs blocking 3.3.0.1 14:29:47 <itamar> sbonazzo: sure. lets backport it and release 3.3.0.1 14:29:49 <mburns> #info 1 is deferred due to qemu-kvm feature set in el6 14:30:01 <mburns> #info other is allowed versions for vdsm 14:30:13 <mburns> #info vdsm version bug will be backported to 3.3.0.1 today 14:30:22 <mburns> #action sbonazzo to build engine 3.3.0.1 tomorrow 14:30:31 <sbonazzo> itamar: ok so I'll push the patches for the build after the meeting and build and testing tomorrow morning 14:30:32 <mburns> #action mburns to post 3.3.0.1 to ovirt.org tomorrow 14:30:46 <mburns> #info expected release: next week 14:30:53 <mburns> ok, moving on to 3.3.1 14:31:03 <mburns> danken: any update on vdsm rebase status? 14:31:26 <mburns> tentative schedule has us building and posting 3.3.1 next week 14:31:31 <mburns> (as a beta( 14:31:49 <danken> 4.13.0 dtagged 14:31:54 <danken> *tagged 14:32:00 <danken> glusterfs bug solved 14:32:12 <itamar> is there a vdsm as well for 3.3.0.1 or only engine? 14:32:17 <danken> ovirt-3.3 branch exists and accepts bugfixes 14:32:24 <danken> itamar: yes. 14:32:34 <danken> dougsland has built one earlier today 14:32:40 <danken> (his yesterday...) 14:32:41 <itamar> good. thanks 14:32:59 <mburns> itamar: it's already posted in updates-testing 14:34:24 <danken> the vdsm build includes the one-liner that makes glusterfs-backed vDisks usable. 14:35:01 <danken> we should add this to the 3.3.0.1 release notes. 14:36:18 <mburns> danken: so nothing that would block 3.3.1 from being build and posted as a beta next week? 14:36:38 <mburns> danken: can you or someone from vdsm provide notes for the 3.3.0.1 updates? 14:36:54 <mburns> sbonazzo: same question as ^^ for engine updates for 3.3.0.1 ? 14:37:01 <danken> mburns: sure, make it my #action. 14:37:35 <sbonazzo> mburns: I'll try to provide the needed updates 14:37:56 <mburns> #action danken and sbonazzo to provide release notes for 3.3.0.1 14:38:53 <mburns> #info 3.3.1 -- vdsm should be ready for beta posting next week 14:39:03 <mburns> sbonazzo: how is engine 3.3.1 looking? 14:39:45 <sbonazzo> mburns: I'm checking bugs targeted for 3.3.1, waiting for bugzilla to answer 14:40:29 <mburns> ok 14:40:30 <itamar> sbonazzo: i'm not sure all targeted to 3.3.1 are blockers for 3.3.1. 14:41:13 <sbonazzo> mburns: itamar: it seems bugzilla is not working right now 14:41:32 <danken> sbonazzo: here it works.. 14:42:36 <mburns> sbonazzo: ok, let's keep 3.3.1 target for next wednesday 14:42:44 <sbonazzo> itamar: mburns: I can see only 3 bugs in post targeted for 3.3.1 14:43:00 <sbonazzo> and 2 on reports also in post 14:43:24 <mburns> #info engine looks to be in good shape for 3.3.1 (only 3 bugs, all in post) 14:43:35 <mburns> #info plan is to post beta by next Wednesday (16-Oct) 14:43:43 <mburns> #info with release around end of October 14:43:53 <itamar> sbonazzo: ok, please check with assignees if they think these are 3.3.1 blockers or not. 14:44:10 <sbonazzo> itamar: ok 14:45:34 <mburns> ok, anything else for 3.3 updates? 14:45:51 <itamar> then we'll have the beta, and see if there are any blockers (which I'd count as regressions from 3.3.0, not new bugs which could wait for 3.3.2, etc.) 14:47:09 <sbonazzo> mburns: anything else from me 14:47:23 <mburns> ok, then we can move on 14:47:27 <mburns> #topic 3.4 planning 14:47:50 <mburns> itamar: is the plan for 3.4 planning to hold off until the meetings at KVM Forum? 14:48:01 <itamar> well, i think we can start discussing. 14:48:32 <itamar> I wanted to propose to change to a monthly cadence, in "same minor version", but we're not ready for this yet on infra of the code in engine/vdsm. 14:48:42 <itamar> i think we should go with smaller releases 14:48:50 <itamar> as the stabilization cycle is too long right now 14:48:57 <itamar> and GA slips because of that, etc. 14:49:02 <mburns> itamar: so become more agile 14:49:15 <mburns> work more in sprints rather than long cycles? 14:49:34 <itamar> mburns: yes. that's what i wanted to push. but sprints which are released, not remain in git only. 14:49:42 <mburns> right 14:49:52 <itamar> but we can't do that for 3.4, so i want to do a "small release", moving that way. 14:49:56 <orc_orc> itamar: so more time boxed, and accept frammage that then gets fixes streamed in? 14:50:00 <itamar> also add more time on stabilization. 14:50:20 <itamar> orc_orc: yes. not sure what frammage means? 14:50:40 <orc_orc> breagave -- some geekish form of damage -- I forget the source 14:50:41 <itamar> i was thinking freeze late december, then stabilize january. 14:51:07 <itamar> orc_orc: well, the idea was to also make sure master is kept stable. not reduce quality. 14:51:08 <mburns> itamar: and release late Jan early Feb? 14:51:15 <itamar> mburns: yes. 14:51:28 <orc_orc> itamar: I dont see end to end tests to support doing that presently 14:52:46 <itamar> orc_orc: that's part of the changes, make system tests on master more visible. hence i said we're still not ready for montly release, but i still want to move to smaller releases. 14:52:47 <ewoud> orc_orc: I think that's also what itamar meant by not ready code wise 14:53:16 <orc_orc> * nod * .. I send a patch to fabiand yesterday for my testing infra here 14:53:16 <itamar> so we're not talking continuous delivery yet. just a smaller release on the way there. 14:53:31 <mburns> itamar: so roughly -- update releases (3.3.1, 3.3.2) every month, bigger releases (3.4.0, 3.5.0) roughly every 3-4 months? 14:53:45 <ewoud> I wonder if it would be useful if vdsm and engine releases were separated and worked more with feature flags, but there was already some discussion about that on the vdsm side I think 14:53:47 <itamar> yes. 14:54:00 <itamar> ewoud: that's part of the "not ready yet" for monthly releases... 14:54:13 <mburns> feature negotiation... 14:54:14 <itamar> ewoud: discussions on this started (see last vdsm call for example) 14:54:40 <itamar> yes - as i said, we aren't there for this one. hence just "smaller", not monthly, etc. 14:54:40 <ewoud> itamar: I saw that yes 14:55:14 <mburns> itamar: i think this is a good approach 14:55:25 <mburns> but probably needs discussion on arch@ 14:55:28 <mburns> or board@ 14:56:58 <apuimedo> the feature negotiation in vdsm is under discussion, but it seems like there is some resistance 14:57:00 <apuimedo> :P 14:57:08 <danken> my problem with this approach is that folks may assume that 3.3.2 is a safe bugfix version of 3.3.1 14:57:11 <mburns> #info rough planning -- dev until end of december 14:57:21 <mburns> #info stabilization/beta/etc during january 14:57:23 <itamar> apuimedo: i don't want to block on it for 3.4. 14:57:34 <mburns> #info release late January or early February 14:57:36 <danken> where in effect, it includes new feature that are likely to cause refressions. 14:57:39 <apuimedo> itamar: Indeed. I don't think it's gonna be for 3.4 in any case 14:58:02 <itamar> I'll send to board an email on going to faster schedule. 14:58:15 <apuimedo> Looking forward to the faster schedule 14:58:36 <danken> itamar: ^^ it may heart our more reserved users 14:59:02 <danken> would would like to get bugfixes in 3.3.z, not bleeding-edge features. 14:59:06 <mburns> #action itamar to send email to board@ to discuss high level schedules 14:59:23 <apuimedo> danken: I also considered that. I think we should pick some monthly releases 14:59:33 <apuimedo> like one in three or so 14:59:41 <apuimedo> that have a bit longer stabilization 15:00:02 <mburns> let's take these thoughts/discussions to the mailing list 15:00:06 <apuimedo> ok 15:00:19 <mburns> that way everyone gets their voice heard 15:00:40 <mburns> #topic Conferences and Workshops 15:00:53 <danken> mburns: I thought kareoke machines are for that, not mailing lists... 15:01:01 <mburns> danken: ;-) 15:01:15 <mburns> #info see the wiki home page for upcoming conferences 15:01:26 <itamar> mburns: sent to board ;) 15:01:29 <mburns> #info big one is KVM Forum in Edinburgh in 2 weeks 15:01:44 <itamar> apuimedo: agree on monthly releases, when we can do them... 15:02:01 <mburns> #topic infra update 15:02:08 <mburns> ewoud: eedri_: any infra updates? 15:02:27 <itamar> apuimedo: i don't want to "run" the cluster levels every month, etc. hence we need feature negotiation. we also need it since some features are not available on .el6 but on fedora, or not in ubuntu, or not in ppc... 15:02:47 <ewoud> mburns: not that much 15:02:58 <apuimedo> itamar: I agree wholeheartedly with the feature negotiation for the same reasons 15:03:06 <itamar> sorry, have to go now. see you (all?) in kvm forum :) 15:03:07 <apuimedo> for me it should be something like cpu flags 15:03:15 <ewoud> mburns: mostly continued to work on existing tasks 15:03:17 <eedri_> mburns, we installed new artifactory.ovirt.org server 15:03:32 <mburns> #info continued work on existing tasks 15:03:37 <apuimedo> for infra, dcaro and I took to the task that checks installability of new vdsm releases to run each time the spec file is modified by a proposed patch set 15:03:39 <mburns> #info artifactory.ovirt.org setup 15:03:40 <itamar> mburns: I'm planning to discuss there planning/tracking the version better via feature items in bugzilla, etc. 15:03:48 <apuimedo> mburns: ^^ 15:03:54 <danken> eedri_: have you seen markwu's request about Fedora kernel? 15:04:00 <eedri_> danken, no 15:04:11 <eedri_> danken, you mean installing new f20 slave? 15:04:13 <danken> request to upgrade it on slaves. 15:04:14 <mburns> #info increased effort into continuous integration in jenkins 15:04:22 <apuimedo> danken: I just saw that in the bugzilla it has been moved to f20 15:04:24 <danken> no, f19 slave 15:04:34 <eedri_> danken, was there an email on it/. 15:04:44 <danken> yes. 15:04:53 <sbonazzo> mburns: about conferences, OpenStack @ LD2013 Rome / Italy on October 26th, not sure if relevant 15:04:56 <mburns> itamar: ack 15:04:58 <eedri_> danken, must have missed it, what was the request - to update slaves? 15:05:04 <danken> eedri_: "Kernel upgrade reques" to infra@ 15:05:12 <apuimedo> eedri_: danken: https://bugzilla.redhat.com/show_bug.cgi?id=1005567 15:05:24 <apuimedo> It is in both 15:05:34 <danken> eedri_: yes 15:05:36 <eedri_> ewoud, dcaro maybe we should install fabric on upstream 15:05:38 <apuimedo> eedri_: for f19 machines it is kernel-3.11.3-201.fc19 15:05:51 <danken> apuimedo: is glusterfs already updated there? 15:05:57 <apuimedo> danken: indeed ;-) 15:06:37 <apuimedo> I just got a ifup issue on my el6 machine, it might be akin to this kernel bug markw reported, I'll have to investigate 15:06:51 <apuimedo> heaven is against my patch verification... 15:06:54 <mburns> sbonazzo: openstack? 15:07:32 <ewoud> eedri_: we still need a session to determine a sort of roadmap I think 15:07:39 <danken> apuimedo: I heard no update about our request to run the vdsm dependency check on each patch 15:07:57 <apuimedo> danken: I put it a few lines above 15:08:02 <apuimedo> 17:03:42 15:08:11 <eedri_> ewoud, so for now manual update to slaves? 15:08:13 <sbonazzo> mburns: there will be an introductory talk 15:08:15 <eedri_> ewoud, with yum 15:08:15 <apuimedo> mburns: did you see it? 15:08:49 <eedri_> ewoud, danken we're updating it now 15:09:07 <mburns> sbonazzo: if you want it captured on the main page, send it to me offline, and i'll add it 15:09:09 <danken> apuimedo: ah, but is it done? 15:09:12 <danken> eedri_: thanks! 15:09:13 <mburns> apuimedo: did i see what? 15:09:19 <apuimedo> danken: of course it is 15:09:30 <sbonazzo> mburns: ok 15:09:38 <ewoud> eedri_: I'd like to use mcollective eventually since it integrates with puppet, but some sort of solution would be nice 15:09:39 <apuimedo> mburns: that dcaro and I got the task that checks installability of new vdsm releases to run each time the spec file is modified by a proposed patch 15:09:48 <apuimedo> it's an infra update 15:09:49 <apuimedo> I'd say 15:10:13 <mburns> apuimedo: yes, i lumped it into "continuous integration" 15:10:13 <danken> apuimedo: yeah, but from the English it's hard to understand that it's a fait acomplis. 15:10:15 <mburns> but i can call it out specifically 15:10:22 <ewoud> eedri_: danken I didn't see a kernel update mail 15:10:25 <apuimedo> nah... That's fine 15:10:36 <mburns> #info apuimedo and dcaro worked on checking installability of vdsm when spec is modified 15:10:41 <apuimedo> danken: yes, sorry. it was not that clear 15:10:49 <mburns> ok, any other high level infra updates? 15:11:10 <eedri_> mburns, in process adding ovirt-3.3 branch for vdsm jobs 15:11:19 <eedri_> mburns, till now it monitored only master branch 15:11:30 <apuimedo> "The jenkins job that checks vdsm dependencies to see if they are in fedora and el6 repositories now runs on each patchet creation that modifies vdsm.spec.in" 15:11:32 <mburns> #info adding ovirt-3.3 branch to vdsm jobs (instead of just master) 15:11:35 <apuimedo> danken: ^^ 15:12:01 <eedri_> apuimedo, isn't it failing on centos? 15:12:22 <apuimedo> eedri_: I'll check it. I don't remember 15:12:24 <apuimedo> :P 15:12:41 * mburns moves on (not to discourage other discussions, but they're specific issues that need working out, not things to cover on the weekly meeting 15:12:47 <mburns> #topic Other Topics 15:12:51 <mburns> anything else? 15:13:31 <apuimedo> eedri_: currently it fails for both due to the glusterfs dep, I think. But I'll look at centos closer 15:13:52 <apuimedo> mburns: nothing further on my side 15:13:56 <mburns> going once... 15:14:07 <mburns> apuimedo: do you have gluster 3.4 repo enabled? 15:14:15 <mburns> el6 requires it... 15:14:23 <mburns> f19 should *just work* 15:14:29 <apuimedo> mburns: it should 15:14:41 <mburns> going twice.. 15:14:42 <apuimedo> I'll check tomorrow with David about the gluster 3.4 repo 15:14:52 <apuimedo> thanks 15:14:54 <mburns> gone. 15:14:57 <mburns> thanks all 15:14:59 <mburns> #endmeeting