| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-21 | |||
| 14:07:53 | johnthetubaguy | mriedem: yeah, overall its "in-use" until the last one is detaching, I gues... | |
| 14:08:12 | mriedem | ildikov: there is an attach_status column on the volume_attachment table in cinder | |
| 14:08:31 | mriedem | johnthetubaguy: yeah that sounds right, in-use until ==1 attachment is 'detaching', then the volume itself is 'detaching' | |
| 14:08:37 | mriedem | once all attachments are deleted, the volume is 'available' | |
| 14:08:46 | johnthetubaguy | anyways, I am +W on the detach patch, lets punt this, seems like its safe for now, appreciate stvnoyes for checking all that. | |
| 14:08:54 | mriedem | so yeah, probably long-term we need a begin_detaching action on the attachments API | |
| 14:08:57 | johnthetubaguy | mriedem: yeah, same for attaching I guess | |
| 14:08:57 | ildikov | mriedem: right, I remember that one, I just don't think we played that much with that state machine yet | |
| 14:09:18 | mriedem | until then you can only detach one attachment at a time | |
| 14:09:24 | johnthetubaguy | mriedem: +1 | |
| 14:09:24 | ildikov | johnthetubaguy: sounds good, thanks | |
| 14:09:27 | mriedem | which today is all you can do anyway b/c we don't support multiattac | |
| 14:09:32 | ildikov | mriedem: +1 | |
| 14:09:50 | mriedem | maybe we should write this down somewhere :) | |
| 14:09:56 | mriedem | b/c you know in 3 weeks we'll have forgotten | |
| 14:09:58 | johnthetubaguy | mriedem: you read my mind | |
| 14:10:03 | stvnoyes | thanks! moving on to the next one... | |
| 14:10:34 | ildikov | mriedem: johnthetubaguy: wiki page, devref, etherpad, love letter? | |
| 14:10:51 | mriedem | i haven't written a love letter since high school | |
| 14:10:57 | mriedem | when we didn't have cell phones | |
| 14:11:01 | gibi | mriedem: hi! thanks for the reviews and fixes on the https://review.openstack.org/#/q/topic:bp/additional-notification-fields-for-searchlight+status:open series. | |
| 14:11:05 | mriedem | gibi: np | |
| 14:11:07 | johnthetubaguy | I wrote a poem for my wedding, I am not doing that again | |
| 14:11:21 | gibi | mriedem: I rebased the keypair patch as well and I'm working on the BDM patch | |
| 14:11:23 | mriedem | i believe we picked poems and had others read them | |
| 14:11:49 | ildikov | :) | |
| 14:12:07 | johnthetubaguy | mriedem: yeah, I couldn't think of how to finish my speach... and didn't think to use google because I was too nervous, lol | |
| 14:12:25 | mriedem | johnthetubaguy: was it pre-dinner or post-dinner? | |
| 14:12:30 | mriedem | or mid-dinner? | |
| 14:12:37 | johnthetubaguy | sort of mid I really | |
| 14:12:59 | sballe_ | morning | |
| 14:13:02 | mriedem | same for my forced impromptu speech | |
| 14:13:09 | johnthetubaguy | heh | |
| 14:13:14 | mriedem | i should have done jimmy from south park | |
| 14:13:18 | mriedem | "wow what a great audience!" | |
| 14:13:55 | sballe_ | I am looking for some documentation on how nova can schedule VMs with FPGAs as well as how FPGAs are represented in nove | |
| 14:13:59 | sballe_ | s/nova | |
| 14:14:17 | sballe_ | Any help is appreciated | |
| 14:14:49 | johnthetubaguy | mriedem: ildikov: maybe update the existing spec with a note about all that? | |
| 14:15:23 | ildikov | johnthetubaguy: that can work too | |
| 14:15:43 | johnthetubaguy | sballe_: we don't really support FPGA passthrough for VMs as such, although I think you could use ironic to give you the whole box including the FPGA | |
| 14:16:32 | mriedem | sballe_: they aren't | |
| 14:16:35 | sballe_ | couls I use nova to schedule flavors with accelerators? | |
| 14:16:48 | sballe_ | I see a lot of post with gpus | |
| 14:17:10 | johnthetubaguy | sballe_: so you can pass through a generic PCI device, maybe that would work? | |
| 14:17:13 | mriedem | sballe_: there is a project called 'cyborg' which you should probably start with | |
| 14:17:21 | mriedem | which is all about acceleration | |
| 14:17:31 | sballe_ | ok cool! thx for the help | |
| 14:17:35 | mriedem | sballe_: https://wiki.openstack.org/wiki/Cyborg | |
| 14:18:00 | mriedem | look for email threads in the openstack-dev mailing list tagged with [acceleration] | |
| 14:18:17 | johnthetubaguy | so I forgot about that thing, my email filters are a bit strong these days | |
| 14:18:26 | mriedem | sballe_: also https://review.openstack.org/#/c/318047/ | |
| 14:19:36 | mriedem | leakypipes: dansmith: johnthetubaguy: https://review.openstack.org/#/c/419185/ on down for bp/additional-notification-fields-for-searchlight is ready to go, has my +2 | |
| 14:20:16 | mriedem | johnthetubaguy: yeah we could amend the spec, | |
| 14:20:22 | mriedem | johnthetubaguy: you going to do that or want me to? | |
| 14:20:25 | mriedem | i'm happy to update it | |
| 14:20:36 | johnthetubaguy | mriedem: if you could, that would be great | |
| 14:20:43 | mriedem | will do | |
| 14:20:45 | sballe_ | mriedem: thx | |
| 14:20:50 | bauzas | mriedem: hola, quick q, when are you planning a stable/newton release ? :) | |
| 14:21:00 | bauzas | and oh snap, TGIF | |
| 14:21:03 | mriedem | bauzas: when you merge the regression fixes proposed to newton | |
| 14:21:22 | bauzas | mriedem: heh, roger. | |
| 14:21:53 | smcginnis | mriedem: Missed your question yesterday while travelling. | |
| 14:22:03 | smcginnis | mriedem: That session is to discuss the track chair process and issues. | |
| 14:22:52 | openstackgerrit | sahid proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820 | |
| 14:22:52 | openstackgerrit | sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 14:22:53 | openstackgerrit | sahid proposed openstack/nova master: network: add command to configure trusted mode for VFs https://review.openstack.org/458513 | |
| 14:24:22 | mriedem | smcginnis: what's a track chair? | |
| 14:24:28 | mriedem | those setting up the summit? | |
| 14:24:35 | mriedem | or those running a session? | |
| 14:24:52 | openstackgerrit | Alex Xu proposed openstack/python-novaclient master: Add `instance-uuid` flag to the migration-list https://review.openstack.org/458728 | |
| 14:24:58 | johnthetubaguy | pick the sessions | |
| 14:25:03 | mriedem | alex_xu: you beat me to it | |
| 14:25:06 | smcginnis | mriedem: Decising which sessions to accept for the official schedule. | |
| 14:25:09 | johnthetubaguy | mriedem: done it twice, its a pain | |
| 14:25:15 | mriedem | oh, i don't care about that session then :) | |
| 14:25:17 | smcginnis | johnthetubaguy: Yep. :) | |
| 14:25:21 | alex_xu | mriedem: hope you didn't start that | |
| 14:25:29 | mriedem | alex_xu: no i didn't, thanks for doing it | |
| 14:25:34 | alex_xu | mriedem: np | |
| 14:29:16 | mriedem | alex_xu: comments inline :) | |
| 14:29:19 | mriedem | otherwise looks good | |
| 14:30:36 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Always disconnect_volume after rebase failures https://review.openstack.org/458807 | |
| 14:31:37 | mriedem | bauwser: these https://review.openstack.org/#/c/457353/ https://review.openstack.org/#/c/448235/ https://review.openstack.org/#/c/458668/ https://review.openstack.org/#/c/456770/ https://review.openstack.org/#/c/448253/ | |
| 14:31:52 | bauwser | mriedem: reviewy reviewy | |
| 14:32:03 | mriedem | ask and ye shall receieve | |
| 14:32:05 | mriedem | *receive | |
| 14:32:26 | bauwser | mriedem: FWIW, I haven't touched the scheduler claims spec since I need time to think about | |
| 14:32:51 | mriedem | i haven't either | |
| 14:32:52 | bauwser | about the super extra cool problem you showed to the world with overhead values | |
| 14:33:04 | mriedem | don't thank me, thank some performance tester internal to huawei | |
| 14:33:33 | bauwser | mriedem: FWIW, my honest first opinion is that problem it's something that we should leave out of placement | |
| 14:33:35 | mriedem | i didn't know the overhead stuff existed before that | |
| 14:33:58 | bauwser | mriedem: that looks something not really useful for placement and very related to the hypervisor | |
| 14:34:28 | mriedem | you have to solve it with placement one way or the other, either by tracking overhead in allocations, or forcing extra reserved inventory to make up for the overhead | |
| 14:34:29 | bauwser | so, say we leave in a world where we're not trying to eat all the resources but still have reserved room for that, then it's not a problem for placement | |
| 14:34:30 | mriedem | right? | |
| 14:34:52 | mriedem | i don't think we can punt on this | |
| 14:35:55 | bauwser | mriedem: if we have rescheduling, would it be a problem ? | |