14:00:27 <gibi> #startmeeting nova
14:00:28 <openstack> Meeting started Thu Mar 22 14:00:27 2018 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:32 <openstack> The meeting name has been set to 'nova'
14:00:34 <tssurya> o/
14:00:35 <mriedem> o/
14:00:37 <edleafe> \o
14:00:49 <edmondsw> o/
14:00:52 <efried> @/
14:00:54 <gibi> hi! I will be your host today
14:01:06 <dansmith> o/.
14:01:27 <gibi> #topic Release News
14:01:38 <gibi> #link Rocky release schedule: https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule
14:01:54 <gibi> Apr 19: r-1 milestone, nova spec freeze
14:02:24 <gibi> Apr 27: spec review focus day
14:02:39 <mriedem> march 27?
14:02:50 <gibi> mriedem: correct :)
14:02:51 <bauzas> \o
14:02:51 <gibi> sorry
14:03:03 <gibi> March 27: spec review focus day
14:03:36 <efried> phew
14:03:36 <gibi> #link http://lists.openstack.org/pipermail/openstack-dev/2018-March/128630.html
14:03:49 * johnthetubaguy hides in the back of the room
14:04:04 <gibi> #link os-vif 1.10.0 was released on 2018-03-21: https://review.openstack.org/#/c/554948
14:04:05 <ttsiouts> o/
14:04:39 <gibi> anything else about the release?
14:04:58 <gibi> #topic Bugs (stuck/critical)
14:05:20 <gibi> 30 new untriaged bugs right now #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
14:05:43 <mriedem> went through a lot of garbage bugs yesterday
14:06:06 <gibi> that was 47 on the agenda so thanks for the triaging
14:06:41 <gibi> we dont have critical bugs
14:07:10 <gibi> there are 4 untriaged and untagged bug in our queue https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
14:07:38 <gibi> tagging helps to route bugs to experts for triage
14:07:43 <gibi> #help tag untagged untriaged bugs with appropriate tags to categorize them
14:08:24 <bauzas> yeah I need to help :(
14:08:54 <gibi> Gate status
14:08:56 <gibi> #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
14:09:13 <gibi> I don't see any major nova related failure in the list
14:09:13 <mriedem> it seems to be oddly slow, but overall no known big failures
14:09:36 <gibi> there was some hanging functional tests the other day
14:09:44 <gibi> I don't know what was the cause
14:10:11 <johnthetubaguy> meltdown fixes?
14:10:20 <mriedem> i would be interested to know what % of nodes are not running openstack stuff now
14:10:30 <mriedem> with the new CI/CD zuulv3 split thingy with the foundatoin
14:10:35 <mriedem> but that's another topic for another channel
14:10:41 * johnthetubaguy nods
14:10:52 <dansmith> do we share a nodepool with other projects?
14:10:53 <gibi> 3rd party CI #link http://ci-watch.tintri.com/project?project=nova&time=7+days
14:11:07 <gibi> dansmith: I guess we run tests triggered from github
14:11:20 <dansmith> I didn't think _our_ zuul did
14:11:33 <mriedem> don't know, probably a question for that thread in the ML
14:12:01 <dansmith> we'd see them in our status dashboard I would think
14:12:05 * alex_xu_ waves late
14:12:06 <dansmith> unless it's just nodepool that is shared
14:12:09 <dansmith> anyway, sorry to derail
14:12:19 <bauzas> I thought it was a separate nodepool
14:12:22 <gibi> going back to 3rd party CI
14:13:02 <gibi> I don't kknow what I have to look for in http://ci-watch.tintri.com/project?project=nova&time=7+days
14:13:13 <gibi> does the recent redness of IBM PowerKVM CI relevant?
14:13:28 <mriedem> we can ask mmedvede later
14:14:06 <gibi> anything else about bugs or CI ?
14:14:31 <gibi> #topic Reminders
14:14:36 <gibi> #link Rocky Review Priorities https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
14:15:16 <gibi> #info Rocky spec review day: next week Tuesday March 27, let's focus a day on reviewing specs
14:15:23 <gibi> once again ^^ :)
14:16:07 * stephenfin walks in late
14:16:10 <gibi> Runaway proposal #link http://lists.openstack.org/pipermail/openstack-dev/2018-March/128574.html
14:16:54 <gibi> anything else for reminders?
14:17:30 <gibi> #topic Stable branch status
14:17:36 <gibi> #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z
14:17:59 <mriedem> gonna do another queens release shortly
14:18:04 <mriedem> once a couple of other fixes land,
14:18:13 <mriedem> we had a revert that impacts hard reboots for libvirt that we need to get released
14:18:18 <mriedem> same for pike
14:18:23 <gibi> #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
14:18:39 <gibi> thanks mat
14:18:43 <gibi> thanks mriedem
14:18:52 <gibi> #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
14:19:14 <gibi> anything else for stable branches?
14:19:27 <mriedem> the stable eol thing is likely getting approval tomorrow
14:19:28 <mriedem> by the TC
14:19:31 <mmedvede> mriedem: we have some problems in CI we are addressing, something internal
14:19:46 <mriedem> #link https://review.openstack.org/#/c/548916/
14:20:06 <gibi> mmedvede: thanks for the info
14:20:20 <mmedvede> turned off reporting
14:20:22 * bauzas needs to leave early (as today is buggy for most people in my country)
14:20:50 <gibi> #topic Subteam Highlights
14:20:54 <gibi> Cells v2 (dansmith)
14:20:58 <dansmith> no meeting this week
14:21:42 <gibi> Scheduler (edleafe)
14:21:50 <edleafe> Discussed whether mirroring Nova host aggregates to Placement was a proxy API, or whether it was a necessary duplication, due to them being used for different purposes. No clear consensus was reached.
14:21:54 <edleafe> efried admitted to being a PITA
14:21:56 <edleafe> jaypipes expressed his opinion that we have already done enough in terms of extracting placement for Rocky, and to hold off on any further work. cdent disagreed, and will continue to push forward.
14:22:00 <edleafe> We agreed that we need to focus on the work for nesting providers in allocation_candidates.
14:22:03 <edleafe> cdent wondered if he is a bug.
14:22:06 <edleafe> That's it.
14:22:21 <gibi> thanks
14:22:22 <gibi> Notification (gibi)
14:22:44 <gibi> every bp I tracked got discussion and most of them is approved
14:22:52 <gibi> list and status is in #link Notification (gibi)
14:23:02 <gibi> I mean #link http://lists.openstack.org/pipermail/openstack-dev/2018-March/128562.html
14:23:31 <mriedem> but some have been approved for awhile with no code yet right?
14:23:36 <gibi> mriedem: yes
14:23:42 <mriedem> which is... :/
14:23:47 <mriedem> >:(
14:23:48 <mriedem> oops
14:23:54 <gibi> mriedem: I share your pain
14:24:03 <mriedem> ~\o/~
14:24:11 <gibi> Stuck Reviews
14:24:15 <gibi> #topic Stuck Reviews
14:24:27 <gibi> nothing on the agenda
14:24:43 <gibi> do we have something to bring up here?
14:24:58 <stephenfin> I have one thing
14:25:04 <gibi> stephenfin: go ahead
14:25:12 <stephenfin> sahid's patch on TX/RX queue sizes
14:25:14 * bauzas leaves now
14:25:16 * stephenfin get's link
14:25:21 <mriedem> ha as bauzas leaves
14:25:44 <stephenfin> *gets, even
14:25:46 <stephenfin> https://review.openstack.org/539605
14:26:16 <stephenfin> As discussed on the spec, we were pretty sure we were going with the global nova.conf option but there's been some disagreement on that
14:26:39 <johnthetubaguy> doesn't this need guest support, I should re-read that thing
14:26:45 <stephenfin> The spec has been rewritten to use extra spec keys. I'm OK with that but want to make sure this is OK for everyone else
14:27:03 <mriedem> the original patch from nic used extra specs right?
14:27:05 <dansmith> johnthetubaguy: it's virtio only
14:27:05 <stephenfin> johnthetubaguy: More hypervisor support than guest support, if I understand it correctly
14:27:26 <stephenfin> mriedem: Correct
14:27:27 <gibi> mriedem, stephenfin: If it is OK to add yet another flavor extra_spec key that is libvirt specific then I'm OK with the rest
14:27:41 <mriedem> the point of the extra spec is it doesn't have to be libvirt-specific,
14:27:42 <johnthetubaguy> I thought these things needed specific kernel versions in the guest for virtio to negociate, but I could be miss-remembering, its probably like 2.20 or something
14:27:44 <mriedem> but a config option would be
14:27:52 <mriedem> johnthetubaguy: correct,
14:27:57 <mriedem> it's super use case specific
14:27:57 <stephenfin> and we (mostly I) pushed him away from that given previous opposition to yet more extra spec knobs
14:27:57 <dansmith> but a config option being libvirt-specific isn't a huge proble
14:28:18 <stephenfin> Yeah, it's easy move it to another group if we need to
14:28:19 <mriedem> a config option isn't a huge problem no
14:28:42 <stephenfin> But I feel bad about pushing him one way when he's now being dragged back, heh
14:28:47 <dansmith> extra spec keys that are in libvirt-specific units (i.e. queues) is less palatable to me than a config option in conf.libvirt
14:28:58 <johnthetubaguy> why would you not want to set it, extra memory usage?
14:29:04 <mriedem> is there no way that other virt drivers would never be able to do this same thing?
14:29:18 <johnthetubaguy> xen has something quite similar brewing upstream
14:29:24 <dansmith> if it's in extra_specs I would like it to be something like shares or percentage of the total, where the total (or max)  is configured by compute in conf or something like that
14:29:25 <stephenfin> johnthetubaguy: gibi raised that, yeah. Realistically though, this is going to be set everywhere and not touched again
14:29:51 <stephenfin> Until the hardware is upgraded to 40 or 100 Gig, anyway
14:30:01 <johnthetubaguy> so if you want it everywhere, feels like it should be a config option?
14:30:12 <johnthetubaguy> right, feels mostly a property of the host capabilities
14:30:13 <dansmith> config option feels like the easy way to go here for now, IMHO
14:30:15 <stephenfin> That was my feeling, yes
14:30:29 <johnthetubaguy> ++ config option here, as much as the churn on the spec sucks
14:30:57 <mriedem> i'm happy to bow out of the spec review if dansmith and johnthetubaguy want to take over
14:30:58 <stephenfin> No one has asked for this to be per guest, so the benefits of that feature are slight at best
14:31:09 <gibi> adding a config option now, and if the use case comes up to set it per VM then addign an extra spec later is doable
14:31:14 <stephenfin> Yeah, I'm also going to bow out
14:31:20 <dansmith> mriedem: sure
14:31:25 <stephenfin> On account of the "go this way, no this way" thing
14:31:28 <dansmith> stephenfin: wait, aren't you the one that asked for it to be extra_specs?
14:31:33 <dansmith> stephenfin: no fair bowing out now :)
14:31:34 <mriedem> i did
14:31:37 <dansmith> oh
14:31:42 <stephenfin> Nope, that was mriedem
14:31:43 <mriedem> i didn't realize this couldn't be used by other virt drivers
14:31:48 <dansmith> okay, then all the more reason for stephenfin to stick around for his victory lap
14:31:59 <stephenfin> :D
14:32:07 <stephenfin> sahid is going to be pi******ed :D
14:32:15 <dansmith> anyway, johnthetubaguy you'll help review?
14:32:17 <mriedem> all he has to do is revert to an older patchset
14:32:18 <stephenfin> but eh, good to get a move on this
14:32:23 <dansmith> I'll comment that we had a big discussion
14:32:25 <gibi> Do I sense properly that we have an agreement to use config option?
14:32:26 <johnthetubaguy> dansmith: yes
14:32:29 <dansmith> he hates me anyway :)
14:32:38 * dansmith -> lightning rod
14:32:38 <stephenfin> gibi: +1 from me
14:33:12 <gibi> dansmith: thanks for taking the bad guy role :)
14:33:18 <gibi> let's move on
14:33:31 <stephenfin> (y)
14:33:32 <gibi> #topic Open discussion
14:33:41 * mriedem prepares for the deluge of powervm blueprints
14:33:42 <gibi> there is a long list of specless bps on the agenda
14:33:50 <gibi> (melwitt): seeking approval for specless blueprint for improving the xenapi image handler: https://blueprints.launchpad.net/nova/+spec/xenapi-image-handler-option-improvement
14:34:00 <jianghuaw> It’s to change a XenAPI config option to specify the image handler, so that xenapi can support non-FS based storage repositories (LVM, ISCSI).
14:34:07 <mriedem> approve
14:34:08 <jianghuaw> We also talked about it in PTG.
14:34:11 <mriedem> it was discussed at the ptg
14:34:24 <mriedem> same thing as the libvirt imagebacked right
14:34:24 <mriedem> ?
14:34:29 <mriedem> image_type or whatever that option is
14:34:44 <jianghuaw> mriedem, yes. similarly.
14:34:57 <jianghuaw> but not image type but the image handler.
14:35:24 <gibi> any objection against approving it?
14:36:14 <gibi> then it is approved
14:36:20 <gibi> next
14:36:21 * johnthetubaguy remembers something about me reviewing that
14:36:21 <jianghuaw> Thanks.
14:36:24 <gibi> (melwitt): seeking approval for specless blueprint for removing execs of system commands: https://blueprints.launchpad.net/nova/+spec/execs-ive-had-a-few
14:37:00 <dansmith> no reason not to do this, IMHO
14:37:07 <mriedem> "Also, it makes us look silly at social occasions."
14:37:07 <dansmith> now that we have privsep, it's possible, but wasn't before
14:37:37 <stephenfin> +1 from me. I've been reviewing those already thinking it was just another one of mikal's daft topics :)
14:37:55 <mriedem> i'm fine with it
14:37:55 <gibi> See we are in agreement, so It is approved
14:38:00 <johnthetubaguy> ++
14:38:14 <gibi> next
14:38:20 <gibi> (melwitt): Based on replies to the spec review day ML thread: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128603.html
14:38:25 <gibi> Can we have an informal vote on when people would like to start using runways? (Start immediately vs start after spec freeze, and let's go with the consensus)
14:38:53 * gibi votes for starting after the spec freeze
14:39:00 <mriedem> as someone that also reviews specs, i'm a big meh on this one
14:39:21 <johnthetubaguy> +1 "Obviously this will be an experiment and we won't get
14:39:21 <johnthetubaguy> it right the first time."
14:39:31 <dansmith> nobody replied to me, which tells me I'm the only one (and efried)
14:39:36 <dansmith> so we should just do it late I guess
14:39:49 <dansmith> and we'll just approve a bunch of stuff that won't land, like usual :)
14:40:28 <johnthetubaguy> how about after the spec review day, we do everything else on a runway?
14:40:28 <mriedem> anyone else going to speak up in this meeting?
14:40:34 <efried> Can anyone tell me why we shouldn't a) allow things like specs in runways, and b) start TODAY?
14:41:05 <mriedem> specs in runways is an idea i haven't had
14:41:05 * stephenfin still has to read that email and will stay quiet for this bit
14:41:16 <mriedem> but,
14:41:19 <cdent> I pretty much agreed with dansmith, but have little enough of an opinion that I didn't bother to response on the email. I also agree with efried just said
14:41:20 <efried> stephenfin: That's the gist of it.  Let's start now.
14:41:22 <mriedem> the idea is to flush out the approved stuff
14:41:31 <gibi> my reason to vote for after the spec freeze is the amount of time I need to spend on the bandwidth spec these days
14:41:52 <dansmith> specs in runways is a little hard because we'd need to have a way to say "okay, we're not going to do this this cycle, so we eject it from the runway without merging", IMHO
14:41:58 <dansmith> which is a little awkward, but I guess we could
14:42:00 <efried> okay, but it's clear that not everybody will be able to focus all their time all the time.
14:42:11 <dansmith> right, I don't really understand why we can't do specs in the background,
14:42:20 <efried> So gibi is focusing on that spec right now, but joebob will be focusing on a feature after spec freeze etc.
14:42:31 <dansmith> and I don't understand why we can't ramp up more spec review/approval when we're getting low on approved things to go in the queue
14:42:35 <dansmith> efried: yeah agreed
14:42:49 <johnthetubaguy> dansmith: yeah, I think that is what I was wanting to see, at least eventually
14:42:53 <mriedem> i think what i said on the etherpad and in dubling,
14:42:56 <mriedem> *dublin,
14:43:03 <mriedem> was if we're going to do both at the same time,
14:43:14 <mriedem> is we should extend spec freeze to basically feature freeze
14:43:25 <mriedem> or milestone 2, something like that
14:43:29 <dansmith> yeah we'd kinda have to,
14:43:39 <dansmith> as we'd be approving things later to keep the pipeline full as necessary
14:43:40 <efried> I'm not opposed to that in principle, though I think that decision can be made later.
14:43:45 <mriedem> so if we're cool with extending the spec freeze to at least milestone 2, i'm ok with doing runways now
14:43:47 <johnthetubaguy> well, its like all specs need an exception, you get granted when there is a slot for you?
14:43:49 <dansmith> so we'd be shooting for smaller things to be approved later
14:44:21 <johnthetubaguy> so a bit I missed, is how were we going to track the runways?
14:44:28 <mriedem> i'm also ok with doing runways now w/o extending the spec freeze, i should say, that's why i said 'meh'
14:44:37 <mriedem> johnthetubaguy: etherpad
14:44:57 <stephenfin> the only issue I have with extending the deadline is increased difficulty getting less obvious specs landed
14:44:58 <johnthetubaguy> mriedem: I was wondering if trello might work, but not sure if that excludes folks
14:45:01 <stephenfin> without the pressure of said deadline
14:45:15 <dansmith> johnthetubaguy: it excludes people with a soul
14:45:25 <efried> johnthetubaguy:  https://etherpad.openstack.org/p/nova-runways-rocky
14:45:37 <mriedem> stephenfin: umm,
14:45:43 <jaypipes> dansmith: shit, I'm out then.
14:45:53 <mriedem> well that's kind of the thing - you can have us all focus on runways and a few do spec reviews,
14:46:06 <mriedem> or we extend the spec review deadline so there is time for both for the few that actually review specs
14:46:19 <johnthetubaguy> OK, I missed its just a list of three, ignore me, etherpad is perfect
14:46:33 <dansmith> so,
14:46:41 <dansmith> can we just have people reply with this stuff on that thread as the votes?
14:46:45 <stephenfin> mriedem: Good point. I guess it'll just shuffle things around a bit
14:46:52 <johnthetubaguy> I am tempted to say we just grant exceptions when needed
14:47:10 * johnthetubaguy goes to email thread
14:47:10 <gibi> dansmith: let's do that
14:47:10 <mriedem> kind of sucks to have this discussion without the PTL here,
14:47:12 <mriedem> so yeah ML it is
14:47:20 <dansmith> mriedem: right that's my point
14:47:23 <johnthetubaguy> timezones suck
14:47:24 <gibi> #action vote on the ML
14:47:34 <gibi> moving on
14:47:44 <gibi> (esberglu): PowerVM specless blueprints
14:48:05 <gibi> Network Hotplug: https://blueprints.launchpad.net/nova/+spec/powervm-network-hotplug
14:48:11 <edmondsw> we originally had a spec for this, but mriedem and melwitt agreed yesterday these could be specless
14:48:11 <mriedem> approve
14:48:13 <efried> Perfect example of how we can use runways for bp+feature as we go.
14:48:20 <edmondsw> yep
14:48:33 <edmondsw> that one is already up and ready for review once the bp is approved
14:48:39 <edmondsw> the impl I mean
14:48:49 <efried> Queue up the first couple.  Get 'em in a runway.  Get 'em approved.  Queue up the next couple.  Repeat until we run out of... runway.
14:49:24 <edmondsw> vscsi and snapshot are also essentially implemented... a little more subteam review needed
14:49:25 <gibi> efried: do you mean not take the whole list of 6 bp now just the first 3?
14:49:31 <mriedem> how we handle priority for a runway slot is up for debate probably
14:49:45 <efried> gibi: I think queueing them up individually would be appropriate.
14:49:54 <mriedem> i.e. i think the certs api stuff from john hopkins all trumps the powervm bp's
14:50:06 <edmondsw> I'd like to get at least the first 3 approved today, since they're implemented...
14:50:18 <efried> mriedem: One of the main purposes of runways was to allow focus on lower-priority work.  We already have high focus on high-priority work.
14:50:36 <mriedem> the certs api thing is low priority work,
14:50:39 <mriedem> it's been so gd low priority,
14:50:43 <mriedem> it's deferred since ocata
14:50:47 <dansmith> the priority thing is hard, and more important later in the cycle, which is one reason I want to start now
14:50:48 <efried> Point was that, with some (but few) exceptions, the queue is FIFO
14:50:50 <mriedem> so at this point, it's kind of high priority right?
14:50:55 <dansmith> so things that are low priority but ready can go ahead and benefit
14:51:07 <efried> If the cert thing is ready, queue it tf up and it'll bubble to the top in order.
14:51:22 <dansmith> efried: it's already in the queue actually :)
14:51:38 <mriedem> so i can approve https://blueprints.launchpad.net/nova/+spec/powervm-network-hotplug right?
14:51:54 <gibi> any objection?
14:51:56 <efried> +1 from me :)
14:52:23 <gibi> seems there is no objectsion so it is approved
14:52:26 <edmondsw> and vscsi and snapshot?
14:52:29 <gibi> next
14:52:30 <gibi> vSCSI cinder volumes: https://blueprints.launchpad.net/nova/+spec/powervm-vscsi
14:52:51 <edmondsw> this was actually ready to go in Queens but didn't get reviews
14:53:09 * bauzas is silently (well, not really) back
14:53:14 <edmondsw> we've made a few small improvements while we've been waiting
14:53:22 <gibi> any objection?
14:53:36 <mriedem> approved
14:53:39 <gibi> next
14:53:41 <gibi> Instance Snapshot: https://blueprints.launchpad.net/nova/+spec/powervm-snapshot
14:54:00 * gibi waiting for objectsion
14:54:09 <edmondsw> impl for this is up and tested. I think efried and I both had comments that were getting addressed and then we'd open it up for wider review
14:54:20 <edmondsw> probably a few days
14:54:27 <mriedem> approved
14:54:40 <mriedem> you guys are also enabling CI testing for all of these right?
14:54:45 <mriedem> b/c tempest tests attach interface and snapshot
14:54:53 <esberglu> Not vSCSI
14:54:53 <mriedem> i will -1 the living hell out of these patches if i don't see it
14:54:57 <mriedem> i know not that one
14:55:05 <esberglu> Snapshot and attach yes
14:55:12 <mriedem> ok, fair warning
14:55:27 <mriedem> next?
14:55:28 <gibi> do we want to go further down the list of powervm bps or it is enough for now and we will take the rest when this 3 are merged?
14:55:40 <gibi> *these 3
14:55:40 <mriedem> i'll just hit the rest in the agenda
14:55:42 <mriedem> after the meeting
14:55:53 <mriedem> or melwitt can
14:55:59 <gibi> mriedem: does hit means approve?
14:56:08 <mriedem> yeah.
14:56:14 <mriedem> these were all in a spec that was basically approved,
14:56:18 <mriedem> but we didn't need a spec,
14:56:25 <gibi> mriedem: ohh I see
14:56:26 <mriedem> so they were split out as feature parity blueprints
14:56:36 <gibi> then I agree
14:56:39 <mriedem> because a spec with a laundry list is annoying
14:56:46 <gibi> so the last item on the agenda
14:56:47 <gibi> (jianghuaw): seeking approval for specless blueprint for "vGPU work in rocky": https://blueprints.launchpad.net/nova/+spec/vgpu-rocky
14:56:55 <jianghuaw> This BP is for tracking the work in Rocky for the vGPU functions which have not been done in Queens.
14:56:56 <mriedem> approve
14:57:02 <mriedem> we talked about this in dublin
14:57:05 <mriedem> it's just closing gaps
14:57:07 <jianghuaw> cool mriedem:-)
14:57:13 <mriedem> everyone agree?
14:57:22 <johnthetubaguy> ++
14:57:31 * gibi doesn't see any objections
14:57:47 <gibi> anything else to discuss in the next 2 minutes?
14:58:02 <stephenfin> nein
14:58:02 <jianghuaw> Thanks all:-)
14:58:47 <gibi> OK. let's close this
14:58:50 <gibi> thanks for the meeting
14:58:58 <gibi> #endmeeting