| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-20 | |||
| 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. | |
| 14:32:42 | mekenmk_ | https://pastebin.com/zrBSLtMn | |
| 14:32:47 | fried_rice | leakypipes Because I still don't understand what approach you're suggesting on that piece of code. Whatever we do there is going to result in *some* kind of behavior in this scenario. I guess you're saying we just pick one, knowing it's buggy, and leave a TODO explaining in what way it's buggy? | |
| 14:32:49 | mekenmk_ | An additional information is that if I restart the instance. he migration work | |
| 14:32:53 | sean-k-mooney | kindo of related to this work superdan leakypipes do you remember the call wew had relating to vswitch hardware offload a few months ago. | |
| 14:32:54 | mekenmk_ | i'm using Redh-Hat 7.4 | |
| 14:33:41 | superdan | mekenmk_: see topic please | |
| 14:33:41 | leakypipes | fried_rice: that is exactly what I'm saying, yes. :) | |
| 14:33:47 | sean-k-mooney | superdan: leakypipes we discussed adding a nova compute config option to label pic devices with traits statically, we breifly discussed that at the ptg | |
| 14:33:59 | mekenmk_ | sorry @superdan | |
| 14:34:08 | sean-k-mooney | superdan: leakypipes is that still something we want to do in queens | |
| 14:34:14 | leakypipes | sean-k-mooney: no | |
| 14:34:54 | leakypipes | sean-k-mooney: I think you're referring to the conversation where we discussed having like an inventory.yaml file on the compute node that would store static device information and things like that? | |
| 14:35:43 | sean-k-mooney | leakypipes: thats what it evolved into at the ptg. it started with just an extra config item to suplement the whitlist that would be used to tag the devices with traits | |
| 14:36:25 | leakypipes | sean-k-mooney: yeah. I'm not a huge fan of adding yet more configuration options, but yes, I remember that being a proposed solution. | |
| 14:37:08 | sean-k-mooney | leakypipes: cool if we want to defer that to rocky with the rest of the generic device stuff i think thats fine | |
| 14:37:22 | leakypipes | sean-k-mooney: yup, my thoughts exactly. | |
| 14:38:30 | sean-k-mooney | leakypipes: by the way i taught you were going to be taking some time off as part of your move to the company that rhymes with horizon | |
| 14:38:59 | mnaser | i can understand why flavors are immutable but why is the public property of them immutable as well? | |
| 14:39:14 | leakypipes | sean-k-mooney: I took last Wednesday to Wednesday off :) | |
| 14:39:31 | leakypipes | sean-k-mooney: I start at Verizon on Monday... | |
| 14:39:40 | sean-k-mooney | leakypipes: ah welcome back, fell refreshed :P | |
| 14:39:48 | leakypipes | sean-k-mooney: slightly :) | |
| 14:40:00 | leakypipes | mnaser: not sure :( | |
| 14:40:26 | mnaser | i'm trying to imagine things that can go wrong if we edit the db field | |
| 14:40:28 | mnaser | and im not seeing much | |
| 14:40:35 | sean-k-mooney | mnaser: what properties exactly are you refering too? | |
| 14:41:32 | mnaser | sean-k-mooney: os-flavor-access:is_public | |
| 14:42:00 | sean-k-mooney | mnaser: i belive you can change that as an admin | |
| 14:42:28 | mnaser | sean-k-mooney really? i looked at the api-ref doc and it doesnt show POST /flavors/{flavor_id} as a thing | |
| 14:43:32 | mnaser | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/flavors.py | |
| 14:43:33 | mnaser | i dont see it | |
| 14:43:58 | sean-k-mooney | mnaser: huh just tried the flavor id changes each time i update the acess so ya its imutable | |
| 14:44:24 | mnaser | sean-k-mooney i think horizon deletes and creates a new flavor | |
| 14:44:57 | sean-k-mooney | mnaser: ah perhaps i can try it from the command line but that would explain what im seeing | |
| 14:45:04 | mnaser | https://bugs.launchpad.net/horizon/+bug/1311561 | |
| 14:45:05 | openstack | Launchpad bug 1311561 in OpenStack Dashboard (Horizon) "editing a flavor changes it's ID" [Undecided,Won't fix] | |
| 14:45:24 | mnaser | i couldnt even find a a CLI option to edit because the api doesn't even have a way of editing things | |