| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-27 | |||
| 18:25:13 | sean-k-mooney | so it has already been migrated | |
| 18:26:03 | sean-k-mooney | or contracted/truncated in this case | |
| 18:26:11 | lowercase | drop nova_api database; show database ; -> confirmed nova-api is no longer present. | |
| 18:27:40 | lowercase | create database nova_api ; and /openstack/venvs/nova-25.2.1.dev3/bin/nova-manage api_db sync now results in echo $? == 0 | |
| 18:27:56 | sean-k-mooney | ok so it succeeded | |
| 18:28:40 | sean-k-mooney | you shoudl be able to run "nova-manage api_db sync" again | |
| 18:28:50 | sean-k-mooney | and i basically shoudl do nothing | |
| 18:29:03 | stephenfin | Cool. So something has gone wrong the first time you applied that. My guesses would be that it was already applied but the alembic_version table wasn't updated for some reason. The other guess is that someone manually dropped these at some point in the past | |
| 18:29:04 | lowercase | Correct, i ran again and no error | |
| 18:32:01 | sean-k-mooney | its also possible that you ran this pointing at the wrong db | |
| 18:32:20 | sean-k-mooney | the api db migratoins wont work on the cell dbs | |
| 18:32:35 | sean-k-mooney | so if you had the wrong db in the config file then you woudl see the issue you had | |
| 18:32:42 | stephenfin | that only makes sense if the config is wrong though, yeah | |
| 18:32:51 | lowercase | no chance. openstack-ansible performed the operation. And i ran a dozen playbooks which all require sql connections successfully before this one | |
| 18:33:19 | sean-k-mooney | ack | |
| 18:33:23 | stephenfin | then I guess you need to restore the backup and try again | |
| 18:33:42 | lowercase | okay, restoring the database | |
| 18:33:57 | stephenfin | you can dummy apply the migration is needed, updating the 'alembic_version' record, but you should figure out why this happened first. Did you keep logs from OSA? | |
| 18:34:53 | lowercase | That seems like a highly desirable feature. but i dont think it does for me. And I didn't go out of my way to save them | |
| 18:35:28 | stephenfin | ack, then you might be stuck with never knowing and just fixing the issue | |
| 18:36:06 | sean-k-mooney | this looks right to me too by the way https://github.com/openstack/openstack-ansible-os_nova/blob/stable/yoga/templates/nova.conf.j2#L216-L217 | |
| 18:36:48 | sean-k-mooney | i do not see an obvious bug in osa | |
| 18:36:58 | sean-k-mooney | if you hit this again and find a repoducer let us know | |
| 18:37:04 | sean-k-mooney | but it seams to be working ok again | |
| 18:38:21 | lowercase | okay, i restored the database. d67eeaabee36 is the alembic_version again. | |
| 18:38:49 | lowercase | /openstack/venvs/nova-25.2.1.dev3/bin/nova-manage api_db sync results in [SQL: ALTER TABLE build_requests DROP COLUMN vm_state] exception again. | |
| 18:39:18 | stephenfin | and the schema's the same before you run that? i.e. those columns are missing? | |
| 18:40:23 | stephenfin | lowercase: If you need to dummy apply the migration, you can create a file like this https://paste.opendev.org/show/818911/ and call alembic with 'alembic -c path/to/file stamp head' | |
| 18:40:24 | stephenfin | If alembic isn't available, 'virtualenv .venv; source .venv; pip install alembic; {commands}; deactivate; rm -rf .venv' | |
| 18:42:06 | lowercase | Yes, build_requests is present with nothing in it. | |
| 18:42:43 | lowercase | and the schema is identical to the paste i shared previosuly. | |
| 18:57:45 | lowercase | stephenfin: alembic resulted in the following error: https://paste.opendev.org/show/beYkgfrwuHYduGCDnGcE/ | |
| #openstack-nova - 2023-02-28 | |||
| 08:12:29 | opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Creating an example of the refactor privileged functions will go through. https://review.opendev.org/c/openstack/nova/+/875497 | |
| 08:12:54 | gibi | o/ | |
| 08:13:12 | bauzas | hola | |
| 08:13:27 | gibi | bauzas: you mentioned things to clean up before RC1, do you have a list? | |
| 08:13:48 | bauzas | gibi: indeed, | |
| 08:13:58 | bauzas | https://etherpad.opendev.org/p/nova-antelope-rc-potential | |
| 08:14:14 | gibi | bauzas: ack, on it | |
| 08:15:22 | bauzas | gibi: actually, we only have the prelude and the logging revert patch to review | |
| 08:15:31 | bauzas | (for the moment) | |
| 08:16:01 | bauzas | also, I forgot to tell about RBAC defaults, shit. | |
| 08:16:07 | bauzas | (in the cycle highlights) | |
| 08:16:39 | bauzas | https://etherpad.opendev.org/p/nova-antelope-blueprint-status it wasn't in the etherpad, neither in the Antelope blueprints | |
| 08:18:26 | bauzas | gibi: about your question about SLURP, well, maybe we should wait for dansmith to be here | |
| 08:19:22 | bauzas | gibi: but AFAIK, we try in Nova to support a N-2 compute | |
| 08:19:33 | bauzas | when N is a SLURP release | |
| 08:19:49 | bauzas | gibi: dansmith tried at least to have a job for testing it | |
| 08:25:40 | gibi | bauzas: I'm fine to make such a statement but then lets make it a clear statement somewhere that we support N-2 computes not just easing on the constraint in the code. | |
| 08:26:52 | gibi | i.e. our change in what is supported is hard to discover as it mentioned nowhere deployer facing | |
| 08:32:05 | bauzas | gibi: yep, I see your point | |
| 08:32:22 | bauzas | fwiw, we haven't yet agreed on this, which should be done at the vPTG | |
| 08:39:25 | bauzas | gibi: got a second for thinking about 2023.1 SLURP implications ? | |
| 08:40:57 | gibi | be back in 5min to think | |
| 08:47:47 | opendevreview | Sylvain Bauza proposed openstack/nova master: Update min service version for Antelope https://review.opendev.org/c/openstack/nova/+/874932 | |
| 08:47:59 | bauzas | right in time | |
| 08:48:04 | bauzas | I totally flipped my mind | |
| 08:48:08 | gibi | so what I quoted from that dock is #6 | |
| 08:48:15 | gibi | s/docks/doc/ | |
| 08:48:20 | bauzas | yup | |
| 08:48:29 | bauzas | see my latest revision | |
| 08:48:35 | gibi | looking... | |
| 08:48:56 | bauzas | my wonder is, do we have a grenade-skip-level job in place that validates our N-2 computes ? | |
| 08:49:48 | opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Creating an example of the refactor privileged functions will go through. https://review.opendev.org/c/openstack/nova/+/875497 | |
| 08:49:49 | bauzas | yeah, we do | |
| 08:49:54 | bauzas | https://github.com/openstack/nova/blob/master/.zuul.yaml#L759 | |
| 08:50:47 | bauzas | https://zuul.openstack.org/builds?job_name=grenade-skip-level&project=openstack%2Fnova&skip=0 | |
| 08:58:39 | opendevreview | Sylvain Bauza proposed openstack/nova master: Update min service version for Antelope https://review.opendev.org/c/openstack/nova/+/874932 | |
| 08:58:40 | opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | |
| 09:00:25 | gibi | bauzas: replied inline | |
| 09:00:40 | gibi | the current patch still proposes allowing Antelope to support Yoga computes, but it does not document it | |
| 09:01:19 | gibi | ahh you pushed PS3 | |
| 09:02:41 | gibi | I think my comments still valid for PS3 too | |
| 09:03:27 | bauzas | gibi: tl,dr : I don't disagree with your very valid points, we haven't properly documented the level of support operators shall expect | |
| 09:03:38 | bauzas | but I think I understood the pattern | |
| 09:04:02 | bauzas | we'll remove the grenade-skip-level patch in Bobcat | |
| 09:06:15 | bauzas | gibi: ideally, I'd clarify this in our meeting | |
| 09:06:21 | bauzas | with dansmith and others around | |
| 09:07:57 | gibi | ohh on that note, I might not be able to join today | |
| 09:07:59 | bauzas | I also wonder whether we should remove the grenade-skip-level job run on check pipeline at the same time of https://review.opendev.org/c/openstack/nova/+/875621/ in https://github.com/openstack/nova/blob/master/.zuul.yaml#L759-L760 | |
| 09:08:28 | bauzas | gibi: ok, then we'll try to discuss this first with dan before you run off | |
| 09:09:12 | gibi | I think having a non voting skip level during Bobcat does not hurt if we clearly communicate what support (none) is expected in Bobcat for Zed computes | |
| 09:10:23 | bauzas | gibi: I don't disagree but maybe it shouldn't be on the check pipeline | |
| 09:10:31 | bauzas | gibi: maybe periodic + experimental | |
| 09:11:01 | gibi | I'm fine either way. For me having a job we ignore is a non issue. I more affaraid of miscommunication of support | |
| 09:11:14 | bauzas | and right after Bobcat RC1, we should set the job to *voting* | |
| 09:11:55 | opendevreview | Jorge San Emeterio proposed openstack/nova master: WIP: Creating an example of the refactor privileged functions will go through. https://review.opendev.org/c/openstack/nova/+/875497 | |
| 09:11:58 | bauzas | the point here is that I'm always context loading at every end of a cycle, this is not great | |
| 09:12:11 | bauzas | I really want we agree on a pattern to follow | |
| 09:12:29 | gibi | sure. have a pattern, document it, and then it is easier to follow | |
| 09:12:32 | bauzas | so new PTLs should just copy/paste | |
| 09:13:11 | bauzas | I'm glad we had the grenade-skip-level job running despite I completely forgot about it | |
| 09:13:24 | bauzas | this was added way earlier | |
| 09:13:40 | bauzas | https://github.com/openstack/nova/commit/219c360dc19f79ce7df8a92f6487aee97a64ee4c#diff-108978819c05ae183d88ec87959c2341a94cfc3f9465e3aeee82d554217b4f58 | |
| 09:14:20 | gibi | the ptl guide has the timeline so I guess that is a good place to document the pattern to follow | |
| 09:14:41 | bauzas | oh yeah | |
| 09:14:50 | bauzas | I used it a lot | |
| 09:14:59 | bauzas | + the rc1 etherpads | |
| 09:15:26 | bauzas | I'll do a bit of scrubbing | |
| 09:26:50 | opendevreview | Sylvain Bauza proposed openstack/nova master: DNM (yet) Update min support for Bobcat https://review.opendev.org/c/openstack/nova/+/875621 | |