Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-12-02
13:58:37 gibi so I dropped that direction
13:59:10 sean-k-mooney sorry i normally expect those to be func tests but ya backporting the func test to victoria woudl be non trivail
13:59:26 sean-k-mooney in this specific case i think a unit test is ok
13:59:40 gibi not that what I meant. I mean creating a func test on master that simulates a pre Victoria instance is hard
14:00:15 gibi I would need to dig in to the DB anyhow to backlevel the data to pre-victoria as our object layer will persist the master version
14:00:34 sean-k-mooney yes so you woudl have to boot the vm
14:00:40 sean-k-mooney then update its request spec
14:00:49 sean-k-mooney then migrate it and assert it expodes
14:01:22 sean-k-mooney gibi: i assumed you ment because we willl be missing several fo the helper functions
14:01:32 gibi not that ^^
14:01:40 gibi but the "then update its request spec"
14:01:54 gibi that would be heavy DB digging in a func test
14:03:54 sean-k-mooney gibi: ya you woudl effectly have to directly execute sql
14:04:00 sean-k-mooney which i think is over kill
14:04:17 gibi and in that sql manipulate a highly nested json dict :D
14:04:18 sean-k-mooney and this is all in a json blob in the db too so its not exactly nice to update via sql either
14:04:25 sean-k-mooney exactly
14:04:25 gibi exactly :D
14:04:33 sean-k-mooney jinks :)
14:04:57 sean-k-mooney so ya its understandable that you chose to go the unit test route
14:04:58 gibi I have a downstream env where they can reproduce the issue so I will have real test result hopefully in a day
14:05:45 gibi that env is a complicated one simulating an upgrade from Mitaka to Victoria :D
14:06:02 gibi so when I say pre-Victoria instance that is actually a Mitaka instance :D
14:06:25 sean-k-mooney i suspect the only reason we have not hit this downstream is our last release was based on train
14:06:42 sean-k-mooney and the next one which will be based on wallaby is not releasing until next year
14:06:52 gibi yepp, the bug is introduced in Victoria
14:07:06 sean-k-mooney that is after the initall cpu in placement work
14:07:09 sean-k-mooney that was in train
14:07:19 sean-k-mooney this is part of the mixed cpu feature i think
14:07:55 sean-k-mooney ya part of https://specs.openstack.org/openstack/nova-specs/specs/victoria/implemented/use-pcpu-vcpu-in-one-instance.html
14:08:27 sean-k-mooney https://specs.openstack.org/openstack/nova-specs/specs/victoria/implemented/use-pcpu-vcpu-in-one-instance.html#work-items
14:08:35 sean-k-mooney it added the pcpuset filed
14:10:22 sean-k-mooney initally after the pcpu in placment change we just used cpuset since all cores were either pinned or not and we coudl tell that from teh config cpu_policy
14:10:48 gibi yepp that is my understanding too
14:14:10 opendevreview Balazs Gibizer proposed openstack/nova master: Migrate RequestSpec.numa_topology to use pcpuset https://review.opendev.org/c/openstack/nova/+/820153
14:14:18 gibi now with release notes :)
14:17:43 sean-k-mooney :)
14:17:57 sean-k-mooney ill wait for ci to finsih and ill try an re review later
14:19:34 gibi thanks
17:43:40 opendevreview Balazs Gibizer proposed openstack/nova master: [WIP]Stop persisting RequestSpec.numa_topology https://review.opendev.org/c/openstack/nova/+/820215
#openstack-nova - 2021-12-03
00:45:37 opendevreview Ghanshyam proposed openstack/nova-specs master: Allow project admin to list hypervisors https://review.opendev.org/c/openstack/nova-specs/+/793011
00:47:15 gmann dansmith: gibi addressed your comment for project-admin-list-hypervisors spec, please check https://review.opendev.org/c/openstack/nova-specs/+/793011
02:25:20 opendevreview Ghanshyam proposed openstack/nova-specs master: Allow project admin to list hypervisors https://review.opendev.org/c/openstack/nova-specs/+/793011
09:08:17 opendevreview Balazs Gibizer proposed openstack/nova master: Reproduce bug 1952941 https://review.opendev.org/c/openstack/nova/+/820121
09:08:24 opendevreview Balazs Gibizer proposed openstack/nova master: Migrate RequestSpec.numa_topology to use pcpuset https://review.opendev.org/c/openstack/nova/+/820153
09:08:55 gibi gmann: ack. I'm swamped with downstream issues, but I will try to get back to the spec
09:13:33 opendevreview Balazs Gibizer proposed openstack/nova master: Migrate RequestSpec.numa_topology to use pcpuset https://review.opendev.org/c/openstack/nova/+/820153
09:56:48 bauzas melwitt: I didn't know Depends-On works with a HTML link
09:56:54 bauzas context : https://review.opendev.org/c/openstack/nova/+/812236
09:57:11 bauzas melwitt: are you sure you use the dependent change ?
09:57:43 bauzas (ie. for me, I was thinking you need to provide a Gerrit change-id and not a link)
10:15:27 bauzas melwitt: nevermind my ping, I was wrong, this works as we can see it in https://zuul.opendev.org/t/openstack/build/9df08666e366407b9c35e09a603d8358/log/job-output.txt#5380
10:25:02 opendevreview Rajat Dhasmana proposed openstack/nova master: WIP: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368
11:14:19 lyarwood bauzas: yeah that has worked for a while, I think it's actually preferred by the zuul devs
12:07:23 opendevreview Lee Yarwood proposed openstack/nova master: libvirt: Ensure all volume drivers log the instance whenever possible https://review.opendev.org/c/openstack/nova/+/780260
12:07:44 opendevreview Lee Yarwood proposed openstack/nova master: Add regression test for bug #1937084 https://review.opendev.org/c/openstack/nova/+/812126
12:07:45 opendevreview Lee Yarwood proposed openstack/nova master: block_device: Ignore VolumeAttachmentNotFound during detach https://review.opendev.org/c/openstack/nova/+/812127
12:08:24 opendevreview Lee Yarwood proposed openstack/nova master: libvirt: Create qcow2 disks with the correct size without extending https://review.opendev.org/c/openstack/nova/+/779275
12:08:53 opendevreview Lee Yarwood proposed openstack/nova master: nova-next: Drop NOVA_USE_SERVICE_TOKEN from subnode https://review.opendev.org/c/openstack/nova/+/816740
12:09:05 opendevreview Lee Yarwood proposed openstack/nova master: nova-next: Deploy noVNC from source instead of packages https://review.opendev.org/c/openstack/nova/+/816738
12:09:27 lyarwood ^ just rebasing various things that are ready for review if cores have time
13:28:53 opendevreview Gabriel Silva Trevisan proposed openstack/nova master: [WIP] Set resize claim resource when changing host https://review.opendev.org/c/openstack/nova/+/820381
15:36:13 rloo Hi, we have some downstream info that we put in nova server's metadata (via --property) when doing a create or rebulid. I didn't see anything explicit about this so wanted to confirm. In the rebuild, if any metadata was explicitly specified as part of the rebuild command, that metadata replaces the server's metadata, so eg keys specified in the create that weren't explicitly specified in the rebuild, are gone. Is that the expected
15:36:13 rloo behaviour? (https://opendev.org/openstack/nova/src/commit/7670303aabe16d1d7c25e411d7bd413aee7fdcf3/nova/compute/api.py#L3640)
16:49:35 gmann gibi: thanks
17:07:00 sean-k-mooney rloo: i dont think rebuild allows updating metadta it only allows updateing user-data
17:07:04 sean-k-mooney they are not the same thing
17:08:19 sean-k-mooney so if you use --property to update teh instance metadata the isntance metadata shoudl still be preserved but an image metadtaa will be updated form the new image and that will replace it
17:08:36 sean-k-mooney and if you speciy new user data on rebuild that shoudl also update the user data
17:08:47 rloo i'm interested in the instance metadata, not the user data.
17:09:52 sean-k-mooney hum it looks like metadta can be inclded in teh rebuild instance action https://docs.openstack.org/api-ref/compute/?expanded=rebuild-server-rebuild-action-detail#rebuild-server-rebuild-action
17:10:23 sean-k-mooney i would expect that to replace all metadta if specifed
17:10:45 sean-k-mooney i would conder it a bug if it only did a partila update
17:10:49 sean-k-mooney which behavior are you seing
17:10:55 rloo i believe the userdata part is correct. but the code that handles metadata looks like it replaces the server's metadata (wahtever was there), with metadata specified in the rebuild. i didn't test, but i think eg 'openstack server create myinstance --property foo=atcreate', then 'openstack server rebuild myinstance --property bar=atrebuild', the server will only have property 'bar=atrebuild'.
17:11:24 sean-k-mooney rloo: well full replacemnt not partil update is what i would expect
17:11:57 rloo so what you describe is what I see. why do you expect full replacement? (my mental model is diff so want to grok)
17:13:18 sean-k-mooney well partly because this is a post/put not a patch then openstack apis generally do not support a paritl update approch
17:13:39 sean-k-mooney it would be strange if this api did when the othere are typicaly a full replacemnt
17:13:40 rloo from user/my point of view, I don't know why i'd want to specify all the properties at rebuild. eg if no properties are specified at rebuild, i get the properties from create. if i specify one property value at rebuild, that wipes out all the properties at create.
17:14:06 sean-k-mooney rloo: well if you do a merge it wont be idompoented as it will depend on the existing state
17:14:24 sean-k-mooney the real question is what do we do it you do not specify it
17:15:01 rloo if no property is specified in the rebuild command, the existing properties are used.
17:15:17 sean-k-mooney ok so that is where the discontinuty might arise
17:15:56 sean-k-mooney we are effectily calling https://docs.openstack.org/api-ref/compute/?expanded=replace-metadata-items-detail#replace-metadata-items
17:16:29 sean-k-mooney rloo: your expection is that we woudl iterate over teh item and only update them
17:16:34 rloo I don't use the --key-name thing, but I am guessing that is similar behaviour? if one key pair is specified in the rebuild, any existing key pairs are gone?
17:16:40 sean-k-mooney but then you could not remove metadta on rebuild only modify or add
17:16:46 sean-k-mooney with the current approch you can do both
17:16:47 rloo yes, that's my expectation. that the new value for key is used.
17:17:10 sean-k-mooney so as the api is today that is not how its ment to work
17:17:16 rloo new value for the specified property (key) is used.
17:17:27 sean-k-mooney we would losue functionality if we change it without adding a way to remove keys
17:18:12 rloo well, one can set/unset via 'openstack server set', 'openstack server unset'
17:18:40 sean-k-mooney yep which would be a valid way to achive your goa
17:18:47 sean-k-mooney rebuidl with current metadata and then update
17:19:26 sean-k-mooney the alterniive is get the meddtata, update it client side and pass the desired state to rebuidl
17:19:40 rloo except that we (downstream) need the values for the rebuild operation itself. and our users don't think they have to set them if they've already set them. they just want to change one of the properties/metadata fields.
17:20:21 rloo i can do a downstream patch for this, just wanted to grok what the upstream/intent was, to figure out if we need to carry this patch downstream forever or not.
17:20:40 sean-k-mooney which downsteam?

Earlier   Later