16:00:27 <jungleboyj> #startmeeting Cinder
16:00:27 <openstack> Meeting started Wed Jun 21 16:00:27 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:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:32 <openstack> The meeting name has been set to 'cinder'
16:00:43 <jungleboyj> ping 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
16:00:43 <jungleboyj> sivn
16:00:48 <e0ne> hi
16:00:48 <xyang1> Hi
16:00:56 <geguileo> hi!
16:01:00 <tommylikehu> hi
16:01:01 <scottda> hi
16:01:07 <jungleboyj> Sean  has asked me to cover today.  :-)
16:01:13 <wxy> hello
16:01:14 <patrickeast> Hey
16:01:37 <diablo_rojo> Hello
16:01:45 * smcginnis is not really here, will catch up later
16:01:49 <tbarron> hi
16:01:53 <cFouts> hi
16:02:13 <jungleboyj> smcginnis:  Is more here than expected.  ;-)
16:02:35 <jungleboyj> Ok, so it looks like we have a good group here to start with.
16:02:45 <jungleboyj> #topic Announcements
16:03:21 <jungleboyj> The usual reminder to please take a look at the review priority for the release:  https://etherpad.openstack.org/p/cinder-spec-review-tracking
16:03:25 <jungleboyj> #link https://etherpad.openstack.org/p/cinder-spec-review-tracking
16:04:04 <jungleboyj> smcginnis:  and I went through the reviews from last month's bug smash and worked to get as many things merged as possible.
16:04:35 <diablo_rojo> jungleboyj, did our tagging bugs ahead of time help them out?
16:05:12 <jungleboyj> Also went through all the spec tracking items and got them updated.
16:05:20 <jungleboyj> diablo_rojo:  I think that worked well.
16:05:23 <Swanson> hi
16:05:54 <jungleboyj> diablo_rojo:  I think it is a practice we should continue to do.  It looked like that was used as a starting point and then some other items were added.
16:05:59 <diablo_rojo> Cool, we will have to keep that in mind for tagging bugs. Might even want to consider a monthly bugsmash day like other projects do. I
16:06:07 <jungleboyj> Last time I checked there were about 19 bugs that were addressed and closed.
16:06:08 <diablo_rojo> jungleboyj, jinx
16:06:23 <jungleboyj> diablo_rojo:  Jinx.  ;-)
16:06:51 <jungleboyj> I have been trying to coordinate with smcginnis  once a month to go through and clean up bugs, etc.  So, yeah, we are on the same page there.
16:07:27 <jungleboyj> I think people have been doing a good job of looking at reviews from what I have seen.  Thank you.
16:08:07 <jungleboyj> Also, one other announcement, I marked all the proposed drivers that missed the Pike deadline with a -2 just so we don't accidentally merge anything there.
16:08:14 <lhx_> hi
16:08:25 * jungleboyj wasn't very popular for that.
16:08:34 <jungleboyj> @!h
16:08:34 <pewp> jungleboyj (/ .□.) ︵╰(゜Д゜)╯︵ /(.□. )
16:08:51 <jungleboyj> So, I think that was all I had for announcements.
16:09:16 <jungleboyj> #topic Add new config option in volume driver class
16:09:22 <jungleboyj> guyk:  You here?
16:09:33 <guyk> jungleboyj: yes
16:09:45 <jungleboyj> Take it away.
16:10:44 <guyk> this idea was proposed by Mike Perez in one of my patch. It is to create and use generic variable in the volume driver.
16:11:16 <geguileo> what kind of generic variable? r:-??
16:11:17 <guyk> And replace current and different config options used in the drivers
16:11:30 <lhx_> guyk, what's the patch?
16:11:42 <geguileo> so consolidation of configuration variables
16:11:42 <guyk> geguileo: set the ip address and the port of the volume backend
16:11:52 <guyk> lhx_: https://review.openstack.org/#/c/457426/3
16:11:59 <lhx_> thx :)
16:12:33 <jungleboyj> Oh yes, we have had this discussion before.
16:12:41 <e0ne> in general, I like this idea
16:12:46 <jungleboyj> #link https://review.openstack.org/#/c/457426/3
16:12:55 <geguileo> wouldn't it be better to support a list
16:13:08 <jgriffith> geguileo +1
16:13:19 <e0ne> geguileo: +1
16:13:27 <tommylikehu> address list?
16:13:39 <geguileo> problem is that each address could have a different port
16:13:47 <geguileo> unlikely, but possible
16:14:12 <jungleboyj> geguileo:  So that is concern with the specific patch.
16:14:18 <jgriffith> guyk just to be clear, we do already have this option FWIW
16:14:19 <jgriffith> san_ip
16:14:28 <jgriffith> just some don't use it
16:14:32 <jungleboyj> I think we want to first address consolidation?
16:14:37 <jungleboyj> jgriffith:  ++
16:14:45 <jgriffith> I'm sort of leary about introducing yet another "common" config option that people choose to not use
16:15:13 <guyk> jgriffith: yes some of the drivers don't use it because their backend doesn't use the san protocol so they rename it
16:15:16 <jgriffith> if we do want a better name that's totally cool with me, but we should deprecate the old one and make it clear we expect it to be used
16:15:29 <jgriffith> guyk there's no such thing as a 'san' protocol
16:15:38 <jgriffith> guyk san just means it's an external device
16:15:38 <e0ne> jgriffith: +1
16:15:45 <xyang2> we have some "common" config options in san.py that some drivers have been using: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/san.py#L42
16:15:52 <jgriffith> guyk and that you're accessing it via API on the 'san_ip' address
16:16:47 <guyk> jgriffith: yes, made a mistake
16:17:31 <jgriffith> In other words, it's the name game IMO; and if people want to play the name game that's fine by me; but be very clear that we already have a generic config option, this change should be a proposal to rename the existing san_ip
16:17:46 <jgriffith> we'll still have the problem we have now of 1/2 the devices not using it though :)
16:18:04 <geguileo> jgriffith: I agree that we have 2 topics: name game and adoption
16:18:20 <geguileo> For adoption we could go through deprecating all individual configuration options
16:18:27 <geguileo> to force drivers to update and consolidate
16:18:41 <geguileo> though it may not be a very nice thing to do  :-
16:18:43 <geguileo> (
16:18:48 <jgriffith> geguileo yeah
16:19:00 <jgriffith> geguileo there's a broader effort there if we wanted to consider it
16:19:23 <jgriffith> geguileo there's pretty extensive duplication of config options and exception classes...
16:19:34 <jgriffith> anyway; that's a bit of a rat-hole probably :)
16:19:37 <diablo_rojo> I think consolidation is a good idea
16:19:52 <jgriffith> and geguileo yes, it's sort of not nice to do probably
16:20:02 <jgriffith> but I'm not a nice person.. so... there's that :)
16:20:07 <geguileo> lol
16:20:23 <geguileo> It would be best if we could consolidate all/most of the common options
16:20:30 <jgriffith> back to guyk 's patch though
16:20:34 <geguileo> but then we would really need to make sure they are adopted
16:20:49 <jgriffith> there is a broader question, but what do we want to do with his proposal to start with?
16:20:57 <jgriffith> geguileo +1
16:21:49 <jgriffith> bueller.... bueller....
16:21:50 <jungleboyj> geguileo:  I agree but that is going to require a large commitment and planning to implement it.
16:21:57 <geguileo> should we decide if we want to go with the deprecation of other options?
16:22:14 <diablo_rojo> geguileo, do it in waves? A few at a time?
16:22:18 <geguileo> because as I see it, without adoption this will be another san_ip
16:22:27 <jungleboyj> geguileo: Agreed.
16:22:27 <jgriffith> diablo_rojo the problem is that never seems to work for us :(
16:22:34 <jungleboyj> jgriffith: ++
16:22:39 <jgriffith> diablo_rojo we set out to do things that way rather often and never finish
16:22:42 <geguileo> diablo_rojo: yeah, but the only way to force it is if we deprecate the options
16:22:45 <diablo_rojo> jgriffith, touche
16:22:46 <jungleboyj> I think it would need to be all at once.
16:22:50 <geguileo> diablo_rojo: and then remove them
16:23:01 <jgriffith> diablo_rojo although it is an optimal approach (when it works)
16:23:16 <diablo_rojo> So deprecating  few at a time is not a good idea?
16:23:19 <jgriffith> keep in mind you have to deal with upgrades too
16:23:21 <winston-d> it's migration from individual cfg opts to common opts instead of adoption
16:23:31 <geguileo> diablo_rojo: I would go with deprecating them all in one patch
16:23:31 <diablo_rojo> How many approx need to be deprecated?
16:23:38 <diablo_rojo> geguileo, that works too :)
16:23:38 <winston-d> adoptions sounds like you had a choice of not to
16:23:46 <jgriffith> winston-d good point!
16:24:01 <winston-d> but it seems not adopting is not allowed here.
16:24:01 <jungleboyj> geguileo:  ++
16:24:20 <jgriffith> so here's an excercise for folks that are interested... generate a current sample.conf
16:24:23 <geguileo> winston-d: if we want this to be really usefull yeah, it wouldn't be optional
16:24:37 <jungleboyj> geguileo:  Agreed.
16:25:06 <diablo_rojo> geguileo, +1
16:25:21 <geguileo> so we agree to force the migration to common config options?
16:25:26 <cFouts> Does the upgrade mean that currently installed cinder.conf files will need to be updated manually?
16:25:27 <jungleboyj> jgriffith:  I think I know where you are going.
16:25:38 <jgriffith> jungleboyj :)
16:25:43 <jungleboyj> cFouts: I think it might.
16:25:44 <diablo_rojo> geguileo, yes?
16:25:54 <winston-d> geguileo: i agree.
16:25:56 <jgriffith> cFouts yup, that's the problem
16:26:03 <xyang2> to support backward compatibility, the old options will have to be supported for many releases
16:26:05 <cFouts> yeah, it is
16:26:09 <jungleboyj> geguileo:  I don't want to go that far yet.
16:26:31 <jungleboyj> Let me make a proposal before we charge forward.
16:26:33 <winston-d> xyang2: yeah, :(
16:26:47 <jungleboyj> I think we need to do what jgriffith started to propose.
16:27:02 <jungleboyj> Generate a config file and take inventory of the options.
16:27:13 <xyang2> so we'll end up with more options than we wanted
16:27:14 <jungleboyj> See how many options this may actually impact.
16:27:18 <winston-d> cfg opts is also considered as  user-facing interface
16:27:37 <jungleboyj> Once we have an idea of the impact we can make a plan going forward.
16:27:45 <xyang2> winston-d: +1
16:28:05 <jungleboyj> Deprecate the old ones.  Do a release accordingly.
16:28:12 <jungleboyj> Document the upgrade path to help people.
16:28:14 <Nil_> this metting , today it's running...
16:28:34 <jungleboyj> Thoughts on this proposal?
16:28:55 <xyang2> jungleboyj: do you think people read document?:)
16:29:10 <xyang2> jungleboyj: you'll get a support call first:)
16:29:16 <e0ne> xyang2: the will once something will fail
16:29:26 <lhx_> so all san options will be deprecate too?
16:29:31 <jungleboyj> xyang2:  True enough.
16:29:46 <jungleboyj> lhx_:  That scares me.  A lot of people use that.
16:31:04 <jungleboyj> Well, that stopped the discussion.
16:31:17 <jungleboyj> Everyone is looking through the sample config?
16:31:55 <jgriffith> jungleboyj :)
16:32:01 <diablo_rojo> jungleboyj, I think people lost interest when it started seeming less imminent
16:32:06 <diablo_rojo> Lol :)
16:32:11 * jungleboyj is suddenly very lonely
16:32:18 <jgriffith> so I think if this is an approach we want to take the starting point would be to use what we have first
16:32:39 <jungleboyj> jgriffith:  Can you say more about that?
16:32:43 <jgriffith> ie consolidate on the existing things like san_ip etc, find as many as we can without introducing new ones
16:32:53 <jungleboyj> jgriffith: ++
16:32:55 <winston-d> yesterday I tried 'tox -egenconfig' on master branch tip, it's not working. :( but probably that's just me.
16:33:09 <jgriffith> if we just go in and introduce a whole new set of "new" options we're just making the problem worse
16:33:09 <jungleboyj> winston-d:  :-(  Yikes.
16:33:20 <jungleboyj> jgriffith: Totally agree.
16:33:25 <jgriffith> even if it's temporary.. and remember temporary is like at least 2 releases
16:33:48 <xyang2> jgriffith: +1
16:34:08 <lhx_> is there a user survey of new options? not sure user care about the new ones.
16:34:17 <e0ne> :(
16:34:31 <jgriffith> winston-d I just ran it succesfully.. so maybe refresh on your tox env?
16:34:58 <xyang2> lhx_: my guess is user wants the existing options they've already configured to continue to work:)
16:34:59 <jgriffith> Look.. here's the thing; our config file is 4,859 lines!!!!
16:35:01 <jgriffith> That's stupid
16:35:13 <diablo_rojo> Agreed
16:35:15 <jungleboyj> diablo_rojo:  This can't be an imminent thing as it directly impacts users.
16:35:19 <winston-d> jgriffith: yup, i should try with new virtual env.
16:35:22 <jungleboyj> Need to be careful here.
16:35:25 <xyang2> lhx_:  if an existing option stops working, they will get upset
16:35:27 <jgriffith> granted that's all the blank-lines and comments, but still
16:35:34 <jgriffith> it's not exactly consumable
16:35:51 <jungleboyj> Right.
16:36:13 <diablo_rojo> jungleboyj, I wasn't saying go for it :) I just mean people are less interested when its not a threat.
16:36:27 * jgriffith hands folks a copy of War and Peach and says.. "here's your example, all the answers are in there"
16:36:36 <jgriffith> good luck
16:36:37 <diablo_rojo> jgriffith, lol
16:36:48 <jungleboyj> I would like to know how much consolidation will change that.
16:36:49 <jgriffith> haha... "Peach"
16:36:51 <diablo_rojo> 'May the odds be ever in your favor'
16:36:54 <lhx_> xyang2, haha, +1
16:36:56 <jungleboyj> jgriffith:  *Laughing*
16:37:07 <jungleboyj> I love War and Peach
16:37:43 <jungleboyj> So we agree we have a problem here.
16:37:56 * jungleboyj wonders if there is support group for config option addiction.
16:38:45 <lbragstad> o/ My name's Lance and it's been 187 days since I've added a configuration option to my project
16:39:03 <jungleboyj> Hi Lance ...
16:39:21 <jungleboyj> o/ My name's Jay and I cried while writing a config file once.
16:39:56 <jgriffith> haha
16:39:57 <bswartz> grep -v '^$\|^\s*\#' /etc/cinder/cinder.conf
16:40:11 <bswartz> that's not profanity it does something useful
16:40:22 <jungleboyj> Anyway, so, it has gotten quiet again.  Do we have anyone who would be willing to take the config file and get an idea of how many options could  be consolidated to use existing options.
16:40:50 <jgriffith> bswartz thanks for that regex foo
16:41:17 <jungleboyj> I think that would be the first step and then re-address discussion in the next meeting.
16:41:23 <diablo_rojo> *crickets*
16:41:33 <diablo_rojo> I can put it on my backlog to take a look.
16:41:57 <jungleboyj> diablo_rojo:  Would be good to have someone familiar with config options do it.
16:42:02 <diablo_rojo> :D
16:42:40 <jungleboyj> Will you have a chance to at least get an idea of how many duplicates there are before next week?
16:43:36 <diablo_rojo> Maybe, I can do an introductory foray to get a general idea of a lot- little, etc.
16:43:49 <jungleboyj> diablo_rojo:  Ok, cool.
16:44:02 <jungleboyj> #agreed We need to look at our crazy list of config options.
16:44:05 <diablo_rojo> I will see if I can get a more exact number, but I suspect it will be tedious and time consuming as hell.
16:44:25 <jgriffith> diablo_rojo you're suspicion is correct :)
16:44:30 <jungleboyj> #action diablo_rojo  will try to get an idea of how many options could possibly be consolidated to existing items
16:44:38 <jgriffith> which is why we have the sprawl we have
16:44:55 <jungleboyj> #agreed We should start by using existing options rather than adding new ones.
16:45:12 <jungleboyj> Those agreements and action look good?
16:45:40 <diablo_rojo> jgriffith, hence my unease at accepting the task lol
16:45:52 <diablo_rojo> jungleboyj, yeah looks fine to me
16:46:07 <jungleboyj> #action Jay to add to agenda for an update next week.
16:46:14 <xyang2> diablo_rojo: I usually ask driver author to use options in san.py, but sometimes they argue that they need to use a different option in their driver for some reason.  Just FYI
16:46:19 <jgriffith> diablo_rojo too late, it's been registered in IRC.... you're DOOOOMED
16:46:20 <jgriffith> :)
16:46:40 <jungleboyj> With a number/impact in mind we can put together a plan.
16:46:42 <e0ne> 15 mins reminder
16:46:48 <winston-d> I guess cinder only cfg opts are only < 50% of all 4,859 lines?
16:46:51 <diablo_rojo> jgriffith, thanks for the vote of confidence ;)
16:46:52 <jungleboyj> diablo_rojo:  You are good at those details.
16:47:07 <diablo_rojo> jungleboyj, not sure if that is a compliment or not lol
16:47:12 <jungleboyj> Ok.  Lets wrap this up for this meeting.
16:47:13 <diablo_rojo> xyang2, noted :)
16:47:16 <jungleboyj> diablo_rojo:  :-)
16:47:18 <winston-d> many shall be library introduced opts.
16:47:38 <jungleboyj> guyk: Sorry, we kind of hijacked things here.
16:47:39 <jgriffith> diablo_rojo I have confidence in you, I just feel bad for you :)
16:48:04 <diablo_rojo> jgriffith, can't be any worse than standing in front of thousands of people and a demo not working ;)
16:48:06 <jungleboyj> guyk: So, I think we want to hold on your patch at the moment and look at this before going forward.  That ok?
16:48:09 <guyk> jungleboyj: it is ok
16:48:22 <jungleboyj> Ouch ...
16:48:27 <jungleboyj> guyk:  Ok.  Thanks.
16:49:15 <jungleboyj> #topic Dynamic Reconfiguration
16:49:21 <jungleboyj> diablo_rojo: More config discussion.
16:49:29 <diablo_rojo> Indeed.
16:50:00 <diablo_rojo> It appears that there is a nontrivial section of Cinder cores that think this is a bad idea- especially for multinode setups
16:50:16 <diablo_rojo> And I am gravitating towards that school of thought
16:50:19 <e0ne> diablo_rojo: could you please share a link to the patch?
16:50:30 <diablo_rojo> e0ne, sure one sec
16:50:38 <eharney> is there a short summary of the reason it's tough for multinode/HA?
16:51:04 <jungleboyj> eharney:  ++
16:51:05 <diablo_rojo> #link https://review.openstack.org/#/c/446132/
16:51:18 <e0ne> diablo_rojo: thanks
16:51:27 <jungleboyj> Sad to see the discussion go this way.
16:51:28 <diablo_rojo> eharney, basically it gets messy fast because processes don't end all at the same time.
16:51:46 <winston-d> eharney: synchronziation between multi-nodes is hard?
16:51:48 <jungleboyj> bswartz:  Manila supports this, doesn't it?
16:51:57 * e0ne still thinks that SIGHUP signal will be always a good potion
16:52:07 <eharney> ?
16:52:35 <e0ne> s/potion/option
16:52:36 <diablo_rojo> e0ne, agreed, especially if CInder actually inherits from oslo's services and its handled how it looks to be written.
16:52:41 <bswartz> jungleboyj: not yet, we want it
16:52:56 <jungleboyj> bswartz:  Ah, ok.  I had been told you have it.
16:53:00 <winston-d> e0ne: potion is better, we need magic here.
16:53:02 * diablo_rojo votes to wait till Manila has solved it like we do with most our problems ;)
16:53:04 <geguileo> diablo_rojo: afaik current SIGHUP will shutdown everything in Cinder afaik
16:53:08 <bswartz> jungleboyj: maybe we inherited it?
16:53:15 <e0ne> winston-d: :)
16:53:21 <bswartz> or maybe I'm less informed than you >_<
16:53:25 <xyang2> bswartz: it's not in cinder yet:)
16:53:45 * jungleboyj is confused.  I though the point of this work was to get SIGHUP working.
16:53:49 <e0ne> geguileo: yes, but we can implement graceful shutdown if it's not implemented yet
16:53:58 <jungleboyj> bswartz:  I doubt it.
16:54:04 <geguileo> e0ne: we have graceful shutdown implemented there
16:54:16 <xyang2> bswartz: I remember we talked about this in some manila meetings, referencing cinder
16:54:24 <geguileo> e0ne: but it still needs to shutdown, which may take a loooong time
16:54:49 <e0ne> geguileo: it's another issue we should care about
16:55:09 <geguileo> the long time?
16:55:34 <eharney> so what's the core reason that we can't implement this?  it's hard?
16:56:14 <tbarron> winston-d: diablo_rojo I'm trying to understand what is different in the multi-node case than when one shuts down service on a single node, changes config, and brings it up while other nodes are running.
16:56:24 <jungleboyj> eharney:  That is my fear.
16:56:24 <tbarron> winston-d: diablo_rojo are we contrasting this with:
16:56:40 <tbarron> shut down service on all nodes, update config, start on all nodes?
16:56:57 <jungleboyj> tbarron: Yeah, I don't understand why that is more dangerous that what we currently do.
16:57:16 <diablo_rojo> eharney, well yes, but from looking through the code, it looks like it should work already. Some people have said it works for them and others have said it does not. I personally haven't been able to figure out why that is.
16:57:16 <tbarron> that last is probably safest, but ...
16:57:23 <tbarron> just trying to understand the issue
16:58:08 <tbarron> and some config options would be safe, whereas some may have problems w/o synchronization across nodes I guess.
16:58:12 <geguileo> If we are talking about using SIGHUP to make cinder restart itself and reload the new config options
16:58:17 <geguileo> that's been working for a long time
16:58:47 <smcginnis> Just shuts down for me.
16:58:49 <diablo_rojo> geguileo, right, that should work but some people say it doesn't?
16:58:51 <jungleboyj> diablo_rojo:  I think that had to do with whether you were running Cinder in Devstack/screen vs. using systemd
16:59:05 <geguileo> smcginnis: on which env? devstack? r:-??
16:59:11 <tbarron> devstack tests don't count :)
16:59:22 <jungleboyj> smcginnis: In devstack ?
16:59:32 <geguileo> smcginnis: did you send SIGHUP to the parent process or to all of them?
16:59:34 <diablo_rojo> jungleboyj, that was part of the confusion, but I thought some people also ran it with their own drivers too
16:59:51 <smcginnis> geguileo: I thought I tried on actual deployment, but can't remember for sure now. Parent process.
16:59:57 <tbarron> for multinode unless you have a better multinode devstack than I've been able to do
17:00:04 <e0ne> geguileo, smcginnis: SIGHUP doesn't work on devstack with screen
17:00:06 <eharney> there was some difference in how services behave when running on a terminal (i.e. in screen) that i looked into a while back, so yeah, devstack tests may not behave like normal services
17:00:17 <jungleboyj> Anyway, we have run out of time.
17:00:20 <geguileo> smcginnis: I tried it while preparing for my Barcelona presentation and it worked for me back then
17:00:30 <tbarron> screen is dead for devstck anyways
17:00:34 <jungleboyj> I think we need to finish this discussion.
17:00:42 <geguileo> e0ne: devstack doesn't use devstack anymore, right?
17:00:43 <smcginnis> geguileo: OK, could be why I was having issues with this too: https://review.openstack.org/#/c/464028/
17:00:46 <smcginnis> Times up.
17:00:54 <bswartz> screen is dead, long live screen!
17:00:57 <diablo_rojo> jungleboyj, yes, cause we have had this part of the discussion several times and made no progress :)
17:00:58 <tbarron> but there's a good question about incompatability across nodes
17:01:05 <e0ne> geguileo: yes, it switched to systemd by default
17:01:05 <jungleboyj> Can we get people to verify what they see working or not and we cna wrap up discussion next week?
17:01:24 <diablo_rojo> Yes please
17:01:31 <eharney> i think we need to do another round on the spec...
17:01:33 <jungleboyj> diablo_rojo:  Ok.  We will go that way.
17:01:38 <diablo_rojo> eharney, :P
17:01:48 <geguileo> smcginnis: that's something I haven't explored but could be interesting
17:01:48 <tbarron> across three apis running concurrently, or if an option affects the rpc between services
17:02:06 <jungleboyj> #action Cores to try using sighup this week and then we will decide what to do in next week's meeting.
17:02:31 <jungleboyj> Ok, we need to free up the meeting room.
17:02:32 * tbarron watches jungleboyj SIGTERM this meeting
17:02:35 <winston-d> tbarron: got disconnected just now, will catch up with you in cinder
17:02:40 <jungleboyj> Thanks for the good discussion!
17:02:43 <bswartz> SIGKILL!
17:02:44 <e0ne> see you next week!
17:02:52 <jungleboyj> #endmeeting