| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-28 | |||
| 12:37:00 | nsingh | are you asking about logs ? | |
| 12:37:08 | nsingh | ok | |
| 12:38:31 | nsingh | http://paste.openstack.org/show/627566/ | |
| 12:42:09 | efried | nsingh Can you paste me that cinder-api-uwsgi.ini? | |
| 12:43:03 | nsingh | http://paste.openstack.org/show/627569/ | |
| 12:45:35 | openstackgerrit | Wangpan proposed openstack/nova master: Handle ImageInUse exception during instance backup https://review.openstack.org/523395 | |
| 12:48:08 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: [placement] use global conf with auth token middleware https://review.openstack.org/523403 | |
| 12:59:15 | jaianshu | Hello everyone | |
| 13:00:21 | jaianshu | i'm getting error in spawning vm on stable/pike " Failed to allocate the network(s), not rescheduling." | |
| 13:00:33 | nsingh | efried: still there? | |
| 13:00:35 | jaianshu | n-cpu.log - http://paste.openstack.org/show/627576/ | |
| 13:01:18 | jaianshu | any ideas? | |
| 13:01:49 | efried | nsingh Yes, sorry, looking at cinder-wsgi... | |
| 13:02:14 | nsingh | efried: ooh thanks | |
| 13:03:49 | cdent | efried: what’s the emoji for :kid with fingers in ears saying la la la la la la over and over: ? | |
| 13:04:13 | efried | cdent I can think of a couple of finger emojis | |
| 13:04:20 | cdent | heh | |
| 13:07:58 | kalyan | jaianshu: virtual interface creation failed...could you please check if vif plugin entries present in the nova.conf | |
| 13:08:10 | efried | nsingh To make sure I understand, we're saying is that your c-api process is registering ksa auth opts in the [glance] conf section, right? | |
| 13:08:43 | nsingh | efried: yes | |
| 13:09:26 | cdent | hurrah it is microversion merge conflict day! | |
| 13:09:49 | jaianshu | and vif_plugging_is_fatal=False | |
| 13:09:49 | jaianshu | kalyan: i have these 2 entries for vif-plugin in nova.conf - vif_plugging_timeout=10 | |
| 13:10:59 | openstackgerrit | jichenjc proposed openstack/nova master: check query param for server groups function https://review.openstack.org/500347 | |
| 13:11:34 | efried | nsingh Okay; I can't see how that's happening. Normally it would be via keystoneauth1.loading.register_auth_conf_options, but I don't see anywhere in cinder that's being done for a [glance] section, directly or indirectly. Perhaps someone in #openstack-cinder could shed some light on that. | |
| 13:12:36 | nsingh | efried: ok is it done for any section? | |
| 13:12:42 | efried | nsingh Not that I can see. | |
| 13:13:31 | nsingh | efried: ok thank you for help. :) | |
| 13:13:37 | efried | nsingh Good luck. | |
| 13:14:05 | nsingh | efried: And your suggestion about cinder to nova interaction that i asked earlier works. So thank you for that also. | |
| 13:14:18 | efried | nsingh Oh, great to hear. | |
| 13:14:31 | efried | nsingh Which one was it? | |
| 13:15:00 | nsingh | efried: you replied me on mail. | |
| 13:15:15 | efried | nsingh Right, and I suggested three or four things - which one was the right one? | |
| 13:16:09 | nsingh | efried: n-cpu was pointing to nova-cpu.conf and i add sevice user configuration in nova.conf | |
| 13:16:18 | efried | nsingh Okay, cool. | |
| 13:16:27 | efried | nsingh I got burned by that a few months ago. | |
| 13:16:47 | nsingh | efried: oohh.. | |
| 13:34:49 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Add cache headers to placement api requests https://review.openstack.org/521640 | |
| 13:34:49 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Object changes to support last-modified headers https://review.openstack.org/521639 | |
| 13:42:16 | mriedem | bauzas: can you take a look at https://review.openstack.org/#/c/521391/ and the patch below it? those have to get backported through to newton and i was holding up the backports until i got some core review | |
| 13:51:49 | mriedem | alex_xu: do you know if @wsgi.action('migrate') ensures that a cold migration request will have a 'migrate' key in the request body even if the value for that key is null? we don't actually care about the value | |
| 13:53:07 | mriedem | my guess is we wouldn't route properly if the request body didn't have the 'migrate' key in it | |
| 13:56:59 | jianghuaw_ | jaypipes, bauzas: are you around? | |
| 13:57:21 | openstackgerrit | Eric Fried proposed openstack/nova master: Use ksa adapter for keystone conf & requests https://review.openstack.org/507693 | |
| 14:00:07 | ildikov | mriedem: hi :) | |
| 14:00:19 | ildikov | mriedem: I hope you had a great Turkey weekend :) | |
| 14:00:32 | jaypipes | jianghuaw_: I am indeed. | |
| 14:00:35 | moshele | jaypipes: hi can you +W review https://review.openstack.org/#/c/519066/ Rabi Mishra for heat team tested and it pass their test | |
| 14:00:47 | ildikov | mriedem: so I think it's time now to do my regular "pretty please speech" for review: https://review.openstack.org/#/c/330285/ | |
| 14:00:56 | jianghuaw_ | jaypipes, hi Jay. I posted a patch to create inventory data for VGPU_DISPLAY_HEAD. But later I realized there would be a problem. | |
| 14:01:02 | jianghuaw_ | https://review.openstack.org/#/c/523342/2/nova/virt/xenapi/driver.py@477 | |
| 14:01:05 | ildikov | johnthetubaguy: same pretty please goes to you too ^^ | |
| 14:01:08 | jaypipes | moshele: done | |
| 14:01:19 | jianghuaw_ | jaypipes, The vgpu display heads is not independent resources. When it consuming VGPUs, it also consumes display heads. | |
| 14:01:26 | moshele | jaypipes: cool thanks :) | |
| 14:02:37 | jaypipes | jianghuaw_: is there a specific relationship between the quantities? for example, does 1 VGPU means 1 display head will be consumed? | |
| 14:02:47 | jaypipes | jianghuaw_: or is it dependent on the vGPU type? | |
| 14:05:01 | efried | sdague Would you please have a look at https://review.openstack.org/#/c/409404/ when you get a chance? | |
| 14:05:49 | jaypipes | efried: I'm rebasing the series from review 520246. just making sure you've no local changes? | |
| 14:06:23 | efried | jaypipes No yet. Go for it. | |
| 14:06:37 | jaypipes | rock on. | |
| 14:06:45 | efried | And thanks as always for checking | |
| 14:06:49 | jianghuaw_ | jaypipes, sorry. I just got a network disconnection. | |
| 14:06:51 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: [placement] use global conf with auth token middleware https://review.openstack.org/523403 | |
| 14:06:58 | jaypipes | jianghuaw_: I'll repeat... | |
| 14:06:59 | jianghuaw_ | jaypipes, yes. it depends on the vGPU type. | |
| 14:07:00 | jaypipes | jianghuaw_: is there a specific relationship between the quantities? for example, does 1 VGPU means 1 display head will be consumed? | |
| 14:07:03 | jaypipes | jianghuaw_: or is it dependent on the vGPU type? | |
| 14:07:16 | jianghuaw_ | For example: There each vGPU supports 2 display heads and total vGPU is 5; then initially the available vGPUs amount is 5; and available amount of display heads is 10 | |
| 14:07:30 | jaypipes | jianghuaw_: ok. so what is the problem with ensuring the flavor requests both VGPU and display head resources? | |
| 14:07:47 | jianghuaw_ | After we boot an instance with one VGPU. The available display heads will also be reduce to 8. But placement doesn’t know of the change on display heads if we don’t specify VGPU_DISPLAY_HEAD in the request spec. | |
| 14:08:12 | jaypipes | jianghuaw_: is there a reason we can't specify display heads in the flavor? | |
| 14:08:12 | jianghuaw_ | if we specify both VGPU and display_heads, it should work. | |
| 14:08:36 | jianghuaw_ | But I think we should allow flavor to only request VGPU. | |
| 14:08:43 | jianghuaw_ | as the display heads is optional. | |
| 14:08:45 | efried | jianghuaw_ That's what I was going to suggest. | |
| 14:09:02 | efried | jianghuaw_ Is it always a certain number of display heads for a given type of vGPU? | |
| 14:09:19 | jianghuaw_ | yes. it is. | |
| 14:09:40 | efried | jianghuaw_ And is it possible to do requests in such a way that you run out of display heads before you run out of VGPUs? | |
| 14:09:42 | jianghuaw_ | the amount of display heads is determined by the vgpu type. | |
| 14:10:04 | jianghuaw_ | shouldn't. | |
| 14:10:25 | efried | jianghuaw_ Then yeah, I say leave display heads out of the picture entirely. Don't register them as resources, and don't include them in the flavor. | |
| 14:11:12 | sdague | efried: +A | |
| 14:11:18 | efried | sdague Thanks! | |
| 14:11:51 | sdague | and +2 on the config matrix update | |
| 14:12:13 | efried | sdague Cool. | |
| 14:12:47 | jianghuaw_ | efried, but I guess some customers may want to request vGPU with needed heads. | |
| 14:14:28 | jianghuaw_ | jaypipes, efried: I'm feeling the display heads somehow looks like a trait. | |
| 14:15:12 | jaypipes | jianghuaw_: it's not :) it's a consumable resource | |
| 14:15:39 | efried | Unless it's like DUAL_DISPLAY_HEAD_CAPABLE :) | |
| 14:16:06 | jianghuaw_ | jaypipes, but it does have problem if we allow having display head as optional. | |
| 14:16:31 | edleafe | jianghuaw_: can you request a vGPU *without* consuming a display head? | |
| 14:16:40 | jaypipes | jianghuaw_: why is that? wouldn't you just have a flavor that doesn't have display heads? | |
| 14:17:46 | jianghuaw_ | efried, some vGPU types don't support display heads. | |
| 14:19:27 | jianghuaw_ | As some vGPUs don't support display heads. so the display heads' inv may be empty. So we should allow the flavor without specifying display heads. | |
| 14:20:50 | efried | jianghuaw_ In those cases, it makes sense. Where I think we're having issues is this idea that, by requesting a certain type of vGPU, we might "automatically" consume some number of display heads. We can't do that if we're inventorying the display heads. | |
| 14:20:51 | jianghuaw_ | But it's still possible to allocate a vGPU which support display heads it only request some kind of vGPU. | |
| 14:21:44 | efried | jianghuaw_ Let me ask it this way: In these cases where certain vGPU types support consuming display heads, is it possible to request a vGPU *without* consuming display heads? | |
| 14:21:46 | jianghuaw_ | efried, yes. that's exactly the problem I met. | |