14:02:29 #startmeeting oVirt Node Weekly Meeting 14:02:29 Meeting started Tue May 21 14:02:29 2013 UTC. The chair is mburns. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:29 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:02:36 * fabiand is here 14:02:36 #topic agenda 14:02:43 #chair fabiand rbarry jbelka 14:02:43 Current chairs: fabiand jbelka mburns rbarry 14:02:48 #chair jboggs 14:02:48 Current chairs: fabiand jbelka jboggs mburns rbarry 14:02:51 sorry jbelka 14:03:00 #unchair jbelka 14:03:00 Current chairs: fabiand jboggs mburns rbarry 14:04:42 #info 3.0.0 updates/plans 14:04:49 #info future plans/features 14:04:54 any other topics? 14:06:25 I'm fine .. 14:06:43 for the release 14:06:53 #topic Node 3.0.0 release 14:06:54 RC spined no Friday 14:07:09 there are already some patches for compat fixes with py2.6 (centos and friends) 14:07:19 and some fixes addressing functional bugs .. 14:07:29 thanks for testing mburns alonbl and others 14:07:35 #info RC spun on Friday (2013-05-17) 14:07:56 #info new patches fixing compatibility with distros using python 2.6 (EL6 and derivatives) 14:08:15 systemd updated fixed the issue we were seeing 14:08:27 I'd traget a respin for later this week 14:08:29 Thursday? 14:08:35 fabiand: sounds good 14:08:47 I hope to find and fix another couple of bugs 14:08:55 systemd update fixed some issues in the beta build 14:09:13 #info targeting new build for Thursday (2013-05-23) 14:09:32 yes, more ... 14:09:40 mburns, you did an initial release of the vdsm plugin .. 14:09:43 #info systemd update fixed some issues in the beta build 14:10:02 #info ovirt-node-plugin-vdsm initial build posted as well 14:10:15 #info some issues with registration due to bugs in the engine_page logic 14:10:44 #info vdsm plugin is part of the oVirt release, so not under pressure to get fixed for node 3.0.0 GA 14:11:50 fabiand: have you done anything on F19? 14:12:08 mburns, yes, I did initial testing with f19 and found a cuple of bugs ... 14:12:09 we'll likely have to have a 3.0.x release for F19 support 14:12:15 oh didn't post them yet - the patches .. 14:12:18 though i hope not 14:12:51 and .. yes, it still does not work 14:13:06 ok 14:13:12 I'll keep on working on it and wil push my patches to gerrit so you can track the progress 14:13:18 thanks 14:13:26 #info f19 needs some additional patches posted 14:13:45 #info may need update release for 3.0.0 to add F19 support 14:14:37 fabiand: we should see if we can get the puppet plugin merged into 3.0.0... 14:14:44 it's not merged yet, afaict 14:14:52 mburns, yep 14:14:58 first, thanks rbarry for the patch .. 14:15:01 even if we say it's a Preview 14:15:02 mburns: Not yet. I'm posting another patchset today to address fabiand's comments 14:15:09 there were a couple of glitches wich I'd like to see fixed before it can land .. 14:15:15 yep 14:15:29 just think we should get it into the RC2 build 14:15:37 okay 14:16:26 fabiand: hey -- one thing that i keep forgetting to mention that we might want to consider 14:16:36 the ovirt.debug.log is located in /tmp currently 14:16:41 and it's not logrotated 14:16:47 mburns, yes, yes ... 14:16:55 we should move that to /var/log and logrotate it 14:17:17 mburns, yes ... on the short term, on the longterm I'd like to see it "fixed" with 908902 14:17:23 .bug 908902 14:17:23 fabiand: Error: "bug" is not a valid command. 14:17:27 .help 14:17:27 fabiand: (help [] []) -- This command gives a useful description of what does. is only necessary if the command is in more than one plugin. 14:17:34 mh 14:18:16 fabiand: sure 14:18:32 fabiand: i think logging might be the next place to do an overhaul... 14:18:40 yep, definetly 14:18:55 overhaul -- a keyword for the next topic .. 14:18:59 yep 14:19:22 fabiand: i'd like to see the debug log move into var/log and be logrotated before we GA 3.0.0 14:19:31 mburns, yes 14:19:34 I'll take care of it 14:19:41 but the overhaul of logging can be later 14:19:49 fabiand: thanks! 14:20:01 ok, anything else for the 3.0.0 release? 14:20:32 jboggs: any thoughts on the edit-node manifest issues? 14:20:38 or re-organizing... 14:20:39 still working on it 14:20:46 ok 14:20:58 something that can land in 3.0.0? 14:20:59 have some of the work completed just need to finish restructuring 14:21:06 should be able to 14:21:08 jboggs: terrific 14:21:33 fabiand: for background -- we hit some issues with edit-node creating manifest files with names that are too long 14:21:46 mburns, ack .. 14:22:00 so we're moving to a hierarchy 14:22:09 okay .. 14:22:12 or directory structure for the manifests 14:22:13 that means? 14:22:25 basically, each run of edit-node will create a directory 14:22:36 and the manifest diffs will go in there 14:22:43 as well as the overall manifests 14:22:48 okay 14:23:09 and symlinks will be maintained to the latest complete manifests in the root 14:24:12 okay 14:24:26 #info ovirt.debug.log will move to /var/log and be rotated (due for 3.0.0 RC) 14:24:39 #info puppet plugin will be included in 3.0.0 RC2 14:24:56 #info cleanup of edit node manifests and manifest diffs will be in 3.0.0 RC2 14:25:12 ok, moving on to some future work 14:25:28 #topic future plans/features 14:25:48 some of this will be just a recap of some earlier conversations, but feel free to chime in with comments/thoughts 14:26:08 #info engine has a feature to create the management network itself 14:26:51 #info this has an implicit requirement that the device being used is not a bridge device since engine supports bridgeless networks 14:27:04 #info this requirement currently cannot be met by ovirt-node 14:27:15 #info plan is to investigate for 3.1 14:27:41 would that imply a 1:1 ratio of vm to nic or what? 14:27:44 #info initial design: make a configuration option that can be set by a plugin to create/not create the bridge 14:28:01 jboggs: it could just imply that the management network is just a management network 14:28:08 and vms run on other nics 14:28:11 ah ok 14:28:39 #info default configuration would be to create the bridge 14:28:49 #info need to check for where we make assumption of a bridged network 14:29:21 #info also need to add a configuration for locking out the network management locally 14:29:39 #info so that the vdsm plugin can lock it without having to depend on finding a bridge named ovirtmgmt 14:30:21 #info use case for bridgeless management network -- a system with multiple nics where vms only run on the non-management nic 14:30:38 any thoughts/comments/concerns on this? 14:30:48 background discussion is all the arch@ovirt.org list 14:30:59 s/is all/is on 14:31:12 #info background discussion is on the arch@ovirt.org list 14:31:31 ok 14:31:52 #info Networking 14:32:15 #info somewhat related to the previous, but we may want to re-design some of the networking setup 14:32:38 #info this is somewhat to make it more modular 14:32:57 #info there is hesitation to making these changes until the NetworkManager bridge support is in 14:33:07 #info (currently supposed to land in F19) 14:33:44 #info something to consider doing if it can be done in such a way that we can simply replace calls with calls to NM api 14:34:06 #info otherwise, i'd rather wait for this support to land in Fedora 14:34:28 #info also -- unknown if EL will get this support or not 14:34:42 thoughts/comments? 14:34:54 mh 14:35:00 no 14:35:06 I just hope that it's going to land .. 14:35:10 me too... 14:35:38 #info Installation flow 14:35:48 #info need to rework some of the installation flow 14:36:19 #info make it more modular so that new things can be easily plugged in 14:36:27 e.g. iscsi .. 14:36:31 e.g. different flows 14:36:33 e.g. plugins .. 14:36:37 yep 14:36:42 was thinking puppet as well 14:37:04 true 14:37:05 #info things like plugins, iscsi, different flows, puppet, etc 14:37:26 #info also need to make the backend more modular and debuggable 14:38:18 any other thoughts/comments 14:38:51 I think that the work on this doesn't depend on anything external 14:39:09 And I'd say that this work can at least start without breaking existing stuff 14:39:28 It would be about moodularizing and isolating existing code blocks .. 14:39:37 * papabur bows intently 14:40:09 fabiand: agreed 14:40:10 ack on that 14:40:27 #info this can probably start now and focus on modularizing and isolating 14:40:36 ok, last thing from me 14:40:41 #info Logging 14:40:54 #info need to get logging cleaner and easier to read 14:41:11 #info make sure that everything we want logged gets logged 14:41:26 make it so that we can change logging level for additional debugging 14:41:29 #info make it so that we can change logging level for additional debugging 14:41:42 * fabiand 'd say this is partially covered by the point above and ... the network item and - which we didn't mention yet, some work on the storage part .. 14:41:59 #info make all components log correctly (and distinctly) 14:42:23 fabiand: yes, but i would like to see some generic improvements 14:42:55 some of things we get in the log aren't all that useful and could be dropped to a lower level of logging 14:43:01 maybe INFO or something 14:43:11 and we log Warn by default 14:43:13 ah okay, yes 14:43:29 also, would be good to get things that we end up needed if certain areas fail 14:43:31 Possibly related, but libvirtd.log is full of spurious iptables/NAT messages and debug messages. It would be nice to pull out messages worth reading somewhere else, or disable all the debug logging in libvirt. 14:44:30 for example -- if an upgrade fails, would be good to perhaps get the state of various things (blkid, labels, etc) 14:44:42 it may be that we need to add a sos plugin or something 14:45:05 rbarry: can you follow up on that? work with the libvirt guys or vdsm guys to see why we're getting them? 14:45:22 mburns: Sure. 14:45:23 rbarry: mkletzan is here to help with stuff like that 14:45:59 rbarry: but some of the logging is also controlled through vdsm, so maybe dougsland (or he can re-direct if it's not him) 14:47:11 #info also, would be good to get things that we end up needing if certain areas fail 14:47:16 #info for example -- if an upgrade fails, would be good to perhaps get the state of various things (blkid, labels, etc) 14:47:23 #info it may be that we need to add a sos plugin or something 14:47:40 #info some libvirt logging seems spurious at the moment -- rbarry to work with libvirt/vdsm people to debug 14:47:49 #info storage config 14:48:02 mburns, I need to leave ... But I'll check the minutes and reply on the ml if I got thoughts to any upcoming discussion .. 14:48:09 #info we may want to investigate the work being done by the anaconda team with blivet 14:48:12 fabiand: ok 14:48:51 mburns, definetly look into blivet 14:49:08 mburns, and definetly look if we can reuse anacondas work for bootloaders ... (which is not part of blivet) 14:49:46 #info perhaps some of the anaconda work for bootloaders as well 14:50:21 #info also some generic modularizing and isolating of the various functions 14:50:21 * fabiand looks at syslinux support landing in fedora .. 14:50:57 ok, anything else? 14:51:49 ok, then let's close this and discuss anything else on email 14:51:52 #endmeeting