14:03:17 <fabiand> #startmeeting oVirt Node Weekly Meeting
14:03:17 <ovirtbot> Meeting started Tue Jan  6 14:03:17 2015 UTC.  The chair is fabiand. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:17 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:03:22 <fabiand> #chairs rbarry tlitovsk dougsland
14:03:52 * rbarry here
14:03:59 <fabiand> #topic Agenda
14:04:02 <fabiand> morning rbarry
14:04:05 * tlitovsk here
14:04:11 <fabiand> #info oVirt 3.5
14:04:15 <rbarry> Morning fabiand
14:04:17 <fabiand> #info Other Items
14:04:23 <fabiand> #undo
14:04:23 <ovirtbot> Removing item from minutes: INFO by fabiand at 14:04:17 : Other Items
14:04:32 <fabiand> #info Next-Gen Node
14:04:43 <fabiand> #info Jenkins
14:04:45 <fabiand> #info Other Items
14:05:06 <fabiand> #topic oVirt 3.5
14:05:14 <fabiand> So.
14:05:16 <fabiand> Still no release.
14:05:21 <fabiand> But a lot of movement in the last weeks.
14:05:34 <fabiand> #info Finally understood and solved the multipath problems
14:05:43 <fabiand> #info Patches to address core multipath problems are merged
14:05:51 <fabiand> #info Patches to address special CCISS handling are also merrged
14:06:13 <fabiand> #info device-mapper-multipath update for el6 is pending (outside of our scope)
14:06:19 <fabiand> #info el7 should be working nicely
14:06:53 <fabiand> #info Remaining partprobe and kpartx calls were removed, should address remainging formating/partition/installation errors
14:07:37 <fabiand> #info Bottom line: All necessary patches merged, waiting for el6 package update
14:07:49 <fabiand> Anything from your side, dougsland, tlitovsk, rbarry on this?
14:08:00 <rbarry> Not here
14:08:03 <tlitovsk> nope
14:08:54 <fabiand> cool
14:08:56 <fabiand> moving on
14:09:02 <fabiand> #topic Next-Gen Node
14:10:04 <fabiand> Next-Gen Node …
14:10:15 <fabiand> I sadly was occupied by the ongoing 3.5 work ..
14:11:00 <fabiand> So did not make any further progress on it.
14:11:00 <fabiand> Well, one thought - I wonder where to draw the line between persistence and configuration management ..
14:12:36 <fabiand> rbarry, anything else you could proceed with?
14:12:40 <rbarry> While configuration management systems are idempotent, the rest of the system isn't
14:13:15 <rbarry> So we can rely on puppet (or salt, or whatever) applying the correct changes every time, but restarting services could be nasty if we just wait for the management system to do it all
14:13:40 <fabiand> Yes, I agree on that.
14:13:44 <rbarry> Plus, running masterless with local definitions means we'll need at least some persistence, since we can't rely on an external classifier and master to do it for us
14:14:51 <rbarry> I guess I'd rather not persist anything without having an associated puppet manifest to do it, even if that manifest doesn't do anything other than persist it
14:15:22 <rbarry> But it would be nice to do everything in one place in next-gen, and not have to hunt through the codebase for persistence calls in multiple places
14:15:43 <fabiand> Yes.
14:15:55 <fabiand> It hink currently persistence is affecting reboots and updates
14:16:01 <fabiand> In next-gen node it will only affect updates
14:16:11 <fabiand> (because the persistence between reboots is given by the writable filesystem).
14:16:27 <fabiand> And then I wondered if upgrading is basically not something like, new OS + new rollout ..
14:16:58 <fabiand> And I wondered if the generic stuff could be covered by cfg mgmt - or said differently - would fall under the umbrella of cfg mgmt
14:17:16 <fabiand> and only the "instance" specific bits need to be covered by "persistence" in our sense
14:17:27 <fabiand> But those were justs ome thouhgts ..
14:17:47 <fabiand> And I'd like to contiinue to discuss them :)
14:18:27 <rbarry> I would think we could just persist the hiera/pillar tree and apply the manifests on the upgraded system
14:18:39 <fabiand> Yes.
14:18:42 <fabiand> Something along those lines.
14:18:57 <fabiand> But there are some one-off's
14:19:09 <fabiand> like vdsm, which does a lot of stuff in the %post scriptlet's of rpms ..
14:19:23 <fabiand> And I wonder if we need to take care of such logic
14:19:31 <fabiand> Well, first I need to really investigate what it is doing ..
14:19:59 <fabiand> Well ... We need to get our hands onto it!
14:20:02 <fabiand> Try different approaches!
14:20:15 <fabiand> And for that we need to free our plate, and get 3.5 out of the door!
14:20:17 <fabiand> :)
14:20:31 <fabiand> Btw, I dumped a couple of thoughts in http://dummdida.tumblr.com/post/104188427385/monolithic-os-delivery-is-popular
14:20:31 <fabiand> and
14:20:41 <fabiand> http://dummdida.tumblr.com/post/104188116490/ways-to-persist-a-reminder
14:20:48 <rbarry> This is something I did in the past for something else entirely, but with a writable filesystem, we could probably ship the image without the vdsm RPMs (and dependencies) installed, and keep a local repo with yumdownloader which we use to install vdsm after install
14:20:50 <fabiand> and a comparison in
14:20:50 <fabiand> http://dummdida.tumblr.com/post/104188041405/node-atomic-upgrades-image-based-delivery-and
14:21:04 <rbarry> But that's moving it back to a sort-of plugin model
14:21:08 <rbarry> If we're worried about %post
14:21:37 <fabiand> Yes ..
14:21:45 <fabiand> I also thought about such a model ..
14:21:55 <fabiand> bare image - and all payloads as plugins ..
14:22:04 <fabiand> This would actually ... fit with what we've got with host-deploy
14:22:23 <fabiand> Which could handle Node like a plain host - when it comes to installation, only updates will be different
14:23:08 <fabiand> But then we loose the tight coupling between OS and payload.
14:23:21 <fabiand> And that would be a to big loss - probably.
14:23:37 <fabiand> So, I'd keep shipping all the necessary bits, just adjust configuration during deployment/configuration
14:25:52 <fabiand> Okay
14:25:57 <fabiand> Thanks for this quick discussion :)
14:26:26 <fabiand> rbarry, any more thoughts on this topic for now - anything to next-gen node...?
14:27:29 <rbarry> Nothing for now. Hopefully in a couple of weeks
14:28:16 <fabiand> Yeah!
14:28:27 <fabiand> One thing I noted is that the jenkins jobs for next gen node fail ..
14:28:39 <fabiand> #info Just general thoughts on next-gen node
14:28:42 <fabiand> #info No code movement
14:28:48 <fabiand> so let's continue
14:28:51 <fabiand> #topic Jenkins
14:28:58 <fabiand> tlitovsk, anything new on the automation front?
14:29:05 * fabiand reviewed a couple of edit-node patches today
14:29:19 <tlitovsk> fabiand, we currently working on the local server
14:29:38 <fabiand> #info tlitovsk working on Node automation locally
14:29:47 <fabiand> tlitovsk, any progress when it comes to oVirt Jenkins?
14:30:06 <tlitovsk> fabiand, waiting for dcaro to come bACK
14:30:17 <fabiand> right
14:30:43 <fabiand> #info Needing support from infra to progress on public instance
14:30:44 <tlitovsk> tlitovsk, but hopefully for his return will be able to put some registration testing on upstream server after barrak fixes the mess I did.
14:30:48 <tlitovsk> :-)
14:30:54 <fabiand> Nice, very nice!
14:31:00 <fabiand> We'll benefit a lot from it!
14:31:36 <fabiand> #info Work on getting automatic registration testing is in progress
14:31:39 <fabiand> Nice
14:31:46 <fabiand> Anything else from your side, tlitovsk ?
14:32:23 <tlitovsk> nope. besides that libvirt in fc21 makes it very laggy
14:32:44 <fabiand> Any reason for that?
14:33:43 <tlitovsk> fabiand, no idea but i suspect some graphic card problems since it slows down the gnome - shell and not individual software
14:33:56 <fabiand> mh okay
14:34:30 <fabiand> #info Next-gen Node jobs currently broken, needs also infra help
14:34:33 <fabiand> Okay, moving on
14:34:37 <fabiand> #info Otehr Items
14:34:40 <fabiand> #undo
14:34:40 <ovirtbot> Removing item from minutes: INFO by fabiand at 14:34:37 : Otehr Items
14:34:42 <fabiand> #info Other Items
14:34:54 <fabiand> dougsland, rbarry tlitovsk - Anything you want to bring up?
14:35:20 <rbarry> Nothing from me
14:35:26 <fabiand> Any response from the IaaS room?
14:36:42 <dougsland> fabiand, not really
14:37:50 <fabiand> :-/
14:37:54 <fabiand> Let's see if we get a reply ..
14:38:03 <fabiand> So if there is nothing else, then thanks everybody
14:38:07 <fabiand> Going once …
14:38:59 <fabiand> Twice …
14:39:54 <fabiand> And a third time.
14:39:57 <fabiand> Happy new year!
14:39:59 <fabiand> #endmeeting