| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-19 | |||
| 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 | |
| 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 | |
| 18:21:05 | dansmith | well, we need it for this to all work like people expect | |
| 18:21:45 | sean-k-mooney | personally i expect that if delete your stuff in keystone first everythign is borked but yes we do | |
| 18:21:52 | dansmith | haha | |
| 18:21:58 | dansmith | well, that's because you're smart :) | |
| 18:22:18 | dansmith | but I meant the expectation of domain users/admins behaving well within their domain | |
| 18:22:29 | sean-k-mooney | i totally see how this could get messy if your not using keystone internal user manamged however | |
| 18:22:45 | johnthetubaguy[m] | I am fairly sure, tempest just did that for me though :) | |
| 18:22:59 | sean-k-mooney | like someone makes an active directory change when you move team | |
| 18:23:17 | dansmith | yeah, I think it's more the projects than the users, | |
| 18:23:20 | dansmith | but yeah totally | |
| 18:24:22 | sean-k-mooney | huh the build request only has the project https://github.com/openstack/nova/blob/master/nova/objects/build_request.py#L43 | |
| 18:25:32 | dansmith | [10: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:25:33 | sean-k-mooney | i would guess there arbou 3 tabels we woudl have to add it too instnace, build_requst and request spec | |
| 18:26:03 | dansmith | I meant BR above^ because it's what we need before it's created, | |
| 18:26:15 | dansmith | but yeah maybe reqspec too, since we use that if a cell is down I guess | |
| 18:26:30 | sean-k-mooney | ah ya | |
| 18:26:45 | dansmith | actually, | |
| 18:27:11 | dansmith | we might only need it on reqspec, since I think we have that the whole time, which means we could join it to BR if we need to | |
| 18:27:21 | dansmith | but anyway, just gotta do it, shouldn't be terrible | |
| 18:27:55 | sean-k-mooney | yep if we have it in at least one location in the api db and cell db for each instance we shoudl be ok | |
| 18:28:01 | dansmith | yeah | |
| 18:28:23 | sean-k-mooney | we would need the other serivce to have the same logic however so maybe a keysotne middelware change | |
| 18:28:43 | sean-k-mooney | regarding the "its a domain admin and the project nolonger exists" logic | |
| 18:29:25 | sean-k-mooney | so that when we call neutron and cinder it actully works | |
| 18:29:34 | dansmith | actually works would be good | |