Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-20
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..."
15:13:01 mriedem mnaser: clearly you have too much time on your hands :P
15:13:22 mnaser ahaha
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: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
15:16:18 sean-k-mooney fallenour_: as what? they should not appear in localstorage. its ceph...
15:16:37 mnaser thanks superdan :D
15:17:04 fallenour_ mnaser: yes, I understand, I am trying to create a massive online development infrastructure as a service for free, so it koalafies? and its a nova issue o.o
15:17:42 mriedem mnaser: cool - keep in mind the input we got in the ML asking if we should do that got that into the spec :)
15:17:48 mriedem so keep it coming
15:17:49 superdan fallenour_: this channel is for nova development, not getting help with nova (see topic)
15:17:58 fallenour_ sean-k-mooney: I understand that, thats the issue, its configured to use ceph, but its only showing I have 140 gb of storage per node, and I hsould have 2.19 tb on the stack
15:18:23 fallenour_ superdan: roger, will take it to pms. My apologies. hard for me to do anything with it if baseline isnt working for me though :(
15:18:43 mnaser fallenour_ the problem isn't nova, the problem is the deployment tool not doing the job, hence suggesting #ubuntu-server :)
15:19:24 sean-k-mooney fallenour_: im guessing your missing the nova config option that make nova use rbd for all guest storage
15:19:45 sean-k-mooney fallenour_: with that set it will report 2.19TB pernode and be equally wrong
15:23:18 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform instance.resize_revert notification https://review.openstack.org/396811
15:27:44 openstackgerrit Takashi NATSUME proposed openstack/nova master: Add a warning in 'nova-manage cell_v2 delete_cell' https://review.openstack.org/513771
15:57:44 openstackgerrit Eric Fried proposed openstack/nova master: Test alloc candidates with same RC in cn & shared https://review.openstack.org/513149
15:58:35 fried_rice cdent gibi Okay, I reworked ^ to "pass" with comments, and extracted it from alex_xu's chain so it can merge without it.
15:59:29 cdent does anybody remember a bug (and fix) where a disk related cache being wrong could cause the disk could go away, especially after a resize?
15:59:40 cdent fried_rice++
16:01:12 cdent I have a memory of that, but haven’t got enough info to search well
16:01:20 leakypipes gibi: hey. so on the "re-parenting a resource provider" thing.
16:01:38 leakypipes gibi, superdan: I think it would be easier to just prevent re-parenting on update for right now.
16:01:59 leakypipes and add in functionality to re-parent at some later time when we can deal with that potential use case.
16:02:40 fried_rice leakypipes Agree almost totally. We ought to be able to set the parent of a RP if it's currently null.
16:02:48 cdent mdbooth: you remember that bug (a few lines up)?

Earlier   Later