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