Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-18
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
14:48:13 stephenfin config_option = config_value
14:48:15 bauzas arvindn05: the problem is that we had a huuuuuge problem during Queens about whether we should accept to check the image when rebuilding
14:48:23 arvindn05 i would just go back to the original behaviour of trying to find destinations via placement if the image changes....
14:48:25 bauzas arvindn05: we had a CVE for that
14:48:38 bauzas arvindn05: then we found some problems with the CVE new behaviour
14:48:44 bauzas arvindn05: then we tried to fix that
14:48:52 sahid oh i think i understand what you mean now
14:48:56 bauzas arvindn05: now we're like middleground
14:49:41 arvindn05 can you reference the conversation for me? i dont have that history unfortunately
14:51:08 bauzas arvindn05: https://etherpad.openstack.org/p/nova-ptg-rocky L317 and below
14:51:22 bauzas we discussed about that during the PTG
14:51:28 bauzas as a retrospective if you wish
14:51:44 arvindn05 will take a look
14:52:22 bauzas arvindn05: so, see, before adding *more* to rebuild about scheduler check, maybe let's discuss about the above
14:52:25 arvindn05 i am trying to understand what the problem is with going to placement always. Only in case that the current host is at capacity, the current host may not get picked during placement. I guess we can add preferred destinations to the placement api so we can prioritize current host if it matches
14:53:25 bauzas arvindn05: there is nothing really related to placement
14:53:53 bauzas arvindn05: it's more about the main issue said in L321
14:54:24 bauzas calling placement for checking traits is just a new scheduler check
14:54:47 bauzas but looks like mriedem isn't around
14:55:25 bauzas we agreed during the PTG to defer the instance.save() *after* rebuilding and mriedem said he was volunteering thart
14:55:37 arvindn05 yup...if you can make it to the nova meeting tommorow....maybe we can discuss in open topics...
14:56:03 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: mdevs returning parent and vendor PCI info https://review.openstack.org/562304
14:56:15 bauzas AFAIR, the nova meeting is EU-compatible this week
14:56:18 bauzas so, yup
14:56:35 arvindn05 great :)
14:57:14 arvindn05 i am not sure mreidem patch would effect me..
14:57:36 arvindn05 i think we first need to get concensus on whether to invoke placement or not....

Earlier   Later