| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-19 | |||
| 13:36:27 | sean-k-mooney | the instance action rows are marked as deleted (but still present) and then archive later | |
| 13:36:45 | sean-k-mooney | and only delete when we purge deleted rows form the shadow tables | |
| 13:57:06 | bauzas | sean-k-mooney: done and don | |
| 13:57:08 | bauzas | done* | |
| 13:57:42 | bauzas | sean-k-mooney: I was currently looking at my RP labels | |
| 14:49:58 | opendevreview | Balazs Gibizer proposed openstack/nova stable/victoria: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818559 | |
| 15:03:12 | pslestang | sean-k-mooney: the behavior we have today is that on archiving all instances and their correponding rows (so instance actions) are moved in the shadows table | |
| 15:05:05 | pslestang | sean-k-mooney: when purging, instances and corresponding rows are deleted based on deleted_at column except for instance_actions, instance_actions_events (and task_log if I remember well) for which the deletion is based on created_at | |
| 15:12:41 | bauzas | folks, have a good weekend | |
| 15:21:13 | gibi | bauzas: o/ | |
| 15:21:15 | gibi | same to you | |
| 15:33:14 | opendevreview | Balazs Gibizer proposed openstack/nova stable/ussuri: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818564 | |
| 16:05:08 | opendevreview | Gustavo Santos proposed openstack/nova master: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/815373 | |
| 16:34:55 | opendevreview | Stephen Finucane proposed openstack/nova master: Use unittest.mock instead of third party mock https://review.opendev.org/c/openstack/nova/+/714676 | |
| 16:42:06 | opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818598 | |
| 16:50:18 | opendevreview | Artom Lifshitz proposed openstack/nova master: api-ref: server rescue adminPass injection is conf-dependant https://review.opendev.org/c/openstack/nova/+/818022 | |
| 16:51:30 | opendevreview | Balazs Gibizer proposed openstack/nova stable/stein: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818601 | |
| 16:53:39 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add PCI VPD Capability Handling https://review.opendev.org/c/openstack/nova/+/808199 | |
| 16:53:40 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Support remote-managed SmartNIC DPU ports https://review.opendev.org/c/openstack/nova/+/812111 | |
| 16:56:34 | opendevreview | Balazs Gibizer proposed openstack/nova stable/rocky: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818604 | |
| 17:00:05 | opendevreview | Balazs Gibizer proposed openstack/nova stable/queens: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818605 | |
| 17:05:21 | opendevreview | Balazs Gibizer proposed openstack/nova stable/rocky: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818604 | |
| 17:07:41 | opendevreview | Balazs Gibizer proposed openstack/nova stable/queens: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818605 | |
| 17:09:59 | opendevreview | Balazs Gibizer proposed openstack/nova stable/queens: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/818605 | |
| 17:13:17 | opendevreview | Balazs Gibizer proposed openstack/nova stable/pike: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/813437 | |
| 17:54:38 | johnthetubaguy[m] | dansmith: just had a thought, if you delete a project in keystone, but now you need a project token to delete a server, the operator could get in quite a bad place now? Or is there something I am missing there? | |
| 17:55:28 | dansmith | johnsom: hmm | |
| 17:56:29 | johnsom | dansmith Wrong nic? o/ John | |
| 17:56:43 | dansmith | yes, sorry | |
| 17:56:50 | dansmith | johnthetubaguy[m]: hmm | |
| 17:57:00 | johnsom | NP | |
| 17:57:19 | sean-k-mooney | johnthetubaguy[m]: ya even domain scopetd tokens wont work | |
| 17:57:29 | sean-k-mooney | cause the proejct is gone | |
| 17:57:37 | sean-k-mooney | can we just say dont do that :P | |
| 17:57:47 | dansmith | yeah, they'd still be able to list those instances, | |
| 17:57:49 | johnthetubaguy[m] | ... now I think you create a project with a known uuid, but not if you deleted an old one | |
| 17:58:09 | johnthetubaguy[m] | yeah, you can still see them and find the project uuid at least | |
| 17:58:12 | sean-k-mooney | johnthetubaguy[m]: i tought the uuid was not user setable when creating users and proejcts | |
| 17:58:18 | dansmith | but we'd have to have some workaround, like if you delete with a domain scoped token, use the project id of the instance while deleting or something | |
| 17:58:36 | dansmith | I think deleing projects in keystone before the resources are cleaned up is a general problem too right? | |
| 17:58:41 | dansmith | like, because you have to remember to do that today | |
| 17:58:47 | johnthetubaguy[m] | sean-k-mooney: just checking, I remember it being wanted for region <-> region sync | |
| 17:58:48 | dansmith | s/that/that cleanup/ | |
| 17:59:25 | johnthetubaguy[m] | I mean, its about getting a token for the correct project uuid, maybe that is allowed for deleted ones in certain cases, possibly... | |
| 17:59:30 | sean-k-mooney | dansmith: well because admin is god today i think you can fix some of those issue on a project by project basis | |
| 17:59:56 | sean-k-mooney | as in most porject allow you to list reouces by projects | |
| 17:59:56 | dansmith | sean-k-mooney: right I know today it works | |
| 18:00:18 | johnthetubaguy[m] | (as an aside, why my brain thinks up these things at 6pm on a Friday, is beyond me!) | |
| 18:00:20 | opendevreview | Gustavo Santos proposed openstack/nova master: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/815373 | |
| 18:01:13 | sean-k-mooney | johnthetubaguy[m]: part of the probelm is there is nothing keystone can do to prevent you deleteing the project as it never know if its in use today | |
| 18:01:44 | sean-k-mooney | well unified limits/placment might help | |
| 18:01:50 | johnthetubaguy[m] | yeah, its nasty, I remember the os-purge discussions in berlin (and a few other places) | |
| 18:02:01 | sean-k-mooney | but we dont track all resouce in palcment so not really | |
| 18:02:29 | johnthetubaguy[m] | sean-k-mooney: you are correct on the uuid thing, we don't allow that in create (yet!) https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=create-project-detail#create-project | |
| 18:02:49 | dansmith | having to re-create the project to clean up the resources is pretty gross anyway, | |
| 18:02:57 | dansmith | so I don't know that we should depend on that for this problem | |
| 18:03:57 | johnthetubaguy[m] | yeah, I was more fixed on: "how to get me a project xyz token again", and possible ways to do that, which might be the wrong question | |
| 18:04:14 | dansmith | right I know | |
| 18:04:28 | dansmith | so, even though it's a hack, | |
| 18:04:39 | dansmith | if you show up with a domain-scoped token trying to delete an instance, | |
| 18:04:46 | dansmith | oh actually, | |
| 18:05:09 | sean-k-mooney | ithe issue with domain is the project is not part of the domain anymore | |
| 18:05:13 | dansmith | I was about to say "we can do the same is this instance in this domain? yes? then delete and use context.project_id=instance.project_id" | |
| 18:05:16 | opendevreview | Gustavo Santos proposed openstack/nova master: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/815373 | |
| 18:05:16 | sean-k-mooney | sicne we deleted it | |
| 18:05:18 | dansmith | right | |
| 18:05:18 | dansmith | but we don't know what domain it was from | |
| 18:05:45 | sean-k-mooney | so we could start storign the domain in nova | |
| 18:05:57 | johnthetubaguy[m] | although then if I delete a federation domain, then go whoops lots of instances, we might be back in the same problem | |
| 18:06:08 | dansmith | well, right so that would be the longer-term "nova actually knows about domains" thing | |
| 18:06:08 | sean-k-mooney | then we can say ha you are a domain admin and this belogs to that domain so sure delete away | |
| 18:06:27 | dansmith | sean-k-mooney: yep | |
| 18:06:27 | johnthetubaguy[m] | I don't mind going to keystone for the project_id doesn't match and you are a domain token case, its admin, doesn't need to be that efficient? | |
| 18:06:46 | dansmith | johnthetubaguy[m]: but the project is gone, so we can't tell if the project is in the domain you're in | |
| 18:06:53 | dansmith | because we can't look it up anymore | |
| 18:07:01 | sean-k-mooney | keystone dose not allwo you to move projet between domains right | |
| 18:07:02 | johnthetubaguy[m] | doh, of course | |
| 18:07:08 | dansmith | (unless it's soft-deleted in keystone?) | |
| 18:07:51 | johnthetubaguy[m] | although if you delete the domain as well? (like delete the customer that had its own domain, or delete some federation thing) | |
| 18:08:24 | sean-k-mooney | johnthetubaguy[m]: we would need to use a system scopted token or a new type of token at that point | |
| 18:08:26 | dansmith | johnthetubaguy[m]: even the old plan of system scoped users being god has this same problem really.. we'd still need to do something hacky to decide what project_id to record in the instance action, since that non-project god user showed up to delete it | |
| 18:09:11 | dansmith | we'd know you have permission because you're god, but the delete would 500 today until we fix the assumption that project_id!=None | |
| 18:09:17 | sean-k-mooney | well yes but we could use all 0 as you have suggesed before | |
| 18:09:21 | johnthetubaguy[m] | I mean we have the all zeros project uuid to play with, but maybe this only matters to the delete call? | |
| 18:09:37 | johnthetubaguy[m] | at least its a super edge case | |
| 18:09:42 | dansmith | sean-k-mooney: right, point being that same hack/workaround would have been needed anyway | |
| 18:10:06 | sean-k-mooney | yep and we also have the problem of deleteing the nova created resocues in other projects | |
| 18:10:15 | sean-k-mooney | which might just be the vms prots | |
| 18:10:16 | dansmith | true | |
| 18:10:26 | sean-k-mooney | althoguh bfv so also cinder | |
| 18:10:36 | johnthetubaguy[m] | hmm, very true | |
| 18:11:07 | sean-k-mooney | we could use our admin token for those service if we needed too in this case but im not sure that will work | |
| 18:11:29 | sean-k-mooney | if we assume our neutron section has a domain scoped admin token on the root domain | |
| 18:11:39 | sean-k-mooney | since the project is gone it will still be invalid | |
| 18:12:20 | dansmith | the whole project deletion before cleanup thing is really pretty problematic | |
| 18:12:23 | sean-k-mooney | maybe we need to jsut check "has role admin and project does not exist" | |
| 18:12:40 | dansmith | well, that's a good thought | |
| 18:12:50 | dansmith | it's a little more power than you expect | |
| 18:12:55 | sean-k-mooney | we are defineing admin now as alwasy the oeprator of the cloud right | |
| 18:13:07 | dansmith | today all domain admins are pretty much powerful across the hierarchy until nova knows about domains itself | |