15:03:44 <doron_> #startmeeting oVirt Weekly Sync
15:03:44 <ovirtbot> Meeting started Wed Jan  8 15:03:44 2014 UTC.  The chair is doron_. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:44 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:03:48 * sbonazzo here
15:03:55 * orc_orc is here
15:04:02 * ybronhei presents infra group
15:04:06 * danken is here
15:04:10 * ecohen here
15:04:12 <doron_> #topic Agenda and roll Call
15:04:14 <doron_> #info 3.3 update releases
15:04:15 <doron_> #info 3.4 progress
15:04:17 <doron_> #info conferences and workshops
15:04:18 <doron_> #info infra update
15:04:20 <doron_> #info other topics
15:04:28 <doron_> ybronhei++ :)
15:04:41 <ybronhei> :P
15:04:44 <dneary> Hi all
15:04:48 <doron_> hi dave
15:04:53 <doron_> we just started
15:05:01 <doron_> #topic 3.3 update releases
15:05:20 * tal here
15:05:29 <doron_> sbonazzo: 3.3.x updates?
15:05:35 * lvernia here
15:06:03 <sbonazzo> 3.3.2 has been released last month, no plans yet for 3.3.3 but we've ~30 commits and ~30 bugs still open targeted to 3.3.3
15:06:14 <sbonazzo> http://red.ht/1cOYkMo
15:06:34 <itamar1> i think we should just do a 3.3.3 when we can (once we do a 3.4 alpha build) to clear the queue on 3.3.3?
15:07:20 <sbonazzo> itamar1: +1
15:07:23 <doron_> #info 3.3.2 has been released last month
15:07:41 <itamar1> doron_, so "3.3.3 will be built after the first 3.4 alpha build"
15:07:43 <bkp> doron Here
15:07:57 <doron_> itamar1: do we have time for 3.4 alfa or will it be beta?
15:08:07 <doron_> bkp: welcome ;)
15:08:47 <doron_> itamar1: ?
15:08:47 <sbonazzo> itamar1: what about the 30 bugs remaining for target 3.3.3? I don't think they'll be handled for 3.3.3 (not all at least)
15:09:40 <sbonazzo> doron_: itamar1: we can have alpha this week and postpone beta by 1 week
15:09:51 <itamar1> doron_ - we should do a 3.4 build as soon as we can. if its prior to january 15th (stable branch creation), I'd call it alpha.
15:09:52 <sbonazzo> http://www.ovirt.org/OVirt_3.4_release-management
15:10:28 <doron_> very well. So are wo OK with 3.4 alpha build this week?
15:10:29 <itamar1> i think it may take a few days to stabilize post stable branch creation, and I'm keen on having it tested. alpha repo could be based on nightlies as well, just a point in time we can reference.
15:10:49 <doron_> So are we OK with 3.4 alpha build this week?
15:11:08 <doron_> sbonazzo: ?
15:11:22 <sbonazzo> doron_: as itamar1 said, we can consider next nightly as alpha
15:11:50 <doron_> #agreed next nightly build will be 3.4 Alpha.
15:11:54 <sbonazzo> otherwise we can build it asking packagers to update versions and set tags
15:11:59 <itamar1> just move it to another repo, have it tested it works for sanity, then release for broader testing, and move MODIFIED bugs in it to ON_QA
15:12:16 <doron_> #agreed 3.3.3 will be built after the first 3.4 alpha build
15:12:26 <doron_> now it makes sense.
15:13:14 <doron_> moving next to 3.4
15:13:20 <sbonazzo> itamar1: my only concern is about package versioning
15:13:37 <sbonazzo> itamar1: vdsm is still 4.13.0 on nightly and it is 4.13.2 on stable
15:14:11 <danken> fsimonce: any problem of advancing it to 4.14 for 3.4alpha?
15:14:13 <itamar1> then lets ask vdsm to give us a better versioned build...
15:14:13 <doron_> sbonazzo: can we bump nightly?
15:14:14 <sbonazzo> itamar1: also -sdk had similar issue in december, not sure it has been fixed
15:14:39 <doron_> jhernand: ^^^^^
15:14:53 <sbonazzo> doron_: vdsm and -sdk just need to bump version and nightly will be update with new versioning
15:15:18 <doron_> danken: jhernand are you ok with it?
15:15:29 <fsimonce> danken, no problem if it makes things easier, beside that is there any meaning attached to the new version? new API? API freeze?
15:16:02 <danken> I want to get set cpu number into ovirt-3.4
15:16:14 <danken> so I'd like not to freeze the API yet.
15:16:19 <itamar1> fsimonce: no api freeze in an alpha build.
15:16:25 <doron_> danken: you can still do it in alpha
15:16:25 <sbonazzo> danken: what about 3.13.99 ?
15:17:02 <danken> sbonazzo: we can have .14 for alpha and .15 for GA.
15:17:05 <fsimonce> ok so it's just a bump, no problem for me
15:17:23 <sbonazzo> danken: as you prefer :-)
15:17:31 <doron_> danken: what will you do with re-spins?
15:17:43 <doron_> will you have .141?
15:17:55 <doron_> or .14-1?
15:18:31 <danken> .14.z
15:18:31 <ovirtbot> danken: Error: "14.z" is not a valid command.
15:18:41 <doron_> going forward this should be consumable for other distro's. Not all of them RPM based.
15:19:05 <doron_> but I'm fine with this for now.
15:19:15 <danken> doron_: what is "it"?
15:19:18 <doron_> Anyone here for SDK?
15:19:35 <doron_> danken: 14.z and 15.z
15:19:36 <danken> afaict vdsm can be released as a tarball as of today.
15:19:37 <itamar1> jhernand --^
15:19:52 <doron_> danken: very well.
15:20:02 <danken> doron_: is there any distro-specificness in 4.14.7?
15:20:11 <jhernand> itamar1: Sorry, what is the question?
15:20:34 <doron_> danken: no, as long as it makes sense to other packaging.
15:20:35 <itamar1> can we use nightly for 3.4 sdk/cli builds as-is. I see they are versioned for 3.4 already
15:20:38 <doron_> jhernand:
15:20:40 <itamar1> jhernand: --^
15:20:51 <doron_> jhernand: hi, we're looking into releasing an alpha
15:20:52 <itamar1> jhernand: i couldn't see one for the java sdk though in nightly?
15:21:10 <doron_> for 3.4. Can you verify nightly version > stable?
15:22:13 <sbonazzo> itamar1: doron_ it seems that sdk versioning in nightly has been fixed
15:22:18 <itamar1> doron_ i see nightly has many versions in it, both 3.3 and 3.4?
15:22:29 <itamar1> sbonazzo: but no java-sdk.
15:23:01 <sbonazzo> itamar1: right
15:23:09 <jhernand> For the SDKs we can generate them once the engine is generated, as we need to take the schema and RSDL from it.
15:23:27 <jhernand> So once we decide what is the git hash of the engine we can generate the corresponding SDKs.
15:23:38 <doron_> sbonazzo: jhernand can this be handled offline? All we need is a way to release 3.4.
15:23:45 <doron_> 3.4 alpha.
15:23:54 <sbonazzo> doron_: jhernand ok for me
15:24:30 <doron_> jhernand: ?
15:24:32 <jhernand> doron_: Ok.
15:24:41 <doron_> thanks.
15:25:08 <doron_> #agreed vdsm .14 for alpha, .15 for beta. -SDK to be sorted out offline.
15:25:21 <doron_> #topic 3.4 progress
15:25:37 <doron_> since we're close to branching / alpha
15:25:44 <doron_> let's do a quick round of updates.
15:26:00 <doron_> sahina: here for gluster?
15:26:06 <sahina> doron_, hi
15:26:13 <sahina> doron_, Monitoring volume capacity feature will not make it, of the other 2 - volume capacity feature under review, manage gluster async tasks already merged.
15:26:13 <sahina> I doubt though if all patches for volume capacity feature would be merged by Jan 15
15:26:56 <doron_> sahina: so volume capacity is at risk?
15:27:06 <sahina> doron_, yes
15:27:23 <itamar1> sahina: ok, i'm removing Monitoring (UI plugin) - Volume capacity monitoring to the other spreadsheet. also, please note if it is a ui plugin, you can release it async in sample-uiplugins. its just a plugin iiuc.
15:27:41 <sahina> itamar1, yes, that's right
15:27:43 <doron_> very well. We'll track it next week.
15:28:32 <doron_> #info gluster for 3.4: gluster async tasks merged. Monitoring volume capacity feature will not make it.  volume capacity at risk.
15:28:48 <doron_> Moving to ovirt engine infra
15:28:54 <doron_> ybronhei: ?
15:29:03 <ybronhei> doron_: the snmp should make it for Jan 15. authentication refactoring is only partial for now
15:29:12 <ybronhei> doron_: we won't make it for Jan 15
15:29:48 <ybronhei> doron_: we still don't have full implementation of the ldap provider
15:30:09 <itamar1> ybronhei: ldap provider is an extra feature. the refactoring should go in prior to stable branch though
15:30:14 <itamar1> (by the 15th)
15:30:21 <ybronhei> doron_: DWH trigger -engine's side already in, trigger heartbit will be merged next week
15:30:44 <doron_> ybronhei: anything else?
15:31:04 <ybronhei> itamar1: I didn't understand it that way, the refactoring includes also merging the providers
15:31:22 <doron_> ybronhei: and will DWH trigger be ready before Jan 15?
15:31:37 <itamar1> ybronhei: the existing providers are part of refactoring. the ldap provider in my understanding is a new provider?
15:31:40 <ybronhei> doron_: "allow to provide a password change url on login failure when password expires" depends on the authentication refactoring, so it won't make it as well probably
15:31:53 <ybronhei> doron_: yes, the trigger will be in
15:31:59 <doron_> thanks
15:32:07 <doron_> summing it all up-
15:32:15 <ybronhei> itamar1: it is
15:33:36 <doron_> #info ovirt engine infra ofr 3.4 status: snmp, DWH will be ready for January 15. Auth refactor and dependents at risk.
15:33:43 <ybronhei> itamar1: ok, i understand, only refactoring was promised to 3.4, the new providers can be delayed. so that's the case for now
15:34:04 <doron_> ybronhei: so will auth refactor make it?
15:34:46 <ybronhei> doron_: yes, only the new providers and the "allow to provide a password change..." won't
15:34:51 <itamar1> ybronhei: well, obviously we hope for new providers as well, but that depends on their status, risk, etc.
15:35:02 <doron_> ybronhei: won;t be or could be?
15:35:44 <ybronhei> doron_: in risk for now. probably won't
15:35:56 <doron_> #info ovirt engine infra ofr 3.4 status: snmp, DWH and Auth refactoring will be ready for January 15. New Auth providers at risk.
15:36:02 <doron_> thanks
15:36:13 <doron_> sbonazzo: here for integration?
15:36:21 <sbonazzo> doron_: yes
15:36:35 <doron_> sbonazzo: how are integration doing?
15:37:15 <sbonazzo> doron_: we're short on resource and time. hosted engine and uri rework are in
15:37:37 <sbonazzo> all the others I think won't make it for Jan 15th
15:38:04 <doron_> sbonazzo: in the spreadsheet you have 4 white tasks.
15:38:13 <doron_> all at risk?
15:38:42 <sbonazzo> alonbl or ydary_ may tell you better, but I don't think they'll be ready in 1 week
15:39:14 <doron_> sbonazzo: We'll consider at risk for now. let's track them next week.
15:39:33 <sbonazzo> doron_: ok
15:39:55 <doron_> #info integration status for 3.4: hosted engine and uri rework merged. Other tasks currently at risk.
15:40:07 <doron_> moving next to node. fabiand here?
15:40:59 <fabiand> doron_, hey
15:41:00 <doron_> I'll retry fabiand later.
15:41:06 <fabiand> doron_, I can give a short update
15:41:13 <doron_> fabiand: shoot
15:41:33 <fabiand> doron_, there is no new buidl for Node.Node team is not happy with this, but we are currently floodded with stuff
15:41:44 <fabiand> We plan to do a build as soon as our time permits it.
15:41:49 <fabiand> ETA - End of next week.
15:42:03 <doron_> fabiand: 875088	 ovirt-node-registration - a generic node registration status?
15:42:42 <fabiand> doron_, no update here.
15:42:52 <doron_> fabiand: can you check it for next week?
15:43:31 <fabiand> yes - should be getting better over the next weeks
15:43:35 <doron_> thanks.
15:43:46 <ydary> sbonazzo: ready for what?
15:43:53 <doron_> fabiand: as for 3.4 alpha, which node should we release?
15:43:57 <doron_> as an alpha
15:44:15 <fabiand> doron_, we don't have one yet to recommend
15:44:24 <doron_> :/
15:44:26 <fabiand> yeah
15:44:29 <doron_> thanks for the update.
15:44:31 <fabiand> We don't feel good about that too ..
15:44:40 <sbonazzo> ydary: feature freeze moving into stabilization (dwh / reports setup migration to otopi)
15:44:43 <fabiand> I try to have something for next week.
15:44:48 * fabiand needs to run
15:45:16 <doron_> #info ovirt node 3.4 status: no available node for 3.4 alpha. Should be tracked for next week.
15:45:19 <doron_> thanks fabiand
15:45:31 <doron_> moving next to network
15:45:35 <doron_> lvernia: evening.
15:45:47 <lvernia> doron_: Hi Doron!
15:46:01 <doron_> lvernia: how are the network team doing for 3.4?
15:46:15 <lvernia> doron_: Not perfect, we have 4.5 / 6 in.
15:46:28 <lvernia> doron_: Maybe danken can elaborate on the 0.5 of iproute2 configurator.
15:46:31 <doron_> lvernia: anything at risk?
15:46:43 <lvernia> doron_: As for network labels, the backend code is in, the GUI and REST aren't yet.
15:46:51 <danken> lvernia: I can - it is NOT yet "Done".
15:47:05 <lvernia> doron_: So I would say labels is at risk, but if the deadline is January 15th I think it'll make it.
15:47:22 <danken> it is missing important functionality: source routing, ipv6, bootproto, and bond modes
15:47:32 <doron_> danken: what about iproute2 for Jan 15?
15:48:17 <danken> doron_: it won't be available as a drop-in replacement of ifcfg
15:48:29 <danken> doron_: but I want it to be usable as a "tech preview".
15:48:49 <doron_> danken: how will it be used?
15:49:22 <danken> configurable in vdsm, that asks to use it instead of ifcfg* files.
15:49:48 <danken> so with it, we're good to go in debian-based systems.
15:49:48 <doron_> danken: which means you need to go over all your hosts?
15:50:10 <doron_> in order to use it?
15:50:13 <danken> doron_: Fedra/el6 builds don't gain anything of it
15:50:29 <danken> but debian builds should enable it out-of-the-box.
15:50:41 <doron_> danken: very well, lvernia thanks.
15:50:49 <lvernia> doron_: Sure, thanks danken.
15:51:21 <danken> we also have an issue with ovs+security_grtoups+migration
15:51:33 <doron_> #info network status for network labels should be ready for Jan 15. iproute2 configurator will make it partially using VDSM configuration.
15:51:41 <doron_> danken: ?
15:52:13 <danken> doron_: neutron integration requires more work. but would be ready for GA.
15:52:48 <doron_> danken: thanks.
15:53:04 <doron_> not in your spreadsheet btw..
15:53:20 <doron_> Anyone here for PPC?
15:53:21 <danken> doron_: I updated it 10 minutes ago...
15:53:32 <lbianc> here
15:53:32 <danken> doron_: last vdsm-side patch merged
15:53:40 <itamar1> it's "Extend integration with Neutron", but i think it was supposed to be split to separate lines for security groups, ipam, etc?
15:53:45 <doron_> danken: marked as done
15:53:51 <lbianc> hi doron_
15:53:58 <doron_> lbianc: hi,
15:54:03 <doron_> ppc status for 3.4?
15:54:16 <itamar1> danken/lvernia - please split "extend neutron" to the specific items it adds.
15:54:28 * gtemple ppc here
15:54:33 <doron_> danken: lvernia and mark green just the ready part ;)
15:54:37 <lbianc> missing only 3 features regarding to the spreadsheet
15:54:38 <doron_> gtemple: hi
15:54:39 <itamar1> [Bug 1048738] New: [oVirt][network][RFE] Add subnet support for neutron  based networks
15:54:43 <doron_> how is PPC doing?
15:54:46 <lvernia> itamar1: No problem. As far as I know then, IPAM is in, and security groups has this issue with migration.
15:54:48 <itamar1> [Bug 1048740] New: [oVirt][network][RFE] Allow deleting Neutron based network (in Neutron) ?
15:54:59 <lvernia> itamar1: And there was some misc. stuff not falling into either of these two, part of which is in.
15:55:15 <itamar1> Bug 1043220 - [oVirt][network][RFE] Add Security-Group support for Neutron based networks
15:55:16 <lvernia> itamar1: That is in.
15:55:29 <lbianc> itś missing some patches for block migration and snapshots that are in risk
15:55:32 <itamar1> (that's the current bug btw in the googledoc, but its scope was changed to security groups - please sort it out).
15:55:44 <doron_> lvernia: so add a neutron-misc bz...
15:55:45 <lvernia> itamar1: Got it, will do.
15:55:53 <lvernia> doron_: Ack.
15:56:02 <vitorlima> doron_: ppc support is almost there, there are 6 critical patches still going under review and 6 patches that are under risk (like lbianc said)
15:56:04 <itamar1> gtemple: which bugs for tracking would it make sense to open on all these PPC lines? I'm not sure it needs one per line?
15:56:10 <doron_> lbianc: how functional is it with currently merged patches is master?
15:56:43 <itamar1> gtemple: vitorlima: maybe open a single BZ for PPC support, covering all of these?
15:56:56 <lbianc> almost full, like 85%
15:57:10 <itamar1> or one for adding cross arch support and one for specific PPC support being added
15:57:14 <doron_> itamar1: they can unite the critical path, and separate specific issues
15:57:32 <vitorlima> doron_: you can run VMs, add hosts, if you just do some small adjustments in the osinfo
15:58:00 <doron_> vitorlima: thanks. I suggest a big push this week. anything we can do to help?
15:58:39 <itamar1> vitorlima: anything which would make this work out of the box would make it easier for ppc adoption i guess
15:59:22 <vitorlima> itamar1: there is a patch to adjust everything and make it work out of the box, it is in change #22596
15:59:57 <doron_> vitorlima: any reason not to have it merged by Jan 15?
16:00:42 <vitorlima> doron_: We are working on the comments made by Roy, as soon as we get done he can merge everything
16:01:10 <doron_> vitorlima: looks like a single comment now
16:01:47 <vitorlima> doron_: yes, it is a small adjustment
16:01:54 <doron_> vitorlima: anyway, please mail the devel list a list of the critical patches and we'll try to help you push it. ok?
16:02:11 <vitorlima> doron_: ok! thanks.
16:02:13 <doron_> at least from reviewing side.
16:02:26 <gtemple> doron_: thanks
16:02:58 <doron_> #info ppc status for 3.4: 6 critical patches at risk. Folks should assist with reviews to push it in.
16:03:01 <doron_> thanks guys
16:03:02 <lbianc> doron_: ok, thanks!
16:03:19 <doron_> moving next to the SLA team
16:04:57 <doron_> #info SLA status for 3.4: affinity, new  cluster policies, HA reservation and hosted engine maintenance under review and should make it to Jan 15. Other tasks at risk.
16:05:14 <doron_> moving to storage team.
16:05:29 <doron_> tal: here?
16:05:38 <danken> doron_: before I forget: http://www.ovirt.org/OVirt_3.4_release-management is out of date. we should add the alpha data to it
16:05:50 <tal> doron_: yes
16:06:02 <doron_> danken: thanks. O think sbonazzo is already handling it.
16:06:07 <itamar1> and push GA out at least two weeks. probably four weeks.
16:06:15 <doron_> sbonazzo: can you verify?
16:06:21 <sbonazzo> doron_: looking right now
16:06:23 <doron_> tal: storage status for 3.4?
16:06:26 <doron_> sbonazzo: thanks
16:06:52 <doron_> tal: we can focus on items at risk.
16:07:58 <doron_> tal: ?
16:08:16 <tal> Multipathing feature is at risk but we hope it will converge for 3.4
16:08:29 <doron_> tal: by Jan 15?
16:08:36 <tal> Yes
16:08:57 <tal> Same goes for https://bugzilla.redhat.com/1038053 - Storage Pool of mixed types
16:08:59 <doron_> Single disk snapshots?
16:09:20 <tal> Single disk snapshots is on track, patches are commited and reviewed
16:09:44 <doron_> Multiple SDs?
16:10:17 <doron_> ok, it's the same one you gave
16:10:18 <tal> As I said, same as multipathing, at risk but we hope it will converge for the version
16:10:20 <tal> Yes
16:10:25 <doron_> anything else?
16:10:38 <tal> VDSM tests is on track
16:10:47 <tal> HSM async tasks will probably not converge
16:11:49 <ydary> sbonazzo: ask barak a or utamar
16:11:56 <doron_> tal: note that some tasks are missing bz numbers. anything else atrisk for jan 15?
16:12:10 <tal> Not that I know of
16:12:14 <doron_> thanks
16:12:58 <doron_> #info storage status for 3.4: HSM async tasks may not make it. Currently at risk: Multiple SDs, Multipathing.
16:13:10 <doron_> ecohen: is UX all set of 3.4?
16:13:21 <ecohen> doron_, we may be able to squeeze in "layout fix for low resolution" before Jan 15, but cannot guarantee (haven't returned it to the spread-sheet yet, will know better later today).
16:13:21 <ecohen> doron_, other than that - no changes since last meeting.
16:13:38 <doron_> ecohen: thanks
16:14:18 <doron_> #info UX status for 3.4: layout fix for low resolution may make it for 3.4 (best effort). Everything else ready.
16:14:24 <doron_> Moving next to virt.
16:14:33 <doron_> ofrenkel: here for virt?
16:14:47 <itamar1> tal: why no BZ's for some lines? please add them.
16:14:58 <tal> Ok
16:15:05 <itamar1> (other than the functional tests which doesn't need one in my view)
16:15:13 <doron_> who's here for virt?
16:15:26 <itamar1> tal: but backup and restore api, Store OVF on any domains and Get rid of storage pool metadata on master storage domain should have BZs. thanks
16:15:43 <doron_> mskrivanek: here?
16:16:25 <doron_> no virt today :/
16:16:34 <danken> doron_: I can tell that set cpu number is risky
16:16:53 <danken> but working hard to get it to alpha
16:17:03 <doron_> danken: in which context? post alpha?
16:17:10 <sbonazzo> danken: doron_: updated
16:17:17 <doron_> sbonazzo: thanks
16:17:35 <itamar1> danken: what is cpu number? its not in the doc?
16:17:37 <mskrivanek> doron_: yes
16:17:47 <doron_> mskrivanek: virt status for 3.4?
16:17:52 <danken> itamar1: cpu hotplug, sorry
16:17:53 <doron_> anything at risk?
16:18:13 <doron_> danken: now it makes sense...
16:18:36 <danken> the API verb is called "set cpu number"...
16:18:36 <mskrivanek> cpu hotplug still in progress, should make it, though actual behvior is still hard to predict on Windows. We have not done enough testing
16:18:52 <mskrivanek> persistent cloud-init/sysprep still at risk as well
16:19:20 <doron_> mskrivanek: mitigation plan for hotplug cpu?
16:19:35 <itamar1> doron_: disable in osinfo for windows by default?
16:19:37 <doron_> (other than not using it..)
16:19:46 <mskrivanek> and template versions won't make it if I should predict. Other than that it's accoridng to the spreadsheet and what is "In progress" should make Jan 15th
16:20:02 <itamar1> mskrivanek: can i remove "pci passthrough for devices like Telephone modem, PCI-express cards,graphic cards)"
16:20:07 <itamar1> pci passthrough for devices like Telephone modem, PCI-express cards,graphic cards)
16:20:15 <itamar1> oVirt guest agent for SLES?
16:20:17 <mskrivanek> itamar1: yes. it's not consumable yet
16:20:19 <itamar1> oVirt guest agent for Debian?
16:20:24 <itamar1> Optimization of the communication between VDSM and oVirt Backend?
16:20:35 <mskrivanek> ywah, yeah, all those "won't make it" can be now safely removed
16:20:50 <doron_> mskrivanek: "safely"...
16:21:02 <doron_> very well.
16:21:08 <mskrivanek> mitigation plan for hotplug cpu - nothing really, YMMV depending on specific OS, it's even more granular than our OS type
16:21:30 <itamar1> mskrivanek: no BZ for cloud-init/sysprep customization, more options exposed, persistence?
16:21:36 <doron_> mskrivanek: consider declaring it "tech preview" or warn?/
16:21:37 <itamar1> mskrivanek: no BZ for "reboot VM" functionality?
16:21:44 <itamar1> mskrivanek: no BZ/status for qemu-ga installed by default on Linux?
16:21:55 <mskrivanek> persistence should make it, more options at risk, but hopefully yes, it's not much work
16:22:31 <mskrivanek> hm, i wonder where are the bugs...i'll check with assignees:)
16:22:48 <itamar1> mskrivanek: no BZ for Clone VM directly (powered off) as well
16:23:04 <doron_> #info virt status for 3.4: several tasks will not make it. Currently at risk: persistent cloud-init/sysprep, cpu hotplug, template versions.
16:23:08 <doron_> thanks mskrivanek
16:23:20 <doron_> this concludes the various team status
16:23:51 <doron_> Previously we decided that next nightly is an alpha.
16:24:02 <doron_> What about feature freeze and beta dates?
16:24:32 <doron_> sbonazzo: itamar1 suggestions?
16:24:33 <sbonazzo> doron_: if we're going to branch on 15th I suggest beta to be built on that branching and relased the day after
16:24:58 <itamar1> sbonazzo: i think the 20th may make more sense?
16:25:16 <doron_> #idea branch on 20,  beta to be built on that branching and relased the day after
16:25:31 <sbonazzo> doron_: branch on 15th, beta on 20th
16:25:45 <sbonazzo> doron_: giving time to branch to stabilize
16:26:02 <doron_> #idea branch on 15th,  beta to be built on that branching and released on the 20
16:26:16 <doron_> any objections?
16:26:37 <doron_> itamar1: and feature freeze moves to 15?
16:26:54 <itamar1> doron_: yes.
16:27:06 <doron_> very well.
16:27:08 <sbonazzo> itamar1: rc and ga?
16:27:21 <doron_> and test day?
16:27:32 <itamar1> sbonazzo: looking at the content, it will take at least a month to stabilize for releasing.
16:27:56 <itamar1> doron_: i'd do one a week after stable branch. and consider doing another one.
16:28:06 <doron_> rc on FEB 15?
16:28:19 <doron_> GA a week later?
16:29:19 <sbonazzo> itamar1: so test day just after beta release?
16:29:32 <doron_> sbonazzo: first test day
16:29:40 <doron_> we hould have another after RC?
16:29:48 <doron_> (should)
16:30:14 <itamar1> sbonazzo: a week after beta
16:31:07 <sbonazzo> ok, so beta on 20th, test on 27th
16:31:37 <doron_> #idea updated 3.4 schedule: branch on 15th, beta on the 20, test day on 27. RC on Feb 15, GA a week later
16:31:42 <doron_> looks ok?
16:32:06 <sbonazzo> doron_: missing second test day on RC
16:32:19 <doron_> wait feb 15 is Saturday...
16:33:38 <doron_> #idea updated 3.4 schedule: branch on 15th, beta on the 20, test day on 27. RC on Feb 17, test day Feb 19, GA Feb 24.
16:33:47 <doron_> this should have it all.
16:34:21 <doron_> itamar1: anything else we missed?
16:34:51 <bkp> Test day on Jan. 27 will be day after FOSDEM, for anyone who's going.
16:34:58 <doron_> if anyone else wants to comment please do now.
16:35:04 <bkp> May not matter, but there it is.
16:35:16 <doron_> bkp: right, thanks
16:35:39 <doron_> bkp: fosdem starts on Feb 1.
16:35:45 <doron_> shouldn;t be an issue
16:36:08 <bkp> Agh, looked at wrong weekend. Apologies.
16:36:14 <doron_> last comments on the proposal?
16:36:35 <doron_> #info updated 3.4 schedule: branch on 15th, beta on the 20, test day on 27. RC on Feb 17, test day Feb 19, GA Feb 24.
16:36:45 <doron_> moving to next topic
16:36:58 <doron_> #topic conferences and workshops
16:37:07 <doron_> bkp: dneary updates?
16:37:18 <bkp> #info oVirt will have a presence at several upcoming European events: Monki Gras, FOSDEM, cfgmgtcamp, Infrastructure.Next, and DevConf.cz. For that last, bkp hopes to visit folks in the Brno office.
16:37:21 <doron_> sbonazzo: please announce the updated schedule.
16:37:42 <doron_> bkp: cool!
16:37:49 <sbonazzo> doron_: http://www.ovirt.org/OVirt_3.4_release-management#Timeline updated, I'll send an email
16:37:56 <doron_> sbonazzo: thanks
16:37:59 <sbonazzo> doron_: itamar1: what about 3.3.3 schedule?
16:38:33 <doron_> sbonazzo: "3.3.3 will be built after the first 3.4 alpha build"
16:38:47 <sbonazzo> so tomorrow?
16:38:56 <doron_> sbonazzo: this was the suggestion
16:39:00 <bkp> #info One of the action items from yesterday's board meeting was starting to set a tentative schedule for the next oVirt workshop in April/May. Will update.
16:39:53 <doron_> bkp: location is known?
16:40:05 <bkp> doron_ Not at this time.
16:40:13 <doron_> very well.
16:40:14 <bkp> But will be soon.
16:40:28 <doron_> anything we need to finalize for fosdem?
16:40:43 <doron_> social event? anything else?
16:40:43 <sbonazzo> itamar1: doron_: 3.3.3 beta build for tomorrow seems not really good to me... we should let maintainers the time to scrub bugs, create tracker for blockers, define blockers and so on. I suggest to build beta on monday
16:41:16 <bkp> I assume everyone's set for travel. dneary has details on social event.
16:42:08 <doron_> sbonazzo: +1. I suggest you send an email to arch and we can decide offline
16:42:19 <doron_> bkp: thanks. anything else?
16:42:39 <bkp> Not for conferences/events.
16:42:52 <doron_> bkp: thanks. moving on,
16:42:58 <doron_> #topic infra update
16:43:03 <doron_> orc_orc: here?
16:43:56 <doron_> dcaroest: here?
16:44:01 <orc_orc> doron_: on lsb confcall
16:44:07 <orc_orc> lemme shift
16:44:12 <orc_orc> ok
16:44:19 <doron_> orc_orc: thanks. how is infra doing?
16:44:39 <orc_orc> infra had a mized telephonic and IRC meeting, to get beter bandwidth to dignose performance logging issues
16:45:00 <orc_orc> we identified some  'hot spots' that we are researching in more depth
16:45:25 <doron_> orc_orc: what are the main problems we currently have in the infra?
16:45:33 <orc_orc> it may be that a 'congestion' fallback for jenkinsbuilds are all that are needed, and we have some candidates identified to implement this
16:46:12 <orc_orc> doron_: the nagging one is the Rackspace unit turnup, and infra has sought information on finances, to see what budget we have to shop with to move away from taht problem
16:46:23 <orc_orc> others are relatively minor
16:46:34 <orc_orc> link to meeding is at ....
16:46:47 <orc_orc> http://ovirt.org/meetings/ovirt/2014/ovirt.2014-01-06-15.06.html
16:47:19 <orc_orc> we have not completed a top to bottom bug triage, and probably that needs to happen
16:47:19 <doron_> orc_orc: so it looks like this is currrently being handled?
16:47:29 <orc_orc> we noted a connection isue to the etherpad as we tried to use it
16:47:43 <orc_orc> doron_: yes -- we are in process and making headway
16:47:58 <doron_> orc_orc: excellent.
16:48:08 <doron_> anyting we can do to help?
16:48:24 <doron_> or as it seems ovirt is in good hands.
16:48:38 <orc_orc> heh:  file tickets when problems are observed, work lickets as one ca, esp to replicate issues
16:48:52 <doron_> very well.
16:48:52 <orc_orc> I feel quite positive as to infra
16:49:00 <orc_orc> 's directiom
16:49:02 <doron_> thanks for the positive update ;)
16:49:08 <orc_orc> indeed
16:49:25 <SvenKieske> I just wanted to mention that I installed today a new test-vm with ovirt-engine from ovirt.org repo and the download speed was much higher than before! thank you for that so far! :)
16:49:55 <doron_> #info ovirt infra in process and making headway. details available in http://ovirt.org/meetings/ovirt/2014/ovirt.2014-01-06-15.06.html Also good feedback on d/l speed.
16:50:01 <orc_orc> SvenKieske: as much as one would like to credit infra with this, it is probably just the Artic Vortex blowing bits around
16:50:01 <doron_> SvenKieske: thanks for the feedback
16:50:27 <doron_> #topic other topics
16:50:32 <doron_> orc_orc: thanks
16:50:44 <doron_> anyone else wants to raise something? discuss?
16:50:59 <bkp> I got some info items...
16:51:03 <bkp> #info Quarterly board meeting for oVirt was held yesterday (Thanks itamar1 and dneary). Good attendance from Red Hat, IBM, Cisco, Intel, NetApp, and HP. Action items include approval for UI extensions and plug-ins portal, as well the aforementioned tentative discussion for the next locations of the oVirt Workshops. Notes should be posted to the [board] mailing list in a bit.
16:51:25 <bkp> #info Working on the first draft of the next oVirt case study on Nieuwland.
16:51:33 <bkp> #info Researching better organizational structures for the oVirt.org wiki.
16:51:38 <bkp> (Done)
16:51:53 <doron_> bkp: thanks for all the updates.
16:51:56 <bkp> NP
16:52:10 <doron_> looks very busy ;)
16:52:23 <doron_> orc_orc: while at it, maybe you can help
16:52:45 <doron_> as bkp mentioned, we're going to participate in several events soon.
16:53:16 <bkp> It will be the European Rock Star Tour for oVirt
16:53:17 <doron_> is there a way to measure effectiveness by rate / amount of downloads, hits, etc?
16:53:18 <orc_orc> doron_: I had a conflict on yesterday's call and could not join until the end
16:53:27 <orc_orc> bkp: is there a replay link?
16:53:37 <doron_> orc_orc: you'll get one soon
16:53:40 <bkp> orc_orc: There will be very soon.
16:53:51 <orc_orc> doron_: it is hard to say on mere DL's as mirroring causes inquiries
16:53:54 <doron_> see my question about analitics of ovirt services.
16:54:09 <orc_orc> ML raccif, and bugs filed, and wiki edits are probably more reliable
16:54:19 <orc_orc> MK posts ....
16:54:40 * doron_ unsure if that will be done by someone who just heard of ovirt .
16:54:52 <orc_orc> I was thinking, on the wiki, that exposing the date last editted, and by whom would be positive
16:54:54 <jplorier> hi, sorry for interrupting. I'd like to know if I can use a gluster volume to create disks to assign no bootable disks to vms running inside of a iscsi cluster
16:54:59 <doron_> can we hook google analytics in?
16:55:06 <orc_orc> we did this at CentOS and it allowed for identification of stale kit mroe easily
16:55:34 <orc_orc> also, adding an: Appeared atn, and obsoleted at: ponvention features posts would be a good habit
16:55:40 <doron_> orc_orc: please raise this in your next infra mtg.
16:55:48 <orc_orc> didi: it is more a wiki authoring issue
16:55:49 <bkp> This is something we are looking at as part of the whole improving metrics project.
16:55:57 <orc_orc> is there disagreement as to exposing such?
16:56:16 <orc_orc> for doron_ , not didi  of course
16:56:35 <doron_> orc_orc: bkp just something I'd like to see pushed forward.
16:56:40 <orc_orc> as to adding AMZN analytics, they changed it a bit recently -- I will look into
16:56:50 <doron_> thanks
16:56:54 <doron_> anything else?
16:57:07 <doron_> going once?....
16:57:15 <bkp> doron_ Noted
16:57:28 <doron_> going twice?....
16:57:58 <doron_> thanks everyone! Goodnight / day wherever you are.
16:58:00 <doron_> #endmeeting