14:00:46 <mburns> #startmeeting ovirt-node weekly sync 14:00:46 <ovirtbot> Meeting started Thu Dec 1 14:00:46 2011 UTC. The chair is mburns. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:46 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:01:41 <mburns> #topic roll call 14:01:44 <mburns> ok, so who's here today for the ovirt-node call 14:01:47 * pmyers is in 14:02:16 <cctrieloff> here 14:02:51 <mburns> #info mburns pmyers jboggs cctrieloff 14:03:14 <mburns> #topic agenda 14:03:31 <ykaul> villep: selinux issues, perhaps? 14:03:34 <mburns> 1. release readyiness 14:03:44 <mburns> 2. stateless updates 14:03:47 <mburns> 3. plugin updates 14:03:54 <mburns> anyone else have other topics? 14:03:55 <pmyers> 4. review of last week's action items 14:04:20 <pmyers> 5. planning the next release to align with f17 and listing which features we're going to target for that release 14:04:49 <pmyers> mburns: let's start with release readiness and follow into AI review 14:04:58 <pmyers> and then follow your ordering from there 14:04:58 <mburns> pmyers: ack 14:05:14 <mburns> #topic release readiness 14:05:47 <mburns> #info current status: node can install and register, storage can be added, slight issue with creating a vm 14:06:06 <pmyers> mburns: ah so dougsland_ fixed the vdsm issue then? 14:06:07 <mburns> some of this is with patches that are not merged yet 14:06:21 <mburns> pmyers: that's my understanding 14:06:22 <pmyers> what is vdsm team's ETA on merging these patches? 14:06:30 <pmyers> abaron? ^^^ 14:06:50 <pmyers> and do the issues w/ creating a vm manifest on bare metal Fedora or only on the Fedora oVirt Node? 14:06:59 <pmyers> i.e. is it a general issue or oVirt Node specific issue 14:07:03 <mburns> #link https://bugzilla.redhat.com/show_bug.cgi?id=752464#c23 14:07:26 <mburns> pmyers: from reading comments on ^^, it's more a iso domain issue 14:07:31 <mburns> which is independent of rhev-h 14:07:33 <pmyers> ok 14:07:41 <mburns> dougsland_: is that still the case? ^^ 14:07:59 <dougsland_> pmyers, still need to improve some of the patches but I got it working 14:08:03 <dougsland_> mburns, yep 14:08:07 <pmyers> mburns: also there was the bug with the oVirt Engine UI not being able to approve a Node 14:08:14 <dougsland_> I cannot push a ISO to my ISO Domain 14:08:18 <pmyers> have we talked to someone on UI team to see if they can prioritize this? 14:08:20 <dougsland_> to install a virtual machine and test 14:08:21 <dougsland_> it 14:08:29 <mburns> pmyers: hmm, wasn't aware of that 14:08:40 <pmyers> dougsland_ listed it in his release blocker email 14:08:46 <mburns> #action mburns will talk to engine team to get approval option prioritized 14:08:51 <mburns> pmyers: oh right, i remember now 14:08:59 <mburns> it's only available through api 14:09:10 <pmyers> yep 14:09:14 <dougsland_> mburns, pardon? 14:09:15 * mburns is apparently a little slow this morning 14:09:22 <dougsland_> is it about the ISO stuff ? 14:09:35 <mburns> dougsland_: no, approval of an ovirt-node image in the engine 14:09:37 <pmyers> dougsland_: no we're talking about a different bug 14:09:42 <dougsland_> ah ok 14:09:48 <mburns> is only available with api, not webadmin 14:09:55 <mburns> pmyers: was there a bz for that? 14:10:04 <mburns> or just a known issue? 14:10:29 <mburns> #action dougsland_ get patches cleaned up and merged for vdsm 14:10:45 <mburns> #action mburns, jboggs review and push ovirt-node patches 14:11:04 <pmyers> #link http://www.ovirt.org/wiki/First_release 14:11:19 <pmyers> #link https://bugzilla.redhat.com/show_bug.cgi?id=755749 14:11:43 <pmyers> mburns: other bug that we need to fix on our end is this: 14:11:46 <pmyers> #link https://bugzilla.redhat.com/show_bug.cgi?id=756136 14:11:57 <pmyers> it's in POST, what's preventing us from doing a build and getting it finished? 14:12:09 <mburns> pmyers: just review and push 14:12:15 <mburns> which is on my list for today 14:12:36 <pmyers> k 14:12:45 <mburns> #action mburns to get ovirt-node and ovirt-node-tools builds posted to ovirt.org 14:13:02 <pmyers> ok so we have no ETA for oVirt Node working since we're blocked on a webadmin bug and a ISO creation bug 14:13:08 <mburns> #action mburns to update wiki with instructions for building iso using just -tools rpm 14:13:11 <pmyers> once we get ETAs on those two, we'll then have an ETA for the Node itself 14:13:19 <mburns> pmyers: correct 14:13:21 <pmyers> cctrieloff: ^^ 14:13:52 <mburns> #info no firm ETA for node image build due to webadmin and vdsm bugs still pending 14:14:14 <pmyers> mburns: as an aside, please update the First_release wiki page as we make progress here 14:14:19 <mburns> anything else on release readiness? 14:14:24 <pmyers> i.e. once that ovirt-node bug is fixed, indicate that 14:14:30 <mburns> #action mburns to update First_release page as appropriate 14:14:56 <mburns> ok, moving on unless someone has something else... 14:15:02 <dougsland_> pmyers, replied to that thread 14:15:16 <mburns> #topic action item review from last week 14:15:34 <mburns> #link http://ovirt.org/meetings/ovirt/2011/ovirt.2011-11-17-14.01.html 14:15:54 <mburns> jboggs: any updates for plugin design? 14:16:08 <jboggs> nothing yet other than what pmyers has posted to list 14:16:16 <pmyers> i updated the wiki page fwiw 14:16:21 <pmyers> maybe we should take a sec to take a look 14:16:24 <pmyers> and comment on it? 14:16:38 <mburns> pmyers: can we defer to plugin updates topic? 14:16:41 <pmyers> ack 14:16:54 <mburns> jboggs: how about stacks? 14:17:09 <jboggs> did get an update on that, will add to wiki page 14:17:29 <mburns> #action jboggs to update wiki page with stacks information 14:17:53 <mburns> my action items: 14:18:18 <mburns> #info hot-add plugin rfe: https://bugzilla.redhat.com/show_bug.cgi?id=754781 14:18:42 <mburns> #info TPM mode for stateless moved to future feature in wiki 14:19:02 <mburns> #info registration issue is making progress, but still open until we get patches pushed 14:19:04 <pmyers> mburns: probably you should make that bug dependent on the general bug for 3rd party plugin support 14:19:25 <mburns> #action mburns to make RFE bug dependent on 3rd party plugin support BZ 14:19:40 <mburns> pmyers: did you add uses cases for upgrades to the wiki? 14:19:43 <pmyers> yep 14:19:56 <mburns> #info wiki updated with upgrade use cases by pmyers 14:20:01 <pmyers> #link http://ovirt.org/wiki/Node_plugins 14:20:39 <mburns> #info plugin design still pending 14:21:06 <mburns> #info stacks info received from RHEL baseos team, to be added to the wiki 14:21:19 <mburns> ok, that's it for last weeks action items 14:21:23 <mburns> well, 2 weeks ago 14:21:36 <mburns> #topic stateless update 14:21:53 <mburns> #link http://ovirt.org/wiki/Node_Stateless 14:22:15 <mburns> i moved the TMP stuff to future features 14:22:30 <mburns> and moved some of the config server stuff around as well, but haven't made any other progress 14:23:11 <mburns> #info no progress other than moving some info to a "Future Feature" section on the wiki 14:23:28 <mburns> any other stateless comments? 14:23:54 <mburns> ok, moving on 14:24:02 <mburns> #topic plugins update 14:24:12 <mburns> #link http://ovirt.org/wiki/Node_plugins 14:24:47 * mburns pauses to allow people to review the page 14:26:37 <jboggs> i think its a good start, just need to figure out what the contents of the tarball should look like 14:27:36 <pmyers> mburns: did I send an email out with that link? 14:27:38 * pmyers forgets 14:27:45 <mburns> pmyers: which link? 14:27:47 <pmyers> we need to circulate the ideas wider than just this audience 14:27:55 <pmyers> the node plugins link after I made the updates 14:28:05 <mburns> pmyers: hmm, not sure 14:28:23 <pmyers> ah I did 14:28:28 <pmyers> [node-devel] Updated thoughts on 3rd party plugins for oVirt Node 14:28:31 <pmyers> on 11/22 14:28:40 <mburns> yes, i see that 14:28:46 <pmyers> I only sent to node-devel tho... I wonder if I should cross post that to arch@ 14:28:52 <pmyers> cctrieloff: is that a reasonable use for the arch list? 14:29:11 <mburns> i don't see anything in the list for adding autoinstallation parameters 14:29:23 <pmyers> mburns: add it then 14:29:28 <mburns> we already have some sort of support for that, but we'll need to document 14:29:53 <mburns> #action mburns to add info on auto-install parameters to the wiki 14:30:05 <mburns> pmyers: what's the point of the arch@ list? 14:30:17 <pmyers> I would suppose to discuss overall ovirt architecture 14:30:19 * mburns not clear on it's reason for existing... 14:30:27 <mburns> s/it's/its 14:30:33 <mburns> ok 14:30:34 <pmyers> and I would think that a high level topic like stateless and/or plugins would fall into that 14:30:41 <pmyers> since it does affect the entire ovirt ecosystem 14:30:42 <mburns> then yeah, arch@ probably would make sense there 14:30:44 <pmyers> and not just the node 14:30:51 <mburns> ack 14:31:21 <mburns> anyone want the action of sending our stateless and plugin architecture designs to arch@ for review? 14:31:43 <jboggs> mburns, sure 14:31:47 <pmyers> i'm doing it already 14:31:49 <pmyers> :) 14:32:07 <mburns> #action pmyers to send plugin and stateless designs to arch@ for review 14:32:26 <mburns> ok, anything else on plugins? 14:33:11 <mburns> #topic Next Release 14:33:24 <mburns> #info planning to coincide with F17 14:33:52 <pmyers> #info f17 feature freeze is Feb 7 2012 14:34:25 <pmyers> #info f17 beta freeze is Mar 20 2012 14:34:47 <mburns> #info https://bugzilla.redhat.com/show_bug.cgi?id=751856 is a must fix 14:34:54 <pmyers> we probably should aim to have the next version of oVirt Node ready with new features for the feature freeze date 14:35:10 <pmyers> and then focus between feature freeze and beta freeze on all of the changes that F17 will do to break the basic functionality 14:35:16 <pmyers> just like we do with _every_ new Fedora release 14:35:22 <mburns> pmyers: ack 14:35:35 <pmyers> ok so the question then is.... 14:35:37 <mburns> what new features can we realistically target for feature freeze 14:35:42 <pmyers> what features can we implement in Jan and early Feb 14:35:45 <pmyers> right 14:35:58 <mburns> and how do we want to approach it 14:36:09 <pmyers> i think we should prioritize the plugin model 14:36:17 <pmyers> and jboggs agreed to own that one right? 14:36:20 <jboggs> yes 14:36:23 <mburns> should we attack multiple things with 1 person each? 14:36:31 <mburns> or put multiple people toward one effort? 14:36:38 <pmyers> to be realistic 14:36:55 <pmyers> i think mburns you can focus on getting the f16 node ironed out and the release process squared away 14:37:03 <pmyers> and jboggs for now can focus on the plugin stuff 14:37:10 <mburns> ack 14:37:12 <pmyers> and we'll only bite of that one feature as the major one 14:37:17 <pmyers> everything else can be small/incremental 14:37:26 <pmyers> but let's review the outstanding fefature list 14:37:27 <pmyers> feature 14:37:51 <pmyers> #link https://fedorahosted.org/ovirt/wiki/Backlog 14:37:55 <mburns> jboggs: if you come up with a task list with things that are mostly independent, i can probably take a couple 14:37:59 <pmyers> speaking of which, when are we migrating the wiki pages? 14:38:39 <mburns> #agreed mburns will handle release coordination and F16 node stuff, jboggs will lead plugin effort 14:38:39 <pmyers> mburns: from the above link, look at the 2.2.0 feature list 14:38:42 <pmyers> there's just the one :) 14:38:50 <pmyers> "Fedora 16 based oVirt Node ISO image release" 14:39:22 <mburns> pmyers: how are you generating that? 14:39:26 <mburns> fixed-in-version? 14:39:34 <pmyers> yes 14:39:43 <pmyers> i'm using it to indicate what version it _will_ be fixed in 14:39:49 <mburns> pmyers: as for wiki, goc started migrating already, though not completed afaik 14:40:08 <pmyers> let's also look at http://goo.gl/IMG4p 14:40:14 <pmyers> the list of all outstanding features 14:40:14 <mburns> pmyers: can we use something like the whiteboards? 14:40:47 <mburns> or are those not visible to everyone? 14:40:52 <pmyers> a lot are not visible 14:40:55 <pmyers> FIV is 14:41:06 <pmyers> and we can diffeerntiate between Fixed vs. will be fixed by doing 14:41:12 <pmyers> 2.2.0 for will be fixed 14:41:20 <pmyers> and full NVR for 'already fixed and built" 14:41:25 <mburns> pmyers: ack 14:41:27 <mburns> that will work 14:41:42 <pmyers> normally you'd use the target drop down for this 14:41:55 <pmyers> but we can't populate that with ALL of the versions for every ovirt subproject 14:42:00 <pmyers> so this method will work 14:42:24 <pmyers> ok so let's review http://goo.gl/IMG4p and assign 2.3.0 FIV as appropriate 14:42:32 <pmyers> first bug in that list for me is 753315 14:42:34 <mburns> pmyers: once we get to a consistent ovirt version, we can populate with that and have mapping of ovirt version to node version 14:42:46 <pmyers> mburns: perhaps 14:42:59 <pmyers> but our release schedule will be likely faster than theirs and not always aligned 14:43:02 <pmyers> so we'll see 14:43:47 <mburns> #info use fixed in version field for target release and actual release. Target will be like 2.2.0 and actual will be full NVR 14:43:49 <mburns> pmyers: true 14:44:36 <mburns> hmm, iirc, we put the virt-manager-tui package in already, but don't have a way to run it 14:45:03 <mburns> pmyers: but imo, it's a nice to have, but probably not a requirement for 2.2.0 14:45:25 <pmyers> which bug are you looking at? 14:45:31 <jboggs> yeah v-m-tui works just not integrated in the ui 14:45:31 <mburns> 753213 14:45:42 <mburns> that was the first on the list when i opened your link 14:45:46 <pmyers> ah 14:45:49 <pmyers> ok different order 14:46:01 <pmyers> mburns: this seems fairly simple to get working then 14:46:07 <pmyers> perhaps smth you can do as a smaller feature for 2.3.0 14:46:29 <pmyers> we need to make sure that we provide a way to restrict to read-only socket for libvirt and read-only operations 14:46:32 <mburns> i'll tag for 2.3 14:46:33 <pmyers> once vdsm takes control of system 14:46:44 <pmyers> mburns: as an aside use 2.3.0 as the field 14:46:53 <pmyers> so we can possibly differentiate things like 2.3.1 etc 14:47:05 * mburns changes to 2.3.0 14:47:19 <mburns> 753214 14:47:27 <mburns> include matahari/libvirt-qmf 14:47:39 <pmyers> this should be fairly easy I think 14:47:41 <mburns> assuming this is just adding the packages, it can go for 2.2.0 14:47:56 <pmyers> with the same caveat that we want to make libvirt-qmf use read only if vdsm is in control 14:48:00 <pmyers> if there's not a way to do that presently 14:48:07 <pmyers> you'll need to work with zbitter from #matahari channel 14:48:13 <mburns> ack 14:48:29 * mburns flags for 2.2.0 and will defer if it gets too big 14:48:35 <pmyers> 2.3.0 you mean 14:48:43 <pmyers> 2.2.0 is the release for F16 that is imminent right? 14:49:01 <pmyers> or do you think you can add this quickly enough to make the F16 image that's about to go out the door? 14:49:02 <mburns> oh, right... 14:49:16 <mburns> i was thinking of 2.2 as the f17 release 14:49:20 <pmyers> ok 14:49:22 <pmyers> so 2.3 then 14:49:43 <mburns> ack 14:49:45 <pmyers> jboggs: https://bugzilla.redhat.com/show_bug.cgi?id=753303 is done right? 14:49:54 <pmyers> that should be pulled back to 2.2.0? 14:50:20 <pmyers> also 753309 goes hand in hand with the 3rd party plugins, so reassign to jbogss and move to 2.3.0 14:50:31 <jboggs> yes other than the encrypted swap part that needs to be pulled in but that a couple lines and its mostly done now 14:50:59 <pmyers> jboggs: ok get that done, that's now a blocker for 2.2.0 release 14:51:26 <pmyers> mburns: 753215 should be doable along with the matahari stuff 14:51:47 <jboggs> will do 14:52:07 <mburns> pmyers: ack 14:52:53 <mburns> 753296 is needinfo, but i'm not sure who we need info from 14:52:56 <mburns> FIPS mode 14:53:05 <pmyers> not critical for 2.3.0 14:53:20 <mburns> i'll put it for 2.3.0 and defer if necessary 14:53:26 <pmyers> put it for 2.4.0 14:53:32 <pmyers> i don't even want to distract us with it for now :) 14:53:38 <mburns> ok, 2.4.0 it is 14:53:48 <pmyers> 753304 should be trivial 14:54:03 <mburns> 2.3.0 14:54:03 <pmyers> 753306 is nebulous and therefore we're not doing it yet 14:54:16 <pmyers> 753313 is not important 14:54:20 <pmyers> ah wait nevermind 14:54:24 <pmyers> that one _is_ important 14:54:54 <mburns> 2.3.0 for 753313 and 2.4.0 for 753306 14:55:52 <pmyers> what about 753298? 14:55:54 <mburns> 753298 i think has some strong interest from some groups, so i'll flag for 2.3 and push back to get them to work on it 14:55:58 <pmyers> jboggs were you working on that? 14:56:13 <pmyers> right 14:56:13 <mburns> no, that was aliguori and his guys 14:56:16 <pmyers> ok 14:56:16 <jboggs> havent touched it yet 14:56:24 <pmyers> we should get aliguori and his team to do the work here 14:56:35 <pmyers> so assign to aliguori and see if they'll take it 14:56:58 <pmyers> 675988 and 753308 are dups 14:57:04 <pmyers> close one of them and target the other one for 2.4.0 14:57:06 <jboggs> need to be in python since we've switched 14:57:12 <pmyers> it's not important enough for 2.3.0 to spend time on it now 14:58:54 <pmyers> ok last one 753314 14:59:28 <mburns> i think 2.3 for that one 14:59:33 <mburns> with possible push to 2.4 14:59:34 <pmyers> ok 15:00:34 <mburns> #info bug planning for future feature bugs 15:00:46 <mburns> ok, anything else for this meeting? 15:00:51 <mburns> #topic open discussion 15:01:07 <pmyers> http://goo.gl/alPU4 15:01:19 <pmyers> 756136 needs 2.2.0 target 15:01:41 <pmyers> as does 758689 15:02:02 <aliguori> eh 15:02:06 * aliguori reads up 15:02:15 <pmyers> aliguori: i actually assigned to rmm not you :) 15:02:36 <aliguori> oh 15:02:37 * aliguori ignores 15:02:38 <aliguori> :-D 15:03:19 <pmyers> mburns: 750662 is 2.3 as well 15:03:20 <pmyers> for jboggs 15:03:54 <mburns> ack 15:04:07 <pmyers> https://bugzilla.redhat.com/show_bug.cgi?id=481611 is jboggs related to the 3rd party plugins 15:04:35 <mburns> pmyers: that one should just be a test to make sure size doesn't increase 15:04:45 <pmyers> ack 15:04:47 <mburns> but edit-livecd wasn't in livecd-tools 15:04:57 <jboggs> i fixed that years ago :) 15:05:04 <pmyers> then retest and close 15:05:07 <mburns> (bug filed already) 15:05:18 <mburns> jboggs: yeah, but that was in the bash version, wasn't it? 15:05:25 <mburns> and edit-livecd is python now? 15:05:44 <jboggs> is was the one huff wrote i think 15:06:01 <mburns> ok, well, test and close should be all it takes 15:06:19 <mburns> selinux policy subpkg i set for 2.3.0 (751830) 15:06:30 <pmyers> ok 15:06:35 <pmyers> so thought is that we have too much for 2.3.0 now 15:06:39 <pmyers> it's not likely to get done 15:06:46 <pmyers> but we do have the correct assignments 15:06:47 <pmyers> so 15:06:57 <pmyers> jboggs and mburns please both take some of these and push to 2.4.0 or beyond 15:07:11 <pmyers> so that we have a realistic set of things we can get done for 2.3.0 15:07:21 <mburns> pmyers: lets leave versions as they are for right now 15:07:25 <pmyers> k 15:07:29 <mburns> and i'll take a pass this week at priorities 15:07:34 <mburns> then we'll work from there 15:07:38 <pmyers> ok 15:07:59 <mburns> always pick off the high prio ones first and when we hit the deadline, we can push to the next version 15:08:04 <pmyers> ack 15:08:20 <mburns> pmyers: 749192 15:08:31 <mburns> i don't know that we need anything here, do we? 15:09:03 <mburns> if vdsm is going to use an ovirt user, shouldn't it be creating it? 15:09:23 <pmyers> yeah 15:09:33 <pmyers> i think so but talk to vdsm team to make sure 15:09:34 <mburns> ok, i'll close 15:09:40 <pmyers> well maybe move to vdsm 15:09:41 <pmyers> vs close 15:09:55 <mburns> i'll ping abaron first then and see what he thinks 15:10:01 <pmyers> k 15:10:43 <mburns> ok, anything else for this meeting? 15:11:12 <mburns> going once.... 15:11:20 <mburns> twice.... 15:11:25 <mburns> gone.... 15:11:36 <mburns> thanks everyone! 15:11:39 <mburns> #endmeeting