13:02:27 <fabiand> #startmeeting oVirt Node Weekly Meeting
13:02:27 <ovirtbot> Meeting started Tue May 27 13:02:27 2014 UTC.  The chair is fabiand. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:27 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:02:34 <fabiand> #chairs jboggs rbarry
13:02:40 <fabiand> #topic Agenda
13:02:42 * jboggs here
13:02:51 <fabiand> #info Build Status (3.0.5)
13:02:54 <fabiand> Good morning jboggs
13:02:57 <dougsland> fabiand, after meeting please ping me, so we can continue.
13:03:03 <fabiand> #info Feature Status for oVirt 3.5
13:03:09 <fabiand> dougsland, yep
13:03:14 <fabiand> #info Other Items
13:03:25 <fabiand> #topic Build Status (3.0.5)
13:03:36 * bkp here
13:03:45 * rbarry her
13:03:52 <fabiand> #chairs bkp
13:04:00 <fabiand> hey bkp and rbarry
13:04:17 <fabiand> #info 3.0.5 has been build an tested. The iso is available here: http://plain.resources.ovirt.org/pub/ovirt-node-base-3.0/iso/el6/ovirt-node-base-iso-3.0.5-20140522.0.el6.iso
13:04:25 <fabiand> #info Release notes and email pending
13:04:37 <fabiand> #info 3.0.5 should be used for oVirt 3.5 Alpha 2
13:04:51 <fabiand> sbonazzo, can you tell when alpha2 will be built?
13:05:16 * doron mostly here
13:05:18 <sbonazzo> fabiand friday morning
13:05:21 <fabiand> #topic Feature Status for oVirt 3.5
13:05:31 <fabiand> sbonazzo, ah great, we can pick up the fresh ovirt-node-3.0.5 then ..
13:05:33 <fabiand> sbonazzo, thanks
13:05:38 <fabiand> hey doron!
13:05:44 <fabiand> So crowded here .. :)
13:05:53 <fabiand> Back to the feature status
13:06:04 <fabiand> rbarry, jboggs - Can you give an update on your features?
13:06:04 <sbonazzo> fabiand for reference, http://www.ovirt.org/OVirt_3.5_release-management
13:06:11 <fabiand> I believe both are under review ..
13:06:34 <jboggs> hosted-engine patch is under review, you had some comments on moving it to the vdsm plugin page, wanted more details if you had time
13:06:57 <doron> fabiand: not too crowded ;)
13:06:57 <rbarry> I'm adding documentation and usage to registration as we speak...
13:07:18 <fabiand> jboggs, yeah ...
13:07:24 <fabiand> I did not realize this initially.
13:07:33 <fabiand> But what do you think about moving it to ovirt-node-plugin-vdsm?
13:07:55 <fabiand> The reason I see is that HE stuff heavily depends on Engine stuff, which is currently only used by the ovirt-node-plugin-vdsm ..
13:08:09 <fabiand> Some bits of the patch should still go into node.
13:08:14 <fabiand> rbarry, great!
13:08:28 <jboggs> ah are you saying to just package it in the plugin-vdsm package?
13:08:36 <fabiand> jboggs, yep
13:08:41 <jboggs> or one page for both vdsm/hosted-engine?
13:08:41 <fabiand> or - rather make it a subpackage ..
13:08:46 <fabiand> no
13:08:50 <fabiand> I would keep it in two separate pages
13:08:55 <fabiand> but move the page source to the vdsm-plugin
13:09:03 <jboggs> ok got what you mean now
13:09:04 <danken> mskrivanek: fromani: do we have plans to start using libvirt's pci-bridge <controller>? it should allow 31 more pci devices in VMs.
13:09:18 <fabiand> Because if we do the building in Node, then we also need to take care of the correct repos etc, what we alreday do in the vdsm-plugin
13:09:19 <jboggs> I'll coordinate with dougsland
13:09:20 <rbarry> Personally, it seems we should either get another repo created if it's not too obnoxious for infra
13:09:23 <mskrivanek> danken: not that i know of
13:09:26 <fabiand> jboggs, thanks!
13:09:42 <fromani> danken: none I'm aware of
13:09:43 <mskrivanek> danken: do we need it with virtio-scsi? disks are the biggest hog
13:09:45 <fabiand> rbarry, what kind of repo would you like to see?
13:10:12 <danken> mskrivanek: if there's no need for it, then fine - let it rot.
13:10:27 <rbarry> Just one for hosted engine. Even though there's little point to having hosted engine without vdsm, it doesn't seem as if the code will intersect in any way
13:10:58 <fabiand> oh. you mean we should create a separate repo where we keep the HE-plugin code?
13:11:04 <doron> rbarry: I'd expect the installer to handle that
13:11:05 * fabiand thought about a yum repo  ...
13:11:08 <rbarry> So another repo (again, if it's not painful for infra to create one, I've never had to go through this process with gerrit involved) with a subpackage which depends on plugin-hosted-engine
13:11:28 <fabiand> rbarry, are you speaking about yum or git repos?
13:11:30 <rbarry> I should specify: another git repo
13:11:32 <fabiand> :)
13:11:34 <fabiand> ah okay :)
13:11:37 <fabiand> yes.
13:11:40 <fabiand> That is also up for discussion
13:11:50 <fabiand> I could also imagine that we make it a completely independent plugin ..
13:12:26 <doron> makes sense.
13:12:36 <fabiand> rbarry, what pros do you see in having a separate repo for HE, instead of having it as a subpackage of the vdsm plugin?
13:12:54 <mskrivanek> danken: well there are still isuees with virtio-scsi forcing people to use regular slots for disks...but i'm not sure how much trouble the bridge would be. maybe rather fix the virtio-scsi issues....and then we're all fine, we need ~6 slots altogether for everything but disks
13:13:11 <fabiand> Not that I am opposed to it
13:13:58 <rbarry> Keeps the existing plugin-vdsm jenkins jobs manageable, for one.
13:14:16 <rbarry> But principally, it seems counterintuitive for users to find the hosted engine plugin code nested inside another plugin
13:14:44 <rbarry> We either have plugins in-tree if they're direct additions to node, or out of tree of they're optional
13:15:07 <rbarry> I'm not sure that having it in tree of another plugin makes sense unless it's an addition to *that* plugin, logically
13:15:17 <fabiand> I see your point rbarry
13:15:23 <rbarry> So if the changes go on the vdsm page, this makes sense to me. If not, it doesn't, but just a suggestion
13:15:43 <fabiand> No, you are right rbarry.
13:15:54 * jboggs agrees as well
13:16:00 * fabiand is a bit "concerned" about the overhead we get when we create a new repo ..
13:16:16 <fabiand> I wonder if it would make sense to renane the ovirt-node-plugin-vdsm package to an ovirt-node-plugin-ovirt
13:16:17 <doron> fabiand: new repo is not a real issue.
13:16:17 * rbarry doesn't know what that overhead is ;)
13:16:23 <fabiand> ah no, that get's messy.
13:16:39 * fabiand also think's of the build
13:16:46 <doron> ?
13:16:51 <fabiand> but that should also be no real issue as we just add another pkg to it ..
13:17:03 <fabiand> doron, yes .. okay (wrt new repo)
13:17:11 <fabiand> Right
13:17:32 <fabiand> I also believe we should create a new repo - even if it's IMO a bit overhead.
13:17:39 <doron> rbarry: can you mail infra@ovirt.org asking for a repo for the new plugin?
13:17:47 <fabiand> The reason why I agree is that - as rbarry argues - it does not fit into the existing plougin
13:17:48 <fabiand> logically
13:17:52 <doron> I'll make sure it's handled properly.
13:18:23 <rbarry> doron: Sure
13:18:27 <doron> thanks.
13:18:29 <fabiand> jboggs, could you the submit the code against the new repo?
13:18:51 <jboggs> yes will do, need to make a few packaging changes first
13:18:56 <fabiand> #agreed ovirt-node-plugin-hosted-engine will reside in an extra repository, and be a standalone plugin
13:19:13 <fabiand> jboggs, yeah, we'll also need the boilerplate, maybe we can take the stuff from the ovirt-node-plugin-vdsm
13:19:44 <fabiand> #info HE plugin does not fit into the Node repo, because it heavily depends on ovirt rpms, which are currently not pulled into Node builds
13:20:05 <fabiand> #info HE plugin will be standalone and a new plugin, hosted on th eovirt infra
13:20:16 <fabiand> #action rbarry to take care of the repository creation
13:20:29 <fabiand> #action jboggs to move the patch to the new repo
13:20:33 <fabiand> Cool.
13:20:38 <doron> :)
13:20:48 * fabiand liked the discussion
13:20:56 <fabiand> So, let's continue
13:21:10 <fabiand> rbarry, so do you also want a separate repo for the genric registration stuff? ;)
13:21:21 * fabiand hope's it's not taken seriously
13:21:23 <fabiand> :)
13:21:33 <fabiand> rbarry, I'll review our code as soon as the documentation is available.
13:22:03 <fabiand> #info generic-registration review is pending
13:22:33 <fabiand> An update from my side
13:22:58 <fabiand> Finally I got a basic image that suites my requirements
13:23:10 <fabiand> Basically an F19 image, with a preinstalled ovirt-engine package
13:23:27 <fabiand> the initial-setup service is started on boot, so the user can set a root password, set the TZ and add another user
13:23:36 <doron> fabiand: where will it be hosted?
13:23:44 <fabiand> Also a small answer file is provided to ease the engine-setup
13:23:48 <rbarry> Maybe odd question: why 19?
13:23:59 <doron> 20 isn;t supported yet...
13:24:01 <fabiand> The image has currently no desktop environment installed - users may not want it on the engine
13:24:07 <doron> it brings in a new JBoss
13:24:07 <rbarry> With all the Wildfly stuff in 20, seems like EL6 may be a better bet
13:24:13 <fabiand> rbarry, as doron said, f20 ain't supported yet
13:24:31 <fabiand> And I choose F19 over el6, because F19 has existing "cloud images" which i derived the ks from, to make it easier to maintain
13:24:51 <fabiand> On the long run - after finding out the best practice I'm alll yours to also provide el6 images
13:25:03 <fabiand> doron, the hosting is not yet decided
13:25:16 <fabiand> doron, for this I could think that we point to nightly builds
13:25:21 <jboggs> I've got a hacked up ks for centos6 I used for hosted-engine testing but its not much really
13:25:28 <doron> fabian I think we have glance.ovirt.org for it....
13:25:37 <fabiand> Because it does not need special packaging, and there are only upstream components used - which should be tested an stable
13:26:11 <fabiand> #action fabiand to investigate where to host the oVirt Virtual Appliance Image
13:26:36 <fabiand> #info the oVirt Virutal Appliance Image is currently Fedora 19 based, because Fedora provides cloiud image templates and Engine is running on F19
13:26:46 <fabiand> doron, glance.ovirt.org is currently pointing to ... a white page
13:26:54 <fabiand> jboggs, right - I can take a look
13:27:01 <rbarry> I think it's only available over glance API
13:27:01 <doron> fabiand: let's check it offline
13:27:11 <doron> could be.
13:27:11 <fabiand> jboggs, What i tired here is to use as many existing stuff as possible. basically to let upstream maintain the basics ;)
13:27:14 <doron> or some port...
13:27:22 <fabiand> jboggs, that's why I derived the ks fomr the fedora cloud images.
13:27:34 <fabiand> Yeah
13:27:37 <fabiand> I will investigate that
13:27:41 <rbarry> http://glance.ovirt.org:9292/
13:27:41 <fabiand> One question is ..
13:27:48 <fabiand> The cloud images provide cloud-init
13:27:56 <fabiand> Is this alos needed in the virtual appliance?
13:28:04 <fabiand> or is cloud init only used by OS?
13:28:08 <fabiand> rbarry, nice
13:28:16 <rbarry> http://glance.ovirt.org:9292/v1/ lists the images
13:28:23 <doron> cool
13:28:34 <rbarry> cloud-init sets up some basic sudo stuff, grabs metadata, keys, etc
13:28:51 <rbarry> It's supported in engine, and if anyone wants this on openstack or whatever...
13:28:53 <fabiand> rbarry, but from what management instance?
13:28:58 <fabiand> Does it also work with Engine?
13:29:05 <fabiand> Okay, great
13:29:09 <rbarry> Yes. If they run the engine in engine
13:29:09 <fabiand> Then I would keep it.
13:29:30 <rbarry> It's mostly harmless unless we depend on avahi for anything
13:29:36 <fabiand> yeah
13:29:39 <doron> hmmm we need to think on local install as well.
13:29:40 <fabiand> the debugging output is a bit annoying
13:29:50 <fabiand> doron, It should nmot do harm on the local install
13:29:57 <rbarry> Though you'll probably want to test the interaction between cloud-init and initial-setup, since I have no idea at all how well those play together
13:30:08 <fabiand> yeah
13:30:11 <fabiand> That was also my thinking
13:30:20 <fabiand> for now initial-setup is run before cloud-init
13:30:49 <fabiand> Ah.
13:30:54 <doron> sorry guys I need to drop off. but defintetly needs some checking here.
13:30:57 <fabiand> In my last state I even removed the cloud-init stuff ..
13:31:03 <fabiand> doron, sure - and yes.
13:31:10 <rbarry> Thanks for coming, doron
13:31:17 <doron> rbarry: thank you ;)
13:31:27 <fabiand> +1
13:32:07 <fabiand> Right
13:32:11 <rbarry> I guess I'd keep cloud-init. If I were an end-user using an appliance, I'd expect cloud-init metadata to work, and it's heavily used for various monitoring bits (passing puppet manifests to install/configure zabbix agents on new hosts)
13:32:20 <fabiand> #info oVirt Virtual Appliance needs more fine tuning
13:32:56 <rbarry> I think it may also handle the root expansion, but I'm not sure. jboggs?
13:33:29 <jboggs> there are other packages that handle that
13:34:12 <fabiand> Yeah
13:34:16 <fabiand> It's a subpackage actually
13:34:28 <fabiand> well, a standalone package which looks like a subpackage
13:34:37 * jboggs drawing a blank on upstream names
13:34:41 <fabiand> #info cloud-init should probably be kept in the appliance
13:34:46 <fabiand> :)
13:34:55 <jboggs> cloud-utils-growpart dracut-modules-growroot are el6 ones
13:35:05 <zauberfisch> good day gents
13:35:55 <fabiand> okay ..
13:36:06 <fabiand> I'd like to move on
13:36:21 <fabiand> #info Other Items
13:36:30 <fabiand> Are there other items we need to discuss?
13:36:37 <rbarry> None here
13:37:14 <bkp> At some point I would like to schedule a Bluejeans call with all of you
13:37:32 <fabiand> That would be great bkp :)
13:37:32 <bkp> Maybe jump in on the next scheduled call?
13:37:57 <fabiand> Yep
13:38:20 <bkp> Just send an invite...
13:39:10 <fabiand> Yep, we'll do!
13:40:45 <fabiand> If there is nothing else
13:40:48 <fabiand> Going once ...
13:41:11 <fabiand> Twice ...
13:41:34 <fabiand> Thanks everybody!
13:41:36 <fabiand> #endmeeting