Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-18
10:43:32 openstackgerrit Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): Add API to support vgpu resource provider create https://review.openstack.org/520313
10:47:55 fghaas lyarwood: I proposed the backport that kashyap just mentioned; I'm here if you need additional info on how exactly we bumped into this in Ocata
10:49:16 lyarwood sorry just on a call, I'll catch up in ~50mins
10:49:56 openstackgerrit Naichuan Sun proposed openstack/nova master: xenapi: Use XAPI pool instead of aggregate pool for shared SR migration https://review.openstack.org/554154
10:50:02 fghaas lyarwood: no rush at all, just wanted to let you know — will be here for several hours
11:05:44 jaypipes naichuans, jianghuaw_: still around?
11:31:13 jaypipes sahid: reviewing the cpu_shared_set patches again now.
11:36:38 jaypipes sahid: +2 on all.
11:40:51 sahid jaypipes: whaa thanks, i did not expected you to be so active on it :)
11:42:13 jaypipes sahid: let's "git r done" ;)
12:24:57 efried kashyap: Good deal man.
12:29:24 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: WIP: complex policy https://review.openstack.org/553776
12:38:52 naichuans jaypipes: Hi, Jay, I'm still here
12:48:15 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: Suggest when to propose notification changes https://review.openstack.org/562265
12:49:21 jaypipes naichuans: hi! so my primary concern is that the virt driver will be adding and removing resource provider records based on a "blip" of some device turning on and off.
12:49:35 kashyap efried: Still ~14 more clean-ups to do. Since this time the (libvirt / QEMU) version increment been a larger jump (because we didn't bump in "Queens"), need to clean up a lot more constants & compat code.
12:53:00 naichuans jaypipes: understood :) we decide to skip removing rp operation, and keep adding.We can't get allocation information in update_provider_tree. So it is difficult to check if the GPU is used by a VM or not. I remove the unavailable rps removing code. If nova schedule to a unavailable rp, then would be a failure and re-schedule
12:53:46 naichuans jaypipes: Any suggestion?
12:59:33 bauzas jaypipes: naichuans: I think we agreed to ask operators to not modify the config opt if so
13:00:04 bauzas at least because it would trample the compute service to understand how many vGPUs are used
13:00:36 bauzas if you want to modify that opt, destroy all your instances using vGPUs IMHO
13:01:12 naichuans Ah, if operators don't modify the config files, then the issue should not happen~
13:01:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix docs for confirmResize action https://review.openstack.org/562062
13:04:50 openstackgerrit Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802
13:05:12 naichuans jaypipes: bauzas: done?
13:05:26 bauzas done by what?
13:06:04 naichuans I mean we will assume operators would not change config opts?
13:09:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix docs for confirmResize action https://review.openstack.org/562062
13:34:59 Shilpa stephenfin: hi
13:35:25 Shilpa stephenfin: changes https://review.openstack.org/#/c/550172/3/ not working, any further inputs to resolve this?
13:44:37 jaypipes naichuans, bauzas: sorry, I really don't understand what you mean by config opts and operators.
13:45:28 bauzas I mean that enabled_vgpu_types shouldn't be modified
13:45:54 bhagyashris efried; Hi,
13:46:02 efried bhagyashris: Hello
13:46:12 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924
13:46:22 efried bhagyashris: It looked like you were getting ready to talk to me yesterday, and then... didn't.
13:47:23 jaypipes bauzas: that's not what we've been discussing, though. we've been discussing removing resource providers that temporarily become "unavailable" due to maintenance or down state, etc. And I have been telling naichuans and jianghuaw_ that it would be best to not auto-remove those resource providers based on some transient state.
13:47:39 bhagyashris efried: Regarding the patches https://review.openstack.org/#/c/560444/ , https://review.openstack.org/#/c/560459/2 I have fixed the unit test case part. so should i need to write the functional test as well?
13:48:12 efried bhagyashris: I think that would be nice, certainly.
13:48:23 efried bhagyashris: A functional test that behaves exactly like your live setup did.
13:48:49 naichuans jaypipes: like jianghua's comment, we mean modify the nova.conf to change supported vgpu types
13:49:08 efried bhagyashris: I would even say you should submit that functional test in its own patch, *before* the above changes, demonstrating that it produces the *wrong* result; and then with the above patches, flip it over to demonstrate the *right* result.
13:49:26 efried bhagyashris: Also, if we don't already have a LP bug open for this, we should do that.
13:49:45 efried dammit bauzas, I was in the middle of reviewing that!
13:49:54 Kevin_Zheng gibi efried , Hi thanks for the reviews, I’m totally fine with adding req Id also to update notifications, I will do it tomorrow, could you guys also check https://review.openstack.org/#/c/560748 it make update notification tests using common sample, so if it got merged I don’t have to rebase ;)
13:50:05 bauzas efried: thank Zuul
13:50:10 efried sigh
13:50:34 bauzas just a doc -1 because I was missing 2 blank lines
13:50:37 efried Kevin_Zheng: I don't know if adding req IDs to those other objects is appropriate - gibi what do you think?
13:50:39 bhagyashris efried: yes and there is test for update_provider_tree in nova/tests/functional/test_servers.py so accordingly i will need to add fuctional test write
13:50:44 jaypipes naichuans: and what happens if there are allocations on a pGPU that you end up removing from the enabled_vgpu_types CONF?
13:50:54 openstackgerrit Lee Yarwood proposed openstack/nova master: Add regression test for bug #1764883 https://review.openstack.org/562072
13:50:54 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP compute: Ignore active evacuations during _init_instance https://review.openstack.org/562284
13:50:54 openstack bug 1764883 in OpenStack Compute (nova) "Evacuation fails if the source host returns while the migration is still in progress" [Undecided,New] https://launchpad.net/bugs/1764883
13:51:13 bauzas jaypipes: I'm fine with your point too
13:51:43 efried bhagyashris: Yes. I don't know where libvirt-specific functional tests live, but that would be the idea.
13:51:51 jaypipes naichuans: at a bare minimum, I'd like to see some handling of a failed delete of a resource provider due to, say, an allocation existing against that provider.
13:52:40 efried bhagyashris: But I'm saying, also a functional test that hits the specific scenario you demonstrated - where the sharing provider was ignored before the fix (the DISK_GB shows up in the compute node RP) but is observed after the fix (shows up in the sharing provider).
13:52:59 naichuans jaypipes: will check it and add the error handling
13:53:10 Kevin_Zheng efried: gibi replied in the patch, he thought it is better to add it for InstanceUpdatePayload but not in status update
13:56:19 bhagyashris efried: ok, any idea or is there any reference that the test written for libvirt
13:56:58 efried bhagyashris: I have no idea. I know nothing about libvirt :)
13:57:06 efried bhagyashris: I thought *you* were the expert there :P
13:57:20 efried Maybe kashyap knows...
13:57:23 stephenfin Shilpa: No idea, sadly. Could you pull it down and deploy it locally. See what happens
13:57:40 stephenfin Shilpa: I imagine the issue is with nova and how it's parsing the URL. Can't say for sure though
13:57:53 jaypipes naichuans: ty!
13:58:46 naichuans np :)
13:59:44 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Spec for volume multiattach enhancements https://review.openstack.org/552078
14:00:01 bhagyashris efried: ohh :) i will try my best
14:00:54 Shilpa stephenfin: i have tested tempst locally for patch set 2, for noVNC v1.0.0, test_novnc failed with 'Not a valid html document in the response.' error and for stable/v0.6, test_novnc failed with 'AssertionError: True is not false : Token must be invalid because the connection closed.'
14:08:43 gibi Kevin_Zheng: thanks. I will look at https://review.openstack.org/#/c/560748 shortly
14:09:47 stephenfin jaypipes, sahid: I have small questions on the first and last of these three patches. Fancy taking a look so I can go/no-go? https://review.openstack.org/#/q/topic:bp/overhead-pin-set+status:open
14:10:38 efried kashyap: bhagyashris was looking for guidance as to where one might find/add libvirt-specific functional tests. I allowed as how I know nothing about libvirt.... but you might.
14:10:43 jaypipes stephenfin: sure thing
14:13:29 jaypipes stephenfin: answered.
14:13:35 stephenfin ta
14:22:52 openstackgerrit Stephen Finucane proposed openstack/nova master: Add CPUWeigher https://review.openstack.org/379525
14:30:09 kashyap efried: Sorry, being pinged on 4 places, just noticed your response.
14:30:40 kashyap efried: This is the place where I see libvirt functional tests: nova/nova/tests/functional/libvirt
14:31:00 efried well that would make sense :)
14:31:01 efried bhagyashris: ^
14:36:02 sahid stephenfin: stephenfin, jaypipes I replied to you about rasing an exception
14:36:24 sahid it's not something we should do actually
14:41:18 jaypipes sahid: yep, you made a good point.
14:41:58 bhagyashris efried: thank you :)
14:42:21 bhagyashris kashyap: Thank you :)
14:44:33 arvindn05 bauzas: are you available for the review of https://review.openstack.org/#/c/560718/ - Handle rebuild of instance with new image
14:44:33 arvindn05 ?
14:45:13 bauzas arvindn05: for 15 mins because of an appointment but yes
14:45:19 arvindn05 cool...
14:46:04 sahid jaypipes: cool
14:46:08 arvindn05 did you see alex_xu latest comment? he suggests rejecting images with new traits
14:46:37 sahid stephenfin: i will respin the fix put the option under [compute] section. I'm not sure i understand why of your comments about '::'
14:47:01 stephenfin sahid: Sweet, thanks :) Just replying to https://review.openstack.org/#/c/510897 now
14:47:24 arvindn05 IMO, i think its too much of an edge case to put in logic to handle it...
14:47:42 stephenfin sahid: If you put '::' at the end of the line, the next line is formatted as monospace text, i.e. code. I think that's what you want there, rather than the block comment
14:47:49 stephenfin e.g.
14:47:57 stephenfin here's some descriptive text::
14:48:02 stephenfin

Earlier   Later