| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-04 | |||
| 14:30:41 | mriedem | or 'update' | |
| 14:30:42 | kashyap | Thanks | |
| 14:30:44 | mriedem | *'upgrade' | |
| 14:31:04 | kashyap | Yep, the 'upgrade' tag seems more applicable | |
| 14:31:26 | giblet | mriedem: the name field of the ResourceProvider has a unique constraint in the DB so the unique compute node RP name is enforced for ironic case as well | |
| 14:32:12 | giblet | mriedem: I guess ironic uses the node name instead of the host name for the compute RP | |
| 14:35:43 | Cardoe | mriedem: So vm_states.py doesn't allow rebooting from rescue either. | |
| 14:36:10 | mriedem | Cardoe: correct. the upstream nova api doesn't allow rebooting a rescued vm | |
| 14:36:10 | openstack | jmccarthy: Error: Could not gather data from Launchpad for bug #1769131 (https://launchpad.net/bugs/1769131). The error has been logged | |
| 14:36:10 | jmccarthy | mriedem: Hiya, just wondering if you have any ideas maybe about this bug ? https://bugs.launchpad.net/nova/+bug/1769131 It seems like another bug that has come up before (1666831) but I'm not sure what the story is | |
| 14:36:18 | Cardoe | mriedem: I'm talking about the rax patched version | |
| 14:36:31 | mriedem | Cardoe: oh, heh | |
| 14:36:56 | Cardoe | I had to figure out how to get into a compute node over here. | |
| 14:37:20 | mriedem | is it maybe hard-coded into the nova/compute/api.py code? | |
| 14:37:38 | mriedem | there was some refactoring done in there in the last couple of releases, and i don't think rax has updated code to match upstream in a long time | |
| 14:37:56 | Cardoe | checked that too. the @check_instance_state is the same as upstream | |
| 14:38:00 | mriedem | so don't check vm_states.py, check nova/compute/api.py:API.reboot() | |
| 14:38:02 | jroll | mriedem: giblet: for ironic, nova creates the port and ironic updates it later in the provisioning process | |
| 14:38:04 | mriedem | hmm | |
| 14:38:31 | jroll | I would like to see qos be a traits thing | |
| 14:38:45 | jroll | for ironic, it's just a property of the machine, not anything we can control | |
| 14:38:45 | Cardoe | well not the same because yeah I see the results of a big refactor but it doesn't seem to be allowed in there. | |
| 14:39:20 | mriedem | Cardoe: i don't suppose anyone still has a line to Matthew Sherborne huh | |
| 14:39:25 | giblet | jroll: the current spec defines bandwidth as a resource on provided by the physical device on the compute https://review.openstack.org/#/c/502306/ | |
| 14:39:35 | jroll | hrm | |
| 14:39:35 | openstack | Launchpad bug 1170237 in OpenStack Compute (nova) "cannot reboot instances when in rescue mode" [Medium,Fix released] - Assigned to Matthew Sherborne (msherborne+openstack) | |
| 14:39:35 | mriedem | because https://bugs.launchpad.net/nova/+bug/1170237 seems totally bogus | |
| 14:39:49 | jroll | giblet: I'll visit it when I'm back from errands | |
| 14:39:55 | mriedem | unless he just took a bunch of nova people on a wild goose chase 5 years ago | |
| 14:39:56 | giblet | jroll: thanks | |
| 14:40:22 | Cardoe | mriedem: I'm lighting up some folks. I'll get you a better answer soon. | |
| 14:45:00 | giblet | mriedem: as far as I understand neutron only configures TOR switches for ironic and ironic does the compute side physical device handling | |
| 14:45:20 | giblet | mriedem: this means that neutron does not know what capabilities the physical device has | |
| 14:45:55 | giblet | mriedem: so I think if ironic needs bandwidth handling the ironic virtdriver can create RPs with traits/resources and the user request that via flavor extra_spec | |
| 14:47:15 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: Granular GET /allocation_candidates https://review.openstack.org/517757 | |
| 14:47:17 | giblet | mriedem: when (if) the bandwidth handling support is extened to TOR switches then baremetal neutron ports will have a resource request describing what the resource the port needs on the TOR switch | |
| 14:50:52 | kashyap | "Lighting up some folks" brings a very strong image to the brain... | |
| 14:57:15 | mriedem | jgwentworth: am i dreaming this up, or did we agree at the dublin ptg to add a type column to the consumers table in placement to be able to distinguish instance from migration consumers? | |
| 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 | |