| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-10-15 | |||
| 09:55:01 | lyarwood | Morning morning | |
| 10:11:09 | stephenfin | gibi: Heads up that I've added specless BP approval for https://blueprints.launchpad.net/nova/+spec/compact-havana-db-migrations to the agenda for today's meeting. I won't be around though so I can move to next week if it proves to be any way contentious | |
| 10:11:53 | stephenfin | "...and make it easier to move to Alembic in the future." /o\ | |
| 10:12:17 | stephenfin | that went super well, evidently | |
| 10:15:42 | tosky | stephenfin: is that related to the usage of sqlalchemy-migrate? | |
| 10:15:54 | stephenfin | tosky: Dumping the use of it, yes | |
| 10:16:52 | tosky | so sqlalchemy-migrate is still a dependency, but it's kind of abandoned (x namespace), I've tried to fix the zuul jobs but of course most of the people marked as maintainers are not around | |
| 10:24:32 | stephenfin | tosky: It's dead. Alembic is apparently a far better designed tool that we should have switched to ages ago but, you know, ENOTIME | |
| 10:25:17 | stephenfin | but our number of DB migrations has plummeted in recent releases so no better time, I'm thinking. We shall see | |
| 10:31:05 | openstackgerrit | Merged openstack/nova stable/victoria: Follow up for cherry-pick check for merge patch https://review.opendev.org/757613 | |
| 10:47:06 | gibi | stephenfin: ack. I don't expect too much pushback on that | |
| 10:50:28 | lyarwood | stephenfin: ^ another pre_live_migration functional test if you have time today | |
| 10:50:28 | openstack | bug 1899835 in OpenStack Compute (nova) "n-cpu attempts to disconnect volumes after early pre_live_migration failures on the destination during a live migration" [Undecided,New] https://launchpad.net/bugs/1899835 - Assigned to Lee Yarwood (lyarwood) | |
| 10:50:28 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add regression test for bug #1899835 https://review.opendev.org/758239 | |
| 11:09:15 | tosky | stephenfin: I know it's dead, but as long as projects still depend on it (because ENOTIME), it's not really dead :) | |
| 11:17:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Compact pre-Juno database migrations https://review.opendev.org/758394 | |
| 11:17:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Compact pre-Liberty database migrations https://review.opendev.org/758396 | |
| 11:17:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: TODO: Compact pre-Kilo database migration https://review.opendev.org/758395 | |
| 11:17:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: Compact pre-Newton database migrations https://review.opendev.org/758398 | |
| 11:17:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: TODO: Compact pre-Mitaka database migrations https://review.opendev.org/758397 | |
| 11:20:31 | stephenfin | gibi: Think you could take a spin through https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove-xenapi maybe early next week too? I assume we can merge now that V is out the door | |
| 11:22:25 | stephenfin | lyarwood: +2 to that and its predecessor | |
| 11:22:28 | stephenfin | <3 functional tests | |
| 11:22:55 | stephenfin | lyarwood: Not nova, but could you buzz through https://review.opendev.org/#/c/755887/ and https://review.opendev.org/#/c/755888/ | |
| 11:23:01 | gibi | stephenfin: thanks for the reminder, will do | |
| 11:24:15 | stephenfin | Does anyone know where that docs that mriedem did on novaclient-OSC gaps is gone to? Think I'm going to spend some time this cycle closing that out too | |
| 11:25:09 | gibi | it is an etherpad... looking.. | |
| 11:25:16 | gibi | https://etherpad.opendev.org/p/compute-api-microversion-gap-in-osc | |
| 11:28:30 | stephenfin | gibi++ thanks! | |
| 11:31:21 | gibi | stephenfin: I also thought about the relationship of o.vo and mypy. o.vo handles the fields by generating properties for it runtime so that static checker is clueless. But I think w might be able to generate a .pyi interface file for o.vos that has the fields with static types to help mypy | |
| 11:47:59 | sean-k-mooney | that makes sense althoug we can proably also extend mypy to pars ovo but the pyi file is proably simpler | |
| 11:49:16 | gibi | sean-k-mooney: yeah a plugin to mypy is also a possibility but as far as I see the plugin interface of mypy is unstable | |
| 11:50:21 | sean-k-mooney | i have not really looked at it | |
| 11:51:13 | gibi | https://mypy.readthedocs.io/en/stable/extending_mypy.html#extending-mypy-using-plugins "The plugin system is experimental and prone to change. I" | |
| 12:04:30 | sean-k-mooney | we could likely write a small script that would loop over the nova/objects dir and produce the pyi files and run that in the tox env | |
| 12:05:04 | sean-k-mooney | we could optionally commit them or just have them generated on the fly | |
| 12:14:32 | gibi | sean-k-mooney: yeah, that is the direction of my thinknig | |
| 12:16:24 | lyarwood | stephenfin: FWIW I wanted to sort the evacuate command out in osc | |
| 12:16:58 | lyarwood | TIL sean-k-mooney had a change for this | |
| 12:19:24 | lyarwood | added to the PTG pad | |
| 12:28:20 | sean-k-mooney | lyarwood: yep it more or less done but we want to rename it back to evacuate | |
| 12:28:34 | sean-k-mooney | its been on my todo list for a whiel if you feel like taking it over | |
| 12:28:43 | sean-k-mooney | if not i can try and do it before the ptg | |
| 12:29:40 | lyarwood | sean-k-mooney: so was that outcome, that we wanted to stay with evacuate for now? | |
| 12:29:48 | lyarwood | sean-k-mooney: if so I can rework it now | |
| 12:30:19 | sean-k-mooney | lyarwood: thats what dansmith wanted | |
| 12:30:36 | sean-k-mooney | also since i want to add recreate as a new action it proably better not to rename | |
| 12:30:43 | brinzhang | gibi, sean-k-mooney: I encounter a question, I want to backport https://review.opendev.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/numa-aware-live-migration to Rocky release | |
| 12:30:53 | brinzhang | gibi, sean-k-moooney: Because there is a big gap between its minor versions, I only merged the changes below the api, including the RPC Version changes, but changed rpc_version=5.3 to rpc_version=5.1 to adapt to the version number of Rocky release. | |
| 12:31:00 | sean-k-mooney | lyarwood: the main concen was people thinking it was a new thing calling it resurect | |
| 12:31:15 | sean-k-mooney | brinzhang: that a feature not a bug | |
| 12:31:21 | sean-k-mooney | brinzhang: so you cant backprot it | |
| 12:31:40 | lyarwood | sean-k-mooney: ack yup np, I'll rework it now in that case | |
| 12:31:42 | brinzhang | gibi: but, when I request live migration the rpcverion=5.1 can not valid | |
| 12:31:48 | sean-k-mooney | brinzhang: rpc backports cant realy be done | |
| 12:33:05 | brinzhang | sean-k-mooney: I know, but if I upgrade the rocky release to ussuri, that will be some impact than backport, so I just want to backport it | |
| 12:33:27 | brinzhang | but encountered the rpcverion invalid issue | |
| 12:33:34 | sean-k-mooney | brinzhang yes | |
| 12:33:57 | sean-k-mooney | you cant backport rpc change because it will break upgrades and rolling deployments | |
| 12:34:14 | sean-k-mooney | we have tried downstream and it really did not go well | |
| 12:34:20 | brinzhang | does it need to change the oslo.messaging to adopt 5.1? | |
| 12:35:17 | brinzhang | I got +1 on the basis of the rpc version of the Rocky version, which is not a complete backport | |
| 12:35:38 | sean-k-mooney | +1 from who? | |
| 12:36:10 | sean-k-mooney | we should not attempt to backport this upstream | |
| 12:36:35 | brinzhang | +1 from rocky rpc version 5.0-->5.1, and change the target_compute version from 35 to 36 | |
| 12:37:32 | brinzhang | I looked into the service db table, the node compute can be 36, but when we restart the compute service,the rpc version also in 5.0 | |
| 12:38:33 | brinzhang | sean-k-mooney: Backport is a last resort | |
| 12:39:25 | brinzhang | base on https://github.com/openstack/nova/blob/stable/rocky/nova/compute/rpcapi.py#L351, +1 for the rpcversion | |
| 12:40:01 | brinzhang | refer this patch: https://review.opendev.org/#/c/634606/86 | |
| 12:44:53 | gibi | brinzhang: I've never tried backporting an RPC change. | |
| 12:45:32 | sean-k-mooney | gibi: stephenfin has | |
| 12:45:37 | gibi | I did assisted backporting API changes downstream, there we simply put the new API into the latest microversion of that branch. It is ugly but it works | |
| 12:46:16 | sean-k-mooney | that is ya less then good if you have to ship it to others | |
| 12:46:17 | brinzhang | gibi: I want to know what key points I have overlooked. This method of incrementing the version number based on the rocky version is the same as adding a feature to the master, but why doesn't it take effect? | |
| 12:46:41 | sean-k-mooney | our rule is if it has object,db,api or rpc change its not backported | |
| 12:47:57 | brinzhang | the rules are clear :D | |
| 12:48:20 | sean-k-mooney | am have you pinned your rpc version in the config | |
| 12:48:43 | gibi | sean-k-mooney: yeah, it was a compromise where the necessary risk and future cost was accepted (and I don't have to touch it so I'm fine with it) | |
| 12:48:53 | brinzhang | but in theoretically, my thought can pass, but it is not | |
| 12:49:17 | sean-k-mooney | gibi: we have considered doing the same for api changes but decied not to for feature discovery | |
| 12:49:55 | gibi | brinzhang: might be your problem related to the RPC version alias on the given branch (simply guessing here) | |
| 12:50:02 | sean-k-mooney | e.g. we did not want ot create interoperabity issue between clouds | |
| 12:50:25 | sean-k-mooney | gibi: yep that is want i was wondering for the config | |
| 12:50:28 | sean-k-mooney | more or less | |
| 12:50:45 | sean-k-mooney | e.g. is it pinned to a version and or an alias | |
| 12:51:56 | brinzhang | gibi: alias? what does this mean? | |
| 12:52:14 | brinzhang | RPC version alias? | |
| 12:52:43 | gibi | brinzhang: https://docs.openstack.org/nova/latest/user/upgrade.html#concepts | |
| 12:53:11 | sean-k-mooney | https://github.com/openstack/nova/blob/stable/rocky/nova/compute/rpcapi.py#L354-L364 | |
| 12:54:20 | brinzhang | sean-k-mooney: we dont change the VERSION_ALIASES | |
| 12:54:43 | brinzhang | it is as the same as your paste | |
| 12:54:57 | sean-k-mooney | yes but what do you have your rpc version set to in the config | |
| 12:55:22 | sean-k-mooney | blank, auto, an alias or a value | |
| 12:55:57 | brinzhang | the default, because we dont config the rpcversion in conf file | |
| 12:56:27 | sean-k-mooney | so i think that will default to the newest version supported by the current node | |
| 12:56:48 | sean-k-mooney | meaing if you have not applie the change to all serivce some will be 5.0 and other will be 5.1 | |
| 12:57:06 | sean-k-mooney | auto i think figures out thet max supported version for all nodes | |
| 12:57:34 | sean-k-mooney | for the numa migration at least both comptue nodes and the conductor would need 5.1 | |
| 12:58:00 | brinzhang | sean-k-mooney: yeah, I can try your suggestion, I changed two nodes's code in my 3 nodes cluster | |
| 12:58:30 | brinzhang | but stoped the nova-* services in another node | |