Earlier  
Posted Nick Remark
#openstack-nova - 2020-09-29
17:26:29 dansmith gmann: I think that losing the live migration on ceph coverage for really any amount of time, is problematic
17:26:35 gmann i expect d-g to be removed in W or X.
17:27:08 gmann tosky: yeah but we can remove dog support if it is 100% done and no dependency at all.
17:27:19 tosky isn't the ceph job a matter of including the devstack-plugin-ceph plugin and delegating the configuration to it?
17:27:21 gmann tosky: and do not forget the 3rd party CI/CD.
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

Earlier   Later