| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-09 | |||
| 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 | |
| 12:17:36 | lyarwood | like the device path, multipath UUIDs etc | |
| 12:17:51 | lyarwood | I still think it's entirely valid in the API | |
| 12:18:12 | lyarwood | there's nothing a caller could do with it anyway outside of calling os-brick with it | |
| 12:18:40 | sean-k-mooney | well you could use it to connect to the backend | |
| 12:18:56 | lyarwood | right I mean with our APIs | |
| 12:19:09 | lyarwood | so the fact it's going away in the future shouldn't matter | |
| 12:19:17 | lyarwood | and there's always another way of getting it | |
| 12:20:07 | sean-k-mooney | i dont know to me this just feels like adding tech debt | |
| 12:20:25 | sean-k-mooney | the admin should not really need to know or care about this | |
| 12:20:48 | sean-k-mooney | i get that its for troble shooting | |
| 12:21:16 | sean-k-mooney | but wont the nova manage command provide a better way to do that | |
| 12:21:23 | sean-k-mooney | as that will also supprot refershing it | |
| 12:21:32 | sean-k-mooney | so fixing the problem if it exitis | |
| 12:24:08 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Unify 'nova.db.api', 'nova.db.sqlalchemy.api' https://review.opendev.org/c/openstack/nova/+/799524 | |
| 12:24:09 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Move remaining 'nova.db.sqlalchemy' modules https://review.opendev.org/c/openstack/nova/+/799525 | |
| 12:24:09 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Post reshuffle cleanup https://review.opendev.org/c/openstack/nova/+/799526 | |
| 12:24:10 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Avoid use of ALTER in initial migration https://review.opendev.org/c/openstack/nova/+/800076 | |
| 12:24:10 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Add initial alembic migration for main DB https://review.opendev.org/c/openstack/nova/+/799527 | |
| 12:24:11 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Add initial alembic migration for API DB https://review.opendev.org/c/openstack/nova/+/799528 | |
| 12:24:11 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Trivial style changes https://review.opendev.org/c/openstack/nova/+/799529 | |
| 12:24:12 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Normalize migrations tests https://review.opendev.org/c/openstack/nova/+/799684 | |
| 12:24:13 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Integrate alembic https://review.opendev.org/c/openstack/nova/+/799530 | |