| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-22 | |||
| 16:42:19 | gary_perkins | artom: +1 | |
| 16:43:11 | gary_perkins | yeah, I could just manually setup iscsid/tgt or user cinder. I just didn't know one could use cinder outside of OpenStack | |
| 16:44:06 | artom | gary_perkins, not Cinder itself directly, I think. But Cinder's backend is what gibi was suggesting. | |
| 16:44:38 | gary_perkins | artom: ahhh, in my case that's just LVM | |
| 16:44:40 | artom | gary_perkins, also, what version is this? Because you could also set disk_allocation_ratio to something really tiny to effectively reserve the vast majority of the computes's disks | |
| 16:44:58 | gary_perkins | I'm running Queens | |
| 16:45:48 | gary_perkins | because Rocky doesn't yet work on the Arm machines I'm using | |
| 16:45:48 | artom | That disk_allocation_hack would work with Queens, I think | |
| 16:45:55 | gibi | artom: instead of allocation ratio you can use reserved_host_disk_mb to reserve disk | |
| 16:46:03 | gary_perkins | artom: thanks, I'll look into it | |
| 16:46:11 | artom | gibi, hah, thanks, yeah, that's smarter :) | |
| 16:55:13 | openstackgerrit | Matthew Booth proposed openstack/nova master: Workaround a race initialising version control in db_version() https://review.openstack.org/619622 | |
| #openstack-nova - 2018-11-23 | |||
| 00:56:56 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: Re-propose numa-aware-live-migration spec https://review.openstack.org/599587 | |
| 01:23:21 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Remove live_migration_progress_timeout config https://review.openstack.org/619142 | |
| 02:00:39 | alex_xu | stephenfin: do you know whether we support resize for numa topology stuff? I didn't see where we update the numa topo in req_spec with new flavor when resize | |
| 06:32:37 | openstackgerrit | Yikun Jiang proposed openstack/nova master: Remove live_migration_progress_timeout config https://review.openstack.org/619142 | |
| 06:49:54 | openstackgerrit | Merged openstack/nova stable/rocky: Imported Translations from Zanata https://review.openstack.org/614757 | |
| 07:47:17 | openstackgerrit | Yongli He proposed openstack/nova-specs master: add 'show-server-group' spec https://review.openstack.org/612255 | |
| 07:51:24 | openstackgerrit | Yongli He proposed openstack/nova-specs master: add spec "show-server-numa-topology" https://review.openstack.org/612256 | |
| 09:01:45 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Bump compute service to indicate attach/detach root volume is supported https://review.openstack.org/614750 | |
| 09:37:28 | lyarwood | mdbooth: morning, can I bug you about fake_imagebackend this morning? | |
| 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) | |