| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-23 | |||
| 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 | lyarwood | mdbooth: https://launchpad.net/bugs/1414895 & https://review.openstack.org/#/c/618478/1 | |
| 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: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 libvirt remotefs calls. https://review.openstack.org/619701 | |
| 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: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:34 | openstackgerrit | Michael Still proposed openstack/nova master: Imagebackend should call processutils.execute directly. https://review.openstack.org/619704 | |
| 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 | kashyap | mdbooth: So the context is I'm trying to fix this bug: https://bugs.launchpad.net/nova/+bug/1780138 | |
| 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: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 | |
| 15:16:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend RequestGroup object for mapping https://review.openstack.org/619527 | |
| 15:16:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239 | |
| 15:16:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528 | |
| 15:16:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240 | |
| 15:16:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529 | |
| 15:16:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459 | |
| 15:16:45 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 17:06:50 | openstackgerrit | Matthew Booth proposed openstack/nova master: Fix configure() called after DatabaseAtVersion fixture https://review.openstack.org/619723 | |
| 17:10:26 | lyarwood | hmm is tox -e debug also broken for others at the moment? | |
| 17:10:44 | lyarwood | Unhandled error: TypeError: Can't instantiate abstract class SubclassSignatureTestCase with abstract methods _get_base_class | |
| 17:11:01 | lyarwood | is all I'm getting, even running oslo_debug_helper directly | |
| 18:56:20 | artom | lyarwood, maybe try with -r ? | |
| 19:11:53 | openstackgerrit | Jack Ding proposed openstack/nova-specs master: Flavor Extra Spec and Image Properties Validation https://review.openstack.org/618542 | |
| 22:12:36 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Always cleanup the instance dir when using block image backends https://review.openstack.org/618478 | |