| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-14 | |||
| 18:31:23 | gmann | dansmith: humm, behavior wise yes it is changed.. | |
| 18:32:42 | dansmith | yeah, so I dunno, probably best to get someone else's opinion on the matter, but it sure seems like that should go hand-in-hand with the microversion to expose it | |
| 18:34:25 | gmann | issue with microversion bump is then it would not be aligned with policy change which are without microversion. | |
| 18:34:48 | sean-k-mooney | why are we over loading the filed | |
| 18:35:00 | gmann | I think booting server with uuid will end up with error ? | |
| 18:35:06 | sean-k-mooney | i can kid of understand at the osc level allowign --host | |
| 18:35:12 | gmann | currently | |
| 18:35:13 | sean-k-mooney | to be the uuid or hostname | |
| 18:35:25 | sean-k-mooney | but at the api that feels weird to me | |
| 18:35:25 | gmann | humm | |
| 18:35:55 | gmann | testing here https://review.opendev.org/c/openstack/tempest/+/793632 | |
| 18:36:06 | sean-k-mooney | we have instance of this i think for instnace show or flavor show where you can pass the name or uuid | |
| 18:37:22 | sean-k-mooney | but i kind of assume we were goning to add a new filed for this | |
| 18:38:18 | sean-k-mooney | its that not we ment by https://review.opendev.org/c/openstack/nova-specs/+/793011/4/specs/xena/approved/allow-project-admin-list-hypervisors.rst#97 | |
| 18:38:36 | gmann | sean-k-mooney: for this case, we are thinking to allow in same field and that is why interop issue | |
| 18:38:56 | sean-k-mooney | well we said we would accpet hypervisor-uuid now | |
| 18:39:09 | sean-k-mooney | so that is a new field no? | |
| 18:39:17 | sean-k-mooney | i have not been following this closely sorry | |
| 18:39:42 | gmann | sean-k-mooney: no, in same field like in 'availability_zone' az:noda:host host as uuid | |
| 18:40:00 | gmann | if new field then sure we need microversion bump | |
| 18:41:10 | sean-k-mooney | i kind of feel like this should be a micoverion bump | |
| 18:41:48 | sean-k-mooney | i mean its unlikely you are suing uuids for your hypervior host names but it would have been allowed before | |
| 18:41:57 | sean-k-mooney | actully dont we do that for ironic | |
| 18:42:17 | sean-k-mooney | the hypervior_hostname is the ironic node uuid | |
| 18:42:56 | dansmith | but that is the actual hostname we record, | |
| 18:42:58 | dansmith | so it's different | |
| 18:43:05 | sean-k-mooney | so if we reuse the same filed dont we have the possibliyt of a uuid colission even thought that wont happen in reality | |
| 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 | |