| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-20 | |||
| 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 | |
| 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 | mriedem | otherwise i'm not sure off the top of my head what could go wrong if you make a private flavor 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: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 | 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:18 | mnaser | (don't shoot me, but then they'll end up with two visible flavors with the same name) | |
| 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 | |
| 15:01:09 | mriedem | which are something you also want | |
| 15:01:17 | mnaser | i should go read code before asking this (but it's friday): if i delete the flavor, recreate it again specifying the same flavorid+name .. could i get away with it? | |
| 15:01:47 | sean-k-mooney | mnaser: we dont actully delete things in nova | |
| 15:01:49 | mriedem | mnaser: that should work... | |
| 15:02:06 | sean-k-mooney | mnaser: we make them as deleted so not sure if it will break the unique constrait | |
| 15:02:09 | mriedem | any instances created with the old flavor have it persisted already per instance | |
| 15:02:33 | mriedem | sean-k-mooney: flavors are in the api db now, | |
| 15:02:36 | mriedem | where we don't do soft delete | |
| 15:02:40 | mriedem | so if he deletes it, it's gone | |
| 15:02:51 | mriedem | it would only be persisted per instance that used it | |
| 15:02:53 | mnaser | at least that way is "supported" so we're not doing black magic that might bite us later | |
| 15:03:10 | mriedem | yeah, so if you deleted and recreated as public i think that would work | |