14:04:39 #startmeeting ovirt node weekly meeting 14:04:39 Meeting started Tue Mar 19 14:04:39 2013 UTC. The chair is mburns. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:04:39 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:04:43 #chair rbarry jboggs` fabiand 14:04:43 Current chairs: fabiand jboggs` mburns rbarry 14:04:47 #topic agenda 14:04:59 #info feature update 14:05:04 #info release timeline 14:05:08 #info other topics 14:05:15 #topic feature update 14:05:26 let's start with rbarry 14:05:33 any updates on your features? 14:06:09 Basically feature complete. Just need to work out registering to engine 14:06:37 rbarry: this is for puppet? 14:06:38 kernel cmdline, modularity, puppet providers work as expected, though 14:06:41 Yep 14:06:48 rbarry: ok 14:06:59 rbarry, have you got some got some code in the public somewhere? 14:07:18 probably a good idea to get the patches posted so we can start reviewing 14:07:19 fabiand: I'll get it up on Github or something today. There's not a repo created for it yet 14:07:36 rbarry: excellent, thanks 14:07:44 #info puppet is nearly feature complete 14:07:45 rbarry, cool 14:08:01 #info still need engine registration 14:08:31 #action rbarry to get code posted somewhere for review 14:08:40 ok, jboggs` 14:08:46 how is upgrade work going? 14:09:13 slowly coming along, almost done, just working on other items in parallel 14:10:03 #info upgrade coming along, slowed by other parallel work 14:10:15 jboggs`: any other feature stuff you're working on? 14:10:31 * mburns knows there is efi stuff going on, but that's more bug fix than anything... 14:10:36 efi testing in general 14:11:13 ok 14:11:24 fabiand: how about you? 14:11:30 mburns, I'm quite relaxed :) 14:11:46 mburns, the new tui and installer are working quite well ... 14:11:59 fabiand: just bug fixing and cleanup for the tui/installer? 14:12:18 mburns, they are merged and right now I'm doing bug triage and upcoming problems with the new ui stuff .. 14:12:22 yep, corret 14:12:38 #info tui and installer are merged, just bug fixing/cleanup items now 14:12:41 fabiand: great 14:12:48 fabiand: anything new in automation land? 14:13:15 mburns, well - I'd like to reduce the dependencies of igor a bit, so it's easier to use and setup 14:13:30 This shouldn't be to hard 14:13:40 It's about dropping the cobbler dep and using only libvirt 14:13:40 fabiand, get a chance to verify that edit-node bug is fixed? 14:13:51 jboggs`, yep sure! I'll do that right after the meeting .. 14:14:30 #info fabiand also working on reducing dependencies for igor (removing cobbler, using libvirt directly) 14:14:38 ok, my updates 14:14:54 #info mburns working through code base for openstack plugin 14:15:21 #info all vdsm related content removed from ovirt-node 14:15:37 #info vdsm-plugin codebase to be uploaded soon 14:15:51 #info no progress on swap improvements yet 14:16:15 14:16:17 mburns, could you explain what you mean with swap improvements? 14:16:21 any other updates people want to give 14:16:44 fabiand: many requests to make swap independent of HostVG disk 14:16:51 right 14:17:27 fabiand: so need to expose either AppVG or extract swap from HostVG 14:18:06 there are a couple other requests around swap, like being able to detect all swap partitions and activate them (optionally) 14:18:15 okay .. 14:18:26 haven't done any real design yet, but it's on my roadmap 14:18:34 swap files came to my mind when you said it should be independet of HostVG 14:18:51 fabiand: where do you put the swap files? 14:19:03 mburns, some remote storage ... 14:19:34 depending how Node is used 14:19:37 so need a way to specify that remote storage, size of swap files, etc... 14:19:57 it's probably not a ton of work, but it's not really insignificant 14:20:08 yep 14:20:08 just needs thought and design 14:20:22 ok, any other feature updates? 14:20:59 ok, moving on to release timeline 14:21:05 #topic Release timelines 14:21:11 fabiand: this is your topic 14:21:15 mburns, :) thanks 14:22:19 With the move to extract all the oVirt specific bits (VDSM) from Node we should consider also decoupling the release cycle of Node from the release cycle of the overall oVirt Project 14:22:46 That doesn't mean that we are completely ignoring it, but that we don't bind ourselfs to that cycle 14:22:53 #idea since vdsm is out of the base image, we should de-couple from the oVirt Release Cycle 14:23:13 #info don't ignore, but don't bind to that cycle 14:23:24 The motivation for this is to focus on our code and distro integration - and to provide a stable image 14:23:48 * mburns agrees 14:23:55 jboggs`: rbarry: thoughts? 14:24:04 im agreeing with that 14:24:12 The idea is that node stabilizes over a time, and by the time that we want to integrate the engine bits, we are already having a tested base ISO 14:24:30 And in addition there might come more consumers of Node 14:24:30 That sounds ideal 14:24:40 nice 14:24:57 so, important things to consider for the next release 14:25:08 should be *before* ovirt beta 14:25:25 good point :) 14:25:42 brb 14:27:32 One thing I want to note is that we got many testers of our Node image, because it was part of the ovirt beta 14:28:53 If we want to provide a stable image before the actual beta, we should really focus on automated testing to prevent regressions so we can still claim to be rock solid .. 14:29:57 The current testcases cover TUI and auto install, but they could be by far more fine grained ... 14:30:19 e.g. checking that all necessary binaries are available (sometimes some don't land in the image, b/c dependencies changed and a package is not pulled in ...) 14:30:57 fabiand, any example of that so far? 14:31:09 brctl is the latets example 14:31:22 there were others 14:31:27 sorry, phone call i had to take... 14:31:40 and mainly happen between major distro releases 14:32:30 fabiand: having the generic image does open us to additional testing from people like OpenStack and oVirt 14:32:42 mburns, I agree partially 14:32:51 The testing will only happen as soon as the other parties are using the image 14:32:52 but yes, we should concentrate on getting the automation increased/improved 14:33:18 My goal would be to have an already tested and stable image out of the door, which then use to feed our consumers ... 14:33:34 fabiand: agreed 14:33:34 that reduces the number of moving components .. so we can focus on the actual integration problems .. 14:33:55 and we'll probably have some initial growing pains with each project that distributes an ovirt-node image 14:34:07 yep 14:34:07 but i think longer term, we'll be better off 14:34:15 I agree 14:34:41 fabiand: fwiw, if we can identify the binaries that we *need*, then we should simply add them to the spec file 14:34:55 the problem is identifying them 14:35:09 mburns, can a binary use for Requires: ? 14:35:15 if they're in the spec file, then we can be relatively sure that they're included 14:35:15 … be used for … 14:35:17 fabiand: yes 14:35:20 oh nice 14:35:26 Requires: /usr/bin/hostname 14:35:31 for example 14:35:33 okay 14:35:34 ack 14:35:36 must be full path 14:36:10 fabiand: but yes, a more fine grained testing is a good idea 14:36:35 having a set of test cases that run on any installed image (or any image running stateless for that matter) that verify certain things is a good idea 14:36:45 yep 14:37:29 fabiand: before we can start asking people to write tests, though, we need documentation for how to write tests 14:37:33 is that up anywhere? 14:37:41 yep 14:37:52 there are docs in the ovit-node tests/igor repo .. 14:37:57 but they'll need an update 14:38:02 (bug is already open for that) 14:38:09 #info need better automated testing in igor 14:38:33 #info more fine grained approach, set of tests that verify certain content in the base image 14:38:58 fabiand: is there a quick wiki howto for creating a simple test? 14:39:07 mh no 14:39:22 But I can add a getting started w/ testing page ... 14:39:43 excellent, that would be great 14:39:54 #action fabiand to add a getting started with testing wiki page 14:40:41 fabiand: i think we should also have a list of features we want in a release that is determined early on 14:40:56 at least for post 2.7.0 14:41:27 yes 14:41:28 fabiand: pretty sure we have most of that stuff already informally defined for 2.7.0 14:41:45 Yes, but we should really summarize it 14:42:16 fabiand: so we should shoot for a mid-May release date for 2.7 14:42:44 yes that sounds good 14:43:05 I'd volunteer to setup the feature page 14:43:09 or 2.7.0 planning page 14:43:13 so target feature complete by around mid april 14:43:38 #action fabiand to create 2.7.0 planning page with feature summary 14:43:56 fabiand: i'm thinking we might want to consider bumping to 3.0.0... 14:44:03 yep 14:44:09 completely new UI, no more vdsm, etc... 14:44:17 those are major changes, imo 14:44:23 yep, I completely agree 14:45:39 #agreed next release will be 3.0, not 2.7 14:46:09 anything else for release timeframes? 14:46:14 or other topics? 14:46:35 I'd say it's good for now 14:46:40 im good 14:47:08 ok, then /me will close the meeting 14:47:11 #endmeeting