Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-04
15:06:36 mriedem giblet: ok
15:06:50 mriedem over my head nfv isms, but ok
15:06:52 jgwentworth hah, yup
15:08:20 giblet mriedem: :)
15:10:35 dansmith jgwentworth: just to be clear, avoiding the type column with mappings doesn't require joining any placement and nova-api tables right?
15:12:08 jgwentworth dansmith: no, I was thinking a mappings query for count of instance_mappings that would be filter on project_id and user_id where queued_for_delete=0
15:12:19 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove support for monitoring Intel CMT `perf` events https://review.openstack.org/565242
15:12:40 dansmith jgwentworth: okay that gets you quotas for instance count, but not the cores,ram,disk -- is that what you mean?
15:12:57 jgwentworth dansmith: right. cores/ram would come from placement /usages query
15:13:21 dansmith which still requires something like a type yeah?
15:13:48 dansmith like if a tenant has some allocations for VCPU that isn't nova-related
15:13:51 jgwentworth I was thinking it didn't. unless we're suggesting VCPU and RAM can come from things that are not instances
15:14:11 jgwentworth that was not my understanding thus far
15:14:16 idlemind so cisco's ftd (firepower threat defense - read new asa) virtual in openstack ... boot from image (w/o create a volume) works but when i create a volume it fails to boot ... what impact does this have? if i "upgrade" a ftd virtual machine does it write back to the image or emphereal storage? do i need to create an "image" for each unique ftdv?
15:14:53 dansmith jgwentworth: we brought that up in dublin, if something else started using placement for those resource types you'd be hosed.. that was the real reason we needed type I thought
15:15:27 dansmith jgwentworth: so for example if bifrost or something like the container service, etc allocated those resources as well
15:15:54 dansmith jgwentworth: and non-instance DISK_GB allocations for just generic volumes
15:15:59 jgwentworth dansmith: yeah, if that's the case, then yeah type would be an inevitable need. or at least need a way for a subsystem to ask, "what's the resource usage for the resources that **I** put there?" so some identifier that describes the source or the type
15:16:20 dansmith jgwentworth: yup, either type or "creator" or something
15:16:36 jgwentworth yeah
15:18:34 kashyap Any "stickler for words", appreciate a quick once-over: https://review.openstack.org/#/c/565242/4/releasenotes/notes/Remove-support-for-Intel-CMT-events-017fbb890b631d70.yaml
15:25:06 jmccarthy mriedman: totally missed your comment earlier ! I don't see image_ref, but 'image' has no value listed
15:27:36 openstackgerrit sahid proposed openstack/nova master: pci: don't consider case when match tags specs https://review.openstack.org/565808
15:27:37 openstackgerrit sahid proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820
15:27:38 openstackgerrit sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514
15:27:39 openstackgerrit sahid proposed openstack/nova master: libvirt: add vf_trusted field for network metadata https://review.openstack.org/566343
15:27:40 openstackgerrit sahid proposed openstack/nova master: metadata: add vf_trusted field to device metadata https://review.openstack.org/566344
15:27:45 jgwentworth idlemind: boot from image without specifying a block device mapping will just use local storage on the compute host (hypervisor). boot from volume will use the volume's storage. what volume backend are you using?
15:28:21 jgwentworth and if your local storage is shared/persistent, boot from image will use that (if you're using ceph, for example)
15:28:56 sahid giblet: there is a serie that jay already started to review, i think you were also interested about it so if you have a moment to have look https://review.openstack.org/#/c/561912/
15:29:42 giblet sahid: I've put it on my review list
15:29:51 sahid giblet: thanks
15:30:14 openstack bug 1769131 in OpenStack Compute (nova) "After cold-migration, disk.info file leftover on source host" [Undecided,New] https://launchpad.net/bugs/1769131
15:30:14 jmccarthy Hiya melwitt: or mriedem: Any thought on this bug 1769131 ? I am getting this disk.info file created on the original compute after migrating the instance
15:31:03 jgwentworth jmccarthy: hey, I looked at that earlier and agreed it looks like the same other similar bug you linked earlier. so I'm not sure what's going on there, how it's happening if someone already fixed the same problem
15:31:46 jmccarthy jgwentworth: I dunno !? I'm not sure how it's happening for me, but it happens everytime
15:32:32 jmccarthy jgwentworth: I have two setups doing it actually, but they both are cinder/lvm for volumes
15:32:36 jgwentworth and it sounds like you're doing boot from volume? when you create the instance, are you specifying a volume or a block device mapping like source=image dest=volume?
15:33:10 jmccarthy I'm just using horizon :| I give it an image name to start with and ask for it to create a new volume for it
15:33:24 jgwentworth okay, that is going to be boot from volume I think
15:33:36 smcginnis I believe so.
15:33:47 jgwentworth that probably is why you're seeing something different than was described in the other similar bug
15:34:53 jmccarthy Well the instance is definitely volume backed, but whether it boots from that as such I'm unclear now
15:35:18 jgwentworth boot from volume is kind of a separate appendage in most of the code
15:37:08 jmccarthy The only file associated with under instances, is it's console.log, that is until I cold migrate it and this disk.info show up
15:38:34 jgwentworth yeah, volume backed == boot from volume. it just means the operating system, disk etc is stored on the volume
15:41:09 mriedem giblet: a virtual cornucopia of comments and questions in https://review.openstack.org/#/c/502306/
15:41:17 mriedem giblet: good news is i think most of it is just asking for clarification
15:42:10 jgwentworth jmccarthy: you see disk.info on the source or destination?
15:42:18 openstackgerrit Eric Fried proposed openstack/nova master: placement: Object changes for granular https://review.openstack.org/564351
15:42:19 openstackgerrit Eric Fried proposed openstack/nova master: placement: Granular GET /allocation_candidates https://review.openstack.org/517757
15:42:23 giblet mriedem: thanks for the review.
15:42:44 jmccarthy jgwentworth: It's no where in sight, until I confirm the resize/migrate - and then it appears on the host (the cold migrate completes fine)
15:43:03 jmccarthy *source host
15:43:09 jgwentworth ok
15:44:08 jmccarthy I'm going to check - I just remembered I looked at the file earlier - have to recheck what is actually in it somethingsomething qcow2 it said in the file
15:44:44 giblet mriedem: I will go through you comments on Monday
15:44:55 jgwentworth yeah, I can never remember what all of those are. I have to re-look at it every time in the code
15:45:31 mriedem dansmith: (1) where is superdan and (2) i've got a request spec modeling comment in https://review.openstack.org/#/c/502306/26/specs/rocky/approved/bandwidth-resource-provider.rst@172 that could use your input
15:45:37 mriedem giblet: ack
15:45:49 superdan mriedem: tab queued
15:50:55 jgwentworth jmccarthy: what's your CONF.libvirt.images_type set to?
15:51:33 jmccarthy one sec
15:51:44 mriedem umm https://review.openstack.org/#/c/516395/
15:52:13 jgwentworth hah, nice
15:52:29 mriedem also added a tempest test for that https://review.openstack.org/#/c/516396/
15:53:18 jgwentworth so maybe ... supposed to remove the disk.info that imagebackend creates but don't remove the whole instance directory?
15:53:23 jmccarthy Hmm it's images_type = rbd in nova.conf
15:53:35 jgwentworth k, thanks
15:53:37 mriedem yeah so that's exactly what that patch was meant to fix,
15:53:46 mriedem and from the tempest patch commit message, it's about shared storage backends
15:53:53 mriedem so in our ci, that's ceph and nfs
15:54:09 mriedem the problem was you would resize the instance and then try to get the console log which was deleted
15:54:25 openstack Launchpad bug 1728603 in OpenStack Compute (nova) pike "Resize a boot-from-volume instance with NFS destroys instance" [High,Fix committed] - Assigned to Matt Riedemann (mriedem)
15:54:25 mriedem https://bugs.launchpad.net/nova/+bug/1728603
15:54:33 jgwentworth right, that's what I'm trying to say is that it's true we shouldn't nuke the entire instance dir
15:54:46 jgwentworth but, we should delete the disk.info by itself
15:55:46 jgwentworth the original intent of https://review.openstack.org/#/c/437356/3/nova/virt/libvirt/driver.py was to delete the disk.info that imagebackend sometimes creates
15:56:17 jgwentworth but it went ahead and took out the entire instance directory not realizing it would lose the console.log
15:56:35 jmccarthy Yea I was reading those comments in driver.py - but the rm commands seem to only involve the dir (which I agree you can remove i.e. nfs)
15:56:49 jmccarthy *can't
15:56:59 Cardoe mriedem: ok so a bit more info. Modifying vm_states.py to allow rescued to be rebooted then it works.
15:57:25 mriedem Cardoe: sure, when using the xenapi driver right?
15:57:29 Cardoe yes
15:57:35 jmccarthy jgwentworth: But there must be logic to know when it's safe to remove that dir on the source host ?
15:57:38 jgwentworth jmccarthy: did you see the patch mriedem linked though? it's bypassing all of that if volume-backed https://review.openstack.org/#/c/516395/2/nova/virt/libvirt/driver.py because it was trying to fix the case where the console.log was being deleted
15:57:41 mriedem i have no idea if libvirt/hyperv/vmware support that
15:57:59 jmccarthy 1728603 ? Let me look
15:58:18 jgwentworth no, https://review.openstack.org/#/c/516395/2/nova/virt/libvirt/driver.py
15:58:18 Cardoe mriedem: I've been told that I do not believe that they do.
15:58:31 Cardoe s/I/rax OpenStack folks/
15:59:36 jmccarthy jswentworth: I think the driver.py that I have now looks like that one ?
16:00:01 jgwentworth jmccarthy: so because you are volume-backed, it's not removing anything at all. I think it needs to be adjusted to only delete disk.info if volume-backed, or something like that
16:00:14 mriedem jmccarthy: because you're on queens and that change was made in queens
16:00:31 jmccarthy jgwentworth: Ok so it's not just me - yes some logic is missing ?
16:00:31 mriedem and backported to pike and ocata because it was fixing a regression which was also backported to pike and ocata :)
16:00:35 mriedem it's bugs all the way down
16:00:52 jmccarthy jgwentworth: Leaving the dir there causes a problem for live migration too
16:00:57 jgwentworth yeah, there is definitely a bug. we were just trying to find what it was
16:01:07 mriedem jmccarthy: the dir or just the disk.info file itself?

Earlier   Later