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