| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-08 | |||
| 16:22:40 | gibi | stephenfin: I will let you know when it make sense to start reviewing | |
| 16:22:46 | stephenfin | ack | |
| 17:06:02 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] ports with both bw and pps resources https://review.opendev.org/c/openstack/nova/+/792394 | |
| 17:06:09 | opendevreview | Balazs Gibizer proposed openstack/nova master: Transfer RequestLevelParams from ports to scheduling https://review.opendev.org/c/openstack/nova/+/791506 | |
| 17:06:15 | opendevreview | Balazs Gibizer proposed openstack/nova master: Parse extended resource request from the port https://review.opendev.org/c/openstack/nova/+/800085 | |
| 17:09:41 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] move unshelve test to the proper place https://review.opendev.org/c/openstack/nova/+/793621 | |
| 17:09:46 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support boot with extended resource request https://review.opendev.org/c/openstack/nova/+/800086 | |
| 17:09:50 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support extended resource request https://review.opendev.org/c/openstack/nova/+/800087 | |
| 17:17:25 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test]Refactor interface attach with qos https://review.opendev.org/c/openstack/nova/+/800088 | |
| 17:19:26 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support interaface attach / detach with new resource request format https://review.opendev.org/c/openstack/nova/+/800089 | |
| 19:22:13 | opendevreview | melanie witt proposed openstack/nova stable/train: [CI] Fix gate by using zuulv3 live migration and grenade jobs https://review.opendev.org/c/openstack/nova/+/795435 | |
| 19:34:03 | opendevreview | melanie witt proposed openstack/nova master: Add func test for nova-manage db archive_deleted_rows --before https://review.opendev.org/c/openstack/nova/+/796744 | |
| 19:44:57 | opendevreview | melanie witt proposed openstack/nova stable/ussuri: Initialize global data separately and run_once in WSGI app init https://review.opendev.org/c/openstack/nova/+/785061 | |
| 19:59:45 | opendevreview | melanie witt proposed openstack/nova stable/train: Initialize global data separately and run_once in WSGI app init https://review.opendev.org/c/openstack/nova/+/785064 | |
| 21:01:42 | opendevreview | melanie witt proposed openstack/nova stable/train: Initialize global data separately and run_once in WSGI app init https://review.opendev.org/c/openstack/nova/+/785064 | |
| 21:09:59 | opendevreview | Rodrigo Barbieri proposed openstack/nova stable/stein: Error anti-affinity violation on migrations https://review.opendev.org/c/openstack/nova/+/800114 | |
| 21:23:24 | opendevreview | Merged openstack/nova stable/wallaby: Move 'check-cherry-picks' test to gate, n-v check https://review.opendev.org/c/openstack/nova/+/797039 | |
| #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 | |