14:06:27 <fabiand> #startmeeting oVirt Node Weekly Meeting
14:06:27 <ovirtbot> Meeting started Tue Mar  4 14:06:27 2014 UTC.  The chair is fabiand. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:27 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:06:34 <fabiand> #chair jboggs rbarry
14:06:34 <ovirtbot> Current chairs: fabiand jboggs rbarry
14:06:37 <fabiand> #topic Agenda
14:06:41 * jboggs here
14:07:01 * rbarry here
14:07:05 <fabiand> #info Release status
14:07:12 <fabiand> #info Build status
14:07:15 <fabiand> # Other items
14:07:19 <fabiand> #info Other items
14:07:26 <fabiand> hey jboggs and rbarry
14:07:37 <fabiand> #topic Release status
14:07:59 <fabiand> We were quite good at reviewing, and as far as I can tell we are still quite stable on master
14:08:41 <fabiand> I did some RHEL 7 work, and the Fedora 20 builds benefit from this work
14:09:13 <fabiand> The main item which didn't get attention is the storage rewrite ..
14:09:19 <fabiand> That beeing said.
14:09:45 <fabiand> I'm slowly thinking about doing a new minor release (3.1) to deliver some new features
14:10:11 <fabiand> And definetly we should also look at the kimchi plugin - for the next minor release
14:10:20 <fabiand> #info New minor release comes into sight
14:10:45 <fabiand> Regarding our stable branch
14:11:00 <fabiand> #info node-3.0.4 is used for ovirt-3.3 and ovirt-3.4
14:11:11 <fabiand> Which is good, because 3.0.4 is stable ..
14:11:32 <fabiand> But there are also a couple of patches in the queue for 3.0.5
14:12:41 <fabiand> #info couple of patches in 3.0.5 (stable branch) queue
14:12:51 <fabiand> #topic Buidl status
14:12:54 <fabiand> #undo
14:12:54 <ovirtbot> Removing item from minutes: <MeetBot.items.Topic object at 0x8bfb9cc>
14:12:57 <fabiand> #topic Build status
14:13:37 <fabiand> In general we are orange (to bring some color into this) IMHO
14:14:00 <fabiand> Just today we saw an issue with some of our node jobs in Jenkins
14:14:36 <fabiand> Basically the problem was that due to the use of sudo, some caches resided in /root - that is a bug, because all files should stay in the workspace ..
14:15:15 <fabiand> We'll need to clean that up ..
14:15:26 <fabiand> Related to this is an action item from last week ..
14:15:43 <fabiand> rbarry, you wanted to look into creating/updating a job to created a ovirt-node for engine iso based on our stable isos
14:15:51 <fabiand> Any update on that?
14:16:14 <rbarry> All ready to go, with one caveat: the reorganization of /pub looks... wrong somehow
14:16:56 <rbarry> i.e. we only have an EL6 build (no Fedora build), and it has a filename which looks autobuilt: http://resources.ovirt.org/pub/ovirt-node-base-stable/iso/
14:17:50 <rbarry> I wanted to confirm a few things before turning the job on, but that should probably wait until after the meeting
14:17:51 <fabiand> rbarry, you mean because it is not jsust ovirt-node-iso-3.0.4.iso?
14:19:03 <rbarry> And because there's no Fedora build. I guess I was expecting to have one EL6 build and one Fedora (19, probably) build that the job would retrieve to build off. While it's really easy to work with this as well, I'm just curious whether we're going to end up with more than one EL6 image in that directory at any point, and whether we'll have Fedora images.
14:19:21 <rbarry> The actual names of the ISOs doesn't matter so much
14:20:21 <fabiand> rbarry, ah okay
14:20:41 <fabiand> let us split this
14:20:58 <fabiand> Basically, yes, I'd have pushed all isos we generate during 3.0 to that dir
14:21:27 <fabiand> Sometimes we need to erespin to pick something urgent up ..
14:21:34 <fabiand> Sometimes a new dir would land because we e.g. release 3.0.5
14:21:39 <fabiand> that build would also land in that dir
14:21:57 <fabiand> But I think we could split it up to have on dir per dist
14:21:59 <fabiand> so basically:
14:22:02 <fabiand> iso/el6
14:22:03 <fabiand> iso/f19
14:22:08 <fabiand> iso/f20 (if applicable)
14:22:25 <fabiand> and each dir would contain the builds for that branch (3.0) and dist
14:22:31 <fabiand> does that make more sense, rbarry ?
14:23:51 <rbarry> Sort of. Better to continue this discussion after the meeting, I think.
14:24:12 <fabiand> okay
14:24:15 <fabiand> agreed
14:24:21 <fabiand> rbarry, what job did you create/modify?
14:26:25 <rbarry> ovirt-node-plugin-vdsm-layered was created to build off the node-3.0 branch instead of master (at the recommendation of dougsland). ovirt-node-iso-edit-node-vdsm is sitting open in a browser tab...
14:27:26 <fabiand> what is difference between ovirt-node-plugin-vdsm-layered and ovirt-node-iso-edit-node-vdsm
14:28:32 <rbarry> ovirt-node-plugin-vdsm-layered autobuilds ovirt-node-plugin-vdsm.rpm from the node-3.0 branch (the previous job, ovirt-node-plugin-vdsm builds from master, which dougsland suggested we shouldn't use, since he commits to node-3.0), but the extant job potentially has consumeers, so I didn't modify it.
14:28:59 <rbarry> ovirt-node-iso-edit-node-vdsm is triggers on completion of ovirt-node-plugin-vdsm-layered, and plugs the new RPM into the ISO
14:29:56 <fabiand> #info ovirt-node-plugin-vdsm-layered autobuilds ovirt-node-plugin-vdsm.rpm from node-3.0 branch
14:30:18 <fabiand> #info ovirt-node-iso-edit-node-vdsm adds rpm from ovirt-node-plugin-vdsm-layered to ISO
14:30:23 <fabiand> okay, great, thanks rbarry
14:31:23 <fabiand> Okay
14:31:41 <fabiand> Yes, my update on my action item washandled implicitly - the hierarchy is not optimal, needs discussion
14:31:48 <fabiand> #topic Other items
14:31:55 <fabiand> Anything else, rbarry, jboggs ?
14:32:04 * jboggs has nothing
14:32:37 <rbarry> Nothing here, either
14:35:10 <fabiand> okay
14:35:11 <fabiand> thanks
14:35:13 <fabiand> #endmeeting