| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-08 | |||
| 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. | |
| 15:10:26 | kashyap | fried_rice: Ah, I see. And te modern customers use OpenStack? | |
| 15:10:28 | fried_rice | kashyap: And it is on the NovaLink partition that we run the nova-compute service. | |
| 15:10:45 | fried_rice | ...so that modern customers can use openstack, yes. | |
| 15:11:28 | kashyap | Noted; thans for the context. | |
| 15:11:31 | fried_rice | kashyap: Note the major difference from the kvm model: the NovaLink partition manages the virtualization, but the VMs don't run "in" the NovaLink partition - they run on the system itself. | |
| 15:13:10 | fried_rice | kashyap: it's a weird concept for kvm folks. Think of it this way: the NovaLink partition is a "peer" of the guest VMs. They're all "logical partitions" (LPARs) on the POWER system. | |
| 15:13:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add bandwidth related standard resource classes https://review.openstack.org/570847 | |
| 15:13:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 15:13:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459 | |
| 15:13:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 15:13:45 | kashyap | fried_rice: Yeah, was going to look up a bit about it to see how it compares. Thanks for the info | |
| 15:14:02 | fried_rice | kashyap: Sure thing. Thanks for listening :) | |
| 15:15:16 | kashyap | Yeah, but just to note -- anytime I suggest something that is KVM/libvirt-specific, and not seem consider other hypervisors, it's largely due to my own ignorance... | |
| 15:17:36 | mgagne | when migrating flavor in newton, this moves flavor to api database. Will CellsV1 read from that database from now on? | |
| 15:19:17 | dansmith | mgagne: you mean cellsv2? | |
| 15:19:23 | mgagne | cellsv1 | |
| 15:19:48 | mgagne | because you can still run cellsv1 in newton right? | |
| 15:20:06 | dansmith | mgagne: the api will read it from the api database yeah, but nothing else changes | |
| 15:20:23 | dansmith | mgagne: so you likely still need all the flavor replication bits or whatever you're doing I think | |
| 15:20:31 | mgagne | so will I need to create them in both api database and api/compute cells database? | |
| 15:20:35 | mgagne | right | |
| 15:20:42 | mgagne | but | |
| 15:20:51 | mgagne | db sync complains if you don't migrate them all to api db | |
| 15:21:01 | mgagne | in ocata I think | |
| 15:21:14 | dansmith | yeah, I'm trying to roll back my brain to think about this | |
| 15:21:34 | dansmith | mriedem: do you remember what belmiro said he was doing? | |
| 15:22:45 | dansmith | they have an api db in each cellsv1 cell, IIRC, and they migrated the flavors to those api databases? | |
| 15:22:50 | mgagne | I'm just trying to figure out something: I run online migration with newton. Flavors get moved to api database. But I also need to run online migration in compute cells right? (still cellsv1) Otherwise ocata complains. So I run that migration but it fails because flavors found in compute cells already exist in api database and migration fails silently with exit code 0. (and don't mark them as deleted in compute cell database) | |
| 15:23:05 | mriedem | context? | |
| 15:23:10 | mriedem | i've been in osc land all day | |
| 15:23:19 | mgagne | dansmith: they had an api db per cell due to per cell placement | |
| 15:23:20 | dansmith | mgagne: are you sharing the api database amongst all the cellsv1 cells? | |
| 15:23:28 | dansmith | ah, right, | |
| 15:23:28 | mgagne | dansmith: yes | |
| 15:23:40 | dansmith | so that's the difference between you and belmiro's approach | |
| 15:23:48 | mgagne | which I assumed was the recommended way unless you wanted per cell placement service | |