| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-09 | |||
| 10:06:14 | sean-k-mooney | i was not aware of that. | |
| 10:06:21 | stephenfin | nope | |
| 10:06:52 | stephenfin | No API microversions in Victoria either. Sign of the times | |
| 10:06:52 | sean-k-mooney | so that tecnicaly mean a master api could talk to a train cell db | |
| 10:06:59 | stephenfin | Yup | |
| 10:08:00 | stephenfin | in theory we don't do contractions so a train API could talk to a master DB | |
| 10:08:04 | stephenfin | also | |
| 10:08:34 | sean-k-mooney | is the same true of the api db | |
| 10:08:44 | stephenfin | yes, afaik | |
| 10:08:52 | sean-k-mooney | good to know | |
| 10:20:08 | lyarwood | sean-k-mooney / stephenfin / gibi ; if you have time today could you take a look at these specs I'm trying to get over the line before spec freeze and my sick leave next week? https://review.opendev.org/c/openstack/nova-specs/+/799811 https://review.opendev.org/c/openstack/nova-specs/+/799624 https://review.opendev.org/c/openstack/nova-specs/+/799850 | |
| 10:22:08 | sean-k-mooney | you have 3 :) | |
| 10:22:27 | sean-k-mooney | ah | |
| 10:22:49 | sean-k-mooney | yes i rememebr all 3 of them being discussed ill review them today | |
| 10:23:06 | gibi | lyarwood: I will check them out after lunch | |
| 10:28:47 | lyarwood | many thanks | |
| 10:30:05 | lyarwood | https://review.opendev.org/c/openstack/nova/+/799964 - we don't need a minor version bump on o.vo objects when adding new field values right? | |
| 10:30:58 | lyarwood | ^ this updated nova.virt.arch.ALL and caused the hashed version of a few o.vo objects to change | |
| 10:31:23 | lyarwood | but as it's just field values and not adding or removing actual attributes from the object I guess we just update the hash? | |
| 10:46:20 | sean-k-mooney | am we do not bump for compostion | |
| 10:46:36 | sean-k-mooney | so if a contained ovo change we dont need the bump the warping ovo | |
| 10:46:57 | sean-k-mooney | but let me look | |
| 10:47:25 | sean-k-mooney | we do need to backlevel the value in some cases | |
| 10:48:12 | sean-k-mooney | do we support armv6l | |
| 10:48:28 | gibi | lyarwood: yeah I think we need a minor bump for enum value. As the old compute will not handle the new enum value | |
| 10:48:29 | sean-k-mooney | i tought we were going to drop all 32bit arch support | |
| 10:48:42 | sean-k-mooney | gibi: for enuma yes | |
| 10:49:31 | sean-k-mooney | we back level the image proerties object for example anytime we bump an enuma field | |
| 10:50:10 | gibi | there is an Architecture enum that uses very similar values than https://review.opendev.org/c/openstack/nova/+/799964/2/nova/virt/arch.py#17 | |
| 10:50:58 | sean-k-mooney | yes there is the current patch is not touching the objects just the virt code | |
| 10:51:10 | lyarwood | gibi: right, I've asked them to update that, it's using the values of nova.virt.arch.ALL that they have updated for the ALL attribute there that caused the test version failures | |
| 10:51:14 | sean-k-mooney | although i thinke we generate one form the ohter | |
| 10:51:32 | sean-k-mooney | lyarwood: well im not sure if wew shoudl be adding this however | |
| 10:51:47 | lyarwood | kk I didn't think it was 32 bit ./me looks | |
| 10:54:29 | lyarwood | hmm does it really matter if libvirt supports it? | |
| 10:54:35 | sean-k-mooney | i mean we can add it but im not sure if that is soemthing we want to support | |
| 10:55:15 | sean-k-mooney | i guess its fine to include if we want to enulate it in the future | |
| 10:55:23 | sean-k-mooney | just not as a host plathform | |
| 10:56:55 | lyarwood | Yeah indeed | |
| 10:57:33 | sean-k-mooney | with that said i did once try to get openstack running in a rasberry pi | |
| 10:58:02 | sean-k-mooney | proably quite doable now with the pi4 | |
| 11:13:41 | gibi | lyarwood: if you add a sentence about locking / unlocking the instance during the connection update then I'm +2 on https://review.opendev.org/c/openstack/nova-specs/+/799624 | |
| 11:20:00 | gibi | lyarwood: I left two questions in https://review.opendev.org/c/openstack/nova-specs/+/799850 | |
| 11:24:52 | gibi | lyarwood: and I'm +2 with a micro nit on https://review.opendev.org/c/openstack/nova-specs/+/799811 | |
| 11:25:18 | gibi | I can get back to these specs still today if you bump them | |
| 11:27:00 | sean-k-mooney | lyarwood: by the way this is still pending we shoudl proably implemaet that soone rather then later ill see if i can get back to that while your away | |
| 11:27:07 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/774044 | |
| 11:37:53 | lyarwood | gibi: ack looking | |
| 11:38:01 | lyarwood | sean-k-mooney: ack kk | |
| 11:39:03 | sean-k-mooney | am i would prefer if we made https://review.opendev.org/c/openstack/nova-specs/+/799811 more general | |
| 11:39:09 | sean-k-mooney | ill push my comments shortly | |
| 11:42:14 | lyarwood | sean-k-mooney: two issues with making it general, we'd have to work out the defaults for all of the image props if they aren't provided | |
| 11:42:51 | lyarwood | sean-k-mooney: and it's a load of work to validate all of the input compared to just targeting what we need at the moment | |
| 11:42:58 | sean-k-mooney | we dont need to recorod all of them but i want to allow updating all excptin the ones we know will break things | |
| 11:43:41 | lyarwood | tbh that's a seperate spec and thing to this | |
| 11:43:42 | sean-k-mooney | lyarwood: there are only 4 addtional ones i think we should be recordeing | |
| 11:44:43 | opendevreview | Lee Yarwood proposed openstack/nova-specs master: Add nova-manage commands to show and refresh connection_info https://review.opendev.org/c/openstack/nova-specs/+/799624 | |
| 11:48:48 | lyarwood | gibi: re https://review.opendev.org/c/openstack/nova-specs/+/799850 - I thought policy was more for overall access to an API but if we can use it to also control the contents of the response then I don't see why we couldn't use it here as well. | |
| 11:51:47 | gibi | lyarwood: e.g. os_compute_api:os-instance-actions:events:details controls the detials of the actions and it is system reader by default | |
| 11:53:21 | sean-k-mooney | we also have a polciy to control if the extra specs of a flavor are show to normal users | |
| 11:55:17 | lyarwood | cool okay I'll copy that pattern then | |
| 11:57:38 | sean-k-mooney | lyarwood: comments pushed on https://review.opendev.org/c/openstack/nova-specs/+/799811 | |
| 11:59:04 | sean-k-mooney | lyarwood: you had another spec similar to https://review.opendev.org/c/openstack/nova-specs/+/799850 for addign the attchment id right | |
| 11:59:16 | sean-k-mooney | can we use the same microversion for both | |
| 11:59:58 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/794799 | |
| 12:00:12 | sean-k-mooney | i kid of feel like those two api cahnges shoudl be done together | |
| 12:00:12 | lyarwood | we could but I thought it needed something separate for the admin/policy driven part | |
| 12:01:19 | sean-k-mooney | i mean we could leave that to the implemation it would be nice not to have to bump twice | |
| 12:02:25 | sean-k-mooney | am one other question | |
| 12:02:39 | sean-k-mooney | we wanted to stop stashing the connection info in nova at somepoitn right | |
| 12:02:58 | sean-k-mooney | and just alwasy get it form cinder | |
| 12:04:18 | sean-k-mooney | basically if we plan to not store it in the db long term i dont think we should add it to the api respocne so that we do not need then proxy it in the future | |
| 12:09:09 | lyarwood | sorry back | |
| 12:09:40 | lyarwood | yeah I don't mind using the same microversion for both if it matters that much | |
| 12:09:55 | lyarwood | and yeah eventually I'd like to but there's no written down plan to attack that this cycle yet | |
| 12:10:16 | sean-k-mooney | it does not but im not conviced we should should add the new api | |
| 12:10:32 | sean-k-mooney | i think we should just proceed with https://review.opendev.org/c/openstack/nova-specs/+/799624 more then likely | |
| 12:11:00 | sean-k-mooney | although i have not read that yet but i think nova manage would be better if we plan to remove the cacheing eventually | |
| 12:11:46 | lyarwood | I disagree, we can always remove it in a later microversion | |
| 12:11:58 | sean-k-mooney | we could but we will have to proxy for old microverions | |
| 12:11:59 | lyarwood | and when it is there it's just going to be None once we've removed the stashing in Nova | |
| 12:12:24 | lyarwood | why would we need to proxy? | |
| 12:12:27 | sean-k-mooney | no if we remove the stashing we will have to have nova proxy to nova for the old microverion | |
| 12:12:32 | lyarwood | nope | |
| 12:12:39 | lyarwood | it's the connection_info that Nova has | |
| 12:12:41 | sean-k-mooney | it would break people if we did not | |
| 12:12:48 | lyarwood | how would it break people? | |
| 12:13:09 | sean-k-mooney | if people used the old microversion then they would expect the connection info | |
| 12:13:21 | sean-k-mooney | and it would nolonger be presnt when we stop stashing | |
| 12:13:27 | lyarwood | they'd expect the connection_info that Nova held about a volume attachment | |
| 12:13:40 | lyarwood | they're not going to use it for anything | |
| 12:13:47 | lyarwood | it's just a troubleshooting tool | |
| 12:14:01 | sean-k-mooney | which i dont think shoudl be at the api level | |
| 12:14:16 | sean-k-mooney | if we put it in the api then it will be used for other things | |
| 12:15:29 | sean-k-mooney | the fact that nova caches this info is an internal implementation detail | |
| 12:15:54 | sean-k-mooney | we also have a network info cache but we dont expose it via the api | |
| 12:16:41 | sean-k-mooney | i dont think we shoudl be treatign novas copy of the the connection info as something different from cinders at the api level | |
| 12:16:45 | sean-k-mooney | its just a cache | |
| 12:16:49 | sean-k-mooney | IMO | |
| 12:17:21 | lyarwood | Partly, there's also some additional stuff we stash in there on the Nova side at the moment | |