| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-19 | |||
| 01:07:16 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Remove tenant_id https://review.opendev.org/737241 | |
| 01:10:42 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: [Trivial] update the upgrade release goal https://review.opendev.org/763294 | |
| 06:20:31 | ninad | Hi | |
| 06:20:32 | ninad | I am using linuxbridge for the neutron services and follow the installation guide as documented but during manila instance creation I am getting [Errno 113] EHOSTUNREACH _test_server_connection | |
| 06:21:03 | ninad | can someone please help me? | |
| 07:58:40 | openstackgerrit | Jorhson Deng proposed openstack/nova master: To deal instance with soft-deleting in _init_instance https://review.opendev.org/761264 | |
| 08:06:20 | openstackgerrit | Jorhson Deng proposed openstack/nova master: To deal instance with soft-deleting in _init_instance https://review.opendev.org/761264 | |
| 09:24:40 | lyarwood | aarents: apologies, had a fun day downstream yesterday, your test changes LGTM, I missed that you had already pulled in the devstack change within the tempest change so assuming it's still passing this should be good to go now. | |
| 09:31:16 | aarents | lyarwood: many thanks, I just repush with nit fix sugested by gmann | |
| 10:21:35 | stephenfin | sean-k-mooney: I think there's something broken in https://review.opendev.org/#/c/602432/. It appears grenade hasn't passed on that for the last couple of revisions. Haven't gone diving through logs yet | |
| 11:13:45 | openstackgerrit | Jorhson Deng proposed openstack/nova master: To deal instance with soft-deleting in _init_instance https://review.opendev.org/761264 | |
| 11:14:24 | openstackgerrit | Lee Yarwood proposed openstack/nova master: zuul: Add devstack-plugin-ceph-compute-local-ephemeral to experimental https://review.opendev.org/743220 | |
| 11:45:38 | sean-k-mooney | stephenfin: if we were to go from new to old i guess it would break | |
| 11:46:09 | sean-k-mooney | the xml would be generated on the souce with type ethernet | |
| 11:46:28 | sean-k-mooney | and the os-vif on the dest would be a noop | |
| 11:46:38 | sean-k-mooney | so nothing would plug the interface | |
| 11:48:02 | sean-k-mooney | the singel node grenade have been passing but not multinode | |
| 11:50:22 | sean-k-mooney | the only way i think of to fix that is to first backport the neutron change then flip the default for the option in os-vif/depercate it for removal and backport that too before we merge on master | |
| 11:50:55 | sean-k-mooney | and i would then have to keep backporting the neutron and os-vif patches first for every release. | |
| 11:51:56 | sean-k-mooney | stephenfin: lyarwood ^ is there a better way around that | |
| 12:06:50 | lyarwood | sean-k-mooney: we shouldn't be going from new to old in the tests right? | |
| 12:07:02 | lyarwood | sean-k-mooney: only old to new, or is that not defined in grenade | |
| 12:07:07 | sean-k-mooney | we do live migration back and fort | |
| 12:07:14 | sean-k-mooney | in the multi node job | |
| 12:08:06 | stephenfin | sean-k-mooney: You could make this dependent on a service version check | |
| 12:08:23 | sean-k-mooney | not really i would have to keep changin it | |
| 12:08:50 | stephenfin | why? Once everything's on Wallaby with a suitably new version of os-vif, we're good, no? | |
| 12:08:52 | sean-k-mooney | i thory this should go to osp 10 so all the way back to queens | |
| 12:08:55 | stephenfin | ah | |
| 12:09:22 | sean-k-mooney | im thinking of stoping at train to be honest | |
| 12:09:34 | sean-k-mooney | but it defiently needs to be backported a few releases | |
| 12:09:41 | stephenfin | (osp 10 is newton, fwiw) | |
| 12:09:55 | sean-k-mooney | ... of course it is | |
| 12:10:32 | sean-k-mooney | since its related to a security issue we are still ment to backport it althou technically i guess 13 would be enough at this point | |
| 12:10:33 | stephenfin | what you've proposed would require os-vif be upgraded before nova, right? I don't think we can count on that | |
| 12:10:45 | stephenfin | *os-vif and neutron | |
| 12:11:34 | sean-k-mooney | without the neturon patch you just get erros in the neutron logs but it fixes its self | |
| 12:11:44 | sean-k-mooney | the os-vif change however would be needed first ya | |
| 12:13:05 | sean-k-mooney | lyarwood: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ff2/602432/26/check/nova-grenade-multinode/ff2bd9a/logs/new/tempest_conf.txt | |
| 12:13:12 | sean-k-mooney | live_migrate_back_and_forth = True | |
| 12:13:37 | sean-k-mooney | that is why its failing | |
| 12:14:06 | gibi | stephenfin: do you have a lauchpad bp filled for this? https://review.opendev.org/#/c/755109 | |
| 12:14:24 | sean-k-mooney | its off in live migration job and that all the new version so it passes the https://zuul.opendev.org/t/openstack/build/e2fa8ae7802f41309877b537f51ba660/log/controller/logs/tempest_conf.txt#76 | |
| 12:14:26 | stephenfin | gibi: I though I did but I'm not sure | |
| 12:14:39 | gibi | the bp link in the specs does not seem to work for me | |
| 12:16:28 | sean-k-mooney | ya cant find it either | |
| 12:16:45 | sean-k-mooney | but it should be a simple copy past of the into section | |
| 12:17:01 | stephenfin | gibi: Didn't look like it. Apologies. Have created one now https://blueprints.launchpad.net/nova/+spec/modernize-os-hypervisors-api | |
| 12:17:07 | gibi | thanks | |
| 12:19:13 | sean-k-mooney | weird i cant add the spec via the spec link so i put it in the whiteborad | |
| 12:19:34 | sean-k-mooney | i tought i could do that once i was on the bug team but i guess not | |
| 12:28:30 | gibi | sean-k-mooney: I guess we edited the whiteboard in parallel and my change overwrote yours, sorry. | |
| 12:30:52 | sean-k-mooney | no launchpad gave me a permission error | |
| 12:31:38 | gibi | Blueprint changed by sean mooney: | |
| 12:31:38 | gibi | interesting, I got the following mail from launchpad | |
| 12:31:39 | gibi | spec: https://review.opendev.org/#/c/755109 | |
| 12:31:39 | gibi | Whiteboard set to: | |
| 12:31:55 | gibi | so at least some part of your update went through | |
| 12:34:46 | openstackgerrit | Merged openstack/nova-specs master: [Trivial] update the upgrade release goal https://review.opendev.org/763294 | |
| 12:55:52 | lyarwood | sean-k-mooney: sorry had to go afk | |
| 12:56:53 | lyarwood | sean-k-mooney: so old to new works, it's just new to old that's failing right? | |
| 12:57:04 | sean-k-mooney | lyarwood: yep | |
| 12:57:19 | lyarwood | sean-k-mooney: do we care in that case, I know we don't downstream | |
| 12:57:21 | sean-k-mooney | new to old nova uses type ethernet | |
| 12:57:54 | sean-k-mooney | but does not tell os-vif to plug the interface by passing crate-port=true | |
| 12:58:15 | sean-k-mooney | well once i do the backport it will alos work but we do allow rolling upgrades | |
| 12:58:22 | sean-k-mooney | so we kind of do care yes | |
| 12:58:50 | lyarwood | yeah I was thinking of major upgrades where we don't allow you to return to the older computes | |
| 12:58:59 | lyarwood | minor upgrades I guess do allow this | |
| 13:00:01 | sean-k-mooney | ya i would basiclaly need to know the version of nova on the dest | |
| 13:00:16 | sean-k-mooney | but i cant just do a normal compute service check if im backporting | |
| 13:00:41 | lyarwood | could we use something in migrate_data? | |
| 13:00:51 | lyarwood | like I did with LUKS volumes | |
| 13:01:06 | sean-k-mooney | we coudl if we dont change the object | |
| 13:01:29 | sean-k-mooney | i could stash something in the port profile or something | |
| 13:01:48 | sean-k-mooney | but i then need to supprot both in the code | |
| 13:01:56 | lyarwood | https://github.com/openstack/nova/blob/60071a2c83ad1d7ed6fd50f8af0bb4d92aa84bea/nova/virt/libvirt/driver.py#L9301-L9311 | |
| 13:02:00 | sean-k-mooney | i ripped out the bridge way of doing things so would have to put it back in | |
| 13:02:23 | lyarwood | that's not the best example as it does need an object change | |
| 13:02:33 | sean-k-mooney | ya but i get the point | |
| 13:02:48 | lyarwood | but yeah if the src can look for something stashed in there it might help | |
| 13:02:50 | sean-k-mooney | i could put it into one of the unversioned dict of string fields | |
| 13:03:14 | sean-k-mooney | ya so stash it n pre-live-migrate | |
| 13:03:24 | sean-k-mooney | and read it on the souce when updating the xml | |
| 13:03:47 | sean-k-mooney | ok ill have to think about it | |
| 13:04:06 | sean-k-mooney | i know more or less how to do that but need to find where makes the most sense | |
| 13:04:15 | lyarwood | kk | |
| 13:04:52 | sean-k-mooney | im thing in here https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L30-L59 | |
| 13:05:00 | sean-k-mooney | probaly the profile_json | |
| 13:05:04 | sean-k-mooney | since nova owns that | |
| 13:05:45 | sean-k-mooney | that is what is stored in the vifs filed of the liveMigrateData | |
| 13:05:46 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L154 | |
| 13:06:30 | lyarwood | kk | |
| 13:06:34 | lyarwood | yeah that could work | |
| 13:06:44 | lyarwood | and you would want to populate that on the dest btw | |
| 13:07:00 | lyarwood | if it isn't set or True then the source would wire things up in the legacy way | |
| 13:07:04 | sean-k-mooney | we are doing it here too https://review.opendev.org/#/c/738432/ | |
| 13:07:19 | sean-k-mooney | lyarwood: yep | |
| 13:08:31 | lyarwood | and then once it's backported you can remove the logic in the next release | |
| 13:08:49 | sean-k-mooney | yes we coudl drop i in X | |