14:06:16 <fabiand> #startmeeting oVirt Node Weekly Meeting
14:06:16 <ovirtbot> Meeting started Tue Dec  2 14:06:16 2014 UTC.  The chair is fabiand. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:16 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:06:23 <fabiand> #chairs rbarry tlitovsk dougsland
14:06:42 <fabiand> #topic Agenda
14:06:42 * rbarry here
14:07:20 <dougsland> here
14:07:53 <fabiand> #info oVirt 3.5
14:08:23 <fabiand> #topic oVirt 3.5
14:09:56 <fabiand> #topic Other Items
14:11:26 <fabiand> #topic oVirt 3.5
14:11:35 <fabiand> So here we go
14:12:32 <fabiand> Hey dougsland and rbarry
14:12:35 <fabiand> tlitovsk, around?
14:12:41 <tlitovsk> fabiand, Hi
14:12:50 <fabiand> tlitovsk, hey
14:13:51 <fabiand> #info Latest Node scratch build is the one from two weeks ago
14:14:04 * fabiand invites rbarry and dougsland to https://appear.in/themess
14:14:15 <fabiand> But  I'll continue to cover it textual
14:14:16 <fabiand> ly
14:14:37 <fabiand> #link https://fedorapeople.org/~fabiand/node/3.5/ovirt-node-iso-3.5.0.ovirt35.20141114.0.el6.iso
14:14:53 <fabiand> #info Some stabilizing patches got merged
14:15:06 <fabiand> #info Most work focused on the hosted-engine feature
14:15:31 <fabiand> #undo
14:15:31 <ovirtbot> Removing item from minutes: INFO by fabiand at 14:15:06 : Most work focused on the hosted-engine feature
14:15:48 <fabiand> #info Most work focused on the hosted-engine feature
14:16:07 <fabiand> rbarry, dougsland tlitovsk actually did a sprint on HE last week IIRC
14:16:16 <fabiand> dougsland, rbarry tlitovsk -- can you give a brief status update on the HE feature?
14:16:24 <fabiand> or - the state of HE in  Node?
14:17:11 <dougsland> fabiand, The TUI for HE is working nice, I have merged all last patches from Ryan and give a test.
14:17:42 <fabiand> dougsland, that sounds great!
14:17:46 <dougsland> fabiand, however, let's keep in mind that if hosted-engine has issues it will affect us.
14:17:53 <rbarry> HE itself works, and PXE booting to install the engine should work once the latest patches are merged
14:18:01 <fabiand> dougsland, right
14:18:02 <dougsland> fabiand, all issues we found, we reported.
14:18:12 <fabiand> rbarry, great
14:18:31 <rbarry> We're just missing fields for hosted-engine --deploy to join an existing HA HE
14:18:36 <fabiand> #info many HE related patches got reviewed and merged during the last few days
14:18:48 <fabiand> #info Basic HE features seems to work fine
14:19:03 <fabiand> #info Joining an existing HA HE is not yet supported
14:19:08 <fabiand> rbarry, right
14:19:18 <fabiand> rbarry, we can see if we push that to 3.5.1 or 3.5.2
14:19:34 <fabiand> But in general nice
14:19:44 <fabiand> So, after this testing, I think we can come up with a refreshed ISO
14:19:59 <dougsland> fabiand, the repo master and 3.5 are updated in HE plugin.
14:20:10 <fabiand> So thanks for that HE update. Great to see that we also make some progress here.
14:20:15 <fabiand> dougsland, nice
14:20:37 <dougsland> fabiand, I think we can improve the TUI for HE for next 3.5.1 but probably we need some bugs on the parts that we want to improve.
14:20:38 <fabiand> dougsland, once the HE plugin is in shape we should do real builds and get ifnra to include them in ther 3.5.? repos ..
14:20:42 <fabiand> We can probabyl target 3.5.1
14:21:06 <fabiand> #info Targetting 3.5.1 to include ovirt-node. ovirt-node-plugins-vdsm and ovirt-node-plugin-he rpms
14:21:33 <fabiand> dougsland, do you recally if we need an update for the vdsm plugin?
14:21:59 <fabiand> Seems like there are no pending pacthes, which is nice
14:22:28 <fabiand> #info ovirt-node-pluginvdsm is looking good
14:22:35 <fabiand> #undo
14:22:35 <ovirtbot> Removing item from minutes: INFO by fabiand at 14:22:28 : ovirt-node-pluginvdsm is looking good
14:22:36 <dougsland> fabiand, I would update it.
14:22:42 <fabiand> #info ovirt-node-plugin-vdsm is looking good
14:22:49 <fabiand> dougsland, update which package?
14:23:09 <dougsland> fabiand, the vdsm one
14:23:20 <fabiand> right
14:23:26 <fabiand> so doing a new plugin-vdsm build?
14:23:35 <dougsland> fabiand,   yes, just to cover el7 autoinstall
14:23:43 <fabiand> ah yeah, you are right!
14:24:11 <fabiand> #info vdsm-plugin also needs an update to address an el7 issue
14:24:15 <fabiand> Okay. Nice!
14:24:26 <fabiand> After weeks we talk abotu Node specific bugs, not platform bugs, that is not bad :)
14:24:44 <fabiand> okay, moving on
14:24:49 <fabiand> #topic Other Items
14:26:03 <fabiand> #info Jenkins
14:26:16 <fabiand> tlitovsk, did you have sucess in reaching out to the infra team?
14:27:07 <tlitovsk> I had some more update to the jenkins jobs , they are now set up and now I need t oadd the actual build step.
14:27:26 <fabiand> Cool!
14:27:47 <fabiand> tlitovsk, do you have a link to the jenkins jobs?
14:28:16 <tlitovsk> fabiand, they are on our local server here
14:28:22 <fabiand> tlitovsk, ah right
14:28:36 <tlitovsk> fabiand, as soon as they run at least something I will start migrating it upstream
14:28:42 <fabiand> tlitovsk, once you have success there, it might be worth to update the jobs on jenkins.ovirt.org as well
14:28:44 <tlitovsk> fabiand, with dcaro help
14:28:49 <fabiand> tlitovsk, cool
14:28:51 <fabiand> sounds like a good plan
14:29:27 <fabiand> #info tlitovsk working on jenkins automation
14:29:46 <fabiand> #info working on local builders, once working, pushing those changes to upstream
14:30:58 <fabiand> Okay
14:30:59 <fabiand> moving on
14:31:06 <fabiand> #info Next-Gen Node
14:31:12 <fabiand> so, next-gen node ..
14:31:37 <fabiand> tlitovsk, rbarry dougsland -- http://blog.mecheye.net/2014/11/why-package-managers-are-not-my-ideal-software-distribution-mechanism/
14:31:48 <fabiand> A nice read. Also about deploying an OS in an image fashion
14:32:01 <fabiand> They (endless.m) are also using ostree
14:32:11 <fabiand> But: They've got pre-defined hardware as far as I can tell.
14:32:20 <fabiand> So no need to add customer driver disks or alike
14:32:46 <rbarry> Very pre-defined hardware, but still interesting
14:33:28 <fabiand> Yeah, rbarry
14:33:31 <rbarry> Jasper has demo code for that system as well
14:33:51 <fabiand> rbarry, have you got a link to that demo?
14:34:45 <rbarry> I'll ask him for it. We mostly end up talking over a forum and he mentioned it in passing
14:35:10 <fabiand> rbarry, great! Would be very interesting to take a look at it
14:35:30 <fabiand> btw, I actually met him last year at FOSDEm
14:35:31 <fabiand> :)
14:36:02 <fabiand> So there are currently ostree, and the systemd idea around, which are very similar to what we try to achieve with next-gen node.
14:36:09 <fabiand> Actaully those two ideas are close to what Node is :)
14:36:15 <fabiand> We just want to improve with next-gen node
14:36:46 <fabiand> In the next few months I'd like to see what efatures we need to prepare our existing codebase for next-gen node.
14:36:57 <fabiand> dougsland, we spoke about splitting the TUI frmo the installer.
14:37:02 <fabiand> I think we could make this a feature for 3.6
14:37:34 <fabiand> rbarry, the puppet backend for configuration. I think we need to investigate it a bit more, and I thin kwe can also make it a standalone package, so we can develop it in parallel, without dropping our current code
14:37:54 <rbarry> We can definitely make it a standalone package
14:37:54 <dougsland> fabiand, indeed, would be nice.
14:38:17 <rbarry> I'd like to see if we can break ovirt-node-config into a separate package, which should be easy, since config.defaults doesn't have any utility functions
14:38:28 <fabiand> rbarry, yeah
14:38:46 <fabiand> Another thing I'd like to revisit, is how we can improve our tui to make some things easier
14:38:55 <fabiand> and another thing is also the generic registration
14:39:34 <fabiand> generic registration, tlitovsk, is basically a mechanism, where we signal Engine that we-are-here and ask Engine to start the registration process with ourselfs
14:40:19 <fabiand> these three things are at least something we can start in 3.6 - maybe we can break them down into smaller features.
14:40:44 <fabiand> The TUI subpackage/split can be a feature
14:40:47 <fabiand> it should not be to big
14:41:05 <fabiand> the puppet backend is also quite isolated, but I am not sure if we should pull it in 3.6 as a feature
14:41:23 <fabiand> the generic registration is also quite isolated and we should get it into 3.6. It's worth it ..
14:41:30 <fabiand> vdsm_reg is just borken.
14:41:33 <fabiand> borked.
14:41:53 <rbarry> 50/50. It'd be nice to start working on it, but hopefully we'll have time for that anyway. There's almost no way to make a puppet backend work in a sane manner on the current R/O Node, though
14:42:06 <fabiand> rbarry, yes
14:42:46 <fabiand> we can at least 3.6 for investigating the puppet direction
14:42:56 <fabiand> or - come up with something else which we can use for centralized management
14:43:01 <fabiand> AND our tui
14:43:30 <fabiand> Some other things on our plate, for hosted engine i.e.
14:43:39 <fabiand> To integrate it better with the engine-appliance
14:43:55 <fabiand> but this needs to go hand  in hand with the hostedengine people
14:43:57 <tlitovsk> fabiand, I have small proposal regarding edit-node .
14:43:58 * fabiand is looking at sbonazzo
14:44:03 <fabiand> tlitovsk, cool!
14:44:04 <fabiand> shoot!
14:44:08 * fabiand notes some things
14:44:15 <fabiand> #info Start thinking about next-gen node and 3.6
14:44:23 <rbarry> I wonder about using etcd or another self-configuring hierarchical model for centralized management
14:44:26 <fabiand> #info generic registration is a potential feature for 3.6
14:44:32 <sbonazzo> fabiand: we're here to help :-)
14:44:37 <tlitovsk> I think we should start move more things on node configuration into edit-node .
14:44:37 <fabiand> #info Using puppet for configuration changes should get investigated
14:44:49 <fabiand> #info Seperating the insatller from the TUI (packaging) is something for 3.6
14:45:00 <tlitovsk> For example move all of the node startup config params into the edit node ,
14:45:15 <rbarry> If we could feed keys into it which got picked up by a background service and passed into config.defaults, it may be easier. Then one configured node could also pass it to another (since syslog config/etc) may be similar, and the size change should be very small. Just an idea, though
14:45:17 <fabiand> rbarry, as far as I can tell etcd seems to be quite low level- but I haven't looked at it in depth yet
14:45:20 * fabiand notes it to himself
14:45:42 <fabiand> tlitovsk, you mean, you would use edit node, to set specific start parameters?
14:45:46 <fabiand> tlitovsk, or what is your idea?
14:45:47 <rbarry> Etcd is pretty low-level, yeah. We'd need some code around it to do anything useful, but not much.
14:46:39 <tlitovsk> Yes. I think we should allow the users preconfigure all the install process using edit node . and left with pnp iso no question asked.
14:47:03 <tlitovsk> configure , plug the iso in , reboot image up and running.
14:47:51 <fabiand> tlitovsk, I see your point
14:48:00 <fabiand> rbarry, right
14:48:04 <tlitovsk> and we can remove the install QA from the node
14:48:15 <fabiand> rbarry, I think etcd might be just another frontend to the configuration bits (eitehr defaults or puppet)
14:48:17 <fabiand> basically:
14:48:30 <fabiand> real-cfgs -- defaults-or-puppet -- trigger (foreman or etcd)
14:49:03 <rbarry> Hiera has an etcd backend, which definitely helps. Just that defaults would need a way to pull it out
14:49:07 <fabiand> So: I see etcd, basically as a source for high-level infos (even if it's a lo-level tool), the puppet module the transforms those high-level infos into a actual state
14:49:16 <fabiand> foreman is just yet another source of oinformation for the puppet classes
14:49:45 <fabiand> rbarry, I see - this is something we need to investiagte tfo 3.6 - probably also look what other tools in that management area use ..
14:49:56 <fabiand> VBut I think you already did part sof this investigation IIRC
14:49:59 <rbarry> That's the idea with the puppet backend, and we wouldn't have to write anything to use it with hiera. But as an intermediate step in 3.6, we could look at adopting it if we're interested in "swarm" configuration (I know tlitovsk also is)
14:50:23 <fabiand> rbarry, agreed
14:50:26 <fabiand> :)
14:50:50 <fabiand> Basically I'd like to find a framework which provides methods to transform high-level directives into specific configuration files.
14:51:03 <fabiand> Puppet is one example for such a  framework, ansible and chef are others
14:51:09 <fabiand> tlitovsk, edit-node ..
14:51:22 <fabiand> #info Possibly re-visit other cfg mgmt systems like ansible and chef
14:51:24 <fabiand> tlitovsk, so
14:51:37 <fabiand> tlitovsk, I actually never thought about that idea
14:51:41 <fabiand> But i see your point
14:51:52 <fabiand> What I'd actually like to see is that we alos rework our boot code.
14:52:15 <fabiand> basically rethink how we configure services etc
14:52:24 <fabiand> Here we can leverage the features which systemd bring's us ..
14:52:31 <fabiand> Yes, systemd also has good sides.
14:52:38 <fabiand> #info systemd has good sides.
14:52:53 <tlitovsk> fabiand, I can pool a graph of current service and take look what we have now.
14:53:10 <fabiand> tlitovsk, I believe the idea with "baking" a specific configuration into a node is also going into the direction which we try to into with the puppet changes
14:53:24 <fabiand> tlitovsk, yes. I think that is just one step
14:53:48 <fabiand> tlitovsk, what you caould do is take a look at ovirt-early and ovirt-firstboot, they include a lot of logic
14:54:04 <fabiand> And I would like to pull this a bit apart, to create seaparate easier to manage parts
14:54:16 <fabiand> So that one change will hopefully not affect the flow of a 3k lines script
14:54:47 <fabiand> i.e: The whole logic we have to transform kernel arguments into variables which are used by the installer
14:55:11 <fabiand> This can become a separate service: taking a set of kernel arguments / parsing the cmdline and destilling them into a kickstart (for next-gen node's anaconda)
14:55:59 <tlitovsk> or this can be prebuild by the edit-node.
14:56:46 <fabiand> :)
14:56:51 <fabiand> Or that way.
14:57:01 <fabiand> Independently where the configuration is written:
14:57:15 <fabiand> We need a logic which transforms high level directives into precise configuration steps
14:57:22 <fabiand> (our current defaults class is doing that)
14:57:54 <fabiand> tlitovsk, just one note. for next-gen node ... which will be probably not alwways be an iso, we might have a different tool than edit-node
14:58:17 <fabiand> tlitovsk, I'd try that we can reuse the existing (proven) tools which are out there: like the whol libguestfs family
14:58:48 <fabiand> #info tlitovsk has the idea of baking a configuration into an ISO
14:59:10 <tlitovsk> fabiand, sure but what I am trying to say is that we can try to move as much of possible decision and parsing out of the node
14:59:20 <fabiand> #info fabiand would liek to reuse existing tools for next-gen node modifications
14:59:29 <fabiand> tlitovsk, right
14:59:40 <fabiand> tlitovsk, we should talka about that, because I'd liek to keep it in there ;)
14:59:58 <fabiand> tlitovsk, mainly because we want to keep Node amnageable. But maybe I don't get your full idea
15:00:08 <tlitovsk> fabiand, ok :-)
15:00:29 <fabiand> #info tlitovsk and fabiand to speak about where to do decision making
15:00:48 <fabiand> Oh
15:01:18 <fabiand> One thing I want to note.
15:01:25 <fabiand> I''d like to split the iso from Node.
15:01:43 <fabiand> Meaning: Node is becoming basically a specific rootfs, the ISO is just one way to deliver it
15:03:01 <fabiand> #info fabiand would like to separate rootfs from delivery format (ISO)
15:03:19 <fabiand> Okay
15:03:20 <fabiand> Nice
15:03:26 <fabiand> I think we should stop here.
15:03:40 <fabiand> This meeting was probably as long as all the meetings of the last two months together.
15:03:47 * dougsland agree
15:03:49 <fabiand> So, anything else, dougsland rbarry tlitovsk ?
15:03:55 <dougsland> which is nice :)
15:03:59 <dougsland> fabiand, not from my side.
15:04:03 <rbarry> Nothing here
15:04:05 <fabiand> dougsland, :) hehe, thanks
15:04:07 <fabiand> rbarry, great
15:04:07 <tlitovsk> fabiand, me neither
15:04:09 <fabiand> tlitovsk, amazing!
15:04:14 <fabiand> We are all good then.
15:04:18 <fabiand> Thanks and have a nice day ahead
15:04:21 <fabiand> #endmeeting