Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-04
15:00:07 jgwentworth mriedem: no, there wasn't agreement on that. but I realized what I needed it for (quotas) could be achieved with instance_mappings + queued_for_delete column + user_id column
15:00:33 mriedem oh i was just looking for it in your "count quotas using placement" spec
15:01:16 mriedem ah i found it here https://etherpad.openstack.org/p/nova-ptg-rocky
15:01:24 mriedem "In Sydney we talked about tracking a 'type' in the placement allocations/consumers tab"...
15:01:35 jgwentworth yeah, that spec has been languishing and I really needed to update it after tssurya proposed her spec for adding queued_for_delete since mine would depend on that
15:02:31 mriedem giblet: i dont know what "If QoS aware and non QoS aware ports are mixed on the same physical port" means
15:02:58 mriedem that's possible today? to have a port in neutron that is both qos aware and not at the same time?
15:03:02 jgwentworth yeah, we discussed the 'type' idea a bit at the ptg but things got pretty complicated, it would not be straightforward. we may need it someday for other reasons but nothing right now really needs it. I had thought I needed it for quotas but realized I didn't if we could have two more instance_mappings columns
15:03:34 mriedem jgwentworth: ack; it's the new bdm.uuid column - something we'll always think we need every 4 months
15:03:55 giblet mriedem: assume there is a compute node with an SRIOV PF that provide VFs for neutron ports.
15:04:11 jgwentworth mriedem: heh yeah
15:04:12 giblet mriedem: after our spec that PF will also provide bandwidth as well
15:04:29 jgwentworth (I think we do have the bdm.uuid column now tho)
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 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

Earlier   Later