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