| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-15 | |||
| 15:29:35 | dansmith | they also seem to focus on "graphics acceleration", which would be in line with being OpenGL-only | |
| 15:29:46 | openstackgerrit | Vladyslav Drok proposed openstack/nova-specs master: Allow having placement inventories with reserved value equal to total https://review.openstack.org/568613 | |
| 15:30:18 | dansmith | jaypipes: ah, they say use P3 for GPGPU | |
| 15:30:39 | dansmith | jaypipes: https://aws.amazon.com/ec2/instance-types/p3/ | |
| 15:30:42 | dansmith | jaypipes: tesla v100 only | |
| 15:30:46 | dansmith | jaypipes: so, yeah, easy :) | |
| 15:32:12 | dansmith | and note they're not saying "you'll get some nvidia somethingorother" they say .. "it'll be a damned v100, alwas" | |
| 15:32:13 | jaypipes | dansmith: I see them say tesla v100. those are passthrough direct GPU devices, though, not vGPU "types", right? | |
| 15:32:35 | jaypipes | "Alternatively, you can also use the NVIDIA AMI with GPU driver and CUDA toolkit pre-installed." ... interesting. | |
| 15:32:52 | dansmith | jaypipes: yeah I dunno if it's a vGPU or them just giving you a whole card | |
| 15:33:04 | jaypipes | dansmith: it's the whole card. or 8 of them :) | |
| 15:33:32 | dansmith | doesn't have anything to do with our discussion though right? they're very specific about what you get, and thus what driver you need | |
| 15:35:08 | jaypipes | dansmith: yes and no? :) the "elastic GPUs" are very much non-vendor-specific. The P3 instances are clearly very much "here is this specific machine configuration with 8 NVIDIA GPUs", etc. | |
| 15:35:24 | jaypipes | dansmith: but I see your point. | |
| 15:35:38 | jaypipes | dansmith: we need to support both cloudy and non-cloudy things. | |
| 15:35:52 | dansmith | jaypipes: but they're not for GPGPU, they're for graphics acceleration | |
| 15:36:01 | jaypipes | dansmith: I've just been trying my best to keep the vendor-specific stuff out of the way. | |
| 15:36:05 | dansmith | and they virtualize the OpenGL interface, so you're far removed | |
| 15:36:09 | jaypipes | dansmith: yes, I understand. | |
| 15:38:02 | openstackgerrit | Vladyslav Drok proposed openstack/nova-specs master: Allow having placement inventories with reserved value equal to total https://review.openstack.org/568613 | |
| 15:38:24 | dansmith | and, they achieve the vendor neutrality of the elastic gpu thing by creating their own vendor so to speak, and provide signed drivers for supported operating systems | |
| 15:38:28 | dansmith | if they didn't have that, | |
| 15:38:45 | dansmith | they'd have to have specific details about which drivers you needed to have to support all their stuff, or provide flavors to let you choose which ones, | |
| 15:38:56 | dansmith | because drivers are required one way or the other | |
| 15:39:20 | dansmith | so unless you're going to write a driver and backend system to do that, I don't see how even the elastic gpu case alters the discussion | |
| 15:40:22 | jaypipes | dansmith: sounds like we need traits that represent the vendor software drivers, then... | |
| 15:41:53 | dansmith | or we expect that people have to do that on their own by using custom traits | |
| 15:42:11 | dansmith | which is what I said in that review, but then that generates a much less interoperable situation for everyone | |
| 15:42:33 | jaypipes | agreed.' | |
| 15:42:48 | jaypipes | dansmith: ok, thx for talking through this with me. was very useful. | |
| 15:43:01 | jaypipes | and for the record, I did not try to shame you. sorry if anything came across that way. | |
| 15:43:16 | dansmith | we also can punt the problem for a while, saying people need to use custom traits for now and see how it goes | |
| 15:45:45 | jaypipes | ack | |
| 15:46:21 | openstackgerrit | Merged openstack/nova master: placement: Fix HTTP error generation https://review.openstack.org/568567 | |
| 16:01:39 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] default to accept of application/json when */* https://review.openstack.org/568630 | |
| 16:08:27 | mriedem | stephenfin: have to talked with claudiu about whether or not the hyperv driver can support https://review.openstack.org/#/c/541290/ also? | |
| 16:09:07 | stephenfin | mriedem: I have not, but HyperV's support for all things NUMA is minimal at best | |
| 16:09:23 | stephenfin | Far as I can tell, they let you define guest topologies but not anything to do with the host topology | |
| 16:10:23 | stephenfin | So they don't do things like "restrict my instance's vCPU processes to CPUs from the same NUMA nodes as the attached PCI device". Wouldn't make sense (yet!) to do that for networks either | |
| 16:20:02 | mriedem | stephenfin: ok, as dansmith mentioned in the spec, it would be good to call out what is lacking in hyper-v to restrict them from being able to do the new magic | |
| 16:20:20 | mriedem | stephenfin: if you haven't seen yet, lots of comments on that spec, mostly concerned about the data modeling changes being proposed | |
| 16:20:26 | dansmith | yeah, sounds like it's cool, just a sentence saying "they don't do host topo" would be good I think | |
| 16:21:06 | mriedem | i'd also like to know what's going on with bauzas' numa topology modeling in placement spec | |
| 16:21:19 | mriedem | since this could technically depend on that and then we wouldn't need to build in more claims logic in the RT for this stuff | |
| 16:21:34 | bauzas | mriedem: I need to update my spec | |
| 16:21:44 | mriedem | like, if numa support is not even close for rocky, then i just need to know that | |
| 16:22:12 | mriedem | bauzas: you should probably read https://review.openstack.org/#/c/541290/ if you haven't already | |
| 16:22:54 | bauzas | mriedem: I'm a bit on and off given the previous week and the next one, but okay | |
| 16:23:16 | bauzas | maybe we could discuss that in Vancouver ? | |
| 16:24:55 | cfriesen | anyone know offhand where the code is that determines how much disk to consume if the flavor specifies a size of zero? | |
| 16:30:01 | openstackgerrit | Eric Fried proposed openstack/nova master: Use placement.inventory.inuse in report client https://review.openstack.org/568639 | |
| 16:30:43 | mriedem | bauzas: i don't think we have any related forum sessions for something like this | |
| 16:30:52 | mriedem | unless you just mean between sessions | |
| 16:30:57 | bauzas | between, yeah | |
| 16:30:59 | bauzas | anyway | |
| 16:31:09 | bauzas | I'll look at the spec tomorrow if I can | |
| 16:31:16 | bauzas | I still have 3 free days | |
| 16:55:22 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Don't reschedule on RequestedVRamTooHigh errors https://review.openstack.org/568642 | |
| 17:10:53 | openstackgerrit | Merged openstack/nova stable/queens: Added ability to configure default architecture for ImagePropertiesFilter https://review.openstack.org/568575 | |
| 17:10:59 | openstackgerrit | Merged openstack/nova master: Update auth_url in install docs https://review.openstack.org/568002 | |
| 17:13:06 | mriedem | dansmith: that queens backport is ready to launch now https://review.openstack.org/#/c/568363/ | |
| 17:13:27 | dansmith | right on | |
| 17:16:53 | openstackgerrit | Merged openstack/nova master: Add INVENTORY_INUSE to DELETE /rp/{u}/inventories https://review.openstack.org/568578 | |
| 17:32:26 | melwitt | gibi, efried: there's not much of a plan. I'm going to put together a short slide deck similar to this cinder one from the boston summit (in case we need it) https://www.slideshare.net/JayBryant2/openstack-cinder-onboarding-education-boston-summit-2017 | |
| 17:33:31 | melwitt | I was thinking I'll also prepare a set of logs from a gate run showing how to trace a request through the various nova services, in case anyone is interested in that | |
| 17:34:21 | melwitt | if you have any other topic ideas, it would help to have more choices available because what we usually do is poll the room and ask what topic they most like to hear about | |
| 17:35:58 | efried | melwitt: When sdague did that (walk through logs) in Boston I found it super useful. So ++ to that idea. | |
| 17:36:48 | efried | um, Boston or Austin, can't remember. | |
| 17:37:21 | melwitt | I think you're right that it was boston | |
| 17:41:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Use placement.inventory.inuse in report client https://review.openstack.org/568639 | |
| 18:20:24 | openstackgerrit | Eric Fried proposed openstack/nova master: Use placement.inventory.inuse in report client https://review.openstack.org/568639 | |
| 18:20:46 | openstackgerrit | Eric Fried proposed openstack/nova master: Use placement.inventory.inuse in report client https://review.openstack.org/568639 | |
| 18:28:28 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Propose counting quota usage from placement and API database https://review.openstack.org/509042 | |
| 18:37:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add granular policy rules for resource providers inventories https://review.openstack.org/568666 | |
| 18:49:20 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Propose counting quota usage from placement and API database https://review.openstack.org/509042 | |
| 18:59:34 | efried | melwitt: Is it cheaper to get a list of instance UUIDs than whatever "instance_mappings" is? | |
| 19:04:30 | melwitt | efried: what do you mean? instance_mappings (API database table) is the cheapest way to get a list of instance UUIDs. otherwise you have to query multiple cell databases to get lists of UUIDs to merge | |
| 19:04:49 | efried | okay, cool, that's what I was asking. | |
| 19:27:54 | openstackgerrit | sunku ranganath proposed openstack/nova-specs master: Submitting blueprint describing usage of resource management daemon to control and use cache as a resource https://review.openstack.org/568678 | |
| 19:32:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Implement granular policy rules for placement https://review.openstack.org/524425 | |
| 19:32:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add granular policy rules for /resource_classes* https://review.openstack.org/565578 | |
| 19:32:05 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add granular policy rules for resource providers inventories https://review.openstack.org/568666 | |
| 19:33:43 | artom | Do we do nested objects printing in debug mode? | |
| 19:34:09 | artom | So, InstancePCIRequests has a list of InstancePCIRequest | |
| 19:34:31 | artom | Logging the former at debug level... it is supposed to print out in full the latter as well? | |
| 19:35:24 | artom | Looking at https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L309, I don't think so | |
| 19:35:58 | artom | Looks like it only prints the object names of the "nested" objects, right? | |
| 19:38:02 | openstackgerrit | Zack Cornelius proposed openstack/nova-specs master: Libvirt file backed memory https://review.openstack.org/563704 | |
| 19:38:32 | dansmith | artom: that calls this for an object field: https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L819 | |
| 19:38:44 | dansmith | artom: which tries to get some reasonable identifying information to print, | |
| 19:38:55 | dansmith | but doesn't recurse and repr() the object inside | |
| 19:39:21 | dansmith | just because it can get really hard to eye-parse that in a useful way, but if you see Instance(...., service=Service(123),...) then you can make sense out of that | |
| 19:39:30 | artom | Ah, thanks for choosing the right words - "recurse and repr()" indeed | |
| 19:39:49 | artom | Yeah, the rationale makes sense | |
| 19:40:07 | artom | Except I need resursive repr in this particular case :/ | |
| 19:51:19 | mriedem | esberglu: just to check sanity, the in-tree powervm ci isn't running some snapshot tests b/c they are on power states that the driver doesn't yet support, like test_create_image_from_paused_server and test_create_image_from_suspended_server right? | |
| 19:54:37 | esberglu | mriedem: Correct | |
| 19:57:56 | efried | mriedem: Because https://github.com/powervm/powervm-ci/blob/master/devstack/master/intree/local.conf#L100 | |
| 20:22:00 | mriedem | esberglu: efried: what passes the disk_path into the StreamToGlance task? https://review.openstack.org/#/c/543023/20/nova/virt/powervm/tasks/image.py@73 | |
| 20:22:08 | mriedem | i thought it was the output of the last task in the flow, | |