| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-12-01 | |||
| 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 | |
| 10:09:26 | bauzas | we need to say we have to persist in two db tables | |
| 10:09:45 | bauzas | gibi: yup, hence my word 'broken' | |
| 10:10:03 | bauzas | in general we have object classes that are backed by a single db table | |
| 10:10:13 | gibi | I can add a generic code to _obj_from_primitives that called in both case and do the data migration genericly, but in that code I cannot decide which table to write the data back | |
| 10:10:17 | bauzas | and we directly map the object fields with the db values | |
| 10:10:35 | bauzas | gibi: agreed with your problem, this is a pain to fix | |
| 10:10:45 | bauzas | the design itself is having flaws | |
| 10:11:29 | bauzas | we somehow need to have ovo objects that know which db table they are related | |
| 10:11:47 | bauzas | but honestly, I somehow feel those necessarly have to be two different objects | |
| 10:12:04 | bauzas | we can nest objects under others | |
| 10:12:34 | bauzas | but given RequestSpecs is at the API DB, we can't just hydrate the value from the cell DB values | |
| 10:13:03 | bauzas | or, the other way to consider that, is that we only use RequestSpecs.InstanceNUMATopology as a non-persisted object | |
| 10:13:45 | bauzas | but we would need to scatter/gather the values from the cell DB before we hydrate such reqspec nested object | |
| 10:14:25 | bauzas | gibi: see ? | |
| 10:14:53 | bauzas | one way to address this would be to gather the instancenumatopology object from the cell DB at the api level before we hydrate the requestspec | |
| 10:14:55 | gibi | I'm not even sure that for a single instnace the InstanceNUMATopology in the instance and in the request spec are the saem | |
| 10:14:58 | gibi | same | |
| 10:15:21 | gibi | i.e. instance multicreate reuses a single request spec object afaik | |
| 10:15:34 | bauzas | this is fine | |