15:01:55 <doron> #startmeeting
15:01:55 <ovirtbot> Meeting started Wed Nov 13 15:01:55 2013 UTC.  The chair is doron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:55 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:02:08 * orc_orc looks on to the meeting
15:02:10 <YamakasY> orc_orc: you became Yoda ?
15:02:19 * sbonazzo here
15:02:21 <orc_orc> YamakasY: not now please -- meeting in progress
15:02:31 <YamakasY> orc_orc: I just saw
15:02:38 * YamakasY half here
15:02:38 <doron> #topic ovirt weekly sync
15:03:13 * danken is here
15:04:12 * mburns here in the background
15:04:31 * sahina here
15:05:11 * jb_netapp here
15:05:52 * lvernia here
15:06:12 <doron> #topic Agenda and roll call
15:07:09 * jb_netapp here
15:07:36 <doron> Agenda:
15:07:39 <doron> 3.3 update releases
15:07:41 <doron> 3.4 planning
15:07:42 <doron> conferences and workshops
15:07:44 <doron> infra update
15:07:45 <doron> other topics
15:07:51 <doron> let's start
15:08:10 <doron> #info 3.3 update releases
15:08:32 <mburns> doron: probably want to #info all the agenda items
15:08:37 <mburns> then switch the topic to each one
15:09:01 <doron> mburns: thanks
15:09:24 <doron> #info 3.3 update releases
15:09:26 <doron> #info 3.4 planning
15:09:27 <doron> #info conferences and workshops
15:09:29 <doron> #info infra update
15:09:30 <doron> #info other topics
15:09:36 <doron> #topic 3.3 update releases
15:09:53 <doron> danken: would you like to share any 3.3 updates?
15:10:11 <danken> well, I am aware of a single blocker
15:10:25 <danken> Bug 1022961 -        Running a VM from a gluster domain uses mount instead of gluster URI
15:10:29 <danken> or are there more?
15:10:32 <sbonazzo> danken: doron: actually we have 2 blockers and one proposed
15:10:40 <sbonazzo> Bug 1022961 -        Running a VM from a gluster domain uses mount instead of gluster URI is in post
15:10:50 <sbonazzo> Bug 1029584 -        create vm does not work with display protocol vnc and operating system linux
15:10:56 <sbonazzo> is a regression found this morning
15:11:17 <sbonazzo> this will need to rebuild ovirt-engine for including a missing patch
15:11:25 <doron> sbonazzo: thanks. Who's handling it?
15:11:32 <danken> is 1029584 a real blocker, sbonazzo?
15:11:46 <sbonazzo> 1029885 has been proposed as blocker too
15:11:59 <danken> I mean, it's annoying, but is it a regression of ovirt-3.3.1?
15:12:24 <sbonazzo> danken: I think so.
15:12:51 <doron> sbonazzo: so you agree with marking it as a version blocker?
15:12:54 <sbonazzo> Bug 1029885 -        cloud-init testcase does not work in engine 3.3.1
15:13:15 <sbonazzo> doron: yes I agree, and I think that also itamar will agree on that
15:13:16 <mburns> i agree that create vm failing should be fixed, especially if it's a regression
15:14:12 <doron> #agreed 1029885 is a blocker.
15:14:16 <doron> what about the others?
15:14:28 <doron> is 1029584 a blocker?
15:14:41 <danken> the cloud-init issue is no regression according to https://bugzilla.redhat.com/show_bug.cgi?id=1029885#c2
15:14:47 <sbonazzo> doron:  1029584 is the vm not starting
15:14:53 <mburns> 1029885 --- not sure that is even ovirt related, looks like either environmental or cloud-init...
15:14:58 <danken> we simply require a too-new cloud-init
15:15:15 <doron> #agreed  BZ 1029584 is a blocker.
15:15:36 <sbonazzo> about 1029885 I think we can postpone to 3.3.2
15:15:36 <danken> who's handling it on virt?
15:15:53 <mburns> 1022961 -- i would like to see that fixed, and it's in POST, but what's the status on getting it merged?
15:15:54 <danken> ack for postponing 1029885
15:16:01 <sbonazzo> doron: 1029584 is handled by  Shahar Havivi
15:16:13 <sbonazzo> doron: Ofer and I will take care of the rebuild
15:16:28 <doron> mskrivanek: any inputs on  1029584?
15:17:36 <doron> I guess we'll have to take it offline to get a status update.
15:17:42 <sbonazzo> mburns: 1022961 is merged on master, posted under review on 3.3 but I don't think it will be an easy merge
15:18:06 <danken> sbonazzo: abaron does not want it in - the code is very ugly
15:18:11 <doron> #action doron to followup on 1029584 with mskrivanek
15:18:32 <doron> any other potential blockers?
15:19:15 <danken> mburns: I worked on that hack last week, and I do not see anyone else fixing the broken glusterSD in any better way soon.
15:19:39 <sbonazzo> doron: i don't think there is anything else for 3.3.1.
15:19:48 <doron> mburns: do we have a list of 3.3.x blockers to monitor?
15:19:50 <mskrivanek> doron: yes
15:19:57 <danken> so we should either convince abaron to take the code, or live with the regression.
15:19:59 <mburns> doron: yes, sbonazzo has a tracker...
15:20:06 <sbonazzo> doron: we've trackre bug for 3.3.1 and 3.3.2
15:20:10 <doron> mskrivanek: we need feedback on 1029584 which is a blocker.
15:20:11 <mskrivanek> doron: it's pending backport to 3.3.1.1 or something like that. it's already fixed
15:20:17 <sbonazzo> 3.3.1 : https://bugzilla.redhat.com/show_bug.cgi?id=1019391
15:20:22 <mburns> danken: the question is whether we can live with this in 3.3.1
15:20:37 <danken> mburns: exactly. I think we cannot.
15:20:38 <sbonazzo> 3.3.2 https://bugzilla.redhat.com/show_bug.cgi?id=1027349
15:20:49 <doron> mskrivanek: it's still in NEW
15:21:01 <danken> that's why I stepped into this quagmire in the first place...
15:21:30 <mburns> danken: ok, then it's still a blocker and we can't release until it's fixed
15:21:41 <mskrivanek> doron: we don't have 3.3.1.1 branch yet and 3.3.1 is gone. once there is a new branch (ofer's doing it?) we'll backport existing fix which is in 3.3.2 already
15:21:52 <danken> mburns: abaron says that glustersd is half-broken anyway
15:21:54 <mburns> 3.3.1 is gone?
15:22:02 <mburns> mskrivanek: it hasn't released yet...
15:22:10 <danken> mburns: even in ovirt-3.3.0, since it does not allow VMs with snapshots
15:22:11 <sbonazzo> mskrivanek: yes, ofer is doing it
15:22:22 <mskrivanek> mburns: I've been told the branch is gone so we have nowhere to backport it to ATM
15:22:28 <sbonazzo> mburns: 3.3.1 branch has been removed after 3.3.1 tagging
15:22:50 <sbonazzo> mburns: ofer is restoring a 3.3.1 branch and handle the tagging issue
15:22:53 <doron> sbonazzo: so how do we plan to build 3.3.1?
15:22:59 <mburns> sbonazzo: ok, seems strange to remove the branch before the release is gone, but whatever...
15:23:30 <sbonazzo> doron: yes, we'll rebuild ovirt-engine just after the branch creation and patch backporting
15:23:35 <mburns> danken: so you think we should at least try to fix the gluster issue in 3.3.1, but abaron doesn't
15:23:50 <mburns> overall summary:
15:24:18 <mburns> 1029885 is a blocker, is fixed and is awaiting backport and rebuild of ovirt-engine
15:24:36 <mburns> no
15:24:45 <mburns> 1029584 is a blocker, is fixed and is awaiting backport and rebuild of ovirt-engine
15:24:55 <mburns> 1029885 is not a blocker, needs to be moved to 3.3.2
15:25:14 <danken> mburns: yeah, I suppose you can some it up this way.
15:25:32 <mburns> 1022961 -- some consider it a blocker, some don't, patch is posted, but under disagreement
15:25:52 <sbonazzo> mburns: 1029885  added to 3.3.2 tracker
15:26:00 <doron> danken: is 1022961 a regression?
15:26:05 <danken> doron: yes
15:26:16 <doron> danken: so it sounds like a blocker.
15:26:20 <danken> an unintended collateral of the rebase we had
15:26:20 <mburns> danken: how about this:  we drop 1022961 from the blocking list so we can at least post engine and an updated vdsm
15:26:48 <mburns> and we fix the gluster domain issue in an async update as soon as a fix is agreed on?
15:27:00 <danken> mburns: that would be a shame to release ovirt-3.3.1 without vdsm :-(
15:27:37 <mburns> danken: we could release a vdsm that has the bug
15:27:58 <mburns> iiuc, gluster domains work, they just use mount instead of libgfapi
15:28:45 <danken> mburns: that's not gluster domain at all...
15:29:03 <danken> it's gluster-fuse, which we had in 3.1, I believe
15:29:32 <doron> danken: so what do you suggest?
15:29:42 <mburns> danken: so when can you have it fixed?
15:29:43 <danken> and it's gonna be non-fun to try to migrate a VM from 3.3.0 to 3.3.1
15:29:55 <danken> abaron: convince abaron to take the patch ;-)
15:30:16 <doron> abaron: ?
15:30:20 <mburns> danken: is it true that we *need* the rebased vdsm with 3.3.1?
15:30:38 <danken> mburns: if that's true we have a serious bug!
15:30:49 <danken> engine-3.3.1 must work with vdsm-3.3.0
15:30:58 <mburns> ok, good
15:31:03 <danken> though that's combination has not been tested thoroughly.
15:31:08 <danken> maybe itamar can help with the decision making.
15:31:24 <abaron> danken: ?
15:31:38 <danken> but holding vdsm sounds the most reasonable choice
15:31:40 <doron> abaron: 1022961 seems to be a blocker
15:32:12 <itamar> danken: reading history
15:32:25 <doron> abaron: according to danken no point of 3.3.1 without it.
15:32:40 <danken> doron: not exactly
15:32:53 <danken> doron: I said that it's bad to release vdsm without it
15:33:01 <abaron> doron: unfortunately, that bug is currently saving our asses
15:33:35 <danken> abaron: I do not understand how. the bug is not on 3.3.0
15:33:47 <doron> abaron: having a regression as a life saver does not sound promising.
15:33:49 <abaron> danken: we want the bug in 3.3.0
15:33:57 <danken> but it's not there.
15:34:03 <itamar> abaron: how is it different between posixfs and libgfapi (other than snapshots not working)?
15:34:14 <abaron> snapshots are not working
15:34:31 <abaron> that's a no go
15:35:25 <mburns> so current state:  3.3.0:  uses libgfapi, but snapshots are broken
15:35:40 <mburns> 3.3.1:  uses posix (which it shouldn't), and snapshots work
15:36:04 <mburns> patch for 1022961 changes it back to using libgfapi, but would break snapshots again
15:36:10 <mburns> abaron: danken:  is that accurate? ^^
15:36:21 <danken> mburns: yep
15:36:34 <danken> we can keep the bug unfixed
15:36:36 <mburns> and the snapshot issue is a bug in libgfapi
15:36:50 <danken> but only if we block glusterSD in Engine
15:36:52 <mburns> (or series of bugs)
15:37:28 <mburns> danken: is there a problem with migration from libgfapi vm to posix vm?
15:37:34 <mburns> or vice-versa?
15:37:34 <danken> It is unacceptable to make people THINK they start glusterSD, but use fues insteead
15:37:52 <danken> it would break future compat, when libgfapi is fixed.
15:38:05 <danken> mburns: yes, it would not work ;-)
15:38:11 <abaron> whoever said that glusterSD is synonymous with libgfapi
15:38:13 <abaron> ?
15:38:14 <mburns> so, today, if someone has a glustersd configured
15:38:25 <mburns> and they upgrade to 3.31
15:38:29 <mburns> 3.3.1
15:38:34 <mburns> it would break
15:38:41 <mburns> because the domain would switch to using fuse
15:38:49 <danken> mburns: indeed.
15:39:05 <abaron> danken?
15:39:16 <abaron> why and how would this affect migration?
15:39:34 <mburns> so then i think we would have to fix this so that it uses libgfapi
15:39:36 <danken> abaron: the domxml uses a file path
15:39:45 <mburns> even if snapshots don't work
15:39:53 <danken> instead of the gluster "network drive" parameters
15:39:58 <mburns> snapshots not working are status quo
15:39:58 <abaron> danken: however it was in source, that's how it will run in target
15:40:41 <abaron> mburns: snapshots are much more basic than libgfapi
15:40:49 <abaron> libgfapi is basics
15:40:52 <abaron> sorry
15:40:55 <abaron> snapshots is basics
15:40:58 <mburns> we can basically release note that due to a bug in libgfapi, snapshots don't work on gluster domains
15:41:24 <danken> abaron: hmm, you may be right
15:41:27 <abaron> mburns: we can do the same but state that libgfapi isn't in use
15:42:12 <mburns> abaron: will that break people upgrading?
15:42:16 <danken> about migration not breaking. vdsm does not do anything on the destination, and the fuse mount should be there.
15:42:50 <abaron> mburns: not that I'm aware of, but really needs testing
15:43:00 <danken> still, it takes the sting from the glusterSD feature
15:43:22 <abaron> not to mention that we don't have a proper fix for this anyway (using libgfapi
15:43:32 <mburns> danken: yes, but we can document that they'll get that ability later
15:43:38 <mburns> when libgfapi is fixed
15:44:12 <orc_orc> mburns: that looks like a handwavy date ...
15:44:14 <orc_orc> I cannot see the context in https://bugzilla.redhat.com/show_bug.cgi?id=797961 as it is private, but it seems to have been lingering since 2012-02 -- it is also blocked by 1022961 as well as the oVirt 3.3.1 release in 1019391
15:44:19 <orc_orc> and that is a while
15:45:02 <mburns> orc_orc: fwiw, i'm pretty sure work is being done to fix the issue in libgfapi now
15:45:08 <mburns> but i don't know details...
15:45:08 <orc_orc> ;)
15:45:59 <orc_orc> I see POST status on 1022961 ... perhaps there is a timeline to general release to reach out to get a 'read' on?
15:46:23 <mburns> orc_orc: that's the debate above between danken and abaron
15:46:37 <danken> orc_orc: the post for that bug is very ugly
15:46:39 <mburns> it's about whether that fix should be accepted or not
15:46:54 <abaron> mbunrs: the fix as is should not be accepted period.
15:47:08 <doron> mburns: so how long can we delay 3.3.1? this will not converge in the near future.
15:47:23 <danken> mburns: I do not think we should
15:47:44 <mburns> ok, so abaron and danken agree we shouldn't accept the fix
15:47:49 <danken> ovirt-3.3.0 did not really have glusterSD
15:47:59 <mburns> danken: abaron:  so release vdsm as is today with 3.3.1?
15:48:09 <mburns> and converge on this issue for 3.3.2?
15:48:10 <danken> mburns: yes
15:48:21 <mburns> doron: there is the agreement!
15:48:29 <doron> mburns: indeed so ;)
15:48:40 <mburns> so let's move this bug to 3.3.2
15:48:43 <danken> danken: but put a big sign that there's no glusterSD
15:48:54 <danken> doron: could you add it to actions?
15:49:01 <doron> #agreed release vdsm as is today with 3.3.1
15:49:03 <mburns> danken: what do you mean?
15:49:16 <doron> #action release vdsm as is today with 3.3.1
15:49:29 <danken> mburns: glusterSD was a promised feature for 3.3, but it's not there.
15:49:33 <doron> #action handle 1022961 for 3.3.2
15:49:50 <mburns> danken: so what are we going to do in engine?
15:49:54 <mburns> prevent people from using it?
15:49:59 <danken> mburns: no, a realease note
15:50:04 <mburns> ok
15:50:09 <mburns> a release note is doable
15:50:37 <mburns> saying that the gluster storage domain uses fuse for the time being due to issues with libgfapi
15:50:41 <doron> #action add a release note for glusterS
15:50:45 <sbonazzo> danken: can you take care of moving the bug to the 3.3.2 tracker?
15:50:47 <dneary> Hi all
15:50:59 <doron> hi dneary
15:51:01 <sbonazzo> dneary: hi
15:51:12 <mburns> doron: ok, i think we can move on now
15:51:36 <doron> #topic 3.4 planning
15:51:42 <danken> sbonazzo: sure.
15:51:49 <sbonazzo> danken: thanks
15:52:01 <doron> who can update on 3.4 planning??
15:52:09 <doron> sbonazzo: ?
15:52:40 * tontsa is pretty disappointed on gluster fapi decission
15:52:52 <YamakasY> guys what about importing VM's, existing ones that are on an NFS share you just attached
15:52:56 <sbonazzo> doron: about 3.4.0 there is the spreadsheet posted by itamar on google docs
15:53:08 <doron> sbonazzo: I'm aware of it.
15:53:18 <sbonazzo> doron: it's linked on http://www.ovirt.org/OVirt_3.4_release-management
15:53:29 <doron> https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1dSMnZwMF9XWVE&usp=sharing#gid=0
15:53:40 <danken> tontsa: no one is happy about it :-(
15:53:52 <sbonazzo> doron: bug scrubing is still in progress but we've moved down from 366 bugs unscrubbed to 307
15:53:56 <doron> IIUC users should add their names to specific features
15:53:58 <danken> tontsa: do you have any other way out?
15:54:00 <abaron> mburns: note that problem is not libgfapi per se but rather lack of support in libvirt for snapshots over libgfapi
15:54:14 <sbonazzo> doron: http://red.ht/17pazhH (unscrubbed bugs)
15:54:19 <tontsa> danken, prolly try to push it via rhev side
15:54:27 <tontsa> but meh..
15:54:44 <doron> sbonazzo: I'm still trying to understand who is looking into features.
15:54:52 <doron> that is 3.4 features
15:55:19 <danken> tontsa: rhev is rhev. we're here to solve ovirt problems.
15:55:25 <sbonazzo> doron: there are a few features with devel owner set
15:55:47 <YamakasY> is ovirt not still an rhev ripoff ?
15:55:59 <abaron> YamakasY: ?
15:56:12 <YamakasY> abaron: ovirt is rhev
15:56:20 <doron> sbonazzo: many of the features coming from users-ml are not handled.
15:56:22 <YamakasY> about we need to fix ovirt bugs
15:56:32 <abaron> YamakasY: if anything it's the other way around
15:56:35 <YamakasY> doron: that is known
15:56:38 <tontsa> danken, yep.. but i need that feature or have to think goin some other way like ceph
15:56:48 <doron> dneary: any idea how to remind folks about it?
15:56:58 <YamakasY> abaron: huh ? centos is also a ripoff from rhel
15:57:12 <abaron> YamakasY: centos is repackaging of rhel srpm
15:57:27 <YamakasY> abaron: yap
15:57:34 <abaron> YamakasY: oVirt is not repackaging of rhev
15:57:40 <YamakasY> abaron: how can rh sell an OSS >
15:57:41 <YamakasY> ?
15:58:06 <danken> tontsa: I'm certain glusterSD is going to get there
15:58:12 <tontsa> ovirt is upstream to rhev, but rhev is much more cherry picked
15:58:14 <danken> but not for ovirt-3.3.1 :-(
15:58:22 <dneary> doron, I don't right now have an "unanswered questions" filter/web page - that would be something noce to have, but mailing lists aren't set up for that
15:58:33 <YamakasY> tontsa: that's true
15:58:51 <abaron> YamakasY: I'm not sure what that has to do with oVirt or how that is relevant here
15:58:52 <dneary> doron, I could do a simple MLStats report which has "unanswered emails" - emails that have not had at least one reply
15:59:13 <doron> dneary: I'm focusing now on features asked in users-ml, while no one steps forward to handle it for 3.4.
15:59:14 <tontsa> danken, yep.. it's just uncertain if we go with fuse whether we can upgrade to libgfapi later on
15:59:27 <doron> dneary: check https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1dSMnZwMF9XWVE&usp=sharing#gid=0
15:59:31 <YamakasY> abaron: it's a normal way that rh created ent stuff on OSS so needs to release too OSC...
15:59:33 <tontsa> or will it be some arcane database manipulation and copying data
15:59:38 <YamakasY> that's why CentOS exists
15:59:53 <doron> sbonazzo: mburns how long do we have to finalize 3.4 planning?
15:59:53 <orc_orc> YamakasY: please wait a bit until after the meeting
16:00:13 <YamakasY> orc_orc: yep, I mean... we have to look to rhev to see what we want
16:00:21 <YamakasY> and what is doable
16:00:31 <danken> YamakasY: it does not sell the software, it sells support., QE, upgrade process...
16:00:46 <sbonazzo> doron: Code freeze:  end of December
16:00:50 <mburns> doron: the important dates are end of Decemeber for dev freeze
16:00:55 <mburns> and end of january for release
16:01:04 <YamakasY> danken: is it possible to download RHEV than ?
16:01:07 <doron> mburns: wow, and we still do not have all 3.4 in place.
16:01:16 <danken> tontsa: we have not tested this, but abaron convinced me that we can upgrade.
16:01:18 <sbonazzo> doron: yep :-/
16:01:23 <dneary> doron, Oh, right.
16:01:31 <YamakasY> mburns: would be great, we can upgrade when we are finally in production than
16:01:51 <danken> YamakasY: I'm sure you can download the source. It's gpl/apache license. RH has to give it.
16:01:58 <dneary> doron, What do you mean by "finalize" 3.4 planning? I would say you want to have a prioritised list of features already, and a cut-off date beyond which new features do'nt get started
16:02:03 <doron> mburns: any idea how to finalize 3.4 plans?
16:02:07 <YamakasY> danken: source, but no "install from here"
16:02:19 <doron> dneary: we have the dates
16:02:22 <tontsa> danken, ok..
16:02:39 <doron> dneary: Code freeze:  end of December
16:02:58 <doron> we should by now have a defined scope for 3.4
16:03:01 <dneary> YamakasY, oVirt is the base on which future RHEV releases will be built. RHEV has fewer new/in-progress features, and more bug fixes (at least, short term) - better integration with RHEL and more testing
16:03:10 <sbonazzo> doron: dneary: that sounds more like a feature freeze
16:03:11 <dneary> doron, Yes, I agree
16:03:15 <danken> YamakasY: of course. Centos could build and ship it if they wanted.
16:03:39 <doron> mburns: I suggest we target next week to finalize 3.4
16:03:51 <doron> otherwise we won't make the dates.
16:03:59 <dneary> sbonazzo, There are 2 different things: 1. "what features would we like to get done for the next release?" and 2. "what features are almost ready to ship?"
16:04:33 <sbonazzo> dneary: looking at fedora model, feature freeze will cutoff features not 100% completed
16:04:56 <mburns> doron: yes, makes sense to finalize next week
16:05:00 <danken> (doron, what are the dates for 3.4?)
16:05:16 <YamakasY> danken: why don't we do that and compare and take stuff out of it ?
16:05:19 <doron> danken: http://www.ovirt.org/OVirt_3.4_release-management
16:05:55 <SvenKieske> may I add a feature wish? I already did via ML, but it didn't get included into google docs and I have no write access to that
16:06:14 <doron> dneary: sbonazzo I'd like for next week to have all dev leads commiting on the list of 3.4 features. Pplus a reminder to users to step in.
16:06:27 <doron> itamar: ^^^^^
16:06:35 <sbonazzo> SvenKieske: you can ask for write access on http://bit.ly/17qBn6F
16:06:39 <SvenKieske> We need every webadmin feature accessible via rest-api, that would be all, and bug fixes :) and a working cloud-init, but that should be in 3.3.2 at least :)
16:06:48 <itamar> doron: +1 from me.
16:07:16 <sbonazzo> doron: +1 for me ( I'm still trying to have write access to the list for instance)
16:07:22 <orc_orc> we had a queston in the channel about http://wiki.qemu.org/Features/LiveBlockMigration
16:07:36 <doron> #action get a commitment for next week from all dev leads on 3.4 scope.
16:08:09 <doron> #action dneary to rmiend users list and devel list on last chance to step in for 3.4 features.
16:08:16 <doron> moving on.
16:08:21 <dneary> doron, OK - put it on me
16:08:35 <doron> dneary: just did ;)
16:08:41 <doron> #topic conferences and workshops
16:08:52 <doron> dneary: care to share some updateS?
16:09:50 <doron> one thing I'm aware of is LISA 13
16:10:39 <doron> #info LISA 13 https://www.usenix.org/conference/lisa13 was held last week.
16:11:00 <doron> itamar:  dneary: upcoming events / updates?
16:11:02 <dneary> doron, Yes
16:11:49 <dneary> First, KVM Forum/oVirt summit in Edinburgh: awesome event, there was huge interest in the KVM management presentations in CloudOpen Europe. People don't have an oVirt problem, but they do have a KVM mgmt problem in these conferences
16:12:07 <dneary> The management track in the KVM Forum did well - room was over half full every session I was at
16:12:20 <dneary> I recorded 2 user stories for oVirt which I still need to write up and publish
16:12:33 <orc_orc> dneary: note presentation by you as well, of course
16:12:43 <orc_orc> did you get notes of 'todo' stuff as you wished
16:12:51 <orc_orc> nice*
16:13:00 <dneary> The oVirt sessions were lightly attended, but the audience was a good one. Not so many note takers, I think
16:13:19 <doron> dneary: do we have all slides in ovirt.org?
16:13:27 <dneary> We will get slides & notes online this week. I'm just back from another conference (OpenStack Summit) so still behind
16:13:53 <doron> #action dneary to complete uploading kvm-forum slides to ovirt.org
16:14:12 <doron> dneary: Thanks. Any other updates?
16:14:15 <dneary> doron, Not sure. I know that someone started that, but haven't checked if it was complete. Thanks to Karen Noel we also have videos of all of the sessions
16:14:29 <dneary> Einav Cohen also represented oVirt at LISA 13 last week
16:14:48 <dneary> She wrote a conference report which I will be sending on to the users list
16:15:13 <doron> #action dneary to  share LIAS report in users-ml.
16:15:23 <doron> #action dneary to  share LISA report in users-ml.
16:15:42 <doron> dneary: future plans?
16:15:45 <dneary> She reported a lot of interest in RHEL and Red Hat, and decent interest in oVirt. Most people she spoke to were looking for a cheaper alternative to vSphere, some were lookinbg for KVM mgmt solution, and some were already oVirt users sharing the love
16:15:58 <bobdrad> I take it nobody is at SUSECon at the moment
16:16:21 <dneary> Future plans: We have requested a stand for FOSDEM, the call for papers is currently open for the virt & cloud devroom in FOSDEM (don't have the link handy right now)
16:16:45 <doron> dneary: something we should track?
16:16:48 <dneary> We also are planning an oVirt board meeting in the coming weeks. I'll send an email to the board list about it
16:17:14 <dneary> doron: Absolutely! I would like to see lots of proposals on oVirt topics for FOSDEM, it's an awesome conference
16:17:16 <SvenKieske> https://fosdem.org/2014/news/2013-09-17-call-for-participation-part-two/ ?
16:17:51 <dneary> We have pushed back plans for an oVirt workshop around the start of the year for logistical & budget reasons. Will keep people posted.
16:17:58 <doron> dneary: please mail me the link and I'll send reminders to users and devel lists.
16:18:09 <orc_orc> the FOSDEM deadline is pretty soon as I recall in November
16:18:11 <dneary> SvenKieske, There is one specifically for virt & cloud
16:18:40 <dneary> https://groups.google.com/forum/#!topic/fosdem14-virt-and-iaas-devroom/04y5YkyqzIo
16:18:54 <dneary> Submission deadline is in 2 weeks
16:18:54 <doron> #info we're looking for people to submit papers for FOSDEM.
16:20:05 <doron> #info Submission deadline: Sunday, December 1st, 2013 https://groups.google.com/forum/#!topic/fosdem14-virt-and-iaas-devroom/04y5YkyqzIo
16:20:12 <doron> thanks dneary.
16:20:23 <doron> moving on.
16:20:39 <doron> #topic infra update
16:20:46 <doron> sbonazzo: can you help on this one?
16:21:36 <mburns> ewoud: eedri_ ?
16:21:38 <orc_orc> minues of weekly meeting were at: http://ovirt.org/meetings/ovirt/2013/ovirt.2013-11-11-14.59.html
16:21:52 <orc_orc> there was a rackspace machine access issue and a ticket pending
16:22:21 <orc_orc> other than that it iws relatively uneventful
16:22:47 <doron> orc_orc: thanks
16:22:52 <orc_orc> doron: a pleasure
16:23:13 <doron> orc_orc: can we follow up on the ticket you mentioned?
16:23:28 <orc_orc> doron: I dno not know the number ...
16:23:39 <orc_orc> looking for filer info
16:23:39 <doron> dcaro_: ping?
16:23:59 <dcaro_> doron: pong
16:24:03 <orc_orc> 15:01:24 <knesenko> so we are still blocked on rackspace migration
16:24:18 <doron> dcaro_: any updates on this ticket?
16:24:21 <orc_orc> 15:06:05 <dcaroest> I'm in the middle of writing it
16:24:32 <dcaro_> yep, we are waiting for someone with admin roghts to give ok to the fw modifications
16:24:45 <doron> dcaro_: reading from last week:     ACTION: dcaroest reply to rackspace ticket and ask them to fix the issue (knesenko, 15:07:52)
16:25:01 <doron> dcaro_: what should we chech next week?
16:25:22 <doron> (check)
16:25:31 <dcaro_> I'll send an email fo jim strong asking for ack
16:25:49 <doron> #action followup with dcaro_ on rackspace ticket.
16:25:53 <doron> thanks dcaro_
16:25:58 <dcaro_> welcome :)
16:26:13 <doron> #topic other topics
16:26:32 <doron> anything else you wish to discuss / ask / etc ?
16:26:37 <orc_orc> I have a general question if this is the right time
16:26:53 <doron> orc_orc: shoot
16:27:18 <orc_orc> it is  a more general 'beta -> release' process question:
16:27:22 <orc_orc> This is my first run through watching the beta cycle for ovirt
16:27:27 <orc_orc> http://www.ovirt.org/OVirt_3.3.1_release_notes  indicates we are in a BETA phase
16:27:32 <orc_orc> yet it was said: 10:22 < sbonazzo> mburns: 3.3.1 branch has been removed after 3.3.1 tagging
16:27:36 <orc_orc> The question is:
16:27:47 <orc_orc> how do fixes found during the beta time get applied and a freshened beta made available for testing against the old tree ?
16:28:14 <orc_orc> is not the old branch still needed until it is released?
16:28:16 <doron> orc_orc: a new 3.3.1 should be created for the ovirt 3.3.1 release.
16:28:34 <doron> orc_orc: I believe it was mentioned that this branch should be re-created.
16:29:02 <orc_orc> so .. the process inadvertently removed it prematurely?
16:29:23 <doron> orc_orc: ] <sbonazzo> mburns: ofer is restoring a 3.3.1 branch and handle the tagging issue
16:29:44 <orc_orc> doron: yes ... but as a general thing, why remove it early?
16:29:46 <doron> orc_orc: and since we havee a tag we should be able to restore it.
16:30:02 <doron> orc_orc: sounds like a mistake to me.
16:30:20 <orc_orc> * nod *
16:30:28 <doron> anything else?
16:30:42 <doron> going once....
16:30:52 <doron> going twice....
16:31:09 <doron> #endmeeting