| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-20 | |||
| 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 | leakypipes | fried_rice: that is exactly what I'm saying, yes. :) | |
| 14:33:41 | superdan | mekenmk_: see topic please | |
| 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 | |
| 14:46:03 | sean-k-mooney | mnaser: i think its a derived property of if you have associate the flavor with a tenant | |
| 14:46:34 | mnaser | sean-k-mooney: when you create a flavor you can choose for it to be public or private, once that's decided, you can't change it from public to private from what i understand | |
| 14:46:44 | mnaser | ive used flavor access with no problems (private + access to specific tenants) | |
| 14:47:19 | mnaser | im just curious behind if there was a concious decision of saying "we cant change if a flavor is public" | |
| 14:47:31 | sean-k-mooney | mnaser: horizon makes the flavor privte if you use the flavor acess property and its public otherwise | |
| 14:48:12 | mnaser | sean-k-mooney i understand, but now i have a bunch of private flavors being used by some tenants. i want to take those flavors and make them public, i have no way of doing that | |
| 14:49:21 | sean-k-mooney | mnaser: yes the only thing i can think of would be what happes if i booted form a pulic flavor and then did a rebuild or migrate after it was made private | |
| 14:49:54 | mnaser | sean-k-mooney buuuut i think in that case, nova takes the current flavor and stores it in system_metadata so there is no hard dependency on it there (i think...) | |
| 14:50:10 | mriedem | cdent: figleaf: superdan: leakypipes: i've made my rounds through the alternate host patch, all of it except for the filter scheduler tests https://review.openstack.org/#/c/486215/ | |
| 14:51:33 | sean-k-mooney | mnaser: if the rebuild uses that cached copy of the original flavor then yes but would that be what a operator wanted to happen | |
| 14:52:02 | mriedem | mnaser: yes you don't want to do edit flavor in horizon | |
| 14:52:08 | mriedem | that's a long-standing known issue, | |
| 14:52:17 | mriedem | and in pike the horizon team provided a way to disable that behavior | |
| 14:52:40 | mriedem | https://docs.openstack.org/releasenotes/horizon/pike.html#upgrade-notes | |
| 14:52:46 | mriedem | "The ability to edit flavors is disabled by default. See ENABLE_FLAVOR_EDIT in the settings documentation for more information." | |
| 14:52:51 | mnaser | mriedem any idea on what could go horrible wrong if we updated the db field to make it public (i can imagine switching to private might break things, but public *feels* ok) | |
| 14:53:14 | mriedem | i haven't read all of the scrollback here | |