Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-20
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.
14:32:33 mekenmk_ Hello, can you help me Plase?
14:32:35 mekenmk_ I made a "yum update" in my computes and now when I run the live-migration command it does not migrate the instances. and I have the following error in the log.

Earlier   Later