| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-20 | |||
| 13:33:40 | mnaser | "Found an unconfirmed migration during delete, id: 14157, status: confirming" | |
| 13:34:40 | mnaser | weird | |
| 13:36:14 | deepak_mourya | hi, in this bug https://bugs.launchpad.net/nova/+bug/1770636 | |
| 13:36:15 | deepak_mourya | Do we need to add exception for CannotDeleteParentResourceProvider only in https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/resource_provider.py#L130-L140 and write test case or something else ? | |
| 13:36:15 | openstack | Launchpad bug 1770636 in OpenStack Compute (nova) "placement API not translating CannotDeleteParentResourceProvider to 409 Conflict" [Low,Triaged] - Assigned to Deepak Mourya (mourya007) | |
| 13:36:41 | bauzas | mnaser: not really weird, we just confirm the resize before deleting an instance | |
| 13:36:58 | mnaser | bauzas: yes, but the status was 'confirming' | |
| 13:37:04 | bauzas | mnaser: but you're right, that means the confirm never reached | |
| 13:37:07 | mnaser | which further goes to the theory that i guess somehow the message was lost | |
| 13:37:12 | bauzas | agreed | |
| 13:37:33 | bauzas | the migration possibly went fine, but then the confirm didn't | |
| 13:37:42 | mnaser | i guess the bug here is once it goes into confirming, if something happens in the compute node, that vm is stuck forever | |
| 13:44:18 | openstackgerrit | Chen proposed openstack/nova master: Specify periodic task interval in configurations https://review.openstack.org/576864 | |
| 14:17:23 | efried | mgoddard: you around to discuss https://review.openstack.org/#/c/576588/3/nova/virt/ironic/driver.py@806 ? | |
| 14:17:45 | efried | jroll, dtantsur: also ^ ? | |
| 14:21:15 | jroll | efried: what about it? :) | |
| 14:21:28 | efried | jroll: I just left a response (sorry for the async) | |
| 14:21:45 | jroll | oh, I only saw the first comment thread | |
| 14:22:45 | jroll | blah | |
| 14:23:08 | jroll | efried: I would vote to blow them away to maintain the current behavior | |
| 14:23:12 | jroll | see if people start yelling | |
| 14:23:16 | mgoddard | efried: just in a meeting, finishing shortly | |
| 14:23:24 | jroll | and then tell them to set them on the ironic node instead :P | |
| 14:24:02 | efried | jroll: I think I agree that's the right approach for now. I'll submit a followon asap. Unless you think this is busted enough that I should try to yank it out of the gate. | |
| 14:24:39 | jroll | efried: probably fine | |
| 14:28:38 | mgoddard | efried: IMO we should stick with the current broken behaviour then fix it, rather than changing to a different broken behaviour before fixing it | |
| 14:29:13 | efried | mgoddard: Okay, that's what jroll said too; I agree that sounds like the right approach. | |
| 14:29:18 | efried | mgoddard: Good spot btw. | |
| 14:29:31 | efried | mgoddard: Do you think a followon patch is sufficient or should I yank this one? | |
| 14:29:50 | mgoddard | efried: I think a follow on would be fine | |
| 14:29:53 | efried | k | |
| 14:30:00 | efried | thanks y'all. | |
| 14:30:09 | mgoddard | efried: thanks for following up | |
| 14:32:53 | openstackgerrit | Eric Fried proposed openstack/nova master: Ironic update_provider_tree: restore traits override https://review.openstack.org/576877 | |
| 14:36:36 | dansmith | stephenfin: can haz? https://review.openstack.org/#/c/576580 | |
| 15:28:31 | openstackgerrit | Eric Fried proposed openstack/nova master: Ironic update_provider_tree: restore traits override https://review.openstack.org/576877 | |
| 15:28:44 | efried | jroll, mgoddard, dtantsur: ^ | |
| 15:28:49 | openstackgerrit | Matthew Booth proposed openstack/nova master: Comment proposed ironic fix for removal of ironic driver workaround https://review.openstack.org/576892 | |
| 15:29:05 | mdbooth | dansmith: ^^^ tacks on the comment I mentioned, btw | |
| 15:29:08 | zcorneli | limitations | |
| 15:29:09 | zcorneli | Ach. search, not send... | |
| 15:31:21 | openstackgerrit | Eric Fried proposed openstack/nova master: Comment proposed ironic fix for removal of ironic driver workaround https://review.openstack.org/576892 | |
| 15:31:43 | efried | mdbooth: I added the reference from the other patch. +2, thanks for the followup. | |
| 15:54:42 | openstackgerrit | Eric Fried proposed openstack/nova master: RT stats deepcopy 1x/node instead of 1x/instance https://review.openstack.org/576591 | |
| 16:25:56 | openstackgerrit | Zack Cornelius proposed openstack/nova master: Implement file backed memory for instances in libvirt https://review.openstack.org/567876 | |
| 16:26:23 | zcorneli | mreidem: dansmith: ^ | |
| 16:26:50 | dansmith | zcorneli: I think mriedem is on vacay fwiw | |
| 16:27:54 | dansmith | maybe stephenfin can look at this with me though, since I think he's been through it a couple times at least | |
| 16:28:05 | zcorneli | Yep, I think he's been through it at least once. | |
| 16:28:11 | zcorneli | Heading off for lunch, should be back soon(ish) | |
| 16:28:21 | stephenfin | zcorneli, dansmith: I have and I can | |
| 16:28:38 | dansmith | cool | |
| 16:32:22 | cfriesen | stephenfin: what's the usecase for file-backed memory? Optane-type devices? | |
| 16:35:11 | dansmith | cfriesen: primarily infiniband-attached memory, or maybe super-fast flash for certain cases | |
| 16:37:00 | cfriesen | looking at the patch briefly, I wonder if it would make more sense to just stop reporting any hugepages when file-backed memory is enabled on a compute node | |
| 16:37:39 | cfriesen | or can you have a mix of file-backed and regular instances on a node? | |
| 16:38:00 | dansmith | you can't currently, although we could allow it in the future based on a flavor key or something | |
| 16:38:35 | dansmith | it's specific enough of a use case that I think it's probably fine to just mention that they don't mix, but if you want a follow-up for the hugepage thing that's fine | |
| 16:40:17 | cfriesen | dansmith: the patch currently checks for "if wantsmempages and wantsfilebacked" and raises an exception, I was just wondering whether it'd be cleaner to not report any hugepages. But if we might support both in the future then it makes more sense as-is. | |
| 16:40:38 | dansmith | right | |
| 16:42:54 | openstackgerrit | Merged openstack/nova master: Convert ironic virt driver to update_provider_tree https://review.openstack.org/576588 | |
| 16:43:02 | openstackgerrit | Merged openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604 | |
| 16:43:11 | openstackgerrit | Merged openstack/nova master: Be graceful about vif plugging in early ironic driver startup https://review.openstack.org/576580 | |
| 16:44:36 | stephenfin | cfriesen: What dansmith said | |
| 16:45:15 | stephenfin | cfriesen: and I'd be happy to see a follow up addressing the hugepage case. Better principle of least surprise factor | |
| 16:45:30 | dansmith | well, on the one hand, | |
| 16:45:38 | dansmith | failing if they're in conflict is more visible | |
| 16:45:58 | dansmith | as configuring them both and then having hugepages just not be exposed might be more obscure, amirite? | |
| 16:46:49 | stephenfin | That's a good point | |
| 16:50:16 | dansmith | tssurya: melwitt and mriedem are out this week, so I'm assuming no cells meeting | |
| 16:50:26 | dansmith | it'd be more like a conversation than a meeting :) | |
| 16:50:30 | tssurya | dansmith: was just about to ask if we are having one | |
| 16:50:33 | tssurya | I agree | |
| 16:50:42 | tssurya | let's skip then | |
| 16:51:11 | dansmith | cool | |
| 16:51:14 | tssurya | dansmith: question regarding https://review.openstack.org/#/c/575996/ , | |
| 16:51:27 | tssurya | does this mean you are against a new microversion ? | |
| 16:51:39 | tssurya | meaning against the adding of the new top key ? | |
| 16:51:49 | dansmith | tssurya: I'm surprised that other people aren't | |
| 16:52:09 | tssurya | actually I should probably also ask the API guys | |
| 16:52:26 | dansmith | tssurya: I'm not against it, I was just surprised to see it and was baiting others into responding | |
| 16:52:27 | dansmith | tssurya: I think we should also ask someone like mordred | |
| 16:52:37 | tssurya | as of now its just been gibi and mriedem on it | |
| 16:52:39 | mordred | what did I do? | |
| 16:52:50 | dansmith | tssurya: see how that works? like beetlejuice | |
| 16:52:55 | dansmith | mordred: I'll need to explain: | |
| 16:52:57 | tssurya | dansmith: hehe :D | |
| 16:53:19 | dansmith | mordred: multiple cells, instances spread across them all. assume one cell is completely unreachable right now | |
| 16:53:32 | dansmith | mordred: would you, the api consumer, prefer either: | |
| 16:54:16 | dansmith | mordred: 1. servers: [ ... ] to include all your instances, but for the ones we can't get the details on, a majorly limited structure with basically just the uuid and an unknown state, or | |
| 16:54:46 | dansmith | mordred: 2. servers: [ ... ] for the ones we can get like normal, and another top-level key of unreachable: [ ... ] which contains the shell instances we can't get the details on | |
| 16:55:06 | mordred | jeez. that's a good question | |
| 16:55:15 | dansmith | option 2 would mean existing clients see instances disappear from the main servers list (unless they go looking in unreachable, which is most of my concern | |
| 16:55:45 | dansmith | option 1 would likely mean the shell instances sort in the wrong order, and are obviously missing a bunch of detail, | |
| 16:55:57 | dansmith | but at least you continue to see them there where you did ten minutes ago before the outage | |
| 16:56:33 | mordred | I think I prefer option 1 - with status=='unknown' or something like that ... | |
| 16:56:42 | dansmith | okay, potential corollary: | |
| 16:57:05 | mordred | but - trying to think through some of the higher-level shade interactions and how we'd handle them | |
| 16:57:21 | dansmith | option 1a (future): we use memcache or something to stash the last-known image of an instance and could fill in a stale version of the whole thing for things that are down | |
| 16:57:36 | dansmith | 1a could come in the future, but won't be available now | |