| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-09 | |||
| 03:08:59 | opendevreview | Merged openstack/nova stable/victoria: Stop leaking ceph df cmd in RBD utils https://review.opendev.org/c/openstack/nova/+/791938 | |
| 09:53:01 | lyarwood | melwitt: https://bugs.launchpad.net/nova/+bug/1931707 btw, that's the same issue as downstream right? | |
| 09:56:52 | stephenfin | lyarwood: gibi: With an operator-like hat on, is there any reason to keep the VERSION argument in 'nova-manage db sync [VERSION]' ? | |
| 09:56:59 | stephenfin | given we don't allow downgrades | |
| 09:57:10 | stephenfin | and you can't really run nova without the latest DB schema | |
| 09:58:33 | sean-k-mooney | stephenfin: my only resevation with removing it is if you want to do the migrations in batches | |
| 09:58:42 | gibi | stephenfin: I think stoping at an intermittent version, do some manual checks / fixes inconsistencies, then continue forward might make sense | |
| 09:59:00 | sean-k-mooney | thats basicaly what i was thinking | |
| 09:59:13 | sean-k-mooney | but if we did things correctly that should not be required | |
| 09:59:14 | gibi | yeah, also batching might make sense if there are heavy transformations | |
| 09:59:39 | gibi | if we never have bugs leading to db inconsistencies then yeah :D | |
| 09:59:54 | sean-k-mooney | stephenfin: with a down stream hat on i dont know if there are FFU cases where we would want to stop an an intermidite release | |
| 10:00:33 | gibi | what my empoyer do during Mitaka -> Victoria FFU is to stop at Pike and Train then go to Victoria | |
| 10:01:19 | gibi | sorry, stop at Newton and Pike | |
| 10:01:35 | stephenfin | okay, batching or step by step upgrades makes sense | |
| 10:01:45 | sean-k-mooney | we might want to stop on n+2 before n+3 to run some online migrations | |
| 10:02:10 | stephenfin | alembic allows us to separate migrations into those that expand (can be done online) and those that contract (requires downtime) | |
| 10:02:24 | sean-k-mooney | ya it does | |
| 10:02:34 | stephenfin | so we might be able to look at finally removing a lot of dead tables and columns in contract migrations | |
| 10:02:38 | sean-k-mooney | is it problematic to continue to supprot this | |
| 10:02:55 | stephenfin | is that a question or a statement? | |
| 10:03:15 | sean-k-mooney | a quetion is it difficult to support db sync version? | |
| 10:03:33 | sean-k-mooney | im wondering why you asked | |
| 10:03:36 | stephenfin | no, not at all | |
| 10:03:43 | stephenfin | I was just wondering if it's worth keeping | |
| 10:04:04 | lyarwood | Yeah I think it is, would avoid the need to ship every release for db migrations | |
| 10:04:04 | sean-k-mooney | ok personally i do not know if it really widely used. typically i would not expect it to be | |
| 10:04:26 | stephenfin | Well, it's slightly tricky. I'm not allowing people to select an sqlalchemy-migrate version. Only alembic ones | |
| 10:04:27 | lyarwood | if we kept a few releases in tree at once that is | |
| 10:04:30 | sean-k-mooney | lyarwood: well we dont drop the db migrations | |
| 10:04:48 | stephenfin | So you won't be able to select any of the migrations > Train, < Xena | |
| 10:04:59 | stephenfin | which I think is fine because they're all placeholders rn | |
| 10:05:11 | lyarwood | right the ones you squashed? | |
| 10:05:24 | stephenfin | I squashed everything up to Train | |
| 10:05:35 | stephenfin | we haven't had a real DB migration since then | |
| 10:05:58 | sean-k-mooney | their have been no db changes since train? | |
| 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 | |