16:00:30 <jungleboyj> #startmeeting cinder
16:00:32 <openstack> Meeting started Wed Jun 28 16:00:30 2017 UTC and is due to finish in 60 minutes.  The chair is jungleboyj. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:35 <openstack> The meeting name has been set to 'cinder'
16:00:37 <Swanson> hi
16:00:38 <eharney> hi
16:00:46 <e0ne> hi
16:00:51 <jungleboyj> dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex karthikp_ patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino karlamrhein diablo_rojo jay.xu jgregor lhx_ baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell watanabe.isao,tommylikehu mdovgal ildikov wxy viks ketonne abishop sivn
16:01:03 <geguileo> hi! o/
16:01:11 <jgriffith> howdy
16:01:12 <tbarron> hi
16:01:14 <lhx__> o/ hi
16:01:16 <patrickeast> Hi
16:01:26 <pewp> hemna (ஐ╹◡╹)ノ
16:01:47 <rarora> o/
16:02:08 <jungleboyj> @!
16:02:09 <pewp> jungleboyj (♦亝д 亝)ﾉ
16:02:19 <jungleboyj> Give people one more minute.
16:02:27 <pots> o/
16:02:36 <Swanson> You'll never get that minute back. Gone forever.
16:02:58 <Swanson> Your last words will be cut short by one minute now.
16:03:31 <jungleboyj> Ok, we have a lot to cover.  smcginnis , the bum , is sleeping in China right now so I am your fearless leader again today.
16:03:39 <jungleboyj> And I am not letting the meeting run over this time!
16:03:54 <jungleboyj> #topic announcements
16:03:55 <tommylikehu> hey
16:04:08 <jungleboyj> Your weekly reminder to check our review focus list.
16:04:18 <jungleboyj> #link https://etherpad.openstack.org/p/cinder-spec-review-tracking
16:04:43 <jungleboyj> smcginnis:  Added specs that are approved for pike but not yet complete.  So, need to be reviewing those.
16:05:12 <jungleboyj> We need to finish implementation against those specs, move them to queens or revert if no longer needed.
16:05:24 <jungleboyj> If you own one of those specs and it needs action, please take care of it.
16:05:59 <jungleboyj> Also, we now have the work item of moving documentation from the docs team to the Cinder project.
16:06:28 <jungleboyj> The first of the patches asettle  was nice enough to start for us:  #link https://review.openstack.org/#/c/472275/
16:07:11 <jungleboyj> I took over the docs liaison project so I am going to shoot to put together an etherpad to organize the work.  Haven't had a chance to do that yet though.  Will update everyone here when that happens.
16:07:44 <hemna> so all docs for cinder are going to live in cinder now ?
16:07:56 <hemna> everybody knows that engineers don't write docs.......
16:08:06 <hemna> guess openstack is just giving up then ?
16:08:11 <tommylikehu> ：）
16:08:12 <jungleboyj> hemna:  Yes.  This is because of the brain drain on the documentation team.
16:08:14 * diablo_rojo finally gets IRC to connect
16:08:19 <jungleboyj> hemna:  I know.
16:08:28 <hemna> oofa
16:08:41 <jungleboyj> So, it is going to be important for Cores to make sure that Docs are happening.
16:08:48 <jgriffith> honestly I think we *should* own our docs
16:08:53 <jungleboyj> I am going to be working/enforcing in that area.
16:08:57 <jgriffith> we should also own interactions with users
16:08:59 <jungleboyj> jgriffith: I think you are right.
16:09:11 <asettle> So nice
16:09:12 <asettle> Very asettle
16:09:16 * asettle walks in late
16:09:21 <jungleboyj> hey asettle
16:09:23 <asettle> o/
16:09:36 <jungleboyj> So, I am just going to have to figure out how to get you all to write docs.  ;-)
16:09:46 <jungleboyj> I can't send a cheesecake to everyone.
16:09:53 <_alastor1> o/
16:09:57 <jungleboyj> :-)
16:10:04 <tommylikehu> you can
16:10:05 <jungleboyj> Any other questions on that topic?
16:10:18 <jungleboyj> tommylikehu: Well, I CAN ... but ...
16:11:01 <geguileo> jungleboyj: can't we just make sure that we add the docs together with the code?
16:11:07 <geguileo> just like unit-tests
16:11:13 <jungleboyj> Let me get an etherpad put together and we can talk in greater detail in the next week or two.  We need to get this done for Pike though.
16:11:29 <ildikov> geguileo: +1
16:11:36 <diablo_rojo> geguileo, +1
16:11:44 <ildikov> geguileo: that would be the point in the whole initiative
16:11:44 <jungleboyj> geguileo: +1
16:11:50 <lhx__> jungleboyj, is this ok? https://etherpad.openstack.org/p/doc-migration-tracking
16:12:19 <lhx__> or something like this etherpad
16:12:24 <ildikov> tl;dr the idea is to let the experts write the doc and the docs team help with formatting and phrasing it consistently
16:12:50 <jungleboyj> lhx__:  Oh cool.  Yes, something like that.  Thanks for getting that to me.
16:13:03 <hemna> s/experts/engineers
16:13:04 <hemna> :P
16:13:07 <hemna> who don't write docs
16:13:08 <hemna> lol
16:13:32 <hemna> anyway, the projects should own their docs, I'm just saying.....99% of engineers don't write em.
16:13:39 <jungleboyj> hemna:  :-p  Things change.
16:13:44 <asettle> hemna: and you have just summed up the problem
16:14:07 <hemna> yah :(
16:14:08 <asettle> So, help us be a part of the change :)
16:14:11 <asettle> Promise it'll be awesome
16:14:16 <asettle> jungleboyj:  is promising cheesecake so ya know
16:14:18 * hemna is ready for awesome.
16:14:22 <asettle> \o/
16:14:22 <jungleboyj> asettle:  ++
16:14:36 <ildikov> hemna: I didn't say you have to write War and Piece length and quality docs from now on
16:14:42 <asettle> jungleboyj: yo fo real i'm a very serious gal about cheese cake
16:14:48 <geguileo> I'm sure we'll bother to write the docs if we can't get our code merged without it
16:14:54 <asettle> no, no hemna ildikov did say you'd have to write giant docs ;)
16:15:00 <jungleboyj> geguileo: ++
16:15:00 <ildikov> hemna: but you're the expert of what you develop :)
16:15:12 <hemna> can we write docs in regex code? :P
16:15:13 <ildikov> asettle: ;)
16:15:15 <asettle> Precisely :)
16:15:18 <asettle> hemna: errrr
16:15:19 <asettle> ERRR
16:15:20 <asettle> UM
16:15:37 <jungleboyj> And there are those of us that don't mind reviewing and helping with documentation.
16:15:40 <jungleboyj> So, it will be ok.
16:15:56 <Swanson> Managers.
16:16:08 * jungleboyj shakes my head a Swanson
16:16:30 <ildikov> hemna: is that the new English? :)
16:16:51 <jungleboyj> Anyway, this was more of a 'heads up' that this was coming and we will discuss further once I have a better handle on this.
16:17:31 <jungleboyj> #topic Critical and security fixes to driverfixes branch
16:17:41 <jungleboyj> So, this topic came out of last week's Manila meeting.
16:17:56 <jungleboyj> They are going to also add a driverfixes branch.
16:18:24 <hemna> a single branch ?
16:18:25 <jungleboyj> Question came up as to whether we are making sure that critical and security fixes are also going back to that branch, but I think the actual answer here is that we don't want to do that.
16:18:42 <bswartz> branches
16:18:42 <eharney> that seems like confusion about what the driversfixes branches are for
16:18:44 <jungleboyj> hemna:  No, the same thing we are doing.
16:18:51 <hemna> didn't we already try this a while back to allow driver devs to get whatever fixes we needed into old releases?
16:18:59 <hemna> (which we still need badly)
16:19:20 <jungleboyj> eharney:  Yeah, after I added this I realized that driverfixes is just for fixes to drivers and that we don't need to be putting other changes back there.
16:19:24 <jungleboyj> Agreed?
16:19:43 <eharney> yes, there is no commitment currently to handle security fixes or critical bug fixes there
16:20:03 <hemna> did we implement that plan ?
16:20:14 <hemna> or wasn't it shot down by the infra folks due to lack of CI ?
16:20:16 <jungleboyj> Ok, good.  Glad we aren't missing anything there.  I will carry that forward to Manila so we are all on the same page.
16:20:27 <bswartz> the reason I wanted to duplicate bugfixes in both branches is so that the 2 branches don't end up with conflicts
16:20:32 <jungleboyj> hemna:  We did, that is the other reason I bring this up is as a reminder that that branch is there.
16:20:40 <hemna> the branch?
16:20:46 <bswartz> driverfixes should have everything stable has and more
16:20:47 <hemna> meaning singular ?
16:20:53 <eharney> bswartz: i'm not sure that will happen since the driverfixes branches don't exist until after the regular stable branch has ended (iirc)
16:21:07 <hemna> we need the ability to fix bugs on each out of service release
16:21:21 <eharney> hemna: we have driverfixes/mitaka and driverfixes/newton branches
16:21:22 <jungleboyj> hemna:  Right.
16:21:29 <hemna> eharney, ok thanks
16:21:29 <bswartz> eharney: there's a period when the both exist -- after the stable branch is closed to non-critical bugfixes but before the stable branch is gone
16:21:32 <hemna> that's what I was wondering
16:21:38 <jungleboyj> hemna:  Sorry, I should be plural.
16:21:43 <eharney> bswartz: ahh, true
16:21:50 <hemna> ok I was getting confused
16:22:04 <hemna> I see the 2 driverfixes branches there in github now
16:22:06 <jungleboyj> I understand why you are confused now.  Sorry.
16:22:08 <bswartz> during that period, everything that goes into stable should (IMO) go into driverfixes too
16:22:08 <hemna> for M and N
16:22:24 <hemna> bswartz, +1
16:22:27 <bswartz> so driverfixes doesn't diverge from stable
16:22:38 <hemna> is anyone doing that?
16:22:48 <jungleboyj> bswartz:  Seems reasonable though I don't think people are taking the whole driverfixes branches.
16:22:55 <hemna> I presume we are managing those driverfixes/* branches manually now
16:22:59 <bswartz> probably not
16:24:02 <jungleboyj> So, do we agree that we should be pulling security and critical fixes back to the driverfixes branches?
16:24:15 <eharney> i'm not sure
16:24:34 <jungleboyj> eharney:  Is RedHat using anything from those branches?
16:24:51 <jungleboyj> As are token distro rep.  ;-)
16:24:55 <jungleboyj> *our
16:25:07 <eharney> jungleboyj: we use them as a place to have patches backported upstream that we can then cherry-pick from
16:25:26 <jungleboyj> eharney:  And you are using it?
16:25:44 <bswartz> so eharney wouldn't you be happier to have patches in driverfixes already rebased on top of any conflicting critical bug fixes from stable?
16:26:00 <eharney> we've used it once or twice, it hasn't been around long enough to see a lot of activity (newton surely will)
16:26:22 <jungleboyj> bswartz: The changes should only be to drivers in those branches.
16:26:31 <eharney> bswartz: probably, but my guess is that critical bug fixes are either going to be in-driver and backported there anyway, or not conflict
16:26:48 <eharney> critical bug fixes that conflict with other driver fixes are probably quite rare
16:26:51 <tbarron> i have some concern about putting critical and security patches on branch that isn't tested
16:27:08 <jgriffith> tbarron how come?
16:27:14 <tbarron> may imply "warrant" as it were to end users that isn't there
16:27:18 <hemna> tbarron, we already went over this when we decided to do the driverfixes branching scheme
16:27:33 <hemna> it's up to each dev that puts the patch up to test it
16:27:34 <eharney> we don't run all of the test jobs on driverfixes/* iirc
16:27:51 <bswartz> I agree conflicts are unlikely, but because they're not impossible it seems worth protected against them by just doing the backports
16:27:55 <jungleboyj> eharney:  Correct.
16:27:58 <tbarron> hemna: jgriffith well I think that "infra" arg has more credibility w.r.t. critical and security fixes than for driver fixes :)
16:27:58 <hemna> we have no way of getting the CI systems to work, as infra refuses to tag/branch their code to keep it working against old stuffs
16:28:10 <bswartz> we're talking about a handful of extra cherrypicks
16:28:28 <jungleboyj> bswartz:  ++
16:28:50 <jgriffith> tbarron I guess my point was I don't know why crit/sec fixes are any different than any change to the driver etc that we've already talked about?
16:29:09 <eharney> but we can't show that those cherrypicks for other critical fixes are properly tested
16:29:09 <jgriffith> tbarron I mean; same rule applies right, change in driver/* only?
16:29:20 <tbarron> jgriffith: are these *driver* crit/sec or core crit/sec that we rebase on?
16:29:28 * tbarron may be confused
16:29:42 <hemna> jgriffith, +1
16:29:43 <jgriffith> tbarron I thought we all agreed on no changes to the core code; it wouldn't be feasible/sustainable
16:29:49 <bswartz> tbarron: if you read the apache license you'll see very clearly we offer no warranty on our code
16:30:03 <jgriffith> because in that model if you don't have gate testing this would NEVER EVER work
16:30:14 <jungleboyj> jgriffith:  ++
16:30:18 <jgriffith> but maybe I'm wrong
16:30:47 <bswartz> jgriffith: somebody has to test these patches -- just not the upstream community
16:30:54 <tbarron> bswartz: that's why I used quotes, trying to indicate a concern about some weaker level of assurance
16:31:01 <bswartz> we rely on vendors and distros to ensure quality of driver bugfixes
16:31:02 <jgriffith> I guess maybe I'm not being clear
16:31:32 <bswartz> and you can be sure that vendors and distros are testing with a combination of all the security patches and the driver bugfixes in question
16:31:43 <jgriffith> bswartz so if you provide a change to cinder/api/xxxx. are you going to test it against all 80 backend/drivers?
16:31:51 <bswartz> so the point here is just to make cherrypicking easier
16:31:58 <jgriffith> so that's not a great example... let's say cinder/volume/manger.py
16:31:59 <hemna> bswartz, the person pushing the fix has to test it.
16:32:15 <hemna> and it's supposed the be the driver dev/owner anyway
16:32:20 <jungleboyj> bswartz: I think what we are trying to say is that the cherry picks should only be under /volume/drivers so that shouldn't be an issue.
16:32:26 <bswartz> jgriffith: such a patch would already have been tested when it went into stable
16:32:37 <bswartz> taking in into driverfixes too causes no harm
16:33:10 <jgriffith> bswartz my experience in backporting/cherry-picking is very different than yours
16:33:12 <eharney> but it also doesn't seem to offer much benefit?
16:33:28 <bswartz> eharney: the benefit is marginal
16:33:34 <jgriffith> the whole point of this was to be a place for driver fixes
16:33:37 <bswartz> if you say you don't want it we can agree to not do this
16:33:40 <jgriffith> not core fixes etc
16:34:00 <hemna> jgriffith,+1
16:34:07 <jungleboyj> bswartz:  I think that is what we originally agreed upon.
16:34:26 <jgriffith> my experience is that the further back you go with trying to backport/cherry-pick things the more difficult it is in terms of conflicts, missing things etc
16:34:28 <bswartz> the specific case I have in mind is a security bug or critical bug in a driver that needs to merge to the stable branch after the driverfixes branch has been forked
16:34:39 <jgriffith> these are all just point in time snapshots remember
16:35:11 <jgriffith> say for example sec fix to Ocata that relies on something added in the object or rpc modules
16:35:19 <bswartz> I agree it's kind of pointless to backport a bugfixes that doesn't touch any driver code to the driverfixes branch
16:35:43 <jgriffith> you try and backport that to Newton, but it turns out it relies on some special thing in the version that only exists in Ocata
16:35:51 <jungleboyj> bswartz: So, I think we have the answer there.
16:36:47 <jungleboyj> I would like to reach consensus and move on here if possible.
16:37:16 <jungleboyj> So, it sounds like the Cinder team is in agreement that we agreed to no core changes to the driverfixes branches.
16:37:28 <bswartz> yeah I can agree to that too
16:37:33 <jungleboyj> I don't feel a need to change that policy.
16:37:45 <jungleboyj> bswartz:  Are are willing to keep that consistent in Manila?
16:38:03 <jungleboyj> *Are you
16:38:07 <bswartz> but if there's a critical bugfix or security bugfix to a driver that goes into stable, it should *also* go into driverfixes
16:38:22 <jungleboyj> bswartz:  I can agree with that.
16:38:36 <jungleboyj> Any disagreements?
16:38:40 <eharney> sounds good to me
16:38:45 <tbarron> bswartz: how do you ensure that it happens though?
16:39:02 <tbarron> vendors will be motivated to do their own patches to drivers
16:39:14 <jungleboyj> tbarron:  That is going to be the core team's oversight and the driver maintainers should want to do that.
16:39:21 <bswartz> tbarron: I think it's in everyone's best interest
16:39:33 <jungleboyj> bswartz: Agreed.
16:39:45 <tbarron> I don't disagree: but it may take some vigilance.
16:40:00 <tbarron> vendors will be motivated to do a quick dump of a local fix in driverfixes
16:40:17 <tbarron> but less motivated to do the due diligence.
16:40:26 <hemna> driver devs want the ability to backport fixes to older revs
16:40:28 <jgriffith> we could probably right a hook that prevents committing to the upper dirs
16:40:33 <jgriffith> write
16:40:36 <jgriffith> geesh
16:40:36 <jungleboyj> hemna: ++
16:40:42 <hemna> they are motivated  ( at least I was when I owned the 3par/lefthand drivers)
16:40:45 <tbarron> and I think we thought there would be expedited review for driver fixes, right?
16:41:23 <eharney> expedited in that there are fewer CI hoops, maybe
16:41:44 <tbarron> I guess what I'm saying is that if I'm cherry-picking from driver-fixes and I want to be sure that
16:42:03 <tbarron> I have all the crit/sec fixes as well I'm probably going to check the other branch anywways
16:42:03 <hemna> I think this would help out the various linux distro maintaners....
16:42:23 <e0ne> hemna: +1
16:42:27 <eharney> tbarron: yes
16:42:29 <jungleboyj> hemna: ++
16:42:45 <tbarron> but I'm not objecting to tryinig to keep driver-fixes up to date when there is a correspondiing stable branch either.
16:42:51 <jungleboyj> Anyway, lets not bikeshed on this further.
16:43:14 <jungleboyj> #agreed No core changes to driverfixes branches
16:43:40 <jungleboyj> #agreed security and critical drivers fixes should be backported to driverfixes
16:43:50 <jungleboyj> Any disagreements there?
16:44:08 <tbarron> only when there is a corresponding stable branch, right?
16:44:08 <jgriffith> jungleboyj but I want it to be fuscia in color!
16:44:31 <jungleboyj> jgriffith: We are color blind.  Why do you care?
16:44:52 <jungleboyj> tbarron: I wouldn't say that, any time the backport makes sense.
16:44:54 <jgriffith> jungleboyj because somebody who's not may tell me they like the color :)
16:45:04 <jungleboyj> jgriffith: :-p
16:45:37 <jungleboyj> tbarron:  But obviously when there is a corresponding stable branch it is something we should enforce.
16:45:40 <jungleboyj> Make sense>?
16:46:11 <tbarron> sorry but now I think you're back to introducing risk when someone cherry-picks a driver fix
16:46:35 <jungleboyj> tbarron:  Ok, lets chat about this in the channel afterwards.
16:46:41 <tbarron> because of the issue jgriffith pointed out, you have a sec/crit fix that doesnt' work right in older release
16:46:47 <tbarron> and it's not tested
16:47:22 <jungleboyj> I think we are going around in circles.
16:47:40 * jgriffith has left the building
16:47:58 <jungleboyj> Lets move on for now.  I think what we have agreed on is good.  Should make sure it is documented somewhere.  We can further discuss details after the meeting.
16:48:23 <jungleboyj> So diablo_rojo  said she is not ready to talk about the config consolidation yet.  I will carry that forward to next week.
16:48:37 <jungleboyj> #topic Dynamic Reconfiguration
16:49:04 <jungleboyj> Did anyone try using SIGHUP with cinder not running in screen to see what happened?
16:49:38 * jungleboyj hears crickets
16:50:19 <jungleboyj> Ok, so I tried this with devstack running in systemd and I saw that c-vol reacted to it but didn't re-read the config file.
16:50:47 <jungleboyj> There was some version pinning that was released but it didn't appear to do anything else.
16:50:51 <hemna> chirp
16:50:55 <jungleboyj> So, I think we have more work to do in this space.
16:51:17 <e0ne> I tried to do it with newton or ocata in the past. not all config options were re-read after SIGHUP
16:51:31 <jungleboyj> eharney:  You had suggested re-addressing the spec giving the changes that have happened since we originally wrote it.
16:51:36 <e0ne> I didn't have a chance to test with master last week
16:51:57 <jungleboyj> I tested using the environment from our Upstream Institute.
16:52:17 <eharney> i'm interested in this, just haven't had a chance to poke at it yet
16:52:25 <jungleboyj> eharney: e0ne  diablo_rojo  Thoughts on how to proceed?
16:52:47 <eharney> i think we should still proceed down the path that SIGHUP should reload config
16:53:09 <geguileo> eharney: +1
16:53:16 <jungleboyj> eharney: +1
16:53:24 <geguileo> I agree SIGHUP reload config, not restart the whole service, right?
16:53:32 <jungleboyj> geguileo: ++
16:54:08 <eharney> is there a bug on this?
16:54:08 <tommylikehu> +1
16:54:15 <jungleboyj> So, lets do this.  Hate to do this, but lets go back, look at the spec and update it based on that knowledge.
16:54:22 <jungleboyj> eharney:  Good question.  Not that I know of.
16:54:37 <jungleboyj> eharney: Do we want to handle it as a bug and abandon the spec?
16:54:56 <eharney> nah, spec is fine for now
16:55:17 <e0ne> #link https://github.com/openstack/oslo.service/blob/b20bd84cbe6db7c6e1cb829fa4700b42fba8f604/oslo_service/service.py#L190
16:55:26 <tbarron> I think the point of a bug would be to have a reproducer with the config that isn't getting reloaded
16:55:48 <e0ne> we have to figure out why cinder doesn't use code approach above ^^
16:55:50 <jungleboyj> diablo_rojo:  Can we go back to the spec, make sure it matches the work and keep going forward?
16:55:52 <diablo_rojo> I will make those updates today.
16:55:54 <tbarron> not bug vs spec
16:55:59 <diablo_rojo> jungleboyj, yes
16:56:10 <tommylikehu> tbarron:  +1
16:56:27 <jungleboyj> tbarron: I will make sure we include in the spec the process that should work.
16:56:58 <jungleboyj> diablo_rojo:  Thanks.  So, I think we have path forward there.  Thank you.
16:57:18 <jungleboyj> #action diablo_rojo  to update spec to ensure that SIGHUP causes reload of config.
16:57:32 <jungleboyj> Ok, I want to make sure we get to the last topic quickly in 3 minutes.
16:57:45 <jungleboyj> #topic HA A/A Certification Criteria
16:57:55 <jungleboyj> geguileo:  Have we made any progress defining this?
16:58:09 <geguileo> jungleboyj: I'm trying to close the multipath stuff
16:58:21 <geguileo> jungleboyj: just got my hands on a backend that does the discovery
16:58:35 <geguileo> I should start working on that in 1 or 2 weeks
16:58:42 <jungleboyj> geguileo: Ok.  So, looks like this is something that may hang over into Queens?
16:58:56 <jungleboyj> geguileo:  Ok, so may still get traction yet in Pike?
16:59:09 <geguileo> I should be able to get a good part of it done in P
16:59:19 <geguileo> but it may drag on to Q
16:59:30 <jungleboyj> geguileo:  Ok.  Cool.  Just wanted to make sure it wasn't lost.
16:59:39 <jungleboyj> patrickeast:  You still on the hook to verify it?
16:59:56 <patrickeast> Sure
16:59:59 <jungleboyj> I am hoping I will have a driver to run through the process with in Queens as well.
16:59:59 <geguileo> jungleboyj: I've been dying to get back to it  :-(
17:00:16 <jungleboyj> geguileo: Ok.  We have all priorities to juggle.
17:00:37 <jungleboyj> It sounds like we still have a plan and just need to keep executing.  Lets check back in a few weeks .
17:00:47 <jungleboyj> And with that, time is up!
17:01:02 <jungleboyj> Lets take additional discussion over to the Cinder channel.
17:01:07 * jungleboyj is looking at tbarron
17:01:13 <jungleboyj> Thank you everyone for coming.
17:01:19 <jungleboyj> #endmeeting