14:05:27 <bkp> #startmeeting oVirt Weekly Sync 14:05:27 <ovirtbot> Meeting started Wed Jul 16 14:05:27 2014 UTC. The chair is bkp. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:27 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:05:37 <ovirtbot> bkp: Error: Can't start another meeting, one is in progress. 14:05:44 <bkp> #topic Agenda and Roll Call 14:06:08 <bkp> Okay, chime in, everyone. I know lvernia is going to be late. 14:06:13 * danken is here 14:06:16 * sbonazzo here 14:06:25 * danken is here 14:06:34 <bkp> #info infra update 14:06:34 <bkp> #info 3.4.z updates 14:06:34 <bkp> #info 3.5 status 14:06:34 <bkp> #info conferences and workshops 14:06:34 <bkp> #info other topics 14:06:55 * tal here 14:07:13 <bkp> Hey all! 14:07:26 <bkp> #topic infra update 14:07:51 <bkp> dcaro, anything to report? 14:08:24 <bkp> Or misc... 14:08:25 <dcaro> phx lab still on the works (installed hosted engine though, but now they are setting up cables for the network) 14:08:44 <dcaro> Most of the 3.5 jobs have been added to jenkins, missing still a few 14:09:09 <dcaro> and, that's mostly all 14:09:17 <bkp> Cool, dcaro 14:09:27 <bkp> #info infra phx lab still on the works (installed hosted engine though, but now they are setting up cables for the network) 14:09:27 <bkp> #info infra Most of the 3.5 jobs have been added to jenkins, missing still a few 14:10:05 <bkp> Moving on... 14:10:06 <bkp> #topic 3.4.z updates 14:10:28 <bkp> sbonazzo has sent in his status report already, so here's what I have. 14:10:37 <bkp> #info 3.4.z updates Detailed status report at http://lists.ovirt.org/pipermail/users/2014-July/026028.html 14:10:37 <bkp> #info 3.4.z updates No active blockers for 3.4.3 GA, 3 bugs (excluding node and documentation) still outstanding 14:10:37 <bkp> #info 3.4.z updates 3.4.3 will start composing on 07-17-14 0800 UTC from 3.4.3 branch 14:10:46 <awels> bkp: here missed rollcall. 14:10:54 <bkp> Hey, awels! 14:11:51 <bkp> sbonazzo was that good? 14:11:55 <sbonazzo> bkp: yep 14:12:17 <sbonazzo> bkp going to build engine in ~30 minutes 14:12:36 <sbonazzo> bkp so it wil lbe ready for tomorrow morning composition and testing 14:14:05 <bkp> #info 3.4.z updates Building engine in ~30 minutes so it will be ready for tomorrow morning composition and testing 14:14:35 <bkp> Okay, moving on... 14:14:41 <bkp> #topic 3.5 status 14:14:42 <danken> sbonazzo: and I've asked dougsland to build 4.14.11 14:14:47 <danken> of vdsm 14:14:54 <sbonazzo> danken: thanks 14:15:16 <dougsland> o> 14:15:52 <bkp> Let's stick with integration. Again, sbonazzo is too cool to do his own updates here, so... :) 14:16:05 <bkp> #info 3.5 status integration Detailed status at http://lists.ovirt.org/pipermail/users/2014-July/026029.html 14:16:05 <bkp> #info 3.5 status integration 3.5.0 Second Beta will be composed on 07-21-14 0800 UTC; Be sure 3.5 snapshots are enabled to create VMs by 07-20-14 1500 UTC 14:16:05 <bkp> #info 3.5 status integration Feature freeze in place, 3.5.0 branch has been created; All new patches must be backported to 3.5 branch too. 14:16:05 <bkp> #info 3.5 status integration Six blockers are currently listed (2 infra, 1 integration, 2 network, and 1 virt) for 3.5.0 14:16:37 <bkp> We will go over the blockers for each team. sbonazzo, integration has one block, what's it's status? 14:17:12 <sbonazzo> bkp we're trying to reproduce the issue SvenKieske pointed out as blocker 14:17:24 <sbonazzo> bkp no ETA yet 14:17:57 <sbonazzo> bkp the other one is in progress 14:18:06 <sbonazzo> bkp should be in for second beta 14:18:11 <bkp> #info 3.5 status integration Blocker Bug 1113974: Trying to reproduce issue, no ETA at this time. 14:18:24 <bkp> What other one? I have just the one for integration. 14:18:46 <sbonazzo> bkp sorry, SvenKieske proposed one just a couple of hour ago 14:19:07 <bkp> Got a Bugzilla # for that one? 14:19:28 <sbonazzo> bkp: Bug 1114914 - engine-setup: cannot import name database 14:19:29 <danken> bkp: I did not declare it as an ovirt blocker yet, but 1119024 network rollback does not take place 14:19:41 <danken> is quite a nagging vdsm regression 14:20:01 <bkp> K, thanks. 14:20:10 * lvernia is here! 14:20:15 <sbonazzo> bkp 1113974 fixed in the while 14:20:38 <bkp> #info 3.5 status integration Blocker Bug 1114914: In progress, should be fixed by second beta. 14:21:50 <bkp> Okay, let's move forward to network, since lvernia finally showed up. :) 14:22:45 <lvernia> bkp: Haha, alrighty then, since I was blocking the entire meeting... 14:23:00 <bkp> (You weren't, good timing) 14:23:25 <lvernia> So we do have a couple of blocker candidates. 14:23:36 <nsoffer> where can I find patternfly1? 14:23:55 <lvernia> There's the one we discussed last week as a potential blocker, I did mark it as such. 14:24:01 <nsoffer> [ ERROR ] Failed to execute stage 'Environment customization': [u'ovirt-engine-3.6.0-0.0.master.20140715053927.git2650110.fc19.noarch requires patternfly1'] 14:24:10 <lvernia> That's 1115001. 14:24:25 <bkp> Okay, status? 14:24:53 <awels> nsoffer: https://copr.fedoraproject.org/coprs/patternfly/patternfly1/ 14:25:10 <lvernia> As of earlier today, pending review (POST). 14:25:30 <bkp> #info 3.5 status network Blocker Bug 1115001 status: pending review (POST) 14:25:36 <lvernia> There's also 1119019, which is a problem with the 3.5 feature of network custom properties. 14:25:43 <lvernia> That is also pending review since yesterday. 14:25:50 <lvernia> So both I reckon will be merged by next week's beta. 14:26:43 <lvernia> And there's another bug that's quite bad on our VDSM side, but hasn't been marked as blocker (and I don't think should block the beta anyway). 14:26:48 <bkp> #info 3.5 status network Blocker Bug 1119019 status: pending review. Both blockers should be merged in next week's beta. 14:27:06 <bkp> lvernia: Is that the one danken mentioned? 14:27:13 <lvernia> bkp: It might be, I wasn't here :) 14:27:27 <bkp> His was bug 119024 14:27:35 <danken> https://bugzilla.redhat.com/show_bug.cgi?id=1119024 14:27:41 <danken> bkp: yep 14:28:01 <lvernia> Wow, on POST already, great. 14:28:04 <danken> I am not proud of my patch for it, but it exists 14:28:12 <lvernia> Ahh, alright :) 14:28:41 <lvernia> So... I think that's it for us. 14:28:47 <urthmover> Is installing a node using 'yum install vdsm' (and adjusting ifcfg-ovirtmgmt) similar to installing a node through the remote webgui? or are there other actions that occur by remotely installing through the webgui? 14:29:08 <bkp> #info 3.5 status network Not an ovirt blocker yet, but bug 1119024 is a persistent vdsm regression affecting network. Patch made. 14:29:17 <bkp> lvernia, thanks! 14:29:21 <lvernia> bkp: Sure thing! 14:29:35 <bkp> Moving on to virt. mskrivanek? 14:29:40 <itamar> urthmover: more steps, yum install vdsm is just one. certificate generation is another for example. 14:29:54 <msivak> urthmover: the host deploy does much more.. certificates, firewall, ssh key.. 14:29:58 <mskrivanek> ah, well, there was a blocker about hv_enlightenment. it's almost in 14:30:15 <urthmover> itamar: ok thank you. 14:30:22 <urthmover> msivak: thank you as well 14:30:54 <bkp> mskrivanek: Almost in... for the next beta? 14:31:00 <mskrivanek> today 14:31:01 <urthmover> I was encountering a yum error that caused a sn ssh timeout code 1 yesterday during a remote install and couldn't figure it out. 14:31:23 <urthmover> so I thought that doing it manually might lead to greater success 14:31:38 <urthmover> oddly I have 8 other nodes that installed fine 14:31:47 <itamar> urthmover: did you check the host deploy log? 14:31:50 <bkp> mskrivanek Gotcha. Anything else? 14:31:59 <mskrivanek> bkp: hm, probably not 14:32:03 <bkp> #info 3.5 status virt Blocker Bug 1110305 status: Almost in. ETA today. 14:32:05 <urthmover> itmardo you folks mind if I share it and get your feedback? 14:32:19 <bkp> Excellent, thanks mskrivanek. 14:32:27 <bkp> Moving to infra. 14:33:11 <bkp> Who's on for infra today? 14:34:34 <bkp> bazulay, You around? 14:35:37 <peetaur2> is there some way of turning of the nagging about power management being disabled? I just have a single host ovirt and it is therefore pointless. 14:35:43 <urthmover> itamar: http://pastey.org/view/1a106efb 14:36:03 <bkp> Last call for infra 14:36:08 <urthmover> anyone else is welcome to look at the log and point me in the direction of the (probably obvious) fix 14:36:11 <urthmover> :) 14:36:25 <urthmover> peetaur2: +1 14:36:40 <bkp> #info 3.5 status infra Blocker Bug 1115044 status: In POST status unknown. 14:36:41 <bkp> #info 3.5 status infra Blocker Bug 1115152 status: In POST status unknown. 14:36:41 <bkp> #info 3.5 status infra No report this week. 14:36:54 <danken> bkp: one infra report from me 14:37:05 <bkp> danken: Yeah, go ahead! 14:37:11 <danken> http://gerrit.ovirt.org/#/c/28817/ is not yet ready 14:37:23 <danken> lastClientIface is not reported over jsonrpc 14:37:45 <danken> it should be deemed as a blocker - it makes host installation over jsonrpc stammer 14:38:01 <danken> pkliczew may share info about it 14:38:08 <bkp> #info 3.5 status infra http://gerrit.ovirt.org/#/c/28817/ is not yet ready, lastClientIface is not reported over jsonrpc. Should be set as a blocker 14:38:27 <bkp> pkliczew, anything to add? 14:39:21 <pkliczew> bkp: the patch awaits final agreement on minor thing, but it is not ready yet 14:40:12 <bkp> #info 3.5 status infra http://gerrit.ovirt.org/#/c/28817/ patch in progress, awaiting agreement on minor aspect. 14:40:13 <urthmover> Here is a link that is easier on the eyes http://hastebin.com/ahinemipoq.md 14:40:23 <bkp> Cool, thanks! 14:40:42 <bkp> Moving on to storage. tal, I hear you're up this week. 14:40:51 <tal> Indeed 14:41:31 <bkp> What do you have for 3.5? No blockers listed... 14:41:41 <tal> No blockers for now, no 14:42:24 <danken> tal: but http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:livemerge,n,z is far from ready 14:42:50 <bkp> tal: Status of this? 14:42:57 <tal> danken: Indeed, but those are not news, the guys are working on it 14:42:59 <danken> (live merge, that is) 14:43:16 <danken> but they still block 3.5 14:43:25 <danken> which is important to mention 14:43:37 <tal> Yes, but again, no change in status from the last weeks 14:43:43 <danken> it is the crown joule feature of the versioin 14:43:51 <urthmover> itamar: did the link work for you? 14:44:14 <bkp> tal: Even no change is worth mentioning. 14:44:30 <tal> Ok, sorry, then what danken said :) 14:44:31 <danken> tal: anyway, it is mentioned now ;-) 14:44:45 <bkp> tal: No worries. Any kind of ETA? 14:45:01 <tal> Not that I know of for now 14:45:15 <itamar> urthmover: yes, but saw nothing suspicious. alonbl_ ? (http://hastebin.com/ahinemipoq.md) 14:45:24 <bkp> Cool. Anything else to report, tal? 14:46:11 <tal> Nope 14:46:15 <bkp> Excellent. 14:46:18 <bkp> #info 3.5 status storage Live Merge feature (http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:livemerge,n,z) not ready, still blocking for 3.5. No change in status, no ETA to report. 14:46:50 <bkp> Moving on to Node. fabiand, I see you hosted a 24-hour+ meeting recently. Surely something to report? :) 14:47:02 <fabiand> :) 14:47:21 <fabiand> bkp, Well, we lost ourselfs in joy that we are basically stabilizing. 14:47:25 <urthmover> itamar: hmm I'll rerun and share that 14:47:49 <fabiand> bkp, Nothing radical new from us, we are in testing mode, and boiling out some build/automation problems. 14:48:35 <fabiand> bkp, but thatz is basically not related to 3.5 (the automation work we do) 14:48:38 <bkp> fabiand: Noted. Anything else? 14:48:43 <SvenKieske> what's the mess in http://resources.ovirt.org/pub/ovirt-3.3/rpm/el6/noarch/ ? there are numerous ovirt-release-* rpms, sbonazzo, could you clean that up please? 14:48:51 <fabiand> bkp, nope, not for now. 14:49:14 <bkp> #info 3.5 status node Node is basically stabilizing. 14:49:14 <bkp> #info 3.5 status node In testing mode, working out some build/automation problems. (Not 3.5-related) 14:49:20 <sbonazzo> SvenKieske: I thought they were all removed in last cleanup, let me check 14:49:27 <bkp> Very well. 14:49:37 <bkp> (I miss doron) 14:49:52 <bkp> SLA! msivak, what do you have for us? 14:50:16 <msivak> everything we had for vdsm is in master now 14:50:18 <SvenKieske> sbonazzo: well there should be at least one package, but there are way to many, I'm still using this one, as I know it works with 3.3.z: yum -y install http://resources.ovirt.org/pub/ovirt-3.3/rpm/el6/noarch/ovirt-release-el6-10.0.1-2.noarch.rpm 14:50:39 <msivak> iotune now needs to be merged to 3.5, but Dan is somewhat reluctant to take it 14:50:49 <danken> bkp: msivak: but pesky vdsm maintainer is picky about it 14:51:02 <sbonazzo> SvenKieske: you should use http://resources.ovirt.org/pub/yum-repo/ovirt-release33.rpm 14:51:05 <danken> exactly - it changes APIs 14:51:20 <danken> and this makes it too late to get to the stable branch 14:51:38 <sbonazzo> SvenKieske: any reason for not using 3.4? 14:52:09 <SvenKieske> sbonazzo: no, I just had no time to upgrade yet, I hope I can upgrade in august.. 14:52:20 <danken> msivak: beyond that, I feel that it is less stable than the rest of the code 14:52:22 <bkp> So, will it be merged or not, danken and msival? 14:52:31 <bkp> *msivak ^^^ 14:52:47 <msivak> I verified it and wrote unittests that cover all of it 14:52:47 <danken> bkp: the question is how important is this feature for ovirt-3.5 14:52:58 <danken> are we ready to consider it as an exception? 14:53:10 <danken> to the process? I am not convinced 14:53:32 <msivak> as far as I know we already have an exception for that, but I am only holding the chair for Doron here 14:53:56 <urthmover> I have 10 nodes each with 2x1TB drives (that I'm zfs mirroring) I intend on running one large 800GB guest on each node. These 10 guests will be running postgres-xc and I'd like to get as much disk IO as I can without running raid0. Should I be creating Storage Domains for each 2x1TB pair of disks? or creating local storage? 14:54:25 <danken> msivak: point is that we found a fair share of issues in the last test day 14:54:26 <SvenKieske> sbonazzo, I get: Host xxx is installed with VDSM version (4.14) and cannot join cluster vrc000201 which is compatible with VDSM versions [4.13, 4.9, 4.11, 4.12, 4.10]. cluster level is 3.3 this should work, shouldn't it? 14:54:39 <danken> for the new sla code that we added 2 days before 14:54:41 <urthmover> I do no anticipate needing to move the 800GB data around. 14:54:46 <danken> I know that the current code is much better 14:55:06 <msivak> danken: I know only about logging and centos support 14:55:10 <danken> but I would rather introduce it in 3.5.1 over russhing it now 14:55:25 <bkp> msivak: You said iotune, is this the feature around Bug 1085049? 14:55:26 <danken> msivak: yeah, these two 14:55:53 <msivak> bkp: yes 14:55:53 <sbonazzo> urthmover: SvenKieske: let's wait for end of meeting 14:56:10 <bkp> msivak danken: There's already an exception granted for this. 14:56:26 <urthmover> sbonazzo: I'm so sorry. That makes ALOT more sense. I'll stop with all the extra chatter 14:56:50 <danken> bkp, ok, but for how long? we are way past feature freeze 14:57:26 <bkp> msivak: How long to address danken's concerns? 14:57:34 <danken> msivak: bkp: what is your opinoin about my idea, of delaying this after 3.5.0? 14:57:38 <SvenKieske> sbonazzo, okay, I'm filing a BZ.. 14:58:12 <msivak> bkp: well his concern is that it is less stable, I think the patches have almost 100% test coverage, I do not know if I can do better than that 14:58:29 <danken> msivak: what is the state of this feature on Engine? 14:59:00 <msivak> danken: stuck on infra.. Arik is on army duty this week and nobody else to review 14:59:08 <bkp> danken: I am not clear on how important this feature is, so I am not sure. 14:59:56 <msivak> Scott is not here, but it is the most important feature for us, even more than numa .. but that cost us a lot of time unfortunately 15:00:31 <danken> bkp: frankly, so am I 15:00:46 <msivak> I understand Dan's concerns, but we are not changing APIs, we are only adding new calls 15:01:38 <danken> msivak: you've made a couple of (important) changed in vm.py that beg to be tested a bit more 15:01:41 <danken> in my opinion 15:01:43 <msivak> and there is one call that was introduced to 3.5 and only half of it is merged, so if we freeze it now, we are stuck with bad API 15:02:07 <bkp> danken msivak: I recommend we push this through, then, if it that important. Let's try this: see if you can double-check the issues danken is worried about, but move forward. 15:02:23 <bkp> I would rather not stick users with a half-baked solution. 15:02:54 <danken> bkp: currently in 3.5 it's not "half baked", it's not there 15:03:20 <msivak> danken: can you be more specific? I am actually using this version for my hosts with no issues atm and the refactoring was very minimal 15:03:39 <danken> msivak: I am not aware of any specific bug or glitch 15:03:40 <bkp> I was referring to the bad API msivak mentioned. 15:03:58 <danken> I am just worried about dumping 16 new patches into 3.5 15:04:17 <danken> bkp: msivak I have NOT called his API bad! 15:04:23 <danken> (it isn't) 15:04:25 <msivak> 16 patches of which I think 13 are mine and that were torn to pieces by three reviewers 15:04:26 <danken> it's just late 15:04:48 <msivak> danken: I did :) the updateVmPolicy needs the second part :) 15:04:51 <bkp> danken: No, msivak did. 15:05:16 <msivak> danken: the arguments there were changed on Piotr's and Nir's request I think 15:05:37 <bkp> msivak: Are you confident this feature will work for 3.5? Because that's what this boils down to. 15:06:03 <msivak> I tested all the basic flows manually using the xmlrpc and virsh 15:06:07 <danken> msivak: could you present the case for these API.py change in 3.5 in a BZ? 15:06:14 <danken> or email 15:06:22 <msivak> so yes, I am pretty much content with how that looks like now 15:06:31 <danken> and how much work is needed in Engine to enable it all 15:06:52 <danken> we should decide weather it is worth the risk of delayin 3.5.0 15:07:30 <bkp> Given we already have a three-week delay from last week, maybe there is time. 15:08:17 <bkp> msivak danken: Let's move forward, see if you can get danken's concerns addressed. I would like to get this feature as green ASAP. 15:08:28 <msivak> ok 15:09:08 <msivak> optimizer now knows how to compute a solution for starting a vm, lacking ui, but that will take no time when vdsm is sorted out 15:09:33 <msivak> hosted engine in good shape and with more stable state machine as far as starting the engine vm is concerned 15:09:41 <bkp> #info 3.5 status sla Everything sla had for vdsm is in master now 15:09:42 <bkp> #info 3.5 status sla iotune now needs to be merged to 3.5. Verified and unittests written. There are still strong concerns from danken. msivak to try to address and get this in the green. 15:09:58 <msivak> numa ui should be ready now, lacks +2 15:10:05 <danken> bkp: please explain your decision about the "need to merge to 3.5" 15:10:23 <danken> I wanted to discuss exactly this point. 15:10:31 <danken> anyway, it can be done offline 15:10:33 <alonbl_> urthmover: how can I help? 15:11:16 <msivak> danken: I have to leave in few minutes, lets discuss tomorrow and figure out what can (or can't) go wrong, ok? 15:11:29 <urthmover> alonbl_: I have 10 nodes each with 2x1TB drives (that I'm zfs mirroring) I intend on running one large 800GB guest on each node. These 10 guests will be running postgres-xc and I'd like to get as much disk IO as I can without running raid0. Should I be creating Storage Domains for each 2x1TB pair of disks? or creating local storage? 15:11:46 <bkp> danken: It's a major SLA feature, msivak wants to merge with 3.5, and there seems to be no specific bugs. But this is still in yellow status, so something needs to be addressed. We are not ignoring this, and will address post meeting. 15:11:50 <urthmover> alonbl_: I think I got the remote install working fine 15:11:57 <urthmover> itamar: I think it's working now 15:12:06 <alonbl_> urthmover: ok 15:12:21 <alonbl_> urthmover: for the storage issues, I think nsoffer can help 15:12:29 <bkp> #info 3.5 status sla optimizer now knows how to compute a solution for starting a vm, lacking ui, but that will take no time when vdsm is sorted out 15:12:29 <bkp> #info 3.5 status sla hosted engine in good shape and with more stable state machine as far as starting the engine vm is concerned 15:12:47 <bkp> Moving on to vdsm, danken 15:12:57 <bkp> I already have this... 15:13:00 <urthmover> alonbl_: but I am thinking through how to handle the 800GB disks for those 10 guests. 15:13:06 <bkp> #info 3.5 status vdsm dougsland to build vdsm 4.14.11 15:13:07 <urthmover> nsoffer: I'm all ears 15:13:58 <bkp> urthmover, alonbl, nsoffer Still in meeting, can you hold off a few more minutes? Thanks. 15:14:01 <dougsland> bkp, you meant 3.4.3? or 3.5 ? 15:14:19 <bkp> Agh. 3.4.3 15:14:26 <dougsland> bkp, ok :) 15:14:27 <bkp> Sorry, strike that. 15:14:47 <bkp> #info 3.4.z updates vdsm dougsland to build vdsm 4.14.11 15:14:49 <SvenKieske> why you are at 3.4.3: maybe test if this occurs in 3.4.z also, as it's a regression in 3.3.z: https://bugzilla.redhat.com/show_bug.cgi?id=1120267 15:15:13 <bkp> danken: Any other 3.5 updates from vdsm? 15:16:33 <bkp> Okay, moving on. 15:16:36 <danken> bkp: nope. sla, lastclientIface 15:16:47 <bkp> Gotcha, thanks. 15:17:26 <bkp> #info 3.5 status vdsm Strong concerns about iotunes in SLA raised. 15:17:42 <sbonazzo> danken: can you take a look at https://bugzilla.redhat.com/show_bug.cgi?id=1120267 ? 15:17:55 <bkp> #info 3.5 status vdsm Also concerns about lastclientIface 15:19:09 <bkp> #action 3.5 status Appropriate owners, please address danken's concerns about sla, lastclientIface 15:19:13 <danken> sbonazzo: can someone from infra help? most probably an old Engine bug 15:19:18 <bkp> Moving on. 15:19:29 <bkp> UX! awels, still here? 15:19:38 <awels> bkp: I am. 15:19:43 <awels> bkp: Sorting is in 3.5 for all main tabs, except Volumes (gluster) that is only in 'master' ATM. Sorting is in 3.5 for most sub-tabs as well, except the ones in 'virt' main-tabs and Volumes. full status is in: https://docs.google.com/spreadsheets/d/1S3qDYqv9OK5ruI41RpFpRAsLaojpGL-W6WYUej3629s/edit?usp=sharing 15:20:06 <awels> bkp: Italian translation in progress (currently in ~30% completion). 15:20:11 <awels> bkp: No blockers 15:20:58 <bkp> #info 3.5 status ux Sorting is in 3.5 for all main tabs, except Volumes (gluster) that is only in 'master' ATM. Sorting is in 3.5 for most sub-tabs as well, except the ones in 'virt' main-tabs and Volumes. 15:20:58 <bkp> #info 3.5 status ux full status is in: https://docs.google.com/spreadsheets/d/1S3qDYqv9OK5ruI41RpFpRAsLaojpGL-W6WYUej3629s/edit?usp=sharing 15:20:58 <bkp> #info 3.5 status ux Italian translation in progress (currently in ~30% completion). 15:20:58 <bkp> #info 3.5 status ux No blockers 15:21:09 <bkp> Cool, anything else? 15:21:18 <awels> bkp: No thats it 15:21:28 <bkp> #topic Conferences and Workshops 15:21:36 <bkp> #info Conferences and Workshops oVirt Workshop around KVM Forum is a go. Funding has been acquired for the one-day event around KVM Forum. Date/deadlines to follow. 15:21:37 <bkp> #info Conferences and Workshops OSCON is next week, looking forward to seeing oVirt community members' presentations and at the Red Hat booth. 15:21:37 <bkp> #info Conferences and Workshops No new information on "Red Hat Day" at Fossetcon in September. Will update. 15:21:49 <bkp> #topic Other Topics 15:21:55 <bkp> Any new topics? 15:22:13 <bkp> #info Other Topics Documentation is ready for review/updating. See http://lists.ovirt.org/pipermail/users/2014-July/025900.html for details on how you can help! 15:22:36 <bkp> Anything else? 15:22:47 <bkp> Going once? 15:23:04 <bkp> Twice? 15:23:27 <bkp> Thank you all! Have a safe week! 15:23:29 <bkp> #endmeeting