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