16:00:01 <smcginnis> #startmeeting Cinder
16:00:01 <openstack> Meeting started Wed Mar 23 16:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'cinder'
16:00:13 * DuncanT waves
16:00:14 <smcginnis> Courtesy ping dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang tbarron scottda erlon rhedlind jbernard vincent_hou kmartin patrickeast sheel dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu
16:00:17 <Swanson> Hello
16:00:20 <geguileo> Hi!
16:00:20 <eharney> hi
16:00:21 <jseiler> hi
16:00:21 <fernnest> hello
16:00:24 <baumann> Hello!
16:00:25 <sheel> hello all
16:00:25 <mtanino> hi
16:00:26 <jgregor> Hello!
16:00:30 <diablo_rojo> Hello :)
16:00:38 <hemna> hi
16:00:41 <patrickeast> Hey
16:00:45 <jgriffith> hey
16:00:45 <dulek> Hi
16:00:47 <Yogi1> Hello
16:00:50 <scottda> hhi
16:01:07 <smcginnis> #topic Announcements
16:01:16 <adrianofr_> hi
16:01:22 <jungleboyj> What up!
16:01:23 <bswartz> .o/
16:01:27 <smcginnis> We're getting really close to the end of the Mitaka cycle.
16:01:42 <smcginnis> We have a few changes queued and some translations imported.
16:02:00 <smcginnis> I plan on cutting the (final?) RC-2 release tomorrow.
16:02:19 <smcginnis> Unless something major comes up, that should be what goes out an April 8th.
16:02:30 <tbarron> hi
16:02:31 <jungleboyj> It will be such a sweet release!
16:02:41 <jgriffith> smcginnis: we'll want to wait on the delete thing I talked about this morning
16:02:50 <jgriffith> ie wait to cut RC2
16:02:59 <smcginnis> jgriffith: OK, will watch for that.
16:03:20 <smcginnis> Notice to everyone that I will be on vacation starting this Friday through next week.
16:03:41 <smcginnis> I'll have my laptop with me, so I will still be able to do the release.
16:03:43 <Swanson> Good timing.
16:03:46 <smcginnis> But I won't be around as much.
16:03:54 <jgriffith> smcginnis: Ummm... that's weird... "YOU" are taking a vacation!
16:03:59 <jgriffith> I didn't think you did that sort of thing!
16:04:01 <smcginnis> Swanson: About as good as it could.
16:04:06 <smcginnis> :)
16:04:14 <e0ne> hi
16:04:19 <smcginnis> We'll see how much I actually do.
16:04:33 <smcginnis> Hopefully I resist the temptation to get out the laptop.
16:04:34 <smcginnis> :)
16:04:40 <jgriffith> smcginnis: we'll just kick-ban you from IRC and disable your gerritt account
16:04:45 <smcginnis> :D
16:05:07 <e0ne> :)
16:05:08 <dulek> jgriffith: What about Launchpad? No more bug targetting!
16:05:19 <jgriffith> dulek: removing him now :)
16:05:32 <smcginnis> Looking forward, we need to start thinking about N.
16:05:32 <dulek> jgriffith: He said Friday… ;)
16:05:40 <smcginnis> I added a new etherpad for spec tracking.
16:05:40 <jgriffith> dulek: maybe we should just steal his laptop
16:05:53 <smcginnis> Hoping to use this to start shaping up things for the summit.
16:06:01 <diablo_rojo> jgriffith: I can handle that ;)
16:06:05 <smcginnis> jgriffith: I have multiple! :P
16:06:19 <e0ne> smcginnis: what about removin xml api? :) it's only -6500 LoC
16:06:22 <smcginnis> #link https://etherpad.openstack.org/p/cinder-spec-review-tracking Spec tracking.
16:06:23 <sheel> smcginnis: we have multiple guys
16:06:26 * jungleboyj pictures diablo_rojo wresting with smcginnis over a laptop.  :-)
16:06:26 <smcginnis> e0ne: +1
16:06:40 <smcginnis> e0ne: Will be nice to get that all cleaned up.
16:06:46 <e0ne> I've rebased my patch today
16:06:59 <vincent_hou> e0ne: why to remove it?
16:07:03 <smcginnis> Not much in that etherpad link yet, but we can start working on that.
16:07:10 <e0ne> vincent_hou: we didn't test it
16:07:16 <e0ne> vincent_hou: does it work?
16:07:47 <vincent_hou> I remember some of my colleagues used t spend a lot of time testing and getting them it.
16:07:50 <e0ne> vincent_hou: btw, nova and neuton removed xml api few releases ago
16:07:53 <sheel> smcginnis: only Spec-less blueprints?
16:08:09 <smcginnis> If folks could start reviewing the specs out there and commenting, it would be nice to have some of that in good condition for the summit.
16:08:13 <smcginnis> Or merged already.
16:08:18 <smcginnis> sheel: And specs.
16:08:30 <sheel> smcginnis: oks
16:08:42 <smcginnis> sheel: I just wanted a placeholder for the few blueprints that come across that need a little discussion but aren't big enough to need a spec.
16:09:10 <sheel> smcginnis: ok, sounds good
16:09:17 <smcginnis> #topic Any more urgent backport fixes for the release
16:09:21 <smcginnis> On that note...
16:09:28 <smcginnis> DuncanT: I think you added this.
16:09:35 <smcginnis> DuncanT created an etherpad for tracking.
16:09:40 <smcginnis> Hasn't been much there so far.
16:09:54 <smcginnis> #link https://etherpad.openstack.org/p/mataka-rc-backports-needed
16:10:02 <DuncanT> I did add it, mostly as a heads up
16:10:11 <smcginnis> If there is something you think needs to make it in M yet, please add it there.
16:10:13 <diablo_rojo> DuncanT: -1 for spelling ;)
16:10:20 <smcginnis> ;)
16:10:26 <vincent_hou> I am working on two patches, I guess need the backport.
16:10:33 <smcginnis> vincent_hou: Which ones?
16:10:35 <vincent_hou> They are ready for review.
16:10:41 <jungleboyj> vincent_hou: Links?
16:11:10 <vincent_hou> https://review.openstack.org/#/c/292570/
16:11:20 <vincent_hou> https://review.openstack.org/#/c/292608/
16:11:34 <smcginnis> Keep in mind, we are in hard string freeze so we should try to limit backports that have public facing strings.
16:12:08 <jungleboyj> vincent_hou: I think those can be backported to our driver after the release.
16:12:14 <jungleboyj> Don't need to hold up for those.
16:12:17 <jungleboyj> smcginnis: Agree?
16:12:22 <smcginnis> vincent_hou: I'll take a look, but I think those may need to wait.
16:12:52 <vincent_hou> ok
16:13:01 <smcginnis> Really only critical core fixes at this point unless they are really small, self-contained changes.
16:13:41 <smcginnis> #topic Some operations pass even if volume service is disabled
16:13:50 <smcginnis> sheel: I think we can talk about this now.
16:14:05 <smcginnis> #link https://bugs.launchpad.net/cinder/+bug/1555938
16:14:07 <openstack> Launchpad bug 1555938 in Cinder "Create snapshot, create volume from snapshot or clone a volume still can succeed even the cinder-volume service is disabled" [Low,Confirmed] - Assigned to aditi sharma (adi-sky17)
16:14:12 <sheel> smcginnis: ohk, but i wanted to have some specific persons in it for discussino
16:14:33 <jgriffith> smcginnis: ahh... interesting
16:14:43 <smcginnis> sheel: OK, no problem. We can defer if you would prefer.
16:14:56 <smcginnis> jgriffith: Yeah
16:14:56 <sheel> smcginnis: ok actually this was about how we should go with calls which works ok even if volume service is disabled
16:15:12 <jgriffith> smcginnis: sheel so it's pretty straight-forward,,, did you have questions about fixing it?
16:15:20 <smcginnis> I found it very surprising the number of tempest tests pass when my driver didn't even get loaded.
16:15:55 <jgriffith> smcginnis: ummm... ok, that's frightening
16:16:00 <sheel> jgriffith: yep, there could be other calls which do not pass through scheduler like backup operations
16:16:03 <e0ne> smcginnis: it could be related to other drivers too
16:16:09 <hemna> that's not good at all
16:16:11 <hemna> wtf
16:16:28 <e0ne> hemna: +1
16:16:33 <jgriffith> sheel: so we talked briefly in Tokyo (and Vancouver) about this
16:16:55 <jgriffith> sheel: we should probably route everything through the scheduler as a gate-keeper
16:16:57 <sheel> jgriffith: sorry, I was not part of that, may be i have to search through youtube
16:17:06 <jgriffith> sheel: nahh... you didn't miss much :)
16:17:06 <smcginnis> jgriffith: +1
16:17:16 <sheel> jgriffith:  what about backup operations?
16:17:20 <e0ne> jgriffith: +1
16:17:30 <jgriffith> sheel: backups IMO made their bed
16:17:42 <dulek> I'm a little opposed to that. snapshot creation cannot really succeed if scheduled anywhere else than where source is placed.
16:17:59 <dulek> Backups are different story - now we have them decoupled.
16:18:00 <smcginnis> dulek: It would just need to route it to the right place.
16:18:13 <DuncanT> Backups can go through the scheduler easily now
16:18:16 <jgriffith> dulek: yeah... but that's not the idea
16:18:32 <jgriffith> dulek: so for those calls it would always be sent to the same backend still
16:18:49 <dulek> smcginnis: But we know the right place in the API - volume.host. And we can inform user fast if something's wrong with that host.
16:18:54 <jgriffith> dulek: the suggestion was route through the scheduler though instead of bypassing
16:19:03 <jgriffith> DuncanT: ok, "they "can" " but they don't
16:19:05 <geguileo> But we would still be routing them even if the service is disabled to keep backward compatibility, right?
16:19:18 <jgriffith> geguileo: was that a joke?
16:19:30 <jgriffith> geguileo: or are you being serious?
16:19:33 <smcginnis> dulek: I agree, it is adding an extra hop in the flow. But it would make things consistent.
16:19:37 <dulek> geguileo: Well, disable is an admin thing. I don't think we need to care here.
16:19:40 <sheel> jgriffith: DuncanT: no issues, we can make them pass through scheduler
16:19:41 <hemna> if we route everything through the scheduler, then we can dynamically update the backend status via get_volume_stats.  if the backend is unreachable by the driver, then the scheduler can stop the call getting to the manager before making the rpc
16:19:46 <dulek> smcginnis: I agree here.
16:19:48 <geguileo> jgriffith: Well, surprisingly enough I was being serious  XD
16:19:51 <jungleboyj> smcginnis: ++
16:20:00 <jungleboyj> It shouldn't be that big a change.  Right?
16:20:09 <smcginnis> I wouldn't think so.
16:20:10 <sheel> smcginnis: +1
16:20:27 <sheel> jungleboyj: not big change
16:20:30 <dulek> jungleboyj: It requires some compatibility code I think, but is certainly possible.
16:20:30 <jgriffith> geguileo: I thought so.... I have a hard time subscribing to the "maintain a bug for backward compatability" approach
16:20:47 <geguileo> jgriffith: I don't mean those operations
16:20:51 <jgriffith> dulek: smcginnis sheel so an easier fix....
16:20:58 <geguileo> jgriffith: That the bug is referring to (creation stuff)
16:21:01 <sheel> jgriffith:  some guys from my team have already started for it...
16:21:04 <jgriffith> dulek: smcginnis sheel put a check in cinder.volume.api
16:21:12 <geguileo> jgriffith: But all other operations that currently are not affected by disabled and are not creation related
16:21:24 <geguileo> jgriffith: Attach/detach for example
16:21:42 <jgriffith> geguileo: ok... your call.  Personally I think that if you "disable" a service it should be "disabled"
16:21:50 <jgriffith> geguileo: not "do some things" but not others
16:22:07 <dulek> jgriffith: Use case for disabling is host maintenance.
16:22:11 <geguileo> jgriffith: I agree, but then it's not backward compatible
16:22:23 <hemna> microversion....
16:22:32 <dulek> jgriffith: I want my users to be able to access their volumes, but not to create new ones here, so I can migrate everything out from there.
16:22:33 * jungleboyj laughs
16:22:34 <smcginnis> hemna: That fixes everything. :)
16:22:38 <jungleboyj> smcginnis: ++
16:22:40 <dulek> hemna: Nooo. :P
16:22:48 <hemna> s/microversion/nightmareversion
16:22:56 <eharney> i'm not sure this is something that needs to be 100% backward compatible
16:22:59 <DuncanT> Maybe we need two different disable type operations? Drain and disable, or similar?
16:23:03 <dulek> eharney: +1
16:23:06 <diablo_rojo> hemna: +1
16:23:14 <smcginnis> "maintenance mode"
16:23:15 <jungleboyj> macrovision!
16:23:16 <DuncanT> I can see why you'd want a drain type operation
16:23:19 <tbarron> eharney: +1
16:23:35 <sheel> DuncanT: what about disabling queue when service is disabled
16:23:36 <sheel> ?
16:24:00 <dulek> sheel: Then admin cannot use disabling to do host maintenance.
16:24:09 <DuncanT> sheel: As I said, there's a desire here for more than one type of 'disabled'
16:24:26 <sheel> dulek: DuncanT : ok
16:24:47 <geguileo> DuncanT: +1
16:24:48 * dulek thinks that disable suffers from poor naming…
16:24:50 <jungleboyj> Diabled and Dead.
16:25:08 <jungleboyj> *disabled
16:25:09 <smcginnis> 'disabled' and 'really-disabled'
16:25:14 <dulek> DuncanT: What use case you have for "drain" type of disabled?
16:25:15 <jgriffith> haha... let's make things as complicated as we can
16:25:18 <hemna> zombie
16:25:23 <DuncanT> "A bit disabled"... "walking with a limp"....
16:25:26 <smcginnis> jgriffith: No doubt!
16:25:32 <sheel> haha
16:25:33 <smcginnis> DuncanT: LOL
16:25:44 <diablo_rojo> DuncanT: :)
16:25:47 <hemna> The Walking Dead
16:25:59 <smcginnis> OK, so maybe we need to work on the naming.
16:26:14 <smcginnis> But I think DuncanT is right. There are a couple different use cases we need to think about here.
16:26:18 <Swanson> Cake and Pie?
16:26:21 <DuncanT> jgriffith: Wanting the current type of 'disabled' in production makes total sense though - not for reasons of complication but because it's useful
16:26:26 <smcginnis> Swanson: Yes!
16:26:28 <jgriffith> I think you guys are making this way more complex than is useful
16:26:34 <DuncanT> 'disabled' 'food coma'
16:26:43 <jgriffith> shit's on or off
16:26:58 <bswartz> condemned?
16:26:58 <smcginnis> jgriffith: You're too practical. :)
16:27:05 <DuncanT> jgriffith: In practice, no, it really isn't
16:27:08 <jgriffith> if you want to introduce a "don't accept new resource creates" that's cool
16:27:09 <sheel> disabled ,'work from home'
16:27:14 <dulek> jgriffith: It's supposed to solve a different use case.
16:27:17 <jgriffith> DuncanT: ok
16:27:30 <jgriffith> I'll step aside, have at it
16:27:48 <DuncanT> jgriffith: The point is, we have that now, we just call it 'disabled'... renaming it to 'frozen' or something makes good sense
16:27:53 <dulek> jgriffith: That's what it's supposed to do - do not accept new creates, for me to be able to move workload somewhere else and update the kernel.
16:27:55 <dulek> That's it.
16:28:08 <smcginnis> jgriffith: In all seriousness, we do need to keep this simple.
16:28:14 <jungleboyj> DuncanT: Frozen actually makes sense given what we were doing with replication.
16:28:27 <smcginnis> But I think this highlights a misnaming or at least a need for a different type of operation.
16:28:28 <scottda> Seems we could benefit from listing the use cases.
16:28:35 <smcginnis> scottda: +1
16:28:37 <DuncanT> jungleboyj: Yup, except that stops new snapshots too. Sigh.
16:28:40 <jungleboyj> DuncanT: Thought maybe now it is confusing since we have already used that concept.  But isn't it really the same thing?
16:28:44 <smcginnis> I think that should probably be the next step.
16:28:55 <jgriffith> DuncanT: and that was my point earlier :)
16:28:56 <smcginnis> What do we actually need to support from a user perspective.
16:29:09 <smcginnis> And where do we fall flat with that with how things are now.
16:29:10 <Swanson> jungleboyj, isn't it the same thing?
16:29:19 <jgriffith> FWIW freeze isn't replication specific
16:29:24 <jgriffith> you can use that today
16:29:25 <dulek> Question on openstack-operators?
16:29:27 <Swanson> jgriffith, That's what I thought.
16:29:30 <scottda> And which use case(s) should go in the first iteration, which can be done separately.
16:29:38 <smcginnis> jgriffith: Hmmm
16:29:47 <jungleboyj> jgriffith: Swanson Just wanted to make sure.
16:29:56 <vincent_hou> what we can still do and what we can't do in this "disabled mode" have not been agreed. I think we can work on this first by listing the use cases we like to support or not.
16:30:06 <sheel> scottda: right question..
16:30:21 <jungleboyj> vincent_hou: That is probably the best first step.
16:30:42 <jgriffith> jungleboyj: DuncanT https://github.com/openstack/cinder/blob/master/cinder/volume/api.py#L1625
16:31:38 <jungleboyj> jgriffith: Cool.
16:31:39 <sheel> jgriffith: yes, we have added this in v2 for services
16:31:50 <jgriffith> sheel: we?
16:31:59 <sheel> jgriffith: s/we/someone
16:32:11 <jgriffith> sheel: haha... jgriffith added them
16:32:12 <DuncanT> jgriffith: The sematics of that don't quite match though, since it will also disable clone / snap. Need a bit more thought I think, and writing up the usecase / point will probably help reduce the circling we're doing here
16:32:14 <sheel> jgriffith:  some community member
16:32:14 <jgriffith> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/services.py#L66
16:32:17 <smcginnis> jgriffith: That is the right conceptual action I think.
16:32:21 <sheel> jgriffith: oh great
16:32:23 <jungleboyj> sheel: So, add the ability to set a backend frozen and we decide what actions are allowed for such a state?
16:32:47 <jgriffith> I give up
16:32:53 <jgriffith> *again*
16:33:07 <jungleboyj> jgriffith: Don't give up.  :-)
16:33:08 <smcginnis> I do think we need to first identify the user needs here and make sure we are mathing the functionality, and naming, to what the end userr would expect and need.
16:33:11 <jgriffith> jungleboyj: that's arleady decided :)
16:33:20 <sheel> jungleboyj: i can voumteer it..with some help from jgriffith
16:33:21 <jgriffith> jungleboyj: you can't create a *new* anything
16:33:34 <jgriffith> you can use what's there, but you can't modify or create, or add or paint blue
16:33:46 <jgriffith> it's "frozen"
16:33:52 <jgriffith> that's the whole point
16:34:11 <sheel> exactly...
16:34:13 <jungleboyj> jgriffith: Ok, that makes sense to me.
16:34:15 <jgriffith> or did I need to call it "apple-pied" to avoid the usual ridiculous argument over naming/semantices
16:34:19 <jgriffith> semantics
16:34:24 <smcginnis> +1
16:34:37 <smcginnis> All new features need a food-based code name for now on.
16:34:38 <smcginnis> :P
16:34:44 <diablo_rojo> a la mode?
16:34:47 * jungleboyj has images from American Pie going through my head.
16:34:52 <jgriffith> smcginnis: :)  Until someone has a food-allergy
16:34:56 <jungleboyj> smcginnis: ++
16:35:00 <hemna> jungleboyj, because band camp?
16:35:08 <jgriffith> what?
16:35:09 <sheel> American Pie... haha
16:35:11 <smcginnis> No peanut butter.
16:35:21 * jungleboyj would like propose Monte Cristo
16:35:21 <jgriffith> Ohhhh.... you guys are terrible!
16:35:32 <jungleboyj> jgriffith: Gets it.
16:35:36 <diablo_rojo> jgriffith: a little late to the party? ;)
16:35:37 <dulek> upgrade cinnamon rolls? :D
16:35:38 <smcginnis> OK, I think this is going down hill.
16:35:51 <smcginnis> sheel: Thanks for looking at that.
16:35:52 <scottda> And we never start very high on the hill
16:35:59 <smcginnis> scottda: Shh
16:36:08 <sheel> smcginnis:  :)
16:36:13 <diablo_rojo> scottda: Ham sammich?
16:36:22 <sheel> smcginnis:  wat's next..
16:36:41 <smcginnis> sheel: If you can start capturing use cases, maybe in an etherpad.
16:36:49 <smcginnis> sheel: Definitely pull in input from other folks.
16:36:55 <smcginnis> sheel: Then we can discuss what we have there.
16:36:56 <sheel> smcginnis:  sure...
16:37:04 <smcginnis> I don't mean to add a bunch of overhead to this.
16:37:15 <smcginnis> But I think we need to be clear about what we are fixing
16:37:17 <smcginnis> And how.
16:37:31 <diablo_rojo> smcginnis: That sounds like a good plan.
16:37:41 <scottda> smcginnis: ++ Writing things down is a good thing.
16:37:44 <sheel> smcginnis:  right... pakka
16:38:04 <smcginnis> sheel: Thank you for bringing this up.
16:38:11 <smcginnis> sheel: Anything else for now.
16:38:15 <sheel> smcginnis:  oh no problem, thanks for discussing
16:38:19 <sheel> smcginnis:  no i am done
16:38:26 <smcginnis> Great
16:38:32 <smcginnis> #topic Open discussion
16:38:41 <smcginnis> One annoucnement I forgot.
16:38:45 <smcginnis> Besides spelling...
16:38:54 <smcginnis> Voting is open.
16:38:58 <smcginnis> Vote early and often.
16:39:05 <smcginnis> Really glad we actually have an election.
16:39:19 <e0ne> just a reminder
16:39:22 <smcginnis> I think I said it last time - it's a great thing for a project =, IMO.
16:39:23 <e0ne> #link https://etherpad.openstack.org/p/newton-cinder-summit-ideas
16:39:32 <smcginnis> e0ne: Oh yes, thanks!
16:39:39 <jgriffith> indeed, thanks to both e0ne and smcginnis for stepping up
16:39:54 <jungleboyj> jgriffith: ++
16:39:56 <sheel> 👍
16:40:00 <diablo_rojo> jgriffith: +!
16:40:02 <dulek> Okay, business is business - how many beers each candidate offers?
16:40:03 <diablo_rojo> +1
16:40:03 <dulek> ;)
16:40:13 <jgriffith> lol
16:40:14 <e0ne> smcginnis, jgriffith: I don't care about voting at all. looks like we're going to the same direction
16:40:14 <jungleboyj> dulek: :-)
16:40:15 <smcginnis> Please add ideas to the summit planning etherpad!
16:40:18 <sheel> dulek:  +100
16:40:25 <smcginnis> e0ne: I agree!
16:40:30 <e0ne> dulek: it's not for public chat question ;)
16:40:43 <jgriffith> indeed, think we're in good hands either way
16:40:54 <e0ne> jgriffith: thank you
16:40:57 <jungleboyj> Agreed!
16:41:11 <scottda> For those interested in Nova-Cinder API....
16:41:14 <scottda> We've scheduled a meeting next Wednesday (March 30), 2100UTC on #openstack-meeting-cp
16:41:18 <smcginnis> What's nova?
16:41:22 <hemna> scottda, sweet
16:41:23 <smcginnis> :P
16:41:37 <scottda> Agenda will come from here: https://etherpad.openstack.org/p/cinder-nova-api-changes
16:41:45 <dulek> scottda: Hey, maybe it's worth announcing on openstack-dev?
16:41:46 <smcginnis> #info nova-cinder meeting March 20, 2100 UTC
16:41:48 <e0ne> scottda: great! could you please send a sorh message to openstack-dev ml?
16:41:52 <dulek> (or maybe it was?)
16:41:54 <scottda> jgriffith: Can you post a link to your POC code for attachment solution?
16:42:15 <scottda> dulek: e0ne Yes, ildikov was going to post to the ML
16:42:28 <e0ne> scottda: this one https://review.openstack.org/#/c/284867/?
16:42:57 <vincent_hou> smcginnis：nova-cinder meeting March 30, 2100 UTC？？？
16:43:05 <ildikov> yeap, I planned to announce if people are available
16:43:07 <scottda> #info Nova-cinder meeting Wed March 30th 2100 UTC #openstack-meeting-cp
16:43:28 <smcginnis> vincent_hou: ?
16:43:28 <ildikov> scottda:
16:43:37 <scottda> ildikov: I say, go ahead and announce and we get whomever we get as attendees
16:43:42 <ildikov> if we say it's final, I send out a mail to the ML
16:43:58 <diablo_rojo> Swanson: Why aren't you here at the coffee shop with smcginnis jungleboyj and I?
16:44:02 <smcginnis> Oh, /20th/30th/
16:44:16 <ildikov> scottda: cool, will do, I added the slot to the etherpad just now already
16:44:27 <Swanson> diablo_rojo, smcginnis didn't tell me about it until an hour ago.
16:44:36 <scottda> e0ne: Yes, that's the link to the review. Thanks.
16:44:41 <vincent_hou> smcginnis: yes
16:44:43 <smcginnis> Swanson: It was an "accident"
16:44:46 <smcginnis> :P
16:44:53 <diablo_rojo> Swanson: I guess it's cool kids only.
16:45:09 <smcginnis> Any other topics?
16:45:41 <smcginnis> OK. Let's free up the channel.
16:45:44 <smcginnis> Thanks everyone!
16:45:51 <diablo_rojo> Thanks :)
16:45:53 <geguileo> Thanks!
16:45:53 <sheel> thank you..
16:45:55 <jungleboyj> Thanks.  Most entertaining meeting ever!
16:46:02 <vincent_hou> thanks
16:46:03 <e0ne> see you next week
16:46:04 <smcginnis> #endmeeting