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