Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-16
15:05:53 sean-k-mooney mordred: well we never added any testing to enforce it so it never will be.
15:06:03 mriedem i found out the other day that azure has a completely undocumented templating rest api and i was pretty surprised and somehow happy that even a giant closed source thing like azure has poor documentation
15:06:39 mriedem sean-k-mooney: core reviewers in nova can certainly say "i'm not going to approve your shiny nugget until i see the glance docs patch written"
15:06:48 mordred also - fwiw - in the docs, it says auto_disk_config should return true of falase
15:06:57 mordred and on rackspace it returned "disabled"
15:07:03 mordred so - you know - there's that
15:07:23 sean-k-mooney mriedem: true we have mentioned that for some of the recent windriver ones like vTPM
15:07:41 sean-k-mooney its a relitvly tirival change if you do it when you add the feature
15:07:42 mriedem mordred: auto_disk_config is a string field in the nova schema so it can be whatever as far as nova is concerned
15:07:56 mordred mriedem: awesome
15:08:22 mnaser mriedem: I'd probably avoid suggesting SIGHUP-ing things for now till we figure out the oslo.service stuff, but yeah, maybe worth restarting nova-conductor to reset its cache I guess
15:08:28 mriedem it does look like the xen driver tries to treat it as a bool though
15:08:40 sean-k-mooney mordred: you shoudl review https://review.openstack.org/#/c/638734/
15:08:49 mriedem like other booleans in the openstack rest api like 1/yes/true/True etc
15:09:22 mordred are _all_ of the extra properties liek that string fields?
15:09:27 mriedem mordred: btw, i think i kind of have a monopoly on depressing topics in this channel and i will fight you over territory
15:09:54 mordred mriedem: I will not fight back - I concede your supremacy in depressing topics in this channel
15:10:02 mriedem mordred: not all https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L233
15:10:04 mordred I claim that monopoly in #openstack-sdks
15:10:35 mriedem everything in ^ should be documented in https://docs.openstack.org/glance/latest/admin/useful-image-properties.html and in glance metadefs
15:10:38 sean-k-mooney mordred: wehre there is a finite set we restict it but where there is not we dont
15:10:47 mriedem anything not in https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L233 will fail in nova (unless you've forked nova)
15:11:11 sean-k-mooney mriedem: well if the key does not match anything in that we will allow it
15:11:26 mordred ok. so that nova file is essentally the ultimate truth
15:11:37 sean-k-mooney e.g. you can define my_randome_metadata_property=whatever
15:11:48 mriedem sean-k-mooney: ummm, are you sure?
15:11:59 sean-k-mooney yes if we cant we broke our api
15:12:15 mriedem i'm pretty sure we intentionally broke the api for this
15:12:19 mriedem and told people to upstream their forks
15:12:26 mriedem this is also why we haven't codified flavor extra specs
15:12:27 dansmith yeah, pretty sure you can have anything you want, we just enforce the format of the ones we know about
15:12:38 dansmith because otherwise you can't use some of the things like jsonfilter right?
15:12:38 sean-k-mooney operators use this for steaing guest to specific host using the image properites filter
15:13:11 mriedem the image properties filter works on like 3-4 known properties
15:13:34 mordred have I mentioed how much it sucks that images in v2 just take the extra properties in the root of the image object?
15:14:04 mriedem you mean flat rather than a special 'properties' sub-dict?
15:14:06 mordred v1's subdict where user-defined metadata went is SO MUCH JBETTER
15:14:08 mordred yeah
15:14:15 mordred flat is horrifically terrible
15:14:22 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_image_properties_isolation.py i think support all the image metadata keys
15:14:31 mriedem now you get to get the base properties and subtract anything to figure out the exras
15:14:32 mriedem weeee
15:14:36 mordred yup
15:14:59 mordred especially since some of the base properties have data types that aren't string
15:15:12 mordred so if you _don't_ deal with all of the base properties, you can be really screwed
15:15:34 dansmith mriedem: this is where we would enforce that all the ones in the dict have to be known right? https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L580-L598
15:17:10 mriedem dansmith: i believe so
15:17:15 openstackgerrit Merged openstack/nova stable/rocky: Error out migration when confirm_resize fails https://review.openstack.org/652127
15:17:30 dansmith mriedem: so, I think we only process the ones we know about, ignore anything else you throw in there
15:17:50 sean-k-mooney ya thats what im seeing too
15:18:39 mriedem i remember people bringing this up in the ML but maybe they were just saying, "my special unicorn properties doesn't make it down to my forked compute manager code, why not?"
15:18:53 sean-k-mooney i dont remember a spec for removing this so this s a regression as it s an api change
15:18:57 dansmith mriedem: that's a different thing
15:19:09 mriedem sean-k-mooney: this has been this way for *years*
15:19:19 mriedem danpb did all this work
15:19:22 dansmith mriedem: the unknown image props don't get put into the object, so the compute nodes never see them, that's definitely true
15:19:45 sean-k-mooney well the unkonw ones are for the scheduler only
15:20:25 mriedem sean-k-mooney: https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_image_properties_isolation.py#L45 is an ImageMetaProps object,
15:20:35 mriedem so if we don't know about the property, it won't be in that object and the filter can't filter on it
15:20:47 mriedem https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_image_properties_isolation.py#L56
15:22:43 dansmith same for image_props_filter
15:22:50 dansmith I guess jsonfilter is only on host state
15:23:07 mriedem yeah the jsonfilter is a whole other unvalidated piece of gorp
15:23:25 dansmith yeah, but I thought it could operate on the image too, but no
15:23:54 NewBruce heading off line for a while; bbl
15:24:14 dansmith well, anyway, we definitely removed some functionality in the image props filter when we did that, but (a) it's been a long time with no real complaint that I know of and (b) I wouldn't call it an api breakage
15:25:21 mriedem liberty https://review.openstack.org/#/c/76234/
15:25:36 dansmith er, hmm, maybe we didn't actually
15:25:46 dansmith I thought image props filter could do more generic matching, but it doesn't
15:26:02 mriedem right it's like 3 or 4 properties
15:26:07 mriedem hw version, type, arch something like that
15:26:09 mriedem very specific
15:26:15 dansmith which is why I was thinking about the jsonfilter
15:26:28 dansmith so if there's not some other filter I'm thinking of I guess we're good
15:26:39 mriedem it's AggregateImagePropertiesIsolation
15:26:46 mriedem that's the generic one
15:26:49 sean-k-mooney ok do we have teh same restion now with flavor extra specs
15:26:52 mriedem to tie aggregates to images
15:27:29 dansmith mriedem: ah, just a straight match to host meta I see
15:27:37 sean-k-mooney yes
15:27:52 sean-k-mooney this was used for think like runt this image on the NFV aggrate
15:27:56 dansmith sean-k-mooney: no such restriction with flavors
15:29:22 dansmith mriedem: mostly unrelated to this, I wanted to throw something out there just for maybe future use
15:29:30 mriedem totally unrelated to this, but there are 2 simple changes below https://review.openstack.org/#/c/570202/ (which i need for cross-cell resize as well as rebuild from cell0) that have a +2 and i'm looking for another core to hit those
15:30:21 dansmith mriedem: when I was reading the two numa specs today I was reminded of something I was thinking about earlier, related to cases where we have instances which store old-format data, like something stuck in their flavor which needs to be migrated
15:30:22 sean-k-mooney dansmith: ok i had tought we still supported "bring your own" metadata key for image too i guess not
15:31:06 dansmith mriedem: things that we would need to online_migrate or something, and things that we would be tempted to resolve with "meh, just migrate all your instances left one rack to clean those up".. kinda like the recent discussion about reshape for that stuff
15:31:30 dansmith mriedem: we might benefit from a "needs upgrade" flag on the instance, that would be shown in detailed list, to admins only,
15:31:44 dansmith where I could list all tenants and see instances that have "needs upgrade"
15:32:16 sean-k-mooney so the old usecase woulould be achive with a member_of request in the flavor extra spec
15:32:25 dansmith anything could set that flag, like compute manager when it notices some legacy data, or even libvirt when it notices something like a disk format that needs to be upgraded or something
15:32:51 mriedem dansmith: if the thing setting the flag has to already calculate that it will set the flag, why not just do the online migration right then?
15:33:31 dansmith mriedem: well, because things like the resource topology thing would need to be done to all instances on the compute node at the same time, and after a config change
15:33:45 dansmith mriedem: referring to the thing stephenfin and jaypipes and bauzas and I were discussing last week
15:34:04 bauzas FWIW, on a 1.5h meeting atm
15:34:15 bauzas but listening
15:34:45 mriedem so instances a,b,c need an upgrade, but the admin doesn't know how to upgrade them, i.e. is it migrating them, running the online_data_migrations cli, restarting the compute they are on, etc
15:35:22 mriedem if the flag were an enum that's one way
15:35:41 dansmith mriedem: yeah, so it'd be nice if we also tagged "issues" to the instance that you whittle down until the upgrade flag goes away, but I think that's too heavy for the moment.. but if we LOG.warning() for each instance that we were setting the flag on, then you would at least have a record
15:35:55 dansmith mriedem: yeah, could be iterative, like service_version

Earlier   Later