| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-11 | |||
| 16:25:35 | bauzas | dansmith: I haven't forgotten the rpc changes but reviews day hell here | |
| 16:25:44 | bauzas | tomorrow, that's better. | |
| 16:40:47 | dansmith | bauzas:ack | |
| 16:41:04 | dansmith | sean-k-mooney: you just too good for the nova meeting these days? | |
| 16:41:38 | sean-k-mooney | sorry forgot it was time for it joining | |
| 16:42:21 | dansmith | sean-k-mooney: so I asked a question there expecting maybe a response from you and realized you weren't around | |
| 16:42:22 | sean-k-mooney | dansmith: ah its just over | |
| 16:42:31 | dansmith | sean-k-mooney: related to the glance metadef api, | |
| 16:42:40 | dansmith | you probably saw the OSSN and query about getting ops feedback | |
| 16:42:58 | dansmith | but I (and stephenfin) thought you might be aware of how this is used | |
| 16:43:11 | sean-k-mooney | the metadef api | |
| 16:43:14 | dansmith | I think horizon uses it to present templates of nova metadata you can apply to things in some way | |
| 16:43:27 | sean-k-mooney | its use by heat i belive and yest its used by horizon | |
| 16:43:42 | dansmith | but it's not clear to me if that's like really useful, widely-used, etc | |
| 16:43:44 | sean-k-mooney | to generate the view that is ues to add flaovr extra specs and image poeprtyes | |
| 16:44:13 | dansmith | okay, does it allow you to create those things or just use it to show? | |
| 16:44:24 | sean-k-mooney | you can create them too | |
| 16:44:35 | sean-k-mooney | i belive that is admin only | |
| 16:44:39 | dansmith | it's not | |
| 16:44:43 | dansmith | at least on the glance side | |
| 16:44:46 | sean-k-mooney | really | |
| 16:44:58 | dansmith | it's also not properly isolated, | |
| 16:45:09 | sean-k-mooney | well its not ment ot be per tenant | |
| 16:45:20 | sean-k-mooney | its ment to be a global registry | |
| 16:45:22 | dansmith | which means you can use (apparently horizon) to poke and see if other tenants have things defined | |
| 16:45:47 | sean-k-mooney | right but this was not ment to be per tenant | |
| 16:45:49 | dansmith | sean-k-mooney: it's completely wide open by default | |
| 16:46:05 | sean-k-mooney | ok so the issue there is that writing to it is allowd | |
| 16:46:14 | sean-k-mooney | reading form it by default is fien for everyone | |
| 16:46:16 | dansmith | sean-k-mooney: also, it is clearly tenantified a little bit, just not well | |
| 16:46:41 | sean-k-mooney | is see i was not aware of that | |
| 16:46:45 | dansmith | sean-k-mooney: so tenants can create things that aren't shown to other tenants, but if you know the name, you can see it | |
| 16:46:56 | sean-k-mooney | ah i see | |
| 16:47:09 | sean-k-mooney | i did not see the OSSN for this by the way | |
| 16:47:17 | sean-k-mooney | so didnt know that context | |
| 16:47:24 | dansmith | it seems to be that namespace is the thing that is tied to the tenant, | |
| 16:47:51 | dansmith | and you create things tied to that namespace that are private to you, but if someone knows the name (or happens to pick the same one you did) then ... oopsie, here's their data | |
| 16:48:14 | dansmith | exposure seems limited to just names, which may be harmless, but may have customer names or infrastructure details of course | |
| 16:48:53 | dansmith | and the other issue is that open by default, with no creation controls, you can fill the database for fun and profit :) | |
| 16:49:31 | sean-k-mooney | ya so what the api was intended for was to provide a central regeistry for all falovr extra specs, image proertes, host aggreate and volumen metadata key and the allows values | |
| 16:50:24 | dansmith | seems odd to put that in glance, but I understand now that's the goal, at least | |
| 16:50:36 | sean-k-mooney | basically it was created as a programatic way to document and encode the value values for all the tunables user and operations might use when creating image/flavor/aggreates and volumnes | |
| 16:51:03 | sean-k-mooney | well it was adding very early on | |
| 16:51:16 | dansmith | yeah, so there have been contributions to the metadefs since the original thing, presumably because someone wants something to show up in horizon | |
| 16:51:55 | sean-k-mooney | well before we added stephenfin flavor validation stuff i was pushing for use to keep it in sysnc to defien the falvor extra specs | |
| 16:59:32 | gibi | stephenfin: will you look at the two artom's and sean-k-mooney's numa policy patches as second core? | |
| 16:59:41 | stephenfin | yup, on it | |
| 17:00:14 | gibi | thanks | |
| 17:24:37 | stephenfin | gibi: done on both | |
| 17:24:44 | gibi | stephenfin: any issue? | |
| 17:24:58 | stephenfin | Nope. Good catch on the socket policy though | |
| 17:25:23 | gibi | reno fix can land after FF so I'm not worrying about it | |
| 17:25:30 | stephenfin | yup, agreed | |
| 17:26:02 | gibi | lyarwood, bauzas, dansmith: we need a second core for an easy refactor patch https://review.opendev.org/c/openstack/nova/+/779851 the rest of the series is reviewd by stephen but his patch is stephen's so we need somebody else to get vdpa to land | |
| 17:26:26 | gibi | stephenfin: thanks | |
| 17:26:52 | lyarwood | looking | |
| 17:27:01 | gibi | lyarwood: thanks | |
| 17:31:58 | lyarwood | gibi: done | |
| 17:33:24 | gibi | lyarwood: thanks | |
| 17:48:09 | gibi | lyarwood: o/ | |
| 19:00:57 | openstackgerrit | sean mooney proposed openstack/nova master: block vm boot with vdpa ports https://review.opendev.org/c/openstack/nova/+/780065 | |
| 19:03:57 | sean-k-mooney | FYI that is only needed if we dont merge the VDPA inital boot support to ensure that even though neutron support the vdpa type we do not try to boot with it until we do | |
| 19:04:21 | gibi | sean-k-mooney: I'm reading vdpa right now | |
| 19:04:32 | gibi | sean-k-mooney: I have a question | |
| 19:05:14 | sean-k-mooney | ask away | |
| 19:05:21 | gibi | sean-k-mooney: do we need to make the VDPA devs unavaible when the related PF is become allocated? | |
| 19:05:38 | gibi | s/is become/becomes | |
| 19:05:43 | sean-k-mooney | yes we should | |
| 19:05:59 | sean-k-mooney | i know wehere we do that let me check if it will do that | |
| 19:06:07 | gibi | I'm looking at https://review.opendev.org/c/openstack/nova/+/778350/7/nova/pci/stats.py#215 | |
| 19:06:17 | gibi | _handle_device_dependents | |
| 19:06:29 | sean-k-mooney | yep | |
| 19:06:43 | sean-k-mooney | so that will mark the parent as unavaiable if we use a vf | |
| 19:06:43 | gibi | and I see that we make the PF unavailable when we allocate a VF or a VDPA | |
| 19:06:47 | sean-k-mooney | *vdpa dev | |
| 19:06:50 | gibi | yepp | |
| 19:06:55 | gibi | but what about the other direction | |
| 19:07:02 | sean-k-mooney | so you are saying we shoudl do the reverse too | |
| 19:07:06 | gibi | wondering | |
| 19:07:10 | gibi | if I allocated the PF | |
| 19:07:26 | gibi | then all the devs under the PF should not be used any more | |
| 19:07:34 | sean-k-mooney | ya i did not think of that edgecase because i only whitelisted the VF in the pci whitelist not the PF | |
| 19:07:52 | sean-k-mooney | gibi: correct | |
| 19:08:20 | gibi | I guess there is also the case when both the VF and the related VDPA is whitelsited and I allocate the VF | |
| 19:08:33 | sean-k-mooney | it might just work however depending on how remove_device works | |
| 19:08:56 | sean-k-mooney | gibi: no we will only ever get either the VF or VDPA divce listed | |
| 19:09:21 | sean-k-mooney | im basically taking the VF recored and changing its type | |
| 19:09:35 | gibi | sean-k-mooney: so when the admin creates the VDPA dev that consumes the VF already from the host? | |
| 19:10:10 | sean-k-mooney | when an admin create a vdpa device on the host it will be reported as vdpa instead of a VF | |
| 19:10:17 | gibi | OK | |
| 19:10:27 | gibi | so we wont see both the VF and the VDPA at the same time | |
| 19:10:36 | sean-k-mooney | not for the same VF no | |
| 19:10:39 | gibi | cool | |
| 19:10:48 | sean-k-mooney | you could have a mix of VF and VDPA devices | |
| 19:10:49 | gibi | then only the PF edge case remains | |
| 19:11:15 | gibi | when the PF is allocated we have the code somewhere that makes the VFs unavailable | |
| 19:11:16 | sean-k-mooney | if each VDPA device is from a VF not listed as a VF | |
| 19:11:38 | sean-k-mooney | yes its here https://review.opendev.org/c/openstack/nova/+/778350/7/nova/pci/stats.py#223 | |
| 19:11:49 | gibi | ahh yes | |
| 19:11:54 | gibi | so that removes the list of vfs | |