| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-14 | |||
| 18:43:15 | opendevreview | Merged openstack/nova master: Use neutronclient's port binding APIs https://review.opendev.org/c/openstack/nova/+/706295 | |
| 18:43:48 | sean-k-mooney | dansmith: well for ironic server the hypervior hostname for each server is the uuid right | |
| 18:44:18 | dansmith | right, that's my point.. so it's not like there's prior art for making them interchangeable, it's that we actually record the uuid *as* the hostname in that case | |
| 18:44:38 | sean-k-mooney | yes | |
| 18:44:57 | sean-k-mooney | do we also make the compute node uuid match the host name for ironic? | |
| 18:46:12 | dansmith | yeah, I think that changed at some point and now we do | |
| 18:46:21 | sean-k-mooney | yes https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L354-L355 | |
| 18:46:33 | sean-k-mooney | ya i dont think it always was either but it is now | |
| 18:46:51 | sean-k-mooney | https://github.com/openstack/nova/commit/9f28727eb75e05e07bad51b6eecce667d09dfb65 | |
| 18:47:12 | sean-k-mooney | to fix https://bugs.launchpad.net/nova/+bug/1771806 | |
| 18:48:50 | sean-k-mooney | gmann: that tempest test https://review.opendev.org/c/openstack/tempest/+/793632/7/tempest/scenario/test_server_multinode.py is still using the old way to select hosts | |
| 18:48:58 | sean-k-mooney | using the az hack no? | |
| 18:49:43 | gmann | sean-k-mooney: adding host uuid there https://review.opendev.org/c/openstack/tempest/+/793632/7/tempest/scenario/test_server_multinode.py#61 | |
| 18:50:17 | sean-k-mooney | but you are using host_name | |
| 18:51:02 | sean-k-mooney | not host or hypervisor_hostname | |
| 18:51:32 | sean-k-mooney | its still computing the az | |
| 18:51:34 | sean-k-mooney | https://review.opendev.org/c/openstack/tempest/+/793632/7/tempest/scenario/test_server_multinode.py#82 | |
| 18:52:21 | sean-k-mooney | its not useing https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/add-host-and-hypervisor-hostname-flag-to-create-server.html | |
| 18:52:45 | gmann | host_name is what i changed to add uuid in L61 | |
| 18:53:00 | gmann | host['host_name'] is uuid | |
| 18:53:24 | gmann | I remember it failed with uuid but double checking | |
| 18:53:58 | sean-k-mooney | so using the az as this test is is more or less deprecated | |
| 18:54:12 | sean-k-mooney | we can test this but we shoudl be testing with 5.74 | |
| 18:54:18 | sean-k-mooney | and not seeting the az at all | |
| 18:54:20 | gmann | sean-k-mooney: I am testing with AZ case for force host. 'host', 'hostname' which use sch I am not testing currently | |
| 18:54:49 | gmann | AZ way is not deprecated right? | |
| 18:55:00 | sean-k-mooney | its stognly discuaged | |
| 18:55:01 | gmann | create server support both | |
| 18:55:13 | sean-k-mooney | its not deperecated and i dont think we want to extend its usage | |
| 18:55:26 | gmann | yeah discuaged but not deprecated | |
| 18:55:30 | sean-k-mooney | i would like to deprecated it | |
| 18:55:51 | gmann | I am just checking compatibility of uuid case | |
| 18:55:58 | sean-k-mooney | its replacement has been avaiable since train | |
| 18:57:18 | sean-k-mooney | gmann: well i gues my point is i dont think we should be supporting this the old way | |
| 18:57:55 | sean-k-mooney | im fine with project admins requesting a host using the info form the hypervior api to get the uuid | |
| 18:58:09 | sean-k-mooney | but im not sure they shoudl be able to force the host and bypass the schudler filters | |
| 18:59:17 | gmann | sean-k-mooney: sure. but in current proposed change I am checking uuid compatibility. But if we want to disallow the bypass the schudler filters that is separate behavior change or we can say 'bypass the schudler filters stop working with new rbac' | |
| 19:00:04 | sean-k-mooney | no i dont think that is really valid. | |
| 19:00:14 | sean-k-mooney | its an iterup issue | |
| 19:00:22 | sean-k-mooney | i cant tell if you are using the new rbac or not | |
| 19:00:34 | gmann | I think we can discuss this separately to deprecate/stop the 'bypass the schudler filters' case instead of mixing two | |
| 19:00:44 | sean-k-mooney | which is why i have argrued that any policy change should be a micorover bump | |
| 19:01:13 | sean-k-mooney | the old az format can work without any nova code changes right | |
| 19:01:19 | sean-k-mooney | with the uuid becaue it accpeted both | |
| 19:01:50 | gmann | yeah that is why I am kind of agree with dansmith concern of 'need of microversion bump' just testing also so that I am fully convinced on interop issue | |
| 19:02:21 | gmann | sean-k-mooney: let's see. i can add host way also in test | |
| 19:02:30 | sean-k-mooney | gmann: can you add a new tempest test to test with the other way to request it with out bypassign the filter | |
| 19:02:40 | gmann | sure | |
| 19:02:46 | sean-k-mooney | cool | |
| 19:03:24 | sean-k-mooney | in which case we would expect the uuid to be in host? or hypervisor_hostname? | |
| 19:03:42 | sean-k-mooney | or in hypervisor_uuid | |
| 19:04:05 | sean-k-mooney | which does not exsit today | |
| 19:04:30 | sean-k-mooney | dansmith: was this what you were poking at^ | |
| 19:05:08 | gmann | if new field then we need microverion bump for sure | |
| 19:05:59 | sean-k-mooney | if feels a little odd to me to do openstack hypervisors list and get the uuid and put it in hypervisor_hostname | |
| 19:06:53 | sean-k-mooney | and using host would feel equially odd since that is the host on which the compute service runs so for ironic that is not the same thing | |
| 19:07:15 | sean-k-mooney | so for the newer way i think weee need a hypervisor_uuid filed on server create to use this | |
| 19:07:51 | dansmith | I'm not so concerned about new field vs new behavior for existing field, | |
| 19:08:06 | dansmith | but it seems worthy of a microversion to me either way so we know if we can use it or not | |
| 19:08:25 | sean-k-mooney | dansmith: well with a new field the old filed behavior would not change | |
| 19:08:42 | dansmith | right but new field would mean microversion for sure | |
| 19:09:34 | gmann | yeah, only way to avoid microversion is existing field but that also seems difficult/not right | |
| 19:10:01 | dansmith | well, I was saying I don't even think you can avoid it then, because we won't know when we can or can't use it | |
| 19:10:31 | gmann | yeah.. | |
| 19:10:46 | gmann | now we are back to same issue on how to solve this for new rbac | |
| 19:11:07 | sean-k-mooney | if it was a uuid we would basicaly have to always check if there was a hypervior_hostname with the value or hypverviour_uuid with that value | |
| 19:11:29 | sean-k-mooney | assuming it was one filed | |
| 19:11:51 | sean-k-mooney | gmann: for new rbac i dont understant the problem | |
| 19:12:25 | sean-k-mooney | you just use the new microverion how those that affect things? | |
| 19:12:29 | gmann | sean-k-mooney: with project admin needs to know the hypervisor name to boot server on host | |
| 19:12:54 | sean-k-mooney | right which it cant get today without system_reader | |
| 19:13:06 | gmann | with new rbac and older microverison (than where we fix this), project admin would not be able to boot server on host specify | |
| 19:13:18 | sean-k-mooney | we dont | |
| 19:13:42 | sean-k-mooney | we only support this form the new microverion on | |
| 19:14:14 | sean-k-mooney | and if you want too supprot that for old microverion give them system_reader or create a custom policy role for hypervior list | |
| 19:15:57 | sean-k-mooney | so effectivly i belive we should just pretend that we are allowing proejct admins to spyify a host as a new feature in xena | |
| 19:16:07 | gmann | yeah so for older microversion they would not have choice than updating the policy. which is what issue we have today | |
| 19:16:26 | gmann | and with old rbac default they are able to do | |
| 19:17:16 | gmann | I think we need to think more on this. I am not hurrying it for Xena at the last min. | |
| 19:18:09 | sean-k-mooney | well let take a step back | |
| 19:18:37 | sean-k-mooney | the old polices for hypervior was admin api and the new one is system reader | |
| 19:18:40 | sean-k-mooney | correct | |
| 19:19:26 | sean-k-mooney | so up to now without custom policy you basically need to be an admin or have readonly admin right to list hostname via the hyperviors api | |
| 19:20:37 | sean-k-mooney | so even thoght project_admins could spefify a host https://github.com/openstack/nova/blob/master/nova/policies/servers.py#L177-L196 | |
| 19:21:00 | sean-k-mooney | in pratice they did not know the name unless an admin told them | |
| 19:21:06 | sean-k-mooney | so in practice they could not use this capablity | |
| 19:21:58 | sean-k-mooney | and the same is true of the non az way https://github.com/openstack/nova/blob/master/nova/policies/servers.py#L177-L225 | |
| 19:22:37 | gmann | sean-k-mooney: legacy project_admins can list hypervisor and specify host | |
| 19:22:53 | sean-k-mooney | gmann: there is no such thing a sa legacy project admin | |
| 19:22:56 | gmann | legacy admin | |
| 19:23:04 | sean-k-mooney | they are a fully admin | |
| 19:23:22 | gmann | yeah the old admin can do both operation | |
| 19:23:30 | sean-k-mooney | right | |
| 19:24:03 | sean-k-mooney | so i dont see why we have to try and support this before xena | |
| 19:24:23 | sean-k-mooney | we may have typed PROJECT_ADMIN on those policies | |
| 19:24:40 | sean-k-mooney | but in reality form an PROJECT_ADMIN point of view they could not use them | |
| 19:24:42 | gmann | PROJECT_ADMIN is new rbac policy | |
| 19:25:04 | sean-k-mooney | yes i know | |
| 19:25:29 | gmann | if we think with old admin way then they were allowed to list hypervisor and boot server on that. but with new rbac whatever admin system or project could not do | |
| 19:25:45 | sean-k-mooney | correct | |