| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-09-29 | |||
| 17:27:38 | tosky | gmann: 3rd party CI/CD have been told about that | |
| 17:27:45 | lyarwood | tosky: no, we need a multinode / multi compute job for these tests | |
| 17:27:57 | lyarwood | tosky: the standard job is just single host | |
| 17:28:28 | lyarwood | cinder-plugin-ceph-tempest-mn-aa looks like it's multinode but I don't think it's deploying two computes | |
| 17:28:52 | tosky | lyarwood: I mean, if you get the standard job, derive a the new job from it, change the nodeset and add devstack-plugin-ceph, what else will be missing? | |
| 17:29:05 | dansmith | the post-config change right? | |
| 17:29:19 | lyarwood | I'm pretty sure the plugin doesn't import the ceph keyring | |
| 17:29:27 | lyarwood | the old LM job would scp things around iirc | |
| 17:29:33 | lyarwood | we could hack something up quickly for that | |
| 17:29:44 | lyarwood | I just wanted to write a role for it etc | |
| 17:29:47 | lyarwood | into the plugin itself | |
| 17:30:21 | tosky | just as a general picture regarding the zuul v3 migration: right now, there are just: | |
| 17:30:41 | dansmith | I'm fully in support of the v3 conversion, and cleaning this all up, but it seems a little foolish to drop coverage of the most common deployment mechanism's live-migration support because of it, | |
| 17:31:08 | dansmith | even if it hasn't caught anything lately.. Murphy's probably due for an appearance if anything :) | |
| 17:31:17 | tosky | a non-voting cinder job (being worked on by me); a heat job (there is a WIP patch); a murano-apps and a murano-dashboard jobs (apparently abandoned) | |
| 17:31:40 | tosky | 2 neutron jobs (being worked on, almost ready); the nova jobs | |
| 17:31:47 | tosky | and that's basically it for the openstack/ namespace | |
| 17:31:49 | tosky | so... | |
| 17:31:56 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add nova-grenade-multinode-ceph job https://review.opendev.org/755092 | |
| 17:32:03 | tosky | not that I want to push for it, but that's what I'm trying to do :) | |
| 17:32:07 | lyarwood | okay well add these ceph jobs to the list | |
| 17:32:47 | lyarwood | gmann: lets take https://review.opendev.org/#/c/752557/ out of the gate and I'll work on the ceph part tonight | |
| 17:32:47 | gmann | lyarwood: dansmith ^^ let's try. but yes we might need to setup the keyring things on subnode | |
| 17:33:05 | gmann | lyarwood: ok | |
| 17:36:18 | dansmith | gmann: I hope it's that easy! | |
| 17:39:43 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add nova-grenade-multinode-ceph job https://review.opendev.org/755092 | |
| 19:06:49 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add modernize-os-hypervisors-api spec https://review.opendev.org/755109 | |
| #openstack-nova - 2020-09-30 | |||
| 03:05:15 | openstackgerrit | wu.shiming proposed openstack/os-vif master: Fix hacking min version to 3.0.1 https://review.opendev.org/755168 | |
| 08:11:42 | ralonsoh | hi folks, do you know what is this message? https://a5e1b7092bd931de9d7c-99461a827f8c9e81159099d5f417814c.ssl.cf1.rackcdn.com/738163/21/check/neutron-ovn-tempest-full-multinode-ovs-master/462d24b/compute1/logs/screen-n-cpu.txt | |
| 08:12:06 | ralonsoh | --> http://paste.openstack.org/show/798558/ | |
| 08:12:29 | ralonsoh | sean-k-mooney, stephenfin ^^ | |
| 08:12:34 | ralonsoh | if you know that | |
| 08:12:39 | lyarwood | bauzas: https://review.opendev.org/#/c/752486/ & https://review.opendev.org/#/c/749233/ & https://review.opendev.org/#/c/729178/ & https://review.opendev.org/#/c/744552/ - would you mind taking a look at these stable backports today if you have time? | |
| 08:24:14 | bauzas | lyarwood: rushing to finish my talk recording this morning, hopefully would be able to review later today | |
| 08:24:25 | bauzas | 7 mins left for recording | |
| 08:24:49 | bauzas | and I can't count the number of rushes i already had | |
| 08:26:04 | lyarwood | bauzas: ack np good luck! | |
| 08:37:51 | frickler | ralonsoh: that looks like https://bugs.launchpad.net/nova/+bug/1863021 but I assumed that that bug had long been fixed everywhere | |
| 08:37:51 | openstack | Launchpad bug 1863021 in OpenStack Object Storage (swift) "[SRU] eventlet monkey patch results in assert len(_active) == 1 AssertionError" [Undecided,In progress] - Assigned to Chris MacNaughton (chris.macnaughton) | |
| 08:39:15 | frickler | maybe not in ovs? | |
| 08:39:22 | stephenfin | ralonsoh: frickler: Yeah, that should have been fixed with github.com/openstack/nova/commit/2078ef850c9 | |
| 08:39:55 | stephenfin | although that's using a subprocess so maybe the fix is needed elsewhere | |
| 08:41:03 | ralonsoh | frickler, stephenfin thanks a lot | |
| 09:18:11 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add modernize-os-hypervisors-api spec https://review.opendev.org/755109 | |
| 09:20:06 | lyarwood | stephenfin: haha is that poop emoji supposed to be in there | |
| 09:20:16 | stephenfin | yes | |
| 09:20:22 | lyarwood | hahaha | |
| 09:37:13 | tobias-urdin | lyarwood: can i borrow your brain for 2 minutes? :) trying to troubleshoot an issue, am i assuming correctly that for a volume-backed instance being resized, and scheduled to another node than it resides on, _is_storage_shared_with() would return false since (source host != dest host) and remotefs.create_dir() would be executed over a SSH connection even if it's volume-backed, so the code | |
| 09:37:19 | tobias-urdin | path is not only for instances with ephemeral disks | |
| 09:37:22 | tobias-urdin | https://github.com/openstack/nova/blob/stable/train/nova/virt/libvirt/driver.py#L9860 | |
| 09:38:21 | bauzas | holy shit, 32 mins recorded for a 25 mins session /o\ | |
| 09:38:27 | lyarwood | tobias-urdin: hey sure | |
| 09:38:43 | bauzas | I need to reshot all my slides... | |
| 09:38:45 | tobias-urdin | i.e a resize with shared storage would still issue a SSH connection to the destination compute (from the source compute) to create the instance basepath in /var/lib/nova/instances/<uuid> | |
| 09:38:57 | bauzas | Christopher Nolan, be aware I'm coming | |
| 09:39:06 | lyarwood | tobias-urdin: yeah even with volume backed instances we still have to copy some instance files over to the dest | |
| 09:40:06 | tobias-urdin | in theory, if we were to implement a RPC call to create those instance files on dest we could, if all storage is shared, drop the requirement of SSH between compute nodes source -> dest? | |
| 09:40:48 | lyarwood | tobias-urdin: yes we could move this up into the compute layer, this is just legacy cruft in the driver that no one has wanted to change | |
| 09:41:40 | tobias-urdin | lyarwood: roger that, thanks for confirming for a confused brain :) | |
| 09:42:04 | lyarwood | tobias-urdin: it would take a spec however as it will likely impact a few virt drivers doing the same kind of thing in migrate_disk_and_power_off | |
| 09:42:53 | lyarwood | tobias-urdin: or did you mean call the compute rpc_api from the libvirt driver instead of ssh? | |
| 09:43:07 | lyarwood | tobias-urdin: I don't think we've allowed that in the past | |
| 09:43:23 | lyarwood | tobias-urdin: but we could look into it again in W | |
| 09:44:50 | tobias-urdin | i see, either way just wanted to confirm since we were hitting issues with resizing between nodes, getting rid of ssh connection would be preferrable somehow | |
| 09:45:24 | frickler | bauzas: just play back at 32 fps instead of 25? ;) | |
| 09:46:03 | tobias-urdin | i assume that would mean abstracting away the action so that the manager does a rpc call to the destination host, which as you said would mean a change for all drivers to implement some new method to prepare the dest node (or not implement it at all if not needed) | |
| 09:46:17 | tobias-urdin | lyarwood: appreciate it! not gonna steal more of your time :) | |
| 09:46:53 | lyarwood | yeah something like that, it would be easier to call from the virt driver but like I said there's no prior art for doing that and I think that's by design | |
| 09:47:01 | lyarwood | tobias-urdin: anytime! | |
| 09:47:41 | lyarwood | gmann / stephenfin: https://review.opendev.org/#/c/754684/ - would you mind hitting this btw? | |
| 09:52:10 | lyarwood | thanks | |
| 09:55:42 | openstackgerrit | Wenping Song proposed openstack/nova master: Add instance project_id for cyborg arq https://review.opendev.org/738428 | |
| 10:33:09 | sean-k-mooney | tobias-urdin: you dont have to usee ssh for resize | |
| 10:33:18 | sean-k-mooney | tobias-urdin: you can use rsync instead | |
| 10:34:04 | sean-k-mooney | we can also use an rpc instead fo the current test we use for detecting shared storage but that would require a spec/blueprint | |
| 10:35:25 | sean-k-mooney | tobias-urdin: lyarwood alternitivly we could finally stop supporting implict shared storgage | |
| 10:35:48 | lyarwood | sean-k-mooney: doubt that would fly with operators | |
| 10:35:55 | sean-k-mooney | e.g. if you put the nova state dir on shared storage you must set a config flag instead of detecting it | |
| 10:36:07 | lyarwood | sean-k-mooney: oh, well yeah that would be nicer | |
| 10:36:17 | sean-k-mooney | yep an ooo or whatever could set that | |
| 10:36:18 | lyarwood | also TIL about [libvirt]/remote_filesystem_transport | |
| 10:36:30 | lyarwood | I didn't think rsync would support that | |
| 10:36:43 | sean-k-mooney | rsync can be used to copy the disk | |
| 10:37:02 | sean-k-mooney | i am not sure about the detection of the shared filesystem | |
| 10:37:46 | sean-k-mooney | but ya https://github.com/openstack/nova/blob/cff7382fb3de4eef7aeddc34b6ae3409cbe50ea0/nova/virt/libvirt/volume/remotefs.py#L201 | |
| 10:38:02 | lyarwood | yeah looks like it can also do that | |
| 10:38:27 | sean-k-mooney | oh cause it can create the file on the dest and see if it shows up on the source | |
| 10:38:34 | lyarwood | yeah | |
| 10:38:46 | lyarwood | haha we create the dir and rsync it across, of course. | |
| 10:40:23 | sean-k-mooney | tobias-urdin: what was you issue by the way i did not read all of scrollback | |
| 10:41:06 | lyarwood | I don't think there was an issue, he just wanted to drop the use of ssh | |
| 10:41:21 | sean-k-mooney | ah ok | |
| 10:41:40 | sean-k-mooney | mnaser ask about the same about 2 weeks ago. e.g. could you drop ssh | |
| 10:42:14 | sean-k-mooney | i suggested an rpc at that time too although the config value occured to me after | |
| 10:44:06 | tobias-urdin | sean-k-mooney: my deployment assumed that no ssh access was required and since our resize operations never changed the destination host in the past i never hit the ssh issue | |
| 10:44:23 | tobias-urdin | and I was assuming ssh access was only needed when supporting ephemeral disks | |
| 10:44:54 | tobias-urdin | (we run soley on cinder volumes and images_type=rbd backend) | |
| 10:46:24 | sean-k-mooney | i see | |
| 10:46:35 | sean-k-mooney | images_type=rbd should not need this path | |
| 10:46:39 | sean-k-mooney | we know that is shared | |