14:01:46 <mburns> #startmeeting
14:01:46 <ovirtbot> Meeting started Thu Nov 17 14:01:46 2011 UTC.  The chair is mburns. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:46 <ovirtbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:02:20 <mburns> ok, so who's here for the node meeting?
14:02:27 <mestery> here
14:03:08 <jboggs> here
14:03:08 <mburns> going to be a quiet meeting...
14:03:12 <pmyers> here
14:03:25 <mburns> #info attendees: mburns mestery jboggs pmyers
14:03:41 <mburns> ok, quick agenda
14:03:51 <mburns> 1.  plugins design
14:03:55 <mburns> 2.  stateless design
14:04:02 <mburns> 3.  bug review
14:04:06 <mburns> any other topics?
14:04:15 <pmyers> 4. release schedule for sub-project and nomination of release manager
14:04:32 <mburns> ack
14:05:11 <mburns> 5.  questions and/or issues
14:05:24 <mburns> #topic Plugins
14:05:47 <mburns> #info http://ovirt.org/wiki/Node_plugins
14:05:56 <pmyers> has everyone read and is familiar with this page?
14:06:05 <pmyers> if not, take a sec to quickly read it :)
14:06:11 * mburns rereads to refresh memory
14:06:52 <pmyers> ok question
14:06:58 <pmyers> "Third party plugins need to be upgradable."
14:07:07 <pmyers> if the intent is to allow injection of plugins into an offline ISO
14:07:14 <pmyers> what does it mean for allowing plugins to be upgradeable?
14:07:35 <pmyers> and then follow up on that
14:07:37 <pmyers> "Third party plugins should be able to hot-add (e.g. not require reboot of the node)."
14:07:41 <mestery> pmyers: Per our discussion yesterday, if we want to focus on stateless, than upgradeable means simply creating a new PXE image with the new 3rd party plugin
14:07:47 <pmyers> ack
14:07:50 <mburns> stateful node installed with plugin v1
14:08:05 <mburns> then new image with plugin v2 should not break stateful node
14:08:07 <mestery> Is the plan to focus primarly on stateless?
14:08:08 <mburns> that's my understanding
14:08:12 <pmyers> mburns: ack, let'
14:08:25 <pmyers> let's make that clearer by outlining use stories for how this function will be used
14:08:32 <pmyers> for both stateful (to start with) and eventually stateless nodes
14:08:36 <mburns> any volunteers to update the wiki?
14:09:03 <pmyers> i'll see if I can make some things clearer
14:09:17 <pmyers> mestery: plan is to focus on getting to stateless
14:09:29 <pmyers> but right now we're not there, so initial plugin integration may be on stateful node
14:09:38 <mestery> pmyers: OK, understood.
14:09:39 <mburns> #action pmyers update wiki with use cases for how upgrades will work
14:09:40 <pmyers> however, we can treat the plugins themselves as nominally stateless
14:10:13 <mestery> Regarding hot-add: I was thinking adding a plugin to a running node should not require a reboot. Makes sense?
14:10:15 <pmyers> mestery: I think this will get us equivalent functionality with what ESXi provides, right?
14:10:39 <mestery> pmyers: Yes, this sounds very similar to ESXi.
14:10:57 <mburns> #info hot-add would give us equivalent to ESXi functionality
14:11:13 <pmyers> wait
14:11:23 <mburns> hot-add sounds like a v2 feature to me
14:11:29 <xTs_w> (hot-added modules needs to reside in the ram, right?)
14:11:30 <pmyers> i thought esxi only allowed adding oplugins to off line images
14:11:44 <pmyers> i'm not sure that we SHOULD allow RUNNING nodes to have plugins added
14:11:53 <mestery> No, you can add them to running images as well, although you have to put hte host in maintenance mode (no VMs running)
14:12:05 <pmyers> ok, that's something we may consider for the future
14:12:14 <mestery> Yes, sounds good.
14:12:20 <pmyers> but the technical challenges associated with dealing with a stateless and read only root environment
14:12:23 <pmyers> may make that challenging
14:12:38 <mestery> Does the node have the concept of a mode where no VMs can be run on it? (e.g. maintenance mode)?
14:12:40 <pmyers> are you sure it's ESXi and not plain ESX that allows this?
14:12:40 <mburns> ok, so move hot-add to future feature?
14:12:54 <mburns> mestery: not directly, but through the engine, yes
14:12:57 <pmyers> mestery: that's not defined by RHEVH itself, maint mode is defined by the mgmt system
14:13:01 <pmyers> i.e. oVirt Engine
14:13:12 <mestery> pmyers: Yes, ESXi allows this, as well as ESX.
14:13:20 <pmyers> however, we could easily include logic that says only allow plugin installation if no VMs are running
14:13:34 <pmyers> the host need not know about maint mode, it just needs to know whether or not VMs are running
14:13:43 <xTs_w> (two steps: overlayfs for the module for hotadding, and changed images for new nodes)
14:13:46 <mburns> #info probably need to *maintenance mode* the node before hot-add
14:14:20 <pmyers> the challenge is dealing with service start and dynamic firewall rule changes during runtime
14:14:31 <pmyers> this is particularly challenging on a livecd based image
14:14:43 <mburns> pmyers: it's doable though
14:14:51 <mestery> pmyers: Yes, we would need APIs for 3rd party plugins to alter those during load, and start themselves during load.
14:14:52 <pmyers> yes, w/ hacks probably
14:14:53 <mburns> and i have some ideas for how
14:14:57 <pmyers> ok
14:15:08 <mburns> pmyers: not hacks really
14:15:11 <pmyers> k
14:15:18 <mburns> but it goes into how we do dynamic firewalls and services
14:15:22 <pmyers> ok
14:15:57 <mburns> but i really think hot-add should be future feature, rather than trying to solve it in first pass
14:16:03 <mburns> agreed?
14:16:08 <pmyers> +1
14:16:15 <pmyers> we have a bz for 3rd party plugins
14:16:27 <pmyers> mburns: can you file new bug for separate rfe for hotplug
14:16:32 <pmyers> that way we'll keep these separate
14:16:41 <mburns> #agreed hot-add will be future feature
14:16:52 <mburns> #action mburns file rfe bz for hot-add
14:17:26 <mburns> is there anyone who want to volunteer for ownership of this feature?
14:17:42 <mburns> or at least to take first pass at designing?
14:17:53 <pmyers> heh, I would if I could go back to coding :(
14:18:02 <pmyers> managers--
14:18:19 <jboggs> mburns, might as well be me
14:18:25 <pmyers> jboggs++
14:18:25 <mburns> jboggs: excellent, thanks
14:18:37 <mburns> #action jboggs will come up with design for plugins
14:18:49 <pmyers> jboggs: basically continue adding to this wiki
14:18:59 <pmyers> w/ more concrete details and technical bits
14:19:04 <pmyers> and we can review on list
14:19:10 <mburns> ack
14:19:20 <pmyers> ok we should go to next topic
14:19:21 <mburns> any other plugin ideas?
14:19:26 <pmyers> lest meeting go for too long :)
14:19:26 <mburns> 3....
14:19:30 <mburns> 2....
14:19:33 <mburns> 1...
14:19:34 <mestery> One thing
14:19:40 <mburns> ooh, just under the wire
14:19:45 <mestery> Persistent storage (e.g. plugin configuration data)
14:19:48 <xTs_w> I've got a question, if I may
14:20:07 <mestery> I imagine some plugins will need that, and whether it comes down from the mgmt host, or resides on the host, it would be good to have that capability
14:20:17 <mestery> This would be for plugin configuration data
14:20:28 <mburns> mestery: for config, yes, i agree
14:20:36 <pmyers> mestery: plugins will need to be aware of and utilize the persist functionality that we provide
14:20:42 <pmyers> so that they can persist their own config files
14:20:43 <mburns> and that would be part of a stateless config bundle
14:20:52 <mburns> yeah, what pmyers said
14:20:55 <pmyers> right and that persist cmd would also add those config files to the bundle
14:20:57 <mestery> pmyers: mburns: Great! A way to store /etc files would be sufficient for the most part.
14:20:59 <pmyers> that would be sent to config server
14:21:03 <pmyers> no
14:21:06 <pmyers> not /etc
14:21:11 <pmyers> we need to not allow random edits to /etc
14:21:13 <mestery> The equivalent maybe?
14:21:14 <pmyers> it's too complicated
14:21:15 <pmyers> yes
14:21:19 <mestery> Yes, makes sense. cool
14:21:22 <pmyers> i.e. /opt/vendor/plugin/etc
14:21:26 <mestery> Perfect!
14:21:28 <pmyers> :)
14:21:35 <mburns> pmyers: we can allow (and may require) some stuff in /etc
14:21:37 <pmyers> the only changes that we'll make to /etc
14:21:40 <mburns> but that's implementation detail
14:21:42 <pmyers> will be through controlled metadata
14:21:43 <pmyers> like
14:21:45 <xTs_w> is there some field in the engine where you can see which version of the node is running on the host? If we're talking about plugins then it might be necessary to see somewhere which node build is running, so you know which node has to be restarted, to load the recent image
14:21:46 <pmyers> 1. services that need to start
14:21:51 <pmyers> 2. firewall ports opened
14:21:56 <pmyers> 3. users/groups need to be added
14:22:01 <pmyers> 4. selinux policy additions
14:22:11 <pmyers> xTs_w: good idea
14:22:16 <pmyers> we need a way to query the node
14:22:20 <pmyers> to get a list of installed plugins
14:22:21 <pmyers> and their versions
14:22:23 <pmyers> and state
14:22:27 <pmyers> xTs_w: that what you're after?
14:22:28 <mburns> xTs_w: i don't know about the engine webadmin right now
14:22:28 <pmyers> ?
14:22:39 <pmyers> mburns: we just need to provide the data for vdsm to gather
14:22:42 <mburns> but rhevm has an about box that has versions
14:22:44 <mestery> #agreed With pmyers design for plugin config data not in /etc, and APIs for things in /etc
14:22:49 <xTs_w> pmyers: sounds even better than my idea
14:22:53 <pmyers> :)
14:23:05 <pmyers> mburns: as long as we provide interface for vdsm to get at this data in a controlled way
14:23:16 <mburns> pmyers: ack
14:23:21 <pmyers> it's then oVirt Engin and vdsm team's responsibility for how they visualize to users
14:23:48 <pmyers> could be as simple as /etc/plugin-registry file
14:23:53 <pmyers> that lists all plugins, vendors, versions
14:24:01 <mburns> #info need to work with vdsm/engine teams to provide info on plugins, vendors, versions, etc
14:24:34 <mburns> #info need RFE on vdsm/engine to publish those details in the UI
14:24:40 <mburns> ok, let's move on
14:24:46 <mburns> #topic stateless
14:24:55 <mburns> #link http://ovirt.org/wiki/Node_Stateless
14:25:27 <pmyers> oh sorry one more thing
14:25:37 * mburns pauses
14:25:59 <pmyers> #info jboggs to check with RHEL baseos team on notion of 'stacks' since stacks will put things into /opt organized by vendor and we should probably consolidate around a single scheme for directory organization if we can
14:26:14 <mburns> ack
14:26:30 <mburns> #action jboggs to check with RHEL baseos team on notion of 'stacks' since stacks will put things into /opt organized by vendor and we should probably consolidate around a single scheme for directory organization if we can
14:26:43 <pmyers> jboggs: check with ddumas she'll have the right info/ppl to get details from
14:26:45 <mburns> ok, Stateless...
14:27:23 <mburns> any comments questions concerns with stateless?
14:27:27 <pmyers> definitely want to separate out TPM usage as a v2 add on to this feature
14:27:41 <pmyers> we can start with sneakernet delivered usb thumbdrives for the paranoid
14:27:53 <pmyers> the thumbdrive can contain the key or cert that we want to use
14:27:58 <mburns> #action mburns move TPM to v2
14:28:35 <pmyers> i think the first thing we need to investigate and decide is 'what does the protocol look like between server and client'
14:28:41 <mburns> pmyers: first should be key embedded in the image
14:28:49 <pmyers> mburns: that's for non paranoid case
14:28:51 <pmyers> but sure
14:28:56 <pmyers> so different levels
14:29:02 <pmyers> 1. no key, no encryptio
14:29:02 <mburns> and then we can expand functionality to allow for overriding
14:29:07 <pmyers> 2. key embedded in ISO
14:29:11 <pmyers> 3. key on thumbdrive
14:29:16 <pmyers> 4. key in TPM
14:29:23 <mburns> pmyers: strike #1 IMO
14:29:31 <mburns> we can build with a default key in the image
14:29:36 <mburns> that's hardcoded in src
14:29:38 <pmyers> that's worse than no key
14:29:46 <pmyers> never include pregenerated keys or passwords
14:29:49 <pmyers> it's a rule pretty much :)
14:29:57 <pmyers> it lures you into a false sense of security
14:30:04 <pmyers> better to be open and just not encrypt at all
14:30:05 <mburns> ok
14:30:14 * mestery agrees with pmyers on not embedding keys or passwords.
14:30:15 <mburns> simpler flow if there is a default key
14:30:27 <pmyers> yeah, but it's just a nono
14:30:28 <mburns> but not too much more complex without
14:30:31 <pmyers> yep
14:30:47 <pmyers> basically if no key, then assume bundle is not encrypted
14:30:54 <pmyers> and skip the decrypt step
14:30:54 <mburns> ok
14:31:10 <pmyers> so are we ok with
14:31:25 <pmyers> a bundle really just being an augeas script?
14:31:33 <pmyers> and then we get that augeas script and apply to the running node?
14:31:45 <pmyers> do we need things that can't be contained in an augeas script?
14:31:57 <pmyers> if so do we need to make the bundle a tarball that contains augeas scripts and 'something else' ?
14:32:04 <mburns> pmyers: not sure we can say that at the moment
14:32:11 <pmyers> ok smth to mull over then
14:32:22 <mburns> i think we should plan on augeas+something
14:32:29 <pmyers> ok
14:32:33 <pmyers> expandible
14:32:34 <pmyers> i like it
14:32:36 <mburns> but minimize the something
14:32:46 <pmyers> so initial would be tarball containing augeas script(s)
14:32:50 <mburns> for things that we can't do with augeas
14:32:51 <pmyers> the tarball is encrypted
14:33:13 <mburns> and file rfes on augeas to be able to do what we need
14:33:18 <pmyers> ack
14:33:34 <mburns> mestery: jboggs:  ack?
14:33:39 <jboggs> ack
14:33:40 <mestery> ack
14:33:52 <pmyers> ok transport/protocol
14:34:02 <mburns> #agreed encrypted tarball with primarily augeas scripts
14:34:18 <mburns> #agreed but support for "something more"
14:34:19 <pmyers> idea is that we define a protocol that other people can implement, but we create reference implmentation
14:34:29 <pmyers> that can be used for testing and small deployments
14:34:44 <jboggs> would matahari fit in here somehow still?
14:34:47 <pmyers> protocol should be very simple, basically get and put
14:34:53 <pmyers> jboggs: it could
14:35:08 <pmyers> that may make sense, we have other reasons for putting matahari on the node as well
14:35:33 <pmyers> but for people w/o broker setups
14:35:35 <pmyers> perhaps we need a fallback
14:35:42 <pmyers> that uses smth simple like a basic webserver
14:35:46 <mburns> #idea matahari may make sense for transport protocol
14:35:47 <pmyers> someone mentioned webdav
14:35:52 <pmyers> that may be a good fallback
14:36:01 <xTs_w> <--- ;)
14:36:03 <pmyers> so if matahari and bus/brokers present, use that, if not use webdav
14:36:12 <mburns> #idea webdav as a fallback
14:36:56 <pmyers> ok what else?
14:37:03 <mburns> pmyers: should this ref impl be part of ovirt-node?
14:37:07 <pmyers> yes
14:37:08 <mburns> or separate git?
14:37:20 <pmyers> well maybe subpackage
14:37:24 <mburns> ok, then as a ovirt-node-config-server
14:37:27 <mburns> sub package
14:37:29 <pmyers> yes
14:37:33 <mburns> (or similar)
14:37:39 <mburns> we can fight about naming later
14:37:45 <pmyers> so that could be the QMF Console project
14:37:48 <pmyers> o-n-config-server
14:38:04 <mburns> #info package as subpackage of ovirt-node
14:38:05 <pmyers> the webdav fallback would basically just be a 'here's how you configure your webdav server to allow this to work'
14:38:21 <pmyers> xTs_w: agree?  ^^
14:38:25 <mburns> #info subpackage would be QMF Console
14:38:41 * mestery has to step out now for a bit.
14:38:45 <mburns> #info webdav is fallback
14:38:51 <xTs_w> pmyers: exactly :)
14:38:58 <mburns> #info webdav is just documentation
14:39:14 <mburns> mestery: thanks!
14:39:15 <pmyers> well documentation and then coding inside of ovirt-node to support that mechanism
14:39:22 <mburns> future meetings should go shorter
14:39:24 <pmyers> as a client of the webdav server
14:39:54 <pmyers> ok next topic?
14:40:04 <mburns> pmyers: i'm picturing ovirt-node-config-server being installed on another machine
14:40:10 <pmyers> ack
14:40:14 <pmyers> it would have to be
14:40:28 <mburns> code to handle in ovirt-node would handle QMF first, then webdav
14:40:43 <mburns> ok, let's skip bug scrub for now
14:40:47 <pmyers> well, it could depend on kernel cmdline args
14:40:55 <pmyers> you might override to say never use matahari only use webdav
14:41:04 <mburns> pmyers: yes, but that's implementation detail
14:41:09 <pmyers> ack
14:41:09 <mburns> ;-)
14:41:18 <mburns> ok, next topic
14:41:26 <pmyers> +1 on skipping bug scrub
14:41:29 <mburns> #topic Release Manager for ovirt-node
14:41:33 <pmyers> imo, you guys can just do that offline
14:41:36 <pmyers> close em at will :)
14:41:41 <mburns> ack
14:41:47 <pmyers> +1 for mburns as release mgr
14:41:54 * mburns volunteers
14:42:48 <pmyers> apevec jboggs: ?
14:42:51 <jboggs> ack
14:43:06 <mburns> #agreed mburns is ovirt-node release mgr
14:43:12 <pmyers> any objection from other community members?
14:43:35 <pmyers> as an aside, ovirt node team would love to get some new folks to help be maintainers
14:43:52 <pmyers> all that is required is to start submitting patches and show that you've got a good understanding of the code and concepts :)
14:43:52 <mburns> pmyers: makes sense for me to take it for now at least
14:43:55 <pmyers> mburns: ack
14:44:04 <pmyers> just trying to solicit help :)
14:44:13 <mburns> if someone is interested, i'm open to working with them to take over
14:44:27 <mburns> at least as a backup
14:44:44 <mburns> ok, moving on
14:44:45 <mburns> #topic Release Schedule
14:44:56 <pmyers> i'm open to suggestions here :)
14:45:11 <mburns> i think roughly monthly releases for now sounds good
14:45:21 <jboggs> same here
14:45:35 <mburns> with flexibility to move to oVirt project release schedule
14:45:41 <mburns> when that eventually gets decided
14:45:50 <mburns> well, not move to, but synchronize with
14:46:07 <pmyers> +1
14:46:12 <mburns> i.e. if oVirt releases every 3 months on the 15th, we'll make our monthly releases on the 15th
14:46:20 <pmyers> so we first need to do the official f16 based release
14:46:24 <pmyers> what will our date be for that
14:46:37 <mburns> do we want it working with engine?
14:46:58 <mburns> if yes, then we're blocked by a vdsm bug
14:47:28 <mburns> i think EOM is a good target in general
14:47:33 <pmyers> yes that's a prereq
14:47:44 <pmyers> abaron_wfh: any movement on that vdsm bug?
14:47:56 <pmyers> it's last thing blocking us getting a working oVirt Node published
14:47:56 <mburns> actually, lets say 15th of the month for releases
14:48:06 <mburns> but f16 will be ASAP
14:48:11 <pmyers> +1
14:48:26 <mburns> pmyers: i'm working with dougsland on vdsm bug
14:48:49 <pmyers> ok, root cause yet?
14:49:11 <mburns> i'm pretty sure i know the problem, but i don't know enough about engine and vdsm internals to fix it
14:49:20 <mburns> #agreed 15th of each month for releases
14:49:38 <mburns> #agreed synchronize day of month with oVirt project
14:49:45 <mburns> #agreed monthly releases
14:49:49 <pmyers> ok, dougsland is aware that this is high prio and is blocking upstream initial release?
14:49:55 <mburns> pmyers: yes
14:50:02 <pmyers> k
14:50:23 <mburns> pmyers: i'm completely at his disposal at this point for making sure he has ovirt-node builds
14:50:29 <pmyers> ok
14:50:40 <jumper45> mburns: do you need engine help?
14:50:50 <pmyers> mburns: let's make sure we are periodically updating the relevant bug with state so we know where this is at on a day to day basis
14:50:59 <mburns> jumper45: possibly, but not sure yet
14:51:07 <mburns> first step is to figure out the vdsm part
14:51:13 <pmyers> cctrieloff is particularly interested in getting this resolved so we can do our initial launch of release #1
14:51:17 <jumper45> mburns: let me know if you need anything
14:51:18 <mburns> jumper45: i'll ping after the meeting
14:51:28 <pmyers> mburns: ok probably next topic
14:51:41 <mburns> #action mburns to work with jumper45 and dougsland on blocking registration issue
14:51:51 <mburns> #topic Questions and Comments
14:52:00 <mburns> ok, open season now
14:52:06 <pmyers> nothing from me :)
14:52:14 * mburns ducks and covers
14:52:25 <mburns> ok, going once....
14:52:28 <mburns> twice....
14:52:33 <mburns> gone...
14:52:42 <mburns> #agreed bug scrub can be done offline
14:52:48 <mburns> Thanks all
14:52:50 <cctrieloff> pmyers: agreed.
14:53:03 <mburns> #endmeeting