Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-22
16:30:24 gibi artom: as far as I understand cinder volumes passed to a VM are also attached to the compute host and then the resulting device is passed to the VM via libvirt
16:30:30 gibi artom: but I can be worng
16:30:31 gibi wrong
16:32:39 artom gibi, oh, right, yeah, I... I'm actually not sure what I understood from your idea
16:32:58 artom For some reason I thought the VMs would be mounting the volumes inside the guest OS
16:36:04 jackding jaypipes: Hi Jay, I have responded to your question on https://review.openstack.org/#/c/618542/
16:38:06 gibi artom: my idea is to use cinder volumes as local disk providers for the compute host directlty
16:38:48 artom gibi, right, so you'd mount the nova instances directly over iscsi or NFS or whatever from the volume's connection_info
16:39:24 artom I guess? I'm not sure how supported that is. It seems weird to do that instead of deploying Ceph or something explicitly for this purpose
16:40:34 gibi artom: yeah deploy ceph would be the ideal solution, or using the cinder backend directly
16:40:59 artom gibi, actually yeah, why not just use Cinder's backend directly.
16:41:46 artom Hrmm, would there be a way to set a compute node's disk capacity to 0?
16:42:02 artom It wouldn't make boot from volume transparent, but it would at least prevent local storage from being used.
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 artom That disk_allocation_hack would work with Queens, I think
16:45:48 gary_perkins because Rocky doesn't yet work on the Arm machines I'm using
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 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)

Earlier   Later