| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-12-02 | |||
| 13:55:53 | sean-k-mooney | well actully | |
| 13:55:59 | sean-k-mooney | did you update the func test | |
| 13:56:16 | sean-k-mooney | i closed the review | |
| 13:56:48 | sean-k-mooney | ok you did not | |
| 13:57:04 | sean-k-mooney | so ya release note and then you need to fix the repoduce func test | |
| 13:57:18 | gibi | sure I will add a reno | |
| 13:57:24 | sean-k-mooney | which passed... | |
| 13:57:26 | gibi | the reproduce was fixed but it is not a func test it is a unit | |
| 13:57:41 | sean-k-mooney | oh ok | |
| 13:57:45 | sean-k-mooney | ya it is | |
| 13:57:59 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/820153/1/nova/tests/unit/objects/test_request_spec.py | |
| 13:58:30 | gibi | creating a pre victoria instance in the func test is far from trivial | |
| 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 | |