| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-08 | |||
| 17:06:28 | dansmith | I mean, there's no new reason why we shouldn't, other than that we haven't really had to use them ever, but I'm not aware of any discussion or decision about it | |
| 17:09:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add placeholder migrations for Stein backports https://review.openstack.org/650964 | |
| 17:09:44 | stephenfin | dansmith, melwitt, efried_lunch: They're there if we need them anyway ^ | |
| 17:23:43 | bauzas | stephenfin: others, FWIW, https://wiki.openstack.org/wiki/Nova/ReleaseChecklist | |
| 17:24:25 | bauzas | blame myself as I'm technically the release czar (heh) | |
| 17:24:28 | stephenfin | dansmith: Hmm, the tests are complaining that I'm not allowed to use 'drop' in migration. Is removing the 'cells' table (cells v1) a valid exception? | |
| 17:24:52 | dansmith | stephenfin: yep, specifically to catch this case, so you have to add an exception | |
| 17:24:59 | stephenfin | dansmith: If I don't do that, I see 'AssertionError: Models and migration scripts aren't in sync:' | |
| 17:25:38 | dansmith | stephenfin: oh right, so I think you have to leave the model too if there's not an exception path for that | |
| 17:25:51 | dansmith | (we've only done this a couple times since some of those modernized tests) | |
| 17:25:57 | stephenfin | dansmith: there is not, no | |
| 17:26:07 | stephenfin | so just leave the model with a TODO to remove in a future release? | |
| 17:26:30 | dansmith | yeah, so leave that but you could neuter it in some way, but definitely remove all the *use* of it yeah | |
| 17:26:40 | stephenfin | (y) less work for me | |
| 17:26:46 | dansmith | stephenfin: you could probably rename the model, right? Call it "class CellsThingDONOTUSE(..)" | |
| 17:27:34 | stephenfin | Um, I guess I could, yeah :D | |
| 17:42:35 | openstackgerrit | sean mooney proposed openstack/nova-specs master: add spec for image metadata prefiltering https://review.openstack.org/647578 | |
| 17:44:06 | sean-k-mooney | stephenfin: the nova-specs docs issue was because i had not rebased against mater where warnings are treated as errors | |
| 17:44:19 | sean-k-mooney | stephenfin: so the tox env and jobs is fine upstream | |
| 18:13:03 | openstackgerrit | Merged openstack/nova master: trivial: Remove dead code https://review.openstack.org/649562 | |
| 18:13:10 | openstackgerrit | Merged openstack/nova master: hacking: Fix dodgy check https://review.openstack.org/649563 | |
| 18:13:19 | openstackgerrit | Merged openstack/nova master: zvm: Remove dead code https://review.openstack.org/649564 | |
| 18:13:27 | openstackgerrit | Merged openstack/nova master: trivial: Remove dead 'ALIAS' constant https://review.openstack.org/649565 | |
| 18:13:38 | openstackgerrit | Merged openstack/nova master: trivial: Remove unused constants, functions https://review.openstack.org/649567 | |
| 18:13:47 | openstackgerrit | Merged openstack/nova master: trivial: Remove dead resource tracker code https://review.openstack.org/649569 | |
| 18:36:10 | mriedem | dansmith: a quick hot take if you will on the path to dropping this online data migration added in ocata: https://github.com/openstack/nova/blob/master/nova/objects/build_request.py#L484 - options: (1) drop it and just assume people are ok (2) add a nova-status upgrade check and drop it or (3) add an api migrations script which just does the query and delete (not a blocker migration, just query for those records and delete th | |
| 18:36:31 | mriedem | i'm partial to #3 which if #1 is true, should be a no-op | |
| 18:39:27 | dansmith | surely we can delete with extreme prejudice | |
| 18:39:47 | dansmith | the case would be what? something created in mitaka that didn't boot that people still want to be able to see in nova-list? | |
| 18:43:00 | dansmith | mriedem: ^ | |
| 18:43:49 | mriedem | yeah i guess, but we're already deleting with prejudice in the online data migration | |
| 18:44:23 | mriedem | because you literally can't load the thing otherwise | |
| 18:44:26 | mriedem | so nova-list won't work anyway | |
| 18:44:28 | dansmith | mriedem: I mean delete all of the code | |
| 18:44:50 | mriedem | so #1 | |
| 18:45:01 | dansmith | if we really need a delete in a schema migration, then I guess, but I'd rather not create the confusion about why it was okay in this case, personally | |
| 18:46:07 | mriedem | i think the only thing that scares me is people doing skip upgrades from let's say mitaka in this case to train, but we've said time and again we don't support that and you have to roll through, | |
| 18:46:20 | mriedem | so if you do that and hit this, your action would be to just drop those records from your api db manually | |
| 18:47:29 | dansmith | yeah, that's a really long skip | |
| 19:50:26 | cfriesen | portdirect: thought I'd give you a heads-up on something weird I saw. was booting up controller nodes and one of them didn't come up due to disk pressure. The other mariadb nodes were stuck in /tmp/start.py because check_if_cluster_data_is_fresh() kept evaluating to false (because the one node wasn't updating its timestamp) | |
| 20:00:43 | cfriesen | whoops...^ was supposed to be in another channel. | |
| 20:12:13 | mnaser | I mentioned this earlier but.. this does a full table scan, even with max rows.. https://github.com/openstack/nova/blob/73edcfae7d5ea498fd17fa8e548ae1bd690f408a/nova/db/sqlalchemy/api.py#L5508-L5537 | |
| 20:12:18 | mnaser | I'm not sure what the best way to work around it is.. | |
| 20:17:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add Instance.hidden field https://review.openstack.org/631123 | |
| 20:17:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add TargetDBSetupTask https://review.openstack.org/627892 | |
| 20:17:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add CrossCellMigrationTask https://review.openstack.org/631581 | |
| 20:17:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Execute TargetDBSetupTask https://review.openstack.org/633853 | |
| 20:17:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add can_connect_volume() compute driver method https://review.openstack.org/621313 | |
| 20:17:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_dest compute method https://review.openstack.org/633293 | |
| 20:17:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add PrepResizeAtDestTask https://review.openstack.org/627890 | |
| 20:17:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_source compute method https://review.openstack.org/634832 | |
| 20:17:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add nova.compute.utils.delete_image https://review.openstack.org/637605 | |
| 20:17:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add PrepResizeAtSourceTask https://review.openstack.org/627891 | |
| 20:17:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor ComputeManager.remove_volume_connection https://review.openstack.org/642183 | |
| 20:17:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add power_on kwarg to ComputeDriver.spawn() method https://review.openstack.org/642590 | |
| 20:17:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add finish_snapshot_based_resize_at_dest compute method https://review.openstack.org/635080 | |
| 20:17:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add FinishResizeAtDestTask https://review.openstack.org/635646 | |
| 20:17:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add Destination.allow_cross_cell_move field https://review.openstack.org/614035 | |
| 20:17:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Execute CrossCellMigrationTask from MigrationTask https://review.openstack.org/635668 | |
| 20:18:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Plumb allow_cross_cell_resize into compute API resize() https://review.openstack.org/635684 | |
| 20:18:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Filter duplicates from compute API get_migrations_sorted() https://review.openstack.org/636224 | |
| 20:18:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Change HostManager to allow scheduling to other cells https://review.openstack.org/614037 | |
| 20:18:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Start functional testing for cross-cell resize https://review.openstack.org/636253 | |
| 20:18:52 | mriedem | mnaser: are we missing indexes? | |
| 20:20:36 | mriedem | i don't see any indexes on instance_actions_events | |
| 20:20:48 | mriedem | but that does: | |
| 20:20:48 | mriedem | update_statement = table.update().values(deleted=table.c.id).\ where(table.c.action_id.in_(deleted_actions)) | |
| 20:21:45 | mriedem | i don't know if adding an index on instance_actions_events.action_id would help though | |
| 20:22:04 | mriedem | probably need jaypipes_ to tell us what sucks about those queries | |
| 20:26:25 | mriedem | that's also in the mainline code https://github.com/openstack/nova/blob/fb1fee6772bb101eac83845bac9022df77113aaa/nova/db/sqlalchemy/api.py#L5288 | |
| 20:28:30 | mnaser | Yeah I don’t know much. I had to kind orchestrate this outside nova and shortcircuit that code path | |
| 20:31:13 | mriedem | mnaser: do you archive/purge on a cron or just during each upgrade? | |
| 20:31:40 | mriedem | and tbc this just makes that archive/purge slower right? | |
| 20:33:27 | mnaser | mriedem: we’ve kinda not done this for a while so we ended up with huge databases. | |
| 20:33:39 | mnaser | so this may be a case of our fault not doing it as often | |
| 20:35:04 | mriedem | ok, was just trying to figure out if it's worth opening a bug report, i.e. if archive takes like 5 minutes or something, then maybe | |
| 20:43:09 | efried | stephenfin, bauzas, dansmith: Do we need to get those placeholder thingies in before the real release? I.e. modify the release patch? | |
| 20:45:01 | efried | mriedem, melwitt: ^ | |
| 20:49:43 | mriedem | no the placeholder migrations are post-release | |
| 20:49:57 | mriedem | so if we needed to add a schema migration in stable/stein, we have a placeholder for it in train | |
| 20:50:51 | efried | mriedem: Okay, so... is there some reason we couldn't backport placeholder migrations for rocky? | |
| 20:51:12 | mriedem | we don't backport placeholder migrations, | |
| 20:51:18 | mriedem | but apparently forgot to add them for rocky | |
| 20:51:21 | mriedem | *in* stein | |
| 20:51:38 | efried | I'm confused | |
| 20:51:46 | efried | then why is https://review.openstack.org/#/c/650964/ in master and not in stable/stein? | |
| 20:51:58 | mriedem | for example, latest cell db migration in stein is 391 https://github.com/openstack/nova/tree/stable/stein/nova/db/sqlalchemy/migrate_repo/versions so if we needed something in stable/stein, we'd have to add 392 in stable/stein and then copy that to the 392_placeholder in train | |
| 20:52:11 | mriedem | it's essentially a buffer, | |
| 20:52:20 | mriedem | because otherwise the first schema migration in train is 392 | |
| 20:52:30 | mriedem | so if we need something in stein but already used 392 in train, we're stuck | |
| 20:53:26 | efried | oh, so if we hadn't done any migrations in stein, we could set up the buffer for rocky. | |
| 20:53:28 | jaypipes | mriedem: instance_action_events.action_id will automatically have an index on it since it's an FK to instance_actions | |
| 20:53:29 | mriedem | rocky ended at 390 and there was one cell db migration in stein, 391 | |
| 20:53:33 | mriedem | so if we need something on rocky we're f'ed | |
| 20:53:51 | jaypipes | at least for mysql and pgsql it will. | |
| 20:54:06 | mriedem | jaypipes: ah ok, thanks. i seem to remember asking about this same query a year or more ago and came to the same conclusion (or you told me the same at the time) | |
| 20:54:07 | jaypipes | I think :) | |
| 20:54:35 | jaypipes | might want to have mnaser do a quick SHOW TABLE instance_action_events to verify | |
| 20:54:38 | mriedem | else i'm thinking action_id/deleted or something | |
| 20:55:11 | jaypipes | hmm, maybe not since we don't use SQLalchemy create_tables() | |