| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-20 | |||
| 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 | |
| 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 | |
| 14:53:33 | mnaser | mriedem: tl;dr - we have a private flavor we shared with a few projects, we want to expose it to all projects now | |
| 14:54:23 | mriedem | can't just create a new flavor with the same attributes except it's public? | |
| 14:54:45 | mnaser | mriedem could do so, but i feel like given the uuid will change it might break users that called the flavor by uuid? | |
| 14:54:45 | mriedem | otherwise i'm not sure off the top of my head what could go wrong if you make a private flavor public | |
| 14:55:01 | superdan | there's no uuid | |
| 14:55:04 | mriedem | mnaser: well the users that have access to the private flavor and are calling it that way won't change right? | |
| 14:55:12 | mriedem | flavorid i assume he means | |
| 14:55:19 | mriedem | yoda talk like i do today | |
| 14:55:43 | mriedem | mnaser: new flavor would have a different flavorid yes | |
| 14:55:51 | mriedem | but projects using the old private flavor won't be broken | |
| 14:55:57 | mriedem | they'll continue to reference the private flaovr | |
| 14:55:59 | mriedem | *flavor | |
| 14:56:18 | mnaser | (don't shoot me, but then they'll end up with two visible flavors with the same name) | |
| 14:56:18 | sean-k-mooney | :) mriedem if mnaser kept both flavor yes but that also may confuse them if they are seching progrmaticlaly for the flavor | |
| 14:56:52 | sahid | mriedem: yesterday you told me that "it's not on your list" do you suggest me to ask somebody else to review, the specs because it's not your area of expertise? | |
| 14:57:18 | mriedem | mnaser: a tenant user would only see flavors they have access to right? | |
| 14:57:24 | mriedem | so they'll see public flavors, | |
| 14:57:28 | sean-k-mooney | mnaser: yes boots with the flavor name would now fail becuase we cant do the horible name to flavior id mapping we do today | |
| 14:57:30 | mriedem | and private flavors that their project has access to, | |
| 14:57:46 | mriedem | so yeah if the flavor name was the same for both the public and private i could see some confusion, but you said they were using the flavorid | |
| 14:58:07 | mriedem | also, i think flavor.name has a unique constraint on it | |
| 14:58:32 | mriedem | sahid: yes cpu pinning is not anywhere near my area of expertise | |
| 14:58:53 | mriedem | yup | |
| 14:58:54 | mriedem | schema.UniqueConstraint("name", name="uniq_flavors0name")) | |
| 14:59:09 | mriedem | mnaser: so it would have to have a unique name for the public version of the flavor, | |
| 14:59:16 | mnaser | ok so that wouldn't even work, boo | |
| 14:59:28 | mriedem | you can tweak the db, but i can't say for sure if anything bad will happen | |
| 14:59:40 | sahid | mriedem: ok, i will probably ask leakypipes... | |
| 14:59:43 | mriedem | going from private -> public seems ok | |
| 14:59:51 | mriedem | public -> private would obviously be bad | |
| 14:59:57 | mriedem | sahid: we're also past spec freeze | |
| 15:00:11 | mriedem | and we already have a lot of stuff approved | |
| 15:00:20 | sahid | mriedem: so both of my specs are not going to pass? | |
| 15:00:44 | mriedem | sahid: you're not the only person with specs that aren't approved right now | |
| 15:00:53 | sean-k-mooney | mriedem: the only case i can see breaking for public -> private is rebuild or migrate actions but even then they may be ok if the use the instance cached flavor? | |
| 15:00:54 | sahid | no worries, just asking | |
| 15:01:05 | mriedem | the more time we spend reviewing specs forever and adding more stuff to the list, the less time we focus on anything like nested RPs and VGPUs | |