| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-19 | |||
| 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 | |
| 18:29:46 | sean-k-mooney | i missed the list dicussion | |
| 18:30:00 | sean-k-mooney | is that server list --all-tenats | |
| 18:30:06 | dansmith | yeah | |
| 18:30:15 | dansmith | I gotta run do something, back later | |
| 18:30:29 | sean-k-mooney | ok to me the simpelt way to do that is again with domain tokens and scope it to the project in that domain | |
| 18:30:51 | sean-k-mooney | ok im going to finsih soon but ^ is how i asuemd that would work | |
| 18:31:14 | sean-k-mooney | if you really wanted all proejct then you would use a domain token on the root domain, assuming keystone exposes that | |
| 20:11:54 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add PCI VPD Capability Handling https://review.opendev.org/c/openstack/nova/+/808199 | |
| 20:11:55 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Support remote-managed SmartNIC DPU ports https://review.opendev.org/c/openstack/nova/+/812111 | |
| #openstack-nova - 2021-11-21 | |||
| 09:55:16 | kevko | any help please ? https://bugs.launchpad.net/nova/+bug/1951720 ? have you seen this already ? | |
| #openstack-nova - 2021-11-22 | |||
| 08:50:21 | bauzas | good morning Nova | |
| 08:50:54 | gibi | good morning | |
| 08:51:50 | bauzas | you appreciate winter times when you have to light on | |
| 13:16:53 | gibi | bauzas: I think this spec is a quick +A https://review.opendev.org/c/openstack/nova-specs/+/810868 if you have minute : | |
| 13:16:56 | gibi | :) | |
| 13:17:16 | bauzas | gibi: I'll need to taxi my daughter in a few mins but I'll look at it after | |
| 13:19:21 | sean-k-mooney | gibi: i kind of agree | |
| 13:19:23 | gibi | bauzas: OK, sure | |
| 13:19:41 | sean-k-mooney | i can take a look but ill leave the +w to bauzas | |
| 13:26:29 | Henriqueof | Is there any articles/guides on how overcommiting CPU/RAM degrades performance? | |
| 13:34:38 | sean-k-mooney | Henriqueof: well over commiting ram is easy to understand in that when you actully start overcommiting the inuse ram it will start swapping to disk | |
| 13:35:42 | sean-k-mooney | using something like zram as first level swap and an actual swap partion as second level swap and have 1 swap partion per numa node can in some casess help but only if the storage is also numa alinged | |
| 13:36:06 | sean-k-mooney | Henriqueof: for cpus it is really just a matter of contntion and context switchign overhead | |
| 13:36:46 | sean-k-mooney | if you vms are mostly idel it will be fien to over commit them but once the host load starts to exceed the number of cpus then the performcne will degrade | |
| 13:37:18 | sean-k-mooney | you likely will hit memory bandwith, disk io or network io bottelneck too depending on your workloads | |
| 13:38:38 | sean-k-mooney | Henriqueof: my recommendation are never over commit cpus more then 4:1, always reserve at least 1 core per numa node for the host, if you are using hyper treading reserve the hypertread sibling of each host core too. | |
| 13:39:26 | sean-k-mooney | Henriqueof: hyperthreading only give you about a 1.4x increase in throughput by the way so dont expect to actully be able to service a load = nproc if you are using HT | |
| 13:40:07 | sean-k-mooney | Henriqueof: form memroy i normally recommend never over commiting and using hugepages but if you must over commit allocate swap equal to total memory*overcommit ratio | |
| 13:41:10 | sean-k-mooney | i would not really over commit more then about 2-4x your ram either. but as i said i recomend keeping memory over comiit at 1.0 so no over commit in most cases. | |
| 14:00:14 | Henriqueof | sean-k-mooney: You actually answered most of my questions, thank you! | |