| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-20 | |||
| 10:05:20 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: [placement] Enable limiting GET /allocation_candidates https://review.openstack.org/513526 | |
| 11:20:29 | openstackgerrit | Huan Xie proposed openstack/nova master: VGPU: Define vgpu resource class https://review.openstack.org/511180 | |
| 11:21:50 | artom_ | stephenfin, since https://review.openstack.org/#/c/345396/22/nova/console/websocketproxy.py is being held up by CI, do you think https://review.openstack.org/#/c/345399/29/nova/console/websocketproxy.py@82 could be addressed? | |
| 11:22:01 | artom_ | My OCD would feel much better :) | |
| 11:22:10 | artom_ | (But I understand if you don't feel like chasing the +2 again) | |
| 11:22:36 | openstackgerrit | Huan Xie proposed openstack/nova master: VGPU: Define vgpu resource class https://review.openstack.org/511180 | |
| 12:18:18 | openstackgerrit | Takashi NATSUME proposed openstack/nova stable/pike: Add 'delete_host' command in 'nova-manage cell_v2' https://review.openstack.org/513717 | |
| 12:30:10 | openstackgerrit | Takashi NATSUME proposed openstack/nova stable/pike: Add 'delete_host' command in 'nova-manage cell_v2' https://review.openstack.org/513717 | |
| 12:32:15 | openstackgerrit | Takashi NATSUME proposed openstack/nova stable/ocata: Add 'delete_host' command in 'nova-manage cell_v2' https://review.openstack.org/513721 | |
| 12:34:25 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix 500 error while passing 4-byte unicode data https://review.openstack.org/407514 | |
| 12:38:10 | stephenfin | artom: I can split it out into a separate patch, but I won't mess with the first one once it's got +W | |
| 12:38:16 | stephenfin | *I will | |
| 12:38:44 | stephenfin | For reference, that got added because the original patch was written without Python 3 being a consideration | |
| 12:41:58 | artom | stephenfin, ah, gotcha | |
| 12:42:07 | artom | I'm obviously not super hung up about it | |
| 13:27:39 | openstackgerrit | sahid proposed openstack/nova-specs master: update: introducing isolate emulthreads on host https://review.openstack.org/511188 | |
| 13:43:39 | efried | Gah, Friday! | |
| 13:44:18 | figleaf | fried_rice: usually people have that reaction to Mondays | |
| 13:45:51 | gibi | this is the time (and the same time on Monday) when I like to be in an EU timezone. For me it is almos over. ;) | |
| 13:54:46 | fried_rice | leakypipes Now a good time to talk about same RCs on main & shared RPs? | |
| 13:55:49 | leakypipes | fried_rice: yuppers. | |
| 13:56:09 | fried_rice | Okay, so I opened a couple bugs and put up a couple test cases that demonstrate the issue: | |
| 13:56:20 | fried_rice | https://review.openstack.org/#/c/513149/ | |
| 13:56:26 | fried_rice | (bugs in the commit msg) | |
| 13:57:00 | fried_rice | The crux of the issue happens when the main RP (the compute node for now) has a resource class that's also present in the shared RP(s) | |
| 13:58:05 | fried_rice | The end game with shared RPs is post-Q, but it's going to come into play with the code alex_xu is writing to handle traits for allocation candidates. | |
| 13:58:55 | fried_rice | Using the example where the RC in question is DISK_GB, the problem is that you can say you want traits "RAID" and "SSD", but placement doesn't know that those are disk-y traits. | |
| 13:59:47 | fried_rice | So if your compute node has localdisk that's SSD, and your shared storage RP has disk that's RAID, you'll get a candidate for (compute node + shared RP) because the combination satisfies both traits. | |
| 14:00:16 | leakypipes | fried_rice: I thought the resources1/required1 stuff solved that particular issue? because that request is saying "gimme 10GB of disk space from a provider with the STORAGE_DISK_SSD trait" | |
| 14:00:57 | fried_rice | Well, first of all, we have deliberately deferred discussion of the semantics of numbered groups with shared, because we're deferring shared. | |
| 14:01:12 | fried_rice | But second, that would only "solve" it if you made sure to use the numbered groups in the right place. | |
| 14:01:13 | leakypipes | ok... and? | |
| 14:01:42 | fried_rice | That would be a tough thing to document for ops. But I suppose it could be done. | |
| 14:02:02 | leakypipes | fried_rice: well, Eric, much of the n-r-p stuff is going to be tough to document for ops... | |
| 14:02:12 | fried_rice | Nevertheless, the code for the un-numbered group needs to handle it in some way or another. | |
| 14:03:06 | leakypipes | fried_rice: or it doesn't and we ignore it until we work on the numbered groups stuff. | |
| 14:03:46 | fried_rice | "it doesn't" meaning what? | |
| 14:04:14 | leakypipes | fried_rice: the un-numbered groups code does not need to handle this scenario. | |
| 14:04:16 | cdent | leakypipes: was this originally supposed to work (in the early design) or had we put some other boundary in that meant it didn’t matter? Trying to refersh my memory. | |
| 14:05:07 | leakypipes | cdent: there's nothing about the current design of the resource providers modeling system that prevents these questions from being answered. Until fried_rice' | |
| 14:05:32 | leakypipes | s numbered groups request format thing was proposed, however, we did not have a way of communicating the question to the placement API. | |
| 14:06:11 | leakypipes | cdent: and what I'm saying is that we have higher priority items to get done. we should shelve this important discussion for after those higher priority items are done. | |
| 14:06:46 | fried_rice | leakypipes Okay, but I'm saying we have code right now (merged and in flight) where this needs to be addressed. | |
| 14:06:59 | leakypipes | fried_rice: your concern is definitely a good one. just saying let's focus on the foundational pieces first, note where we have bugs, and solve those bugs with the numbered groups stuff. | |
| 14:07:02 | cdent | leakypipes: I get that, but I’m just trying to confirm some of my memroy about resource classes and shared providers, in existing code | |
| 14:07:14 | leakypipes | fried_rice: it does not need to be addressed right now. | |
| 14:07:51 | leakypipes | fried_rice: unless by addressed you mean "put a func test with commented-out assertions that explain how things *should work* when X bug is fixed" | |
| 14:08:06 | leakypipes | cdent: ack | |
| 14:08:53 | fried_rice | leakypipes https://review.openstack.org/#/c/479766/10/nova/objects/resource_provider.py@2549 is in flight right now: we just can't write this code without answering the question in some way. | |
| 14:08:57 | figleaf | leakypipes: I remember saying that a CN could have local disk or shared disk, but not both | |
| 14:09:00 | figleaf | then that changed | |
| 14:09:20 | figleaf | well, not *me* saying that, but... | |
| 14:09:39 | leakypipes | fried_rice: yes, you can. | |
| 14:10:24 | leakypipes | fried_rice: I will put a review comment in the patch. | |
| 14:12:02 | leakypipes | figleaf: what you're remembering is the scheduler folks (you, me, cdent, superdan, etc) agreeing to "keep things simple" for now and assume a CN has either local or not, and not support both at this time. | |
| 14:12:27 | figleaf | leakypipes: ok, thanks. Why did that change? | |
| 14:12:42 | leakypipes | figleaf: it hasn't. | |
| 14:13:08 | fried_rice | leakypipes The patch has an implementation that already takes shared RPs into account. If that code is unreachable/no-op at the moment, then okay - but that patch is either going to need to rip out the existing shared RP stuff or create known-buggy situations. | |
| 14:13:12 | leakypipes | figleaf: but what fried_rice is getting at is the *request* part of that equation. meaning how does a flavor ask for distinct groups of identical resources with different traits. but again, we're pushing that work out to Rocky | |
| 14:13:32 | fried_rice | whoah, we are? | |
| 14:13:36 | leakypipes | fried_rice: ack. that is precisely what I've been saying. | |
| 14:13:47 | fried_rice | The numbered syntax is approved for Queens. | |
| 14:14:02 | leakypipes | fried_rice: oh? sorry I didn't know that. | |
| 14:14:07 | leakypipes | fried_rice: apologies. | |
| 14:14:22 | leakypipes | fried_rice: in any case, my point is the same. | |
| 14:14:49 | leakypipes | fried_rice: there will be a time where there are known buggy areas in the code. | |
| 14:15:06 | leakypipes | fried_rice: those areas should be documented with code comments and func tests with correct assertions commented out. | |
| 14:15:09 | leakypipes | fried_rice: understood? | |
| 14:15:35 | fried_rice | leakypipes I understand your words :) | |
| 14:15:52 | leakypipes | fried_rice: and I understand your sarcasm. | |
| 14:16:01 | superdan | leakypipes: we need the numbered syntax bit for things like NRPs to work properly right? that's why it needs to be in queens | |
| 14:16:36 | leakypipes | superdan: well, we need the numbered resources stuff for *some* types of requests for n-r-p resources to work properly, yes. | |
| 14:16:42 | superdan | right | |
| 14:16:54 | superdan | that doesn't mean we have to implement everything you could possibly request with the numbered syntax, agree | |
| 14:17:25 | leakypipes | precisely. | |
| 14:17:30 | fried_rice | This issue is about the un-numbered piece anyway. | |
| 14:17:55 | sean-k-mooney | superdan: the numbered syntax is also need for non dested resouces when using traits | |
| 14:18:01 | superdan | yes | |
| 14:18:42 | leakypipes | fried_rice: but right now, all requests are assumed to be "gimme X amount of these resources and make sure the providers providing those resources have these Y traits between them all" | |
| 14:20:07 | fried_rice | leakypipes Right. Do we agree there's a hole there? | |
| 14:20:18 | leakypipes | fried_rice: yes. | |
| 14:20:27 | leakypipes | fried_rice: please please read my comments from Oct 2 here: https://review.openstack.org/#/c/489206/ | |
| 14:21:04 | fried_rice | ... | |
| 14:21:09 | leakypipes | fried_rice: sorry for the please please. | |
| 14:22:14 | leakypipes | fried_rice: I had typed please, then ctrl-x'd please, responded to your comment with "yes." and then pasted and typed please again... sorry about that | |
| 14:22:45 | leakypipes | fried_rice: all that to say I only meant to point you at the review comments I made on that review above. :) | |
| 14:22:58 | leakypipes | fried_rice: which discusses the implementation of this particular piece of code. | |
| 14:23:08 | fried_rice | leakypipes No offense taken. And I apologize for sounding sarcastic earlier - that was not my intent. | |
| 14:24:04 | fried_rice | leakypipes The review I linked above is alex_xu's response to those comments, implementing it in the way you suggested (I think). | |
| 14:24:32 | fried_rice | leakypipes ...which happened while you were out of course. | |
| 14:25:16 | gregwork | does anyone know how a flavor rx/tx factor affects an instance where its networking is plumbed through ovs-dpdk (if at all) | |
| 14:25:59 | superdan | gregwork: it affects nothing anywhere | |
| 14:27:27 | gregwork | superdan: so leaving it unset when I create the flavor wont affect instances spawned by that flavor in any way ? | |
| 14:27:56 | superdan | gregwork: leaving it unset, or setting it to anything you want will have zero effect on anything anywhere at any time and in any alternate dimension | |
| 14:28:30 | gregwork | superdan: excellent, i had been concerned that my flavor might be unliked in extradimensional territories | |
| 14:29:51 | leakypipes | lol | |
| 14:30:22 | fried_rice | leakypipes Read and grokked. (I had read it previously while reviewing alex_xu's work, but I understand it better now.) It's a very clear statement of how we're going to wind up merging traits. IIUC, it's not suggesting a different design, just a different implementation of that design. | |
| 14:30:23 | leakypipes | fried_rice: shall I comment on the patch then? :) | |
| 14:30:43 | leakypipes | fried_rice: correct. | |
| 14:31:01 | fried_rice | leakypipes https://review.openstack.org/#/c/479766/10/nova/objects/resource_provider.py@2549 <== here? Sure. | |