Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-20
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
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
15:03:14 sean-k-mooney mriedem: ya i just tested it on the commandline too
15:03:24 sean-k-mooney mriedem: it works on newton
15:03:32 mriedem mnaser: i think you'd want to be sure to recreate with the same flavorid
15:03:51 mnaser yeah, that would be the most important thing, same flavorid, same name, make sure we keep the extra_specs there too
15:04:32 mriedem sean-k-mooney: rebuild and migrate actions use the embedded instance.flavor
15:04:32 mnaser mriedem sean-k-mooney thank you so much for the back-and-forth, it's helpful and i guess this explains why the flavors edit thing isn't necessary, as you can recreate the flavor with the same exact state (as you have control over flavorid)
15:04:43 sean-k-mooney mnaser: doing that though would be the same as jsut chaning the db flag though right
15:05:04 mriedem sean-k-mooney: public -> private would be bad because anyone relying on a given flavorid/name in their tooling would be broken if they didn't have private access to the flavor
15:05:21 mnaser sean-k-mooney but cleaner, such as it will probably clean up and remove any tenant access assignments that shouldn't be there (in the case of a public flavor)
15:05:27 sean-k-mooney mriedem: oh yes i know i ment form a internal nova point of view
15:05:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225
15:06:03 sean-k-mooney mnaser: ah yes that would be a delta between the dirct update
15:06:03 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225
15:06:07 mnaser and that way, nova is healthy in a way that we don't have a broken upgrade because some migration tries to change things around later and has these weird inconsistent flavors or so
15:06:45 mnaser probably the one thing i learned the most (and in the hardest way) is that quick fixes make your installation unpredictable, so upgrades become a pain because you're hitting these weird corner cases
15:07:56 sean-k-mooney mnaser: also dont deploy resealse candiates into production for you internal dev cloud... i proably could upgrade it but its easier to redeploy
15:08:35 mnaser i cant imagine rc => release should be too problematic? unless the rc's had an issue that mangled your db up;
15:09:01 mriedem if it did, the fix would have to account for it
15:09:05 mriedem each commit is a release
15:09:09 mriedem assumed to be deployed
15:09:19 mriedem at least round these parts
15:10:01 sean-k-mooney mnaser: true but to get to pike i would have to do rc -> newton, enable placement newton-> ocata, enable cells v2, ocata-> pike
15:10:20 sean-k-mooney or i can just deploy pike
15:10:38 mnaser well in our case we can't just shut down our entire cloud and redeploy it :D
15:10:43 mriedem heh, was going to say,
15:10:46 mriedem not so easy with a public cloud
15:11:16 mriedem that's why at my old dept in ibm we had an essex cloud, a folsom cloud, and a juno cloud at some point

Earlier   Later