Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-04
15:04:30 giblet mriedem: a neutron port might have a QoS policy rule attached
15:05:01 mriedem jgwentworth: yes we do
15:05:08 giblet mriedem: when we place a neutron port with QoS policy rule attached to the above PF we will consume some bandwidth as well
15:05:12 mriedem for mdbooth's local device serial series
15:05:15 jgwentworth need=TRUE
15:05:20 jgwentworth ah right
15:05:38 jgwentworth persistent cereal numbers
15:05:52 giblet mriedem: but if there is two neutron port one with QoS another without QoS ends up using VFs from the same PF then the minimum bandwidth rule cannot be garanteed
15:06:17 mriedem jgwentworth: ala https://images-na.ssl-images-amazon.com/images/I/51hDzZDOhdL.jpg ?
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 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: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: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 mriedem https://bugs.launchpad.net/nova/+bug/1728603
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: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 Cardoe mriedem: I've been told that I do not believe that they do.
15:58:18 jgwentworth no, https://review.openstack.org/#/c/516395/2/nova/virt/libvirt/driver.py
15:58:31 Cardoe s/I/rax OpenStack folks/

Earlier   Later