15:00:40 <quaid> #startmeeting
15:00:40 <ovirtbot> Meeting started Wed Feb 22 15:00:40 2012 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:40 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:48 <teuf> danken1: this will be libvirt erroring out, but the end result will be the same
15:01:04 <quaid> #meetingname oVirt weekly sync
15:01:04 <ovirtbot> The meeting name has been set to 'ovirt_weekly_sync'
15:01:18 <quaid> #topic Roll-call
15:01:22 * sgordon is here
15:01:25 <teuf> danken1: and it will probably also give an error if a TLS port is set in libvirt domain xml while qemu.conf has spice_tls=no
15:01:25 * jb_netapp is here
15:01:29 <ovirtbot> 14[[07Release Process14]]4 !10 02http://www.ovirt.org/w/index.php?diff=2497&oldid=2496&rcid=2573 5* 03Oschreib 5* (-8) 10
15:01:36 * oschreib here
15:02:17 * mburns here
15:02:27 <teuf> danken1: can you answer to the email on the list?
15:02:57 <ovirtbot> 14[[07Release Process14]]4 !10 02http://www.ovirt.org/w/index.php?diff=2498&oldid=2497&rcid=2574 5* 03Oschreib 5* (+42) 10/* General */ 
15:03:40 * ykaul here
15:03:53 * ovedo here
15:04:29 <ovirtbot> 14[[07Release Process14]]4 !10 02http://www.ovirt.org/w/index.php?diff=2499&oldid=2498&rcid=2575 5* 03Oschreib 5* (+42) 10/* General */ 
15:04:32 <quaid> #topic Agenda check
15:04:38 <quaid> so I've got:
15:04:42 <quaid> * Update on release process plan
15:04:47 <quaid> * Beijing workshop status
15:04:53 <quaid> * Anything else?
15:05:33 <oschreib> update on release criteria
15:05:51 <quaid> ok, I was thinking of that as part of the first item
15:06:02 <oschreib> fine by me
15:06:16 <quaid> ok, let's go, anything new can be added at the end
15:06:34 <quaid> #topic Release process and criteria
15:06:57 <oschreib> So, we have new wiki page for the second release (probably version 3.1)
15:07:10 <acathrow> re: release criteria we need to discuss platform support. Right now we are only releasing F16 RPMs we need to add others to the plan.
15:07:10 <acathrow> We need people to sign off for other distros - obviously I want to add EL6, but we of course need Debian. ubuntu and (open) suse
15:07:22 <oschreib> http://www.ovirt.org/wiki/Second_Release
15:07:28 <oschreib> quaid: chair me please
15:07:46 <quaid> #chair oschreib
15:07:46 <ovirtbot> Current chairs: oschreib quaid
15:07:48 <danken1> teuf: I lack context. which email and list?
15:07:57 <quaid> you can #link without chair btw
15:08:10 <oschreib> #info new wiki for second release
15:08:22 <oschreib> #link http://www.ovirt.org/wiki/Second_Release
15:08:46 <oschreib> #info new wiki for release process (work in progress)
15:08:49 <teuf> danken1: the "non-TLS spice connections" email on vdsm/libvir-list to which you already replied once
15:08:58 <oschreib> #link http://www.ovirt.org/wiki/Release_Process
15:09:19 <oschreib> we're in the middle of the release process discussions
15:09:35 <oschreib> I need to edit the wiki mentioned earlier, but we're in the right track
15:09:51 <oschreib> about release criteria, I just created the second release page.
15:10:13 <oschreib> so feel free to edit it, I'll maintain it.
15:10:16 <danken1> teuf: I did not notice another question...
15:11:25 <danken1> teuf: do you really have listen_tls=no ?
15:11:34 <danken1> in qemu.conf?
15:11:36 <oschreib> anything more? questions?
15:12:24 <teuf> danken1: listen_tls=0 # by vdsm
15:12:29 <oschreib> acathrow: Actually, upstream shouldn't maintain rpms. it should maintain tarball
15:12:30 <rharper> oschreib: on the second release, how long of a window for proposing the criteria ?  has the last release been out long enough to pull in any feedback from that ?
15:13:00 <teuf> danken1: I don't think your email answered my questions, or I did not understand what you meant if they did
15:13:05 * quaid looking at wiki pages, no questions here ...
15:13:22 <oschreib> rharper: in the last meeting we agreed on 29th of FEB as the last day for release criteria discussions.
15:13:27 <oschreib> but it might take a bit longer
15:13:38 <teuf> danken1: ie what behaviour do you expect from libvirt when listen_tls=0 but some tls ports/channels are set (ie error or silently ignore them)
15:13:47 <rharper> oschreib: ok
15:13:52 <oschreib> rharper: since it's a second release, and the bar for the first one was really low, we want to get the bar higher.
15:14:16 <oschreib> and make the project more mature, as there are so much patches getting in these days
15:14:29 <teuf> danken1: and would it be fine with you if libvirt errored out in this case instead of prentending things went well (even if the spawned qemu is not usable through spice)
15:14:46 <rharper> oschreib: indeed, the criteria seems sparse; I wonder given the patch activity, we might need to have the component owners update the wiki with planned features/fixes as well
15:15:09 <oschreib> that's post feature freeze
15:15:19 <oschreib> the release criteria is not a PRD
15:15:36 <oschreib> and generally, we don't handle features, just product quality
15:15:53 <oschreib> rharper: but sure, we must make the criteria clear, and deep enough.
15:16:18 <mburns> oschreib: with the exception of critical features that are must haves for a new release
15:16:30 <mburns> those belong in the release criteria
15:16:57 <ovirtbot> 14[[07Second Release14]]4 !10 02http://www.ovirt.org/w/index.php?diff=2500&oldid=2493&rcid=2576 5* 03Oschreib 5* (+18) 10/* Release Criteria */ 
15:17:07 <oschreib> mburns: sure
15:17:49 <oschreib> so guys, feel free to add suggestions to the release criteria.
15:18:14 <oschreib> good one might be: MUST: No data corruption in common flows.
15:18:52 <ovirtbot> 14[[07Second Release14]]4 !10 02http://www.ovirt.org/w/index.php?diff=2501&oldid=2500&rcid=2577 5* 03Oschreib 5* (-2) 10/* Timeline */ 
15:19:01 <ykaul> but uncommon flows (error flows) it's OK to have data corruption?
15:19:11 <oschreib> ykaul: nothing is OK
15:19:42 <ykaul> so lets not have an exception for error flows, for example. No data corruption.
15:19:45 <oschreib> but you cant add "MUST: 100% no data corruption" or "MUST: Unbreakable product"
15:20:24 <ykaul> A data corruption is a blocker bug and we should not release with a blocker bug, right?
15:20:34 <oschreib> ykaul: if both vdsm and engine component maintainers will agree to that (and commit that they will fix every bug until 31/05) so it's fine by me
15:20:38 <mburns> oschreib: could simply add "MUST:  no known data corruptors"
15:20:55 <ykaul> (unless waived in the go/no-go for some reason).
15:21:07 <oschreib> fine by me. again, the commitment from the maintainers is important.
15:22:07 <oschreib> ykaul: we must distinguish between a common corruption, and a super-rare one.  don't think we should delay the release if we discover an extremely rare corruption, when Nogah and Mars align.
15:22:25 <oschreib> but that not up to me to decide.
15:22:47 * mburns votes that data corruptors be automatic blockers
15:23:09 <mburns> but we can waive in go/no-go if it's one of those "only on a leap day" issues
15:23:26 <oschreib> mburns: sounds good. feel free to update the wiki.
15:25:16 <oschreib> anything more on that topic?
15:25:25 <ykaul> oschreib: security issues.
15:25:47 <oschreib> ykaul: what about them?
15:25:48 <ykaul> oschreib: again, need to define their severity, etc. but they are blockers, unless waived in a go/go (or somehow have a workaround, etc.)
15:26:05 <oschreib> ykaul: +1
15:26:31 <mburns> security issues should be sent through the security mailing lists
15:26:35 <mburns> and triaged there
15:26:52 <oschreib> lets say "No high severity security issues", that's general enough.
15:26:55 <mburns> though the security experts should probably be able to stop a release
15:27:18 <mburns> so maybe +1 from security people is a requirement...
15:28:06 * mburns wonders if we should have a defined contact person for security issues...
15:28:47 <sgordon> djorm
15:29:33 <quaid> scurity ACK makes sense :)
15:30:30 <quaid> ok, anything more on this topic?
15:30:34 <ykaul> "works on at least one Linux distribution and at least one ovirt-node flavor" (so we don't end up releasing without ovirt-node support, at least on one distribution).
15:31:34 <oschreib> a bit obvious (to me), but reasonable.
15:31:45 <oschreib> please add it there guys.
15:32:12 <mburns> #action mburns to add node related release criteria to wiki
15:32:15 <quaid> yeah, obvious criteria helps in case you aren't available sometime :)
15:32:34 <ykaul> "can define NFS, iSCSI, FC and local based storage domains"
15:33:22 <ykaul> "can define VLAN based networks, bond interfaces, and have VLANs over bonded interfaces".
15:33:39 <ykaul> "can authenticate users against at least one external LDAP server"
15:33:59 <mburns> maybe we should add the requirements to the page and look for acks next week?
15:34:07 <oschreib> mburns: +1
15:34:14 <oschreib> ykaul: +3
15:34:30 <mburns> we just need component maintainers to add criteria
15:34:41 <oschreib> I'll handle them.
15:35:21 <acathrow> is there a basic test plan that we can get executed  - even it it's to run through the basic install wiki.
15:35:21 <acathrow> Eg. in the current release you have to work around things like iptables etc.
15:36:26 <oschreib> acathrow: if we will have one, who will execute it?
15:36:31 <oschreib> we have the test day
15:36:39 <oschreib> last time, we covered multiple issues.
15:36:46 <acathrow> if we can't get one person per distro to sign up to do that then we have a bigger problem
15:37:55 <oschreib> I think the test day is the right platform.
15:38:05 <oschreib> but maybe someone can create a more formal test plan.
15:39:42 <ykaul> we can have some basic flow automated as well, mainly via REST/SDK, etc.
15:40:46 <ykaul> we've had quite good plan in the test day - http://www.ovirt.org/wiki/Testing/OvirtTestDay#Execution_Plan_and_Guidelines
15:40:58 <mburns> jenkins will help with some automation as well if we commit to actually using it
15:41:15 <ykaul> mburns: using = fixing regressions found by it?
15:41:51 <mburns> ykaul: using = developing tests there, building all the components there, analyzing/fixing issues found there
15:42:45 <mburns> on last check, only the engine stuff was there
15:43:01 <mburns> node is partially there, but waiting for a new resource
15:43:29 <mburns> no vdsm there though...
15:44:23 <ykaul> anyone from vdsm here?
15:44:36 <mburns> danken1:
15:44:51 <danken1> mburns: ?
15:44:53 <danken1> ykaul: ?
15:45:21 <mburns> danken1: any plans to start using jenkins for vdsm builds/automated testing?
15:45:37 <danken1> mburns: I believe there is
15:45:51 <danken1> eedri has discussed this with iheim
15:46:17 <danken1> I would very much like to see a nightly build of rpms
15:46:37 <mburns> danken1: +1 on nightly builds
15:46:58 <danken1> installation, and running a few REST-driven tests
15:48:06 <ykaul> http://ovirt.org/wiki/Testing/PythonApi for example is a good start.
15:48:37 <danken1> I've seen eedri leaving the office
15:48:56 <danken1> but yes, I'm all for it
15:49:01 * quaid does another "are we done with this topic?" check
15:49:13 * mburns done...
15:49:19 <quaid> looks like it :)
15:49:22 <oschreib> +1
15:49:27 * quaid changing topic in 10 seconds
15:49:40 <quaid> #topic Beijing workshop update
15:50:29 <quaid> just double checking but ...
15:50:49 <quaid> we're at 41 attendees
15:51:07 <quaid> the cap is going to be ~115
15:51:45 <quaid> jbrooks sent out a test presentation to see about ease of translation
15:52:21 <quaid> oh, right, uh, bot ...
15:52:30 <quaid> #info 41 attendees out of ~115
15:52:59 <quaid> #info Presentation translation is in progress
15:54:02 <quaid> #info Open workshop agenda being worked via arch@ovirt.org
15:54:27 <quaid> #link http://lists.ovirt.org/pipermail/arch/2012-February/000227.html
15:54:56 <quaid> #info Venue details still being worked out, announcements about that will go to workshop mail list
15:55:16 <quaid> that's it
15:55:28 <quaid> any comments, questions about the workshop?
15:55:42 * quaid changing topic in 15 seconds
15:56:03 <quaid> #topic Other business
15:56:13 <quaid> anybody with anything else?
15:56:34 * quaid will keep this open for a few minutes, then close the meeting
15:57:30 <quaid> ok then
15:57:41 <quaid> thanks for the meeting everyone, see you later
15:57:50 <quaid> #endmeeting