| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-19 | |||
| 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 | dansmith | sean-k-mooney: right I know today it works | |
| 17:59:56 | sean-k-mooney | as in most porject allow you to list reouces by projects | |
| 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 | sean-k-mooney | sicne we deleted it | |
| 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:18 | dansmith | but we don't know what domain it was from | |
| 18:05:18 | dansmith | right | |
| 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 | 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:08 | dansmith | well, right so that would be the longer-term "nova actually knows about domains" thing | |
| 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:27 | dansmith | sean-k-mooney: yep | |
| 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 | |
| 18:13:11 | dansmith | so maybe that's not so bad? | |
| 18:14:19 | johnthetubaguy[m] | how do we know the poject doesn't exist? we go check keystone in the case where context.project_id != instance.project_id ? | |
| 18:14:39 | dansmith | you show up for the delete with a domain token, | |
| 18:14:45 | dansmith | which means we go to do the "is this in your domain" check, | |
| 18:14:49 | johnthetubaguy[m] | ah, only with domain tokens, right | |
| 18:14:51 | dansmith | and if the project is 404 we assume yes | |
| 18:15:35 | johnthetubaguy[m] | ah, right, I quite like that 🤔 | |
| 18:15:45 | dansmith | and in the future, | |
| 18:15:50 | dansmith | if nova starts supporting domains properly, | |
| 18:16:04 | dansmith | we would have domain_id on the instance and would be able to drop the 404 check and just say "yep, it's in your domain, go for it" | |
| 18:16:17 | sean-k-mooney | nova could jsut stick the domain of an instance in the instance_system_metadata tabel for now if we wanted too | |
| 18:16:31 | sean-k-mooney | but ya | |
| 18:16:38 | sean-k-mooney | we could start validating it | |
| 18:16:52 | johnthetubaguy[m] | that has nice symetry with the list instances across all projects | |
| 18:17:05 | dansmith | that will suck for listing though, which was the primary thing we said should work, so we might as well just do it properly and add it to the table | |
| 18:17:10 | dansmith | johnthetubaguy[m]: right | |
| 18:17:55 | sean-k-mooney | dansmith: ya we can add it to the tahble but ideally not to alot of tables | |
| 18:18:07 | dansmith | just need it on instance | |
| 18:18:33 | sean-k-mooney | what about the request_spec | |
| 18:18:42 | sean-k-mooney | or other api db tablels | |
| 18:19:28 | sean-k-mooney | we might need to stor it in the build qruest or reuest spec before we create the instnace in the cell db | |
| 18:19:50 | sean-k-mooney | anyway we can figure that out | |
| 18:19:53 | dansmith | well, okay maybe once in there too, I have to go refresh my memory on those.. I think we do have project (but not user?) on reqspec? | |
| 18:19:55 | dansmith | yeah | |
| 18:20:05 | sean-k-mooney | but it sound like we need doamin awareness sooner rater then later | |
| 18:20:58 | sean-k-mooney | we have both https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L69-L70 | |