Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-23
09:37:37 mdbooth lyarwood: You may
09:39:06 lyarwood mdbooth: cool, so, https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/fake_imagebackend.py#L124-L183 and the way it's currently returning a func over an actual class
09:39:32 lyarwood mdbooth: do you recall why you wired it up this up instead of returning some fake Image class?
09:39:43 mdbooth Have I got a patch up which changes that?
09:39:59 mdbooth The issue, iirc, is that you'd need to have a closed class
09:40:07 mdbooth i.e. the function it returns is a closure
09:40:19 lyarwood ahhhhh
09:40:25 mdbooth If you returned a class, the class would also have to be a closure over the same data
09:40:41 mdbooth However, I vaguely recall I may have a patch which touches this
09:41:44 lyarwood right, so I have that WIP change on top of another series from you where I'm attempting to use the static is_shared_block_storage method from the image classes that I obviously can't when it's a func
09:41:47 mdbooth Hmm, if I do I can't see it right now
09:42:53 mdbooth I'm *convinced* I've written a patch for this already
09:43:38 mdbooth If only we could land cleanup changes in non-geological time I wouldn't lose track of this stuff.
09:45:32 mdbooth lyarwood: I'm pretty sure that whenever I wrote it, it was for exactly the issue you just hit, so I'm guessing we've worked on this before.
09:47:23 lyarwood kk looking through https://review.openstack.org/#/q/owner:%22Matthew+Booth+%253Cmbooth%2540redhat.com%253E%22+file:%22nova/tests/unit/virt/libvirt/fake_imagebackend.py%22 now
09:49:33 lyarwood mdbooth: yeah I really don't see it there, maybe you didn't post it?
09:49:59 mdbooth lyarwood: Possible
09:51:51 mdbooth lyarwood: Which bug are you working on?
09:52:24 openstack Launchpad bug 1414895 in OpenStack Compute (nova) "failed compute node didn't delete instance's path directory in init_host" [Low,In progress] - Assigned to Lee Yarwood (lyarwood)
09:52:24 lyarwood mdbooth: https://launchpad.net/bugs/1414895 & https://review.openstack.org/#/c/618478/1
09:53:35 mdbooth lyarwood: Nope, I'm coming up blank.
09:53:50 mdbooth lyarwood: Lemme have a quick look at the code to refresh my memory.
09:54:11 lyarwood mdbooth: basically with images_type = rbd we never cleanup the instance directory after an evacuation
09:54:38 lyarwood mdbooth: we also don't have migrate_data set so I wanted to call down into the local backend to see if it's safe to remove the instance directory
09:55:29 lyarwood mdbooth: I don't understand the use of migrate_data here if I'm honest, given how the imagebackend is local to the current compute, I know we can't mix but it still seems pointless to stash in migrate_data
09:58:32 kashyap Hey folks, those who dwell on the Nova API part: any specific reason why the custom server metadata value is limited to 255 bytes here: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L343,L360
09:59:41 mdbooth lyarwood: is_shared_block_storage() is a bug, btw
09:59:57 mdbooth lyarwood: Any use of it is pretty much guaranteed to be wrong in some circumstances
10:00:14 lyarwood mdbooth: how so?
10:01:22 lyarwood mdbooth: it's only True for the Rbd backend
10:01:33 lyarwood mdbooth: which is always shared
10:02:28 mdbooth lyarwood: Not necessarily shared between everything, though
10:03:10 mdbooth It's broken if you have more than 1 ceph pool
10:04:10 lyarwood mdbooth: that's still not a reason to leave the instance directory around on the source node of an evacuation
10:04:24 lyarwood mdbooth: or to not clean the instance directory up
10:04:25 mdbooth lyarwood: Ok, from very vague memory I picked an arbitrary imagebackend, probably Flat, and made it return a closed subclass of that
10:05:09 mdbooth Or perhaps it wasn't a subclass... perhaps it was an autospec'd Mock
10:05:39 lyarwood mdbooth: kk thanks, I'll take a swing at that today
10:06:32 openstackgerrit Michael Still proposed openstack/nova master: Remove utils.execute() calls from xenapi. https://review.openstack.org/619700
10:06:33 openstackgerrit Michael Still proposed openstack/nova master: Remove utils.execute() from quobyte libvirt storage driver. https://review.openstack.org/619702
10:06:33 openstackgerrit Michael Still proposed openstack/nova master: Remove utils.execute() from libvirt remotefs calls. https://review.openstack.org/619701
10:06:34 openstackgerrit Michael Still proposed openstack/nova master: Imagebackend should call processutils.execute directly. https://review.openstack.org/619704
10:06:34 openstackgerrit Michael Still proposed openstack/nova master: Move nova.libvirt.utils away from using nova.utils.execute(). https://review.openstack.org/619703
10:06:35 openstackgerrit Michael Still proposed openstack/nova master: Remove final users of utils.execute() in libvirt. https://review.openstack.org/619705
10:39:07 kashyap mdbooth: Hi, got a moment to borrow your eyes on my understanding of a bit certain code?
10:40:16 mdbooth kashyap: Sure
10:41:01 openstack Launchpad bug 1780138 in OpenStack Compute (nova) "Don't assume the guest machine type to be of 'pc'" [Medium,Confirmed] - Assigned to Kashyap Chamarthy (kashyapc)
10:41:01 kashyap mdbooth: So the context is I'm trying to fix this bug: https://bugs.launchpad.net/nova/+bug/1780138
10:41:14 kashyap mdbooth: See the "What will break?" section to get to the "tofu of the matter".
10:42:25 mdbooth Is that like a less-substantial meat of the matter?
10:42:48 kashyap Heh
10:43:27 kashyap mdbooth: My first step is to see in _get_guest_config() here: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5194
10:43:46 kashyap If the host capabilities (including the machine type for a given QEMU binary) will be in memory.
10:43:59 kashyap Let me show an example of what I mean:
10:46:21 kashyap Given this line of code there: caps = self._host.get_capabilities()
10:46:41 kashyap Will we have both the 'host' _and_ 'guest' part of the capabilities output as shown here: https://kashyapc.fedorapeople.org/virsh-capabilities.txt
10:48:03 mdbooth ok
10:48:40 kashyap I need to extract the default machine type (caps.guest.machine) for the QEMU on the given host, from this snippet:
10:48:43 kashyap <guest>
10:48:46 kashyap <os_type>hvm</os_type>
10:48:48 kashyap <arch name='x86_64'>
10:48:51 kashyap <wordsize>64</wordsize>
10:48:53 kashyap <emulator>/usr/bin/qemu-system-x86_64</emulator>
10:48:56 kashyap <machine maxCpus='255'>pc-i440fx-3.0</machine>
10:48:58 kashyap [...]
10:50:06 kashyap So my question is do you know if we'll have the "guest.arch.machine" as well in memory. (And not just the <host> part)
10:50:24 kashyap If you're deeply buried in something, disregard me, I'll keep duking around :-)
10:52:44 mdbooth kashyap: Sorry, repair guy just turned up
10:52:56 kashyap mdbooth: Yeah, saw your note about it earlier. Keep going
10:53:08 kashyap I also need to shortly step out to get some groceries
10:55:12 mdbooth kashyap: To 'answer' your question, I have no idea :)
10:55:37 kashyap mdbooth: No worries, I'm trying to figure out how on earth to try it; maybe break-points and do 'print' of "caps", etc
10:56:02 kashyap I'll let you know when / if I see the light
10:57:37 sean-k-mooney kashyap: i belive you can use the machive type to set the arch but not sure. this was a capablit i taught we always had but recently i have been less sure if we actully support it or not
10:58:16 kashyap sean-k-mooney: Heya, I'm not trying to set the arch via machine type. What I want to know is, what _exactly_ are the contents of "caps"
10:58:31 kashyap [Where caps = self._host.get_capabilities()]
10:58:38 kashyap And how do I "see" it
10:59:05 sean-k-mooney kashyap: i would hope it was be what is show in virsh cabalities for that emalator type
10:59:56 kashyap sean-k-mooney: So, 'virsh capabilities' has two parts: <host> and <guest> (per emulator)
10:59:59 kashyap E.g. https://kashyapc.fedorapeople.org/virsh-capabilities.txt
11:00:24 kashyap sean-k-mooney: Given that 'caps' holds self._host.get_capabilities(), will it have _both_ parts is what I'm wondering.
11:01:44 sean-k-mooney kashyap: i added the arm package and this got added to virsh capablities http://paste.openstack.org/show/735969/
11:02:54 kashyap sean-k-mooney: That's on your host, and is expected :-).
11:03:11 kashyap So, I'll assume Nova will have the entire 'virsh capabilities' output from the host.
11:03:16 kashyap When it runs: self._host.get_capabilities()
11:03:45 sean-k-mooney yes but you can list the falgs of the different cpus yes and get there capablities
11:07:10 kashyap sean-k-mooney: Nod; my main goal is to extract the default machine from the caps XML and update the code in _get_guest_config() to reflect that
11:07:54 kashyap (Instead of assuming the machine the machine type is "pc", when 'guest.os_mach_type == None' -- as noted in the code snippet in the bug.)
11:14:03 sean-k-mooney o/
11:15:15 kashyap cdent: Heya, wonder if you saw my earlier question about Nova API and metadata value limit to 255 bytes
11:15:49 cdent kashyap: I didn't see it. I also know almost nothing about anything :)
11:15:54 kashyap 10:58 < kashyap> Hey folks, those who dwell on the Nova API part: any specific reason why the custom server metadata value is limited to 255 bytes here: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L343,L360
11:16:04 kashyap Heh, okay; I'll do a `git blame` and find the culprit ;-)
11:16:40 cdent It's probably an arbitrary choice of the "there needs to be some limit and we all love the number 255" sort
11:17:05 kashyap Hehe
11:26:51 sean-k-mooney kashyap: if you like im sure we could change it to 42
11:58:46 jangutter clearly, 640KB should be enough for everybody (second time today I said this).
12:06:15 openstackgerrit Matthew Booth proposed openstack/nova master: Fix configure() called after DatabaseAtVersion fixture https://review.openstack.org/619723
12:06:50 mdbooth ^^^ was a pig to find, causes non-deterministic failures in unit tests based on the order they run in a worker
13:17:14 openstackgerrit Elod Illes proposed openstack/nova master: Transform scheduler.select_destinations notification https://review.openstack.org/508506

Earlier   Later