Posted	Nick	Remark
#openstack-nova - 2017-10-20
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
15:11:17	mnaser	bofh public cloud
15:11:18	mnaser	:p
15:11:41	mriedem	writing tooling on top was super fun!
15:12:08	mnaser	i feel like it would be fun to deploy essex from essex-eol just for the fun of it and see how far we come
15:12:09	mnaser	:p
15:12:10	mriedem	"why doesn't this work? oh yeah, nova-net on essex has that one bug...let me code around that in my jenkins job..."

Earlier   Later