21:04:11 <alaski> #startmeeting nova_cells
21:04:11 <david-lyle> apologies alaski
21:04:12 <openstack> Meeting started Wed Nov 11 21:04:11 2015 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:04:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:04:16 <alaski> david-lyle: no worries
21:04:16 <openstack> The meeting name has been set to 'nova_cells'
21:04:17 <mrunge> thanks!
21:04:48 <alaski> who's here to discuss cells!?
21:04:53 <dansmith> me is
21:05:22 <belmoreira> o/
21:05:32 <alaski> great
21:05:34 <pranav_> o/
21:05:37 <alaski> #topic v1 testing
21:06:18 <alaski> I didn't have time to put together a summary of what's been going on, but a ec2 volume test has been failing regularly
21:06:35 <alaski> due to an apparent race in updating/creating bdms in the parent cell
21:07:04 <alaski> for now the test is skipped, but dansmith and mriedem have put some work together at ** https://review.openstack.org/#/c/231858
21:07:23 <alaski> any eyes on that would be great
21:07:32 <dansmith> I don't think that's all working
21:07:38 <dansmith> i.e. not needing eyes yet
21:07:42 <alaski> it's not
21:07:55 <alaski> true, review isn't needed yert
21:07:57 <alaski> *yet
21:08:05 <alaski> but people can help debug if they'd like
21:08:10 <dansmith> yes
21:08:57 <alaski> and the lock_unlock test was recently added to the skiplist
21:09:13 <alaski> other than that I think things are fairly stable
21:09:25 <alaski> #topic Specs for Mitaka
21:09:49 <alaski> If anyone has any specs they should list them on https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
21:10:07 <alaski> including me, because I have one open I think
21:11:03 <alaski> and I would like to discuss open specs each meeting and I'm going to pull a list from there
21:11:35 <alaski> #topic Open Reviews
21:11:49 <alaski> any reviews needing attention?
21:11:58 * alaski suspects not this early in the cycle
21:12:37 <alaski> #topic Open Discussion
21:12:37 <belmoreira> alaski: we still have the grenade problem with the code for the flavors
21:12:54 <belmoreira> we need some help on this
21:13:17 <alaski> that's the series at https://review.openstack.org/#/c/201606/
21:13:54 <belmoreira> yes
21:14:13 <alaski> belmoreira: that should have been fixed when we went into Mitaka and grenade switched from L->M
21:14:24 <dansmith> yeah, I should get that base grenade patch working again
21:14:30 <dansmith> that's a prerequisite for the flavors stuff
21:14:35 <dansmith> I'll try to get that done in the next week
21:14:50 <alaski> okay, great
21:14:52 <belmoreira> dansmith: great
21:16:17 <alaski> so based on the summit outcome my take is that the big work items this cycle are modifying boot to call the scheduler in a new place, persist request-spec, and cell0
21:16:33 <alaski> and the flavor migration to set a pattern for future migrations
21:17:10 <dansmith> yeah, I had some concerns about the flavor thing
21:17:19 <dansmith> I don't remember what they were, but they might just be outright fear
21:17:36 <belmoreira> soft delete?
21:17:38 <dansmith> I think we need to figure out how we're going to draw a box around that to make it graceful and not too painful
21:18:05 <dansmith> ah, well, yeah, that wasn't my complaint but I don't recall what the outcome of that was
21:18:24 <dansmith> really don't want to add soft delete into the cell db, but also don't want to delay any further
21:18:56 <alaski> I think we said that we would carry it over for now, but I can't recall for sure either
21:19:05 <dansmith> ugh
21:19:10 <dansmith> I wonder,
21:19:13 <alaski> it's not on the etherpad
21:19:15 <dansmith> could we use the migration path to help us defer this?
21:19:17 <dansmith> meaning,
21:19:20 <alaski> https://etherpad.openstack.org/p/mitaka-nova-cells
21:19:28 <dansmith> er, no that's not going to work
21:20:07 <alaski> the contention was that it's an API change
21:20:17 <alaski> since deleted flavors can currently be listed
21:20:25 <alaski> and we need to tackle that first
21:20:25 <dansmith> yeah
21:20:33 <dansmith> which is death knell
21:20:36 <belmoreira> I think Sean will write a spec for it
21:20:58 <dansmith> but we can't support deleted flavors in older microversions otherwise,
21:21:08 <dansmith> so I'm not sure how we're going to spec our way out of that box
21:21:26 <belmoreira> and the outcome was not to block the current work, at leat is what I thought
21:22:00 <alaski> I think we need to defer that all for now, and carry over soft delete
21:22:13 <alaski> and by defer I mean let sdague run with his spec
21:23:54 <alaski> dansmith: the current migration review attempts to be painless, and online, so if you could list your fears there that would be helpful
21:24:17 <dansmith> alaski: yeah, I need to remember them and then document the defensible ones I guess
21:24:18 <sdague> oh, good reminder that I'm supposed to write something up there
21:24:30 <dansmith> alaski: I'm generally concerned about the moving things between databases thing
21:24:51 <dansmith> alaski: and the thing about us not being able to hit graceful API restart this time
21:25:05 <dansmith> but I have no cats to pull from my hat to make that better, so...
21:25:05 <alaski> dansmith: yeah, good point
21:25:25 <alaski> I've been starting to think about needing an "atomic move" for instances as well
21:25:58 <dansmith> alaski: so, about that
21:26:02 <alaski> I'll try some different things and share my failure with the group and maybe we can find something
21:26:31 <dansmith> alaski: we initially talked about not persisting the instance and just using the request spec to answer queries until it's either scheduled or dead in cell0
21:26:46 <dansmith> alaski: that would mean no atomic instance move.. have you changed your mind about that?
21:27:20 <alaski> no
21:27:31 <alaski> but the problem is still sort of the same right?
21:27:46 <dansmith> why?
21:27:54 <dansmith> with flavors, we need to move them from the cell to the api db
21:28:05 <dansmith> with instances, existing ones stay in the existing db, which becomes the cell
21:28:12 <alaski> we're moving the request-spec to the cell, albeit in a different format
21:28:12 <dansmith> and only newly failed instances go into the cell0
21:28:21 <dansmith> we're not storing request-spec yet though
21:28:53 <alaski> I'm thinking of boot, not migration
21:29:25 <alaski> it is slightly different though, so nvm for now
21:29:49 <dansmith> right, I'm talking about boot and existing data too
21:29:50 <dansmith> anyway
21:30:33 <alaski> what we want is a copy, ensure it's written, delete operation I think
21:30:56 <dansmith> yeah, I'm just totally missing why we need that for instances or request spec
21:31:03 <dansmith> but maybe we can catch up high bw offline and discuss
21:31:16 <alaski> sure
21:32:57 <alaski> I'm going to rework the request-spec persistence patch since dansmith went and changed object while I was out
21:33:11 <alaski> dansmith: do you have any interest in the cell0 or scheduling work?
21:33:14 <dansmith> I did?
21:33:25 <alaski> the relationship mappings thing
21:33:41 <dansmith> well, I changed that in liberty and you haven't been out that long, but okay :)
21:34:00 <alaski> well, I didn't notice the review comment on it until then :)
21:34:20 <dansmith> alaski: I'm too stupid for scheduling stuff, but I guess I need to help with the cell0 and general object support for who-am-i-talking-to, eh?
21:35:00 <alaski> oh yeah, the object support would be great
21:35:34 <alaski> melwitt had some initial work on that
21:35:51 <alaski> https://review.openstack.org/#/c/161906/
21:36:00 <alaski> but there were open questions about it
21:36:10 <dansmith> ah, cool
21:37:17 <alaski> anything else to discuss today?
21:38:07 <alaski> oh, I should mention that we're back to meeting weekly now
21:38:20 <alaski> I'll send an email out to the ML
21:38:21 <pranav_> dansmith : can you point me to that grenade patch?
21:38:40 <dansmith> pranav_: https://review.openstack.org/#/c/190399/
21:39:02 <alaski> thanks everyone!
21:39:06 <alaski> #endmeeting