Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-20
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
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 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:32 mriedem sean-k-mooney: rebuild and migrate actions use the embedded instance.flavor
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 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: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..."
15:13:01 mriedem mnaser: clearly you have too much time on your hands :P
15:13:22 sean-k-mooney our current private cloud is only using 10 of the 40 nodes its ment to be deployed on so i can keep the old run running while i bring up the new one.
15:13:22 mnaser ahaha
15:13:43 mnaser well hey mriedem if it's cool to know work is actively wanted/needed
15:14:03 mnaser https://blueprints.launchpad.net/nova/+spec/deprecate-file-injection => literally customer right now "upon rebuild, is there a way to send userdata script?"
15:14:32 fallenour_ YAY PEOPLE!
15:15:04 fallenour_ has anyone ever seen an issue where config applies ceph osd devices, and registers OSD devices, but doesnt show them in openstack-dashboard under hypervisors for the compute nodes?
15:15:33 fallenour_ deployment method: conjure-up ; cloud version: xenial:pike
15:15:47 mnaser fallenour_ - please have a look at the topic, i'd suggest #openstack :)
15:16:05 mnaser and given that seems to be deployment tool related, i'd suggest #ubuntu-server

Earlier   Later