| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 11:43:32 | cdent | bauzas, gibi: ^ please and thank you | |
| 12:26:42 | gibi | cdent: thanks, +2d | |
| 12:27:42 | AJaeger | novaclient team, please review https://review.openstack.org/543115 , https://review.openstack.org/#/c/543114, https://review.openstack.org/#/c/541370/ - the first two are needed to fix building, the third is needed for Zuul v3 | |
| 12:38:34 | ameeda | gibi: could you please check https://review.openstack.org/#/c/526900/, it doesn't has any activity from awhile | |
| 13:08:11 | bauzas | hrw: https://review.openstack.org/#/c/541728/ will be merged in master, which is now for Rocky | |
| 13:08:59 | bauzas | hrw: let's discuss with mriedem if we should cherry-pick to Queens | |
| 13:41:43 | hrw | bauzas: thanks | |
| 13:42:16 | hrw | bauzas: I think that status-matrix part can be merged | |
| 13:49:14 | efried | cdent: Thank you sir. | |
| 13:49:37 | efried | cdent: Was it because of global_id? | |
| 13:50:32 | cdent | efried: I _think_ so. The method that you had deleted was different from when you had deleted if before, so I just deleted it again | |
| 13:50:44 | efried | right | |
| 13:54:07 | efried | leakypipes: Yet another +2-after-rebase please: https://review.openstack.org/#/c/539712/ | |
| 13:55:38 | efried | cdent: here's that spec on resource class affinity for NUMA: https://review.openstack.org/543062 | |
| 13:56:39 | leakypipes | efried: done | |
| 13:56:44 | efried | leakypipes: Thanks | |
| 13:56:52 | cdent | efried: yeah, already noted it because of the spying you suggested i might do | |
| 13:57:06 | efried | cdent: Turns out the "aggregate distance" business isn't actually suited for NUMA. I'll still send out a link to the eavesdrop/etherpad, but I'm going to kinda push it out of main memory to keep room for other stuff. | |
| 13:57:44 | efried | cdent: eh, spying? | |
| 13:58:04 | cdent | efried: I haven't digested it yet. glanced over the weekend and was all "ugh, not another table" and decided to come back later | |
| 13:58:37 | cdent | efried: spying: p!spy in https://anticdent.org/purple-irc-bot.html | |
| 13:58:52 | efried | cdent: Another table - you're talking about agg distance, not rc affinity, right? | |
| 13:59:20 | cdent | efried: right, I haven't looked at rc affinity yet, but its in the queue | |
| 13:59:21 | efried | cdent: Ah :) | |
| 13:59:26 | efried | okay, cool. | |
| 14:00:30 | edleafe | Scheduler subteam meeting running now in #openstack-meeting-alt | |
| 14:01:35 | mriedem | bauzas: i don't think https://review.openstack.org/#/c/541728/ needs to go to queens | |
| 14:01:46 | bauzas | sure, np | |
| 14:02:27 | efried | p!spy | |
| 14:17:53 | openstackgerrit | Chris Dent proposed openstack/nova master: Move db MAX constants to own file https://review.openstack.org/543469 | |
| 14:21:04 | AJaeger | mriedem, who's reviewing python-novaclient nowadays? I have some reviews: review https://review.openstack.org/543115 , https://review.openstack.org/#/c/543114, https://review.openstack.org/#/c/541370/ - the first two are needed to fix building, the third is needed for Zuul v3. | |
| 14:21:44 | efried | AJaeger: I hear takashin might be a good candidate :) | |
| 14:25:22 | AJaeger | takashin: ^ please ping me in case of questions. Without the first two changes, the stable branches are broken. | |
| 14:30:31 | mriedem | AJaeger: i can look after the scheduler meeting | |
| 14:30:49 | AJaeger | mriedem: thanks | |
| 14:33:39 | takashin | AJaeger: I'm not a core reviewer for python-novaclient project... | |
| 14:36:02 | openstackgerrit | Merged openstack/nova master: Provide basic data for AArch64 support matrix/functionality https://review.openstack.org/541728 | |
| 14:42:09 | hrw | mriedem, bauzas: thanks for helping with getting this stuff merged | |
| 14:44:28 | gibi | mriedem, bauzas: when I mentioned that a volume used in BFV case might not have any image associated to it I thought about someting like this: http://paste.openstack.org/show/670002/ | |
| 14:44:59 | gibi | mriedem, bauzas: In this case nova cannot do anyithing to have the image reference, as there was never an image associated to the volume | |
| 14:46:02 | gibi | mriedem, bauzas: I don't think we can enforce to have image_id in the request spec | |
| 14:46:08 | mriedem | gibi: that vm is worthless though right? | |
| 14:46:31 | gibi | mriedem: yeah, I oversimplified it, but I could attach my-vol to a vm, populate it, detach it, then boot from it | |
| 14:47:48 | mriedem | sure, i wasn't saying we should 'require' an id in the requestspec.image field, | |
| 14:48:04 | mriedem | just that in certain cases (presumably the more normal cases), it's available via the volume_image_metadata | |
| 14:48:19 | mriedem | and furthermore, we can use that information later if a cell is down | |
| 14:48:30 | mriedem | and we use the request spec to represent the instance in the GET /servers/{id}/detail response | |
| 14:48:39 | mriedem | *if we use | |
| 14:49:28 | gibi | mriedem, bauzas: OK, it is clearer now. I had the feeling that we want to make image_id mandatory in the request spec | |
| 14:50:10 | mriedem | jroll: added the healthcheck middleware to both https://etherpad.openstack.org/p/self-healing-queens-ptg and https://etherpad.openstack.org/p/api-sig-ptg-rocky | |
| 14:50:21 | mriedem | we probably need a few more SIGs for this | |
| 14:51:18 | bauzas | mriedem: heh for "more SIGs" | |
| 14:51:30 | bauzas | that can become a very discussed and argued thing | |
| 14:51:36 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Move resource provider objects into placement hierarchy https://review.openstack.org/540049 | |
| 14:51:37 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 14:51:37 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Isolate placement database config https://review.openstack.org/541435 | |
| 14:51:41 | jroll | mriedem: what have I done | |
| 14:51:58 | jroll | this really wasn't something I intended to tilt that hard at | |
| 14:51:58 | bauzas | gibi: mriedem: for the image.id being mandatory, I think I understand the point | |
| 14:52:19 | bauzas | gibi: mriedem: the problem is that AFAICS we assert in a lot of places about having an instance with an image | |
| 14:52:33 | mriedem | jroll: i just wanted to see it socialized more before it's adopted across a few projects, | |
| 14:52:53 | mriedem | because i'm projecting it on the community wide goals process | |
| 14:52:54 | bauzas | so we can 'fix' that, but that won't solve the design issue that we accepted in the past a different paradigm | |
| 14:52:59 | jroll | mriedem: also, I wasn't aware of the "new" thing until today, so adding the new thing you linked wasn't my intention at all | |
| 14:53:19 | mriedem | jroll: so your ironic patch and graham's spec aren't the same thing? | |
| 14:53:21 | jroll | mriedem: the new thing sounds like it'll take a year just to get through committee and have code written | |
| 14:53:23 | jroll | correct | |
| 14:53:27 | bauzas | jroll: from a very practical standpoint, do you feel blocked ? | |
| 14:53:29 | jroll | mine is the "old" one | |
| 14:53:38 | mriedem | bauzas: jim just wants to upstream it, but meh | |
| 14:53:40 | mriedem | it sounds like | |
| 14:53:45 | jroll | bauzas: no, what matt said | |
| 14:53:45 | mriedem | it's middleware | |
| 14:53:46 | bauzas | jroll: because I don't really see *why*it needs to be something | |
| 14:54:13 | jroll | bauzas: because it's what we use for every paste-enabled service, and so trying to standardize the rest there | |
| 14:54:49 | bauzas | jroll: well, you wanna standardize your own monitoring model :) | |
| 14:55:04 | jroll | bauzas: s/your own/oslo's/ | |
| 14:55:10 | gibi | bauzas: on the image_id, theoretically we can forbid booting from volume in nova where the volume doesn't have the image_id in the metadata, but I think that would be restrict some use cases that is possible today | |
| 14:55:12 | cdent | jroll: I'd say go ahead with the old thing. the new thing needs to be discussed but is a whole different kettle | |
| 14:55:14 | jroll | I'm not forcing it on anyone ¯\_(ツ)_/¯ | |
| 14:55:20 | bauzas | I'm not sure operators are sold on using middleware healthchecks for knowing whether my app is up | |
| 14:55:48 | cdent | jroll: I reckon the way it is done in ironic is just fine for placement | |
| 14:56:06 | bauzas | gibi: If I'm sure about one thing, it's how operators can find solutions with things we don't officially support | |
| 14:56:07 | mriedem | gibi: i wasn't suggesting making that break now, | |
| 14:56:13 | cdent | it doesn't preclude some different future | |
| 14:56:19 | mriedem | gibi: was just wondering if we have the information from the volume meta, if we should store it in the request spec | |
| 14:56:43 | bauzas | mriedem: at the request_spec creation time, then ? | |
| 14:56:46 | mriedem | yes | |
| 14:56:50 | bauzas | well | |
| 14:56:56 | mriedem | the confusion will be, | |
| 14:57:01 | bauzas | if you rebuild ? | |
| 14:57:04 | mriedem | instance.image_ref == None == volume-backed, | |
| 14:57:09 | gibi | copying image_id over from the volume meta to the request_spec is fine by me | |
| 14:57:09 | bauzas | also | |
| 14:57:11 | mriedem | but requestspec.image.id == None....? | |
| 14:57:55 | mriedem | bauzas: if you rebuild a volume-backed instance with a new image, we fail today | |
| 14:58:09 | jroll | cdent: thanks | |
| 14:58:23 | mriedem | bauzas: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2979 | |
| 14:59:24 | bauzas | mriedem: okay, gtk | |
| 15:01:18 | takashin | mriedem: Would you check my reply to you comment in https://review.openstack.org/#/c/513721/ ? | |