| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-20 | |||
| 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 | |
| 16:57:43 | mordred | yah - I think 1a would be ideal | |
| 16:57:53 | dansmith | if we did that later, option 2 would become 1a suddenly, and make the unreachable: key never used | |
| 16:58:13 | dansmith | tssurya: all this I'm saying is correct yeah? | |
| 16:58:32 | mordred | out of curiosity ... in the 1a world -if I get a list of stuff and it's got a stale cached server in it - and I do DELETE /servers/{id} ... what happens? | |
| 16:58:34 | tssurya | dansmith: yea makes sense | |
| 16:58:58 | dansmith | mordred: do you want to ask about PUT instead of delete? | |
| 16:59:01 | mordred | if the cell is still down - do I get a 404 for that? or do I get a 'retry again later please' ? | |
| 16:59:05 | dansmith | delete is async right now, and does't go away immediately | |
| 16:59:18 | mordred | dansmith: well - both are questions I guess | |
| 16:59:32 | mordred | will the scheduler accept the async delete if the cell for the server is down? | |
| 16:59:35 | dansmith | DELETE would "succeed" and never happen, like it does today for lots of things | |
| 16:59:49 | tssurya | dansmith: although I never thought of doing 1a), plus we were thinking if we could fully req_spec as of now or not and maybe just go with uuids and not put in flavors and images | |
| 16:59:51 | mordred | so it wouldn't eventually get queued and handled? | |
| 16:59:52 | dansmith | PUT would fail with some code | |
| 16:59:55 | dansmith | mordred: no | |
| 16:59:59 | mordred | nod | |
| 17:00:01 | dansmith | mordred: well, | |
| 17:00:26 | dansmith | mordred: yeah, no. | |
| 17:00:45 | dansmith | tssurya: yeah that makes option 1 more completeish, and 1a a smaller delta | |