| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-12-01 | |||
| 14:34:59 | artom | So that worked, though I had to disable IPv6 after rebooting to be able to connect here | |
| 14:54:41 | sean-k-mooney | ipv6 might have been the issue | |
| 14:54:47 | sean-k-mooney | if you dont have native ipv6 | |
| 15:02:21 | pslestang | Hey all, what's the next step once we created a blueprint? https://blueprints.launchpad.net/nova/+spec/delete-instance-actions | |
| 15:08:33 | sean-k-mooney | pslestang: in this case since its requesting a config option not a api change it can be added to the team meeting adgenda and you can request this to be done as a specless blueprint | |
| 15:09:28 | sean-k-mooney | pslestang: if that is approved then you just submit a patch referince the bluepirnt in the commit and topic "bp/delete-instance-actions" with a release note and docs for the new feature | |
| 15:10:22 | sean-k-mooney | pslestang: if its determined that we have upgrade conscerns or other topics that need detailed discussion then we would ask for a spec to discuss the desgin but i dont think that will be required in this case | |
| 15:11:16 | pslestang | sean-k-mooney: thanks for your answer, how can I add it to the meeting agenda? | |
| 15:17:04 | sean-k-mooney | edit https://wiki.openstack.org/wiki/Meetings/Nova and add it to the open discussion section | |
| 15:17:07 | pslestang | sean-k-mooney: ok I just edited https://wiki.openstack.org/wiki/Meetings/Nova I guess that the way to add it to the agenda | |
| 15:17:18 | sean-k-mooney | yep | |
| 15:17:25 | pslestang | thx | |
| 15:17:25 | sean-k-mooney | i see it there now | |
| 15:18:26 | sean-k-mooney | by the way my summary is correct yes? you want a new config option to automitcally fully delete instance actions on instance delete instead of soft deleteing them or vis versa depending on if its true or false | |
| 15:19:00 | pslestang | I want a config option to soft delete instance action on instance delete | |
| 15:19:07 | pslestang | not a hard delete | |
| 15:21:41 | sean-k-mooney | ack can you sate that expcitly in the bz | |
| 15:21:54 | sean-k-mooney | /bz/blueprint/ | |
| 15:23:49 | sean-k-mooney | actully i just updated the whiteboard with it https://blueprints.launchpad.net/nova/+spec/delete-instance-actions | |
| 15:23:56 | pslestang | I thougth that my first line in BP description was explicit "The goal is to add an option in nova that allow the operator to choose if he wants the instance actions to be soft-deleted when an instance is soft-deleted or not." but I may miss something | |
| 15:25:10 | sean-k-mooney | what was not clear was what is the currnt behavior and if you wanted that to be an api option or config | |
| 15:25:31 | sean-k-mooney | but i think we understnad the request | |
| 15:25:50 | sean-k-mooney | part of me feel like this is a bug | |
| 15:26:12 | sean-k-mooney | e.g. we shoudl not delete the instance actions if we have only soft deleted the instnace | |
| 15:26:44 | sean-k-mooney | they shoudl only be deleted form the table when we archive the deleted rows | |
| 15:29:12 | pslestang | what you describe is actually how it works: when an instance is soft deleted, instance action are not to let the operator retrieve actions done on a soft deleted instance | |
| 15:32:21 | sean-k-mooney | pslestang: so instance is deleted and both instance and instnace actions are marked as deleted but not actully deleted today correct? | |
| 15:32:30 | opendevreview | Merged openstack/nova master: docs: Add notes about IoOpsWeigher, BuildFailureWeigher https://review.opendev.org/c/openstack/nova/+/814561 | |
| 15:32:56 | sean-k-mooney | and you want the ablity to special case instance action so that it can be deleted before the isntance is archived? | |
| 15:33:25 | sean-k-mooney | pslestang: if so this is sounding less like something we actully should do | |
| 15:34:00 | sean-k-mooney | since it would break the ablity to undelete an instnace using restore | |
| 15:49:42 | opendevreview | Dan Smith proposed openstack/nova master: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | |
| 15:51:48 | gmann | brinzhang_: ack. will check those | |
| 19:48:18 | opendevreview | Merged openstack/nova master: Remove broken tempest-full-py3-opensuse15 job https://review.opendev.org/c/openstack/nova/+/816574 | |
| 23:17:11 | opendevreview | Steve Baker proposed openstack/nova master: Allow remaining in in DELETING for ironic cleaning https://review.opendev.org/c/openstack/nova/+/813729 | |
| #openstack-nova - 2021-12-02 | |||
| 00:47:43 | opendevreview | melanie witt proposed openstack/nova master: Add stub unified limits driver https://review.opendev.org/c/openstack/nova/+/712137 | |
| 00:47:44 | opendevreview | melanie witt proposed openstack/nova master: Make unified limits APIs return reserved of 0 https://review.opendev.org/c/openstack/nova/+/712141 | |
| 00:47:44 | opendevreview | melanie witt proposed openstack/nova master: Assert quota related API behavior when noop https://review.opendev.org/c/openstack/nova/+/712140 | |
| 00:47:45 | opendevreview | melanie witt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/c/openstack/nova/+/712139 | |
| 00:47:45 | opendevreview | melanie witt proposed openstack/nova master: DNM Run against unmerged oslo.limit changes https://review.opendev.org/c/openstack/nova/+/812236 | |
| 00:47:46 | opendevreview | melanie witt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143 | |
| 00:47:46 | opendevreview | melanie witt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142 | |
| 00:47:47 | opendevreview | melanie witt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749 | |
| 00:47:47 | opendevreview | melanie witt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707 | |
| 00:47:49 | opendevreview | melanie witt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/c/openstack/nova/+/615180 | |
| 00:47:49 | opendevreview | melanie witt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/c/openstack/nova/+/713301 | |
| 00:47:51 | opendevreview | melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499 | |
| 00:47:51 | opendevreview | melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498 | |
| 00:47:53 | opendevreview | melanie witt proposed openstack/nova master: WIP Enable unified limits in the nova-next job https://review.opendev.org/c/openstack/nova/+/789963 | |
| 00:47:53 | opendevreview | melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271 | |
| 08:52:25 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1952941 https://review.opendev.org/c/openstack/nova/+/820121 | |
| 09:07:45 | gibi | if somebody has good ideas how to do a proper OVO data migration (including writing the upgraded data back to the DB) in case an OVO is persisted in two different tables (instance_extra.numa_topology and request_spec.numa_topology) then let me know. See ^^ as reference | |
| 09:09:16 | gibi | I can create a solution that has two separate code patch one for the instance_extra and one for the request_spec case but that is i) ugly ii) does not generic enough to handle the case when object will be persisted in a 3rd table iii) create a bad precedence for future OVO data migrations | |
| 09:51:59 | bauzas | morning | |
| 09:52:35 | gibi | bauzas: o/ good morning | |
| 09:52:42 | bauzas | gibi: we did some data migrations in the past | |
| 09:52:58 | bauzas | but if you need to update two objects, well, wow | |
| 09:53:04 | gibi | bauzas: yes, and the pcpuset one is broken :) | |
| 09:53:18 | gibi | bauzas: it is one OVO class that is persisted to two db table | |
| 09:53:39 | gibi | InstanceNUMACell is part of instance_extra.numa_topology as well as request_spec.numa_topology | |
| 09:53:43 | bauzas | I guess we don't use a same ovo object for NUMATopology ? | |
| 09:54:01 | gibi | same ovo class for both | |
| 09:54:02 | bauzas | lemme look at your bug above ^ | |
| 09:54:07 | gibi | sure | |
| 09:54:07 | bauzas | hah | |
| 09:54:19 | gibi | I'm hacking on a soluiton atm | |
| 09:59:36 | bauzas | okay, I think I understand the problem | |
| 10:02:10 | bauzas | we updated instance_extra | |
| 10:02:28 | bauzas | when we called the InstanceNumaTopology object | |
| 10:03:15 | bauzas | but if you don't hydrate this object this way, we don't update it | |
| 10:03:39 | gibi | yepp | |
| 10:03:42 | bauzas | I thought we had an db upgrade too before moving to Wallaby then | |
| 10:03:55 | bauzas | at least a nova-upgrade check | |
| 10:04:18 | bauzas | telling that some objects weren't updated | |
| 10:04:33 | gibi | I don't think so as the code still has todos to remove the migration code once we are sure the the objects are loaded once | |
| 10:04:37 | bauzas | at least that's what I'd do if I would write some upgrade change | |
| 10:04:43 | gibi | but even if we had a blocking migration that would miss request spec too | |
| 10:05:09 | bauzas | gibi: because we persist it in the RequestSpec API DB ? | |
| 10:05:16 | gibi | yewpp | |
| 10:05:17 | gibi | yepp | |
| 10:05:29 | bauzas | ok I see the problem | |
| 10:05:42 | bauzas | so in theory the cell db is upgraded | |
| 10:05:46 | gibi | I assume that if we forgot to migrate the request spec then we forgot to add a blocking migration for that too | |
| 10:05:54 | bauzas | but the api db continues to have old values | |
| 10:05:59 | gibi | yes | |
| 10:06:20 | gibi | or more precisely when an instance is loaded it has a proper value, but if a request spec is loaded it has still the old value | |
| 10:06:26 | bauzas | ok, so we need to use this migrate method for the requestspec object then | |
| 10:06:41 | bauzas | gibi: yup, understood | |
| 10:06:47 | gibi | yes, but we need to split the code as in case of request spec we need to persist the updated value to a different table | |
| 10:06:52 | gibi | hence my pain | |
| 10:06:57 | bauzas | hah | |
| 10:06:59 | gibi | it is ugly and non generic | |
| 10:07:03 | bauzas | got it | |
| 10:07:26 | bauzas | well, this should have been done this way in Victoria either way, right? | |
| 10:08:15 | bauzas | problem is, we assume that InstanceNumaTopology object is only persisted by instance_extra db table | |
| 10:08:18 | bauzas | right?N | |
| 10:09:00 | gibi | right | |
| 10:09:03 | bauzas | if so, the object is broken | |
| 10:09:13 | bauzas | I mean the object persistency | |
| 10:09:24 | gibi | the problem is that the InstanceNUMATopology object does not know that it is used in two differnt context | |