| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-08 | |||
| 13:40:44 | fungi | apparently an ubuntu security update for unbound (the local caching resolver we run on all our servers) failed to successfully restart on many of our zuul executors and so they spontaneously ceased being able to resolve any dns names | |
| 13:40:59 | fried_rice | Is that bad? | |
| 13:41:12 | fungi | the only real downside to unattended security upgrades | |
| 13:41:27 | fried_rice | Hey, it's secure at least. | |
| 13:41:37 | fungi | securely broken :/ | |
| 13:41:46 | jroll | every service is secure when it doesn't run :P | |
| 13:41:51 | fungi | anyway, fixed now and yes, thanks for the reminder that we didn't log that giblet | |
| 13:42:43 | giblet | fungi: thanks for working on the issue :) | |
| 13:48:04 | fungi | giblet: sure, it was mostly frickler and ianw who figured it out and fixed it | |
| 13:48:18 | fungi | but you're welcome nonetheless | |
| 13:53:58 | openstackgerrit | Merged openstack/python-novaclient master: fix tox python3 overrides https://review.openstack.org/573347 | |
| 13:58:55 | openstackgerrit | Eric Fried proposed openstack/nova master: fix tox python3 overrides https://review.openstack.org/572974 | |
| 13:58:59 | fried_rice | finucannot: ^ | |
| 14:00:11 | finucannot | fried_rice: done. Cheers :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::;;;;;;;;;;;;;;;;;;;0 | |
| 14:00:20 | finucannot | lovely | |
| 14:00:31 | mdbooth | finucannot: Was that an attempt at buffer overflow? | |
| 14:01:41 | finucannot | mdbooth: Notifications cause my screen to lock up for an indeterminate period. No idea what's wrong :( | |
| 14:12:05 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: always create consumer records https://review.openstack.org/567678 | |
| 14:12:06 | openstackgerrit | Jay Pipes proposed openstack/nova master: add consumers generation field https://review.openstack.org/557958 | |
| 14:12:08 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405 | |
| 14:12:08 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407 | |
| 14:12:10 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604 | |
| 14:14:27 | fried_rice | kashyap: libvirt isn't the only hypervisor, dude. | |
| 14:14:50 | kashyap | But there are other "hypervisor dudes" here too | |
| 14:16:03 | fried_rice | kashyap: Nothing to scroll, referring to the >26 volumes discussion on the ML. | |
| 14:16:26 | fried_rice | kashyap: Your response reads like "Well, because this libvirt-specific thing handles 256, we should make the limit 256." | |
| 14:16:27 | kashyap | fried_rice: Err, sorry. I misread your comment :-) | |
| 14:17:04 | kashyap | Hmm, true, I didn't mean it to imply that way. | |
| 14:17:06 | fried_rice | kashyap: Sorry, it's a sore point for me. | |
| 14:17:13 | kashyap | No, no. It's completel fine. | |
| 14:17:28 | kashyap | I'm interested in data from other hypervisors too. Can those just chime in? | |
| 14:17:40 | fried_rice | kashyap: I appreciate how thoroughly you thought through and researched. | |
| 14:17:58 | kashyap | I just meant to share whatever data I have from a libvirt PoV. Didn't mean to say this is all "cut and dried". | |
| 14:18:10 | fried_rice | kashyap: Yeah, I pestered the relevant folks from my team yesterday to respond to that. We have scenarios where IBMi customers on POWER stripe data across literally hundreds of volumes. | |
| 14:18:23 | fried_rice | I'll fup and bug them again. | |
| 14:18:23 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Unchain _get_phynet_info from _get_port_vnic_info https://review.openstack.org/564443 | |
| 14:18:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Add 'create_resource_requests' to network API https://review.openstack.org/564444 | |
| 14:18:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Retrieve tunneled status in '_get_network_info' https://review.openstack.org/564445 | |
| 14:19:56 | kashyap | fried_rice: I see, interesting. I don't have access to POWER machine, so certainly I don't know its limitations | |
| 14:20:02 | kashyap | (Or capabilities) | |
| 14:20:29 | kashyap | fried_rice: Also how is I/O performance across those many 100s of volumes? | |
| 14:20:30 | fried_rice | kashyap: Oh, nobody does, that's totally understandable :) | |
| 14:20:56 | fried_rice | kashyap: As I understand it, they did that striping specifically to achieve better performance. So it must be... good. | |
| 14:21:05 | fried_rice | kashyap: But I'm not the expert there. | |
| 14:21:23 | kashyap | (I suggested 256 as a potential number after looking through Kernel threads this morning, and all that testing done by the libguestfs folks.) | |
| 14:21:45 | kashyap | fried_rice: I see. I'll check with some RHT folks have access to POWER machines | |
| 14:23:45 | fried_rice | kashyap: my SME says he wants the max to be 4k :) | |
| 14:24:03 | kashyap | fried_rice: Ask them to respond with a bit more detail, please :-) | |
| 14:24:04 | mriedem | dansmith: this is for you https://review.openstack.org/#/c/490015/ | |
| 14:24:17 | fried_rice | kashyap: Yeah, I'm doing that. For some reason my guy didn't see the thread originally. | |
| 14:24:22 | dansmith | mriedem: oh boy! | |
| 14:24:50 | fried_rice | kashyap: I may wind up having to proxy his response. But one way or another we'll get it out there :) | |
| 14:24:55 | mriedem | osc didn't have host-evacuate-live so someone wants to add it | |
| 14:25:19 | dansmith | we really really should avoid more name confusion | |
| 14:25:40 | kashyap | fried_rice: Sure, noting on his behalf is fine. Just understanding the requirements of different hypervisors. If it's not too unpalatable ... we can even conditionalize based on hypervisor? | |
| 14:26:00 | fried_rice | host-evacuate-live. To me, that means "clear out this host by live-migrating all the instances off of it". So that must not be what it does. | |
| 14:26:30 | fried_rice | kashyap: That sounds like the right approach to me, and is what dansmith expressed as his first preference as well. | |
| 14:26:48 | kashyap | fried_rice: Oh, I didn't see his response yet. | |
| 14:30:34 | melwitt | mriedem, dansmith: I dunno if y'all saw but I added a -W to this https://review.openstack.org/569923 last night to signal that it's legit failing at least the xenserver, hyperv, and vmware third party CIs. so it seems there's some coordination we need to do there | |
| 14:32:20 | melwitt | oh, the tempest change that disables the virtual interfaces tests hasn't merged yet, that would explain it https://review.openstack.org/571556 | |
| 14:32:32 | melwitt | I didn't notice that last night | |
| 14:36:35 | mriedem | dansmith: yup hence my -1 on the change | |
| 14:36:43 | dansmith | mriedem: yup | |
| 14:36:50 | mriedem | fried_rice: that's exactly what it does | |
| 14:36:57 | fried_rice | holy shit! | |
| 14:37:46 | mriedem | melwitt: the 3rd party CIs must not be honoring depends-on | |
| 14:37:58 | fried_rice | I know ^ is true for powervm ci. | |
| 14:38:19 | melwitt | mriedem: yeah, I didn't realize there was possibility of it working differently and not honoring | |
| 14:38:20 | fried_rice | uh, sorry, we get it for zuul but not for tox? Or something. | |
| 14:54:05 | pvc | hi | |
| 14:54:07 | pvc | anyone | |
| 14:54:59 | pvc | can i share the GPU on my compute node with 3 VMs? | |
| 14:58:01 | artom | pvc, only as of queens, with specific nvidia gpus | |
| 14:58:18 | pvc | im using quens | |
| 14:58:24 | pvc | my compute node uses GTX 1080 TI | |
| 14:59:57 | finucannot | pvc: Then no, to the best of my knowledge | |
| 15:00:16 | finucannot | You're going to need an enterprise card with vGPU support to multiplex it | |
| 15:00:42 | finucannot | Otherwise the best you can do is PCI passthrough which only allows it to be attached to one instance | |
| 15:01:27 | finucannot | pvc: https://www.openstack.org/videos/vancouver-2018/call-it-real-virtual-gpus-in-nova | |
| 15:02:50 | pvc | so if ever i launch instance with flavor property of gtx:2, i cannot use it again to launch another VM right? | |
| 15:03:08 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add requested_resources field to RequestSpec https://review.openstack.org/567267 | |
| 15:03:51 | kashyap | fried_rice: Hey, a quick question -- surely your SME has tested those 4K disks with just bare KVM? I bet they haven't tested with OpenStack... | |
| 15:04:16 | kashyap | fried_rice: Because, I doubt OpenStack as it stands will handle those many in a graceful manner, even with POWER... | |
| 15:04:16 | pvc | finucannot in order to use GPU clustering i need a vGPU supoprt right | |
| 15:04:27 | finucannot | pvc: Assuming gtx is a PCI alias, that is correct | |
| 15:04:46 | pvc | i see. thats why i can launch just one instance | |
| 15:04:59 | fried_rice | kashyap: Not KVM. POWER is a different hypervisor. The 4k disks thing was using IBMi guests, I believe. | |
| 15:05:29 | kashyap | fried_rice: Err, thinko. | |
| 15:05:32 | fried_rice | kashyap: But you're right, I doubt it was openstack - it was probably just HMC. | |
| 15:05:38 | pvc | is nvidia tesla good finucannot? | |
| 15:06:08 | melwitt | pvc: this is the support matrix for nvidia vgpu https://docs.nvidia.com/grid/latest/product-support-matrix/index.html | |
| 15:06:35 | finucannot | pvc: NVIDIA would like to say so :) I've no personal experience with that or any other enterprise-grade GPU | |
| 15:07:12 | kashyap | fried_rice: Nod. What is HMC? (My brain throws AcronymNotFound exception...) | |
| 15:07:26 | pvc | melwitt thank you so GTX does not support vGPU sad, its okay finucannot thank you btw :) | |
| 15:07:38 | kashyap | fried_rice: Ha, it must be: Hardware Management Console | |
| 15:07:41 | fried_rice | kashyap: Hardware Management Console, I think. It's the classic POWER-specific hypervisor manager | |
| 15:07:42 | fried_rice | yes | |
| 15:07:48 | kashyap | Okido; thanks | |
| 15:09:31 | fried_rice | kashyap: It's what all the old legacy POWER customers use to manage their virtualization. It's an appliance server (can be a VM or a standalone box or whatever) running a specialized MCP with the management software on it. It talks to the POWER hypervisor firmware thingy (PHYP) as well as the Virtual I/O Servers to do virtualization stuff on the system. | |
| 15:10:18 | fried_rice | kashyap: Couple years ago we forked off a thing called NovaLink, which is a similar management stack, but it lives on a plain ol' Linux VM on the POWER box itself. Idea being more scalability. | |