Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-26
09:56:16 sahid bauzas: well that one was question at the beginning
09:56:17 bauzas sahid: I was rather thinking of libvirt doing the syscall
09:56:39 sahid bauzas: libvirt does not provide any api to allocate mdev
09:56:50 bauzas sahid: we could make the sys call
09:56:58 bauzas not by libvirt of course
09:57:00 bauzas in the virt driver
09:57:21 sahid oh ok so you want to also manage the allocation of mdev
09:57:26 bauzas that's right
09:57:43 bauzas because mdevs don't support reboots
09:57:49 sahid basically that was my first question: 11:50 < sahid> bauzas: in you implmentation, you want to also allocate the mdev?
09:57:58 sahid but it's better like that for sure
09:58:00 sahid +1
09:58:17 bauzas sahid: sorry about the confusion, the 'allocation' word is heavily used in my mind :p
09:58:58 bauzas tbc, the workflow I see is that when you ask for an instance, the virt driver will lookup the allocations and see there is one for VGPUs
09:59:22 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
09:59:24 jaypipes gibi: done, sir ^
09:59:30 bauzas then, it will call the system to create the mdev, and then create the XML with the according UUID
09:59:46 gibi jaypipes: lookgin
10:00:14 bauzas at init (when we reboot), we could also lookup the instances and see if they have mdevs in their domain XML, so we could recreate it on the fly
10:01:00 sahid bauzas: well the uuid will be different
10:01:29 bauzas sahid: you can create a mdev by passing a specific UUID right?
10:01:43 sahid bauzas: yes you right, my mistake
10:02:05 bauzas anyway, I need to fix a problem with my testing machine
10:02:17 bauzas can't see the created mdevs for some reason
10:02:22 bauzas very frustrating
10:10:36 gibi jaypipes: thanks, I'm +2
10:11:36 openstackgerrit Radoslav Gerganov proposed openstack/nova master: VMware: implement get_inventory() driver method https://review.openstack.org/506175
10:28:42 efried jaypipes You're up early
10:36:42 efried dansmith FYI, this is what we were discussing yesterday: https://review.openstack.org/#/c/515223/
10:39:20 efried alex_xu yt?
10:39:43 openstackgerrit Merged openstack/nova master: Remove usage of kwarg retry_on_request in API https://review.openstack.org/501073
11:14:25 openstackgerrit Chris Dent proposed openstack/nova master: Do not attempt volume swap when guest is stopped/suspended https://review.openstack.org/389798
11:24:23 openstackgerrit Yikun Jiang proposed openstack/nova master: Add migration db and object pagination support. https://review.openstack.org/514904
11:36:48 openstackgerrit Yikun Jiang proposed openstack/nova master: Add migration db and object pagination support. https://review.openstack.org/514904
12:02:02 avolkov jaypipes: hi, if not allowing to delete RP with associated traits is error or feature?
12:02:05 efried cdent FWIW, my IDE complains when I use set([]) instead of {} for set literals. I agree it's tougher to read (though it's fewer characters, which is all-important in python :) Maybe I'll switch that IDE warning off.
12:02:39 cdent yeah about that “fewer characters” thing,wait for my review on the next in the seriues
12:03:07 Dinesh_Bhor jaypipes, bauzas: Hi, could you please give your opinion on this: https://review.openstack.org/#/c/512990/ when you get time.
12:03:15 cdent efried: in that particular case since it is a doc string you can do whatever you like
12:03:18 jmccarthy There seems to be an issue with console logging (in horizon) on xen compute, looking at the instance xml - I don't find any of the path .. console.log type definitions (as seen on other computes) ? Looking at https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py for clues ..
12:03:44 efried cdent Roger wilco.
12:05:19 alex_xu efried: hi, i'm here
12:05:47 jmccarthy Any suggestions ? Editing the xml by hand works to a point (to try and find out what actually works), but changes it doesn't like don't seem to be applied
12:05:53 efried alex_xu Hey, so I was thinking perhaps you and I should try to do some collaboration on these placement changes, edleafe style.
12:07:52 alex_xu efried: yea, that's good idea
12:08:02 efried alex_xu E.g. I'd like to feel at liberty to write tests and make tweaks, but sometimes it makes a lot more sense to do it in the same change set rather than trying to do separate ones with commits based on each other and whatnot.
12:09:13 efried alex_xu Here's the edleafe reference: https://blog.leafe.com/pair-development/
12:09:47 alex_xu give me 10 mins to ready edleafe's blog :)
12:10:25 alex_xu s/ready/read/
12:10:46 jaypipes avolkov: the user should be able to delete a provider unless that provider has allocations against it. nothing to do with traits.
12:10:53 jaypipes avolkov: does that answer your question?
12:11:19 efried Dinesh_Bhor FYI, spec freeze has passed - is this proposed for Rocky?
12:12:12 avolkov jaypipes: Yes, I file a bug then
12:12:21 Dinesh_Bhor efried: yes, I will do the needful for that. I just want to take the early feedback.
12:12:28 jaypipes avolkov: sounds good, thanks Andrey! :)
12:12:52 jaypipes Dinesh_Bhor: ok, I can review it. but as efried said, please update it to point to rocky first, ok?
12:12:56 efried jaypipes avolkov I don't remember if/where we landed on the issue of removing a trait from an RP with allocations against it.
12:13:11 alex_xu efried: I guess edleafe means two people work on different timezone, anyone can fix the problem when review the code?
12:13:24 Dinesh_Bhor jaypipes: yes, I will update it
12:14:02 efried alex_xu I think of it as a tighter collaboration than that. You and I would agree to work on a particular patch or series, like the one you're doing for AllocationCandidates, together.
12:14:20 jaypipes efried: since traits are not consumed, I don't have an issue with deleting providers that have traits assigned to them.
12:14:43 efried jaypipes Other way around: removing a trait from a provider if that provider has allocations against it.
12:15:08 efried jaypipes Objection being that then the RP may no longer "satisfy" the conditions that were originally in play when the allocation was made.
12:15:36 efried jaypipes My take: who cares? You're never, like, re-checking afterwards.
12:15:52 efried jaypipes If you need to do a migration or resize, you would have to reschedule anyway and find appropriate RPs.
12:16:05 alex_xu efried: ok, then what we can do?
12:16:06 efried jaypipes I guess it could make resize-to-same-host impossible. But so could resource exhaustion. So...
12:16:07 jaypipes efried: agreed.
12:16:37 efried alex_xu Each of us ensures we upload patches in progress before we sign off for the day (so that we don't have local work-in-progress that gets overridden by the other)
12:17:14 efried alex_xu Ideally we have a "handoff" time when we can briefly discuss anything as one of us leaves and the other comes on.
12:17:17 alex_xu edleafe: ok, that should be under the situation the direction is solid
12:17:37 alex_xu efried: yea, edleafe help me update the patches before when I'm sleeping
12:18:24 efried alex_xu Okay. I obviously didn't want to start patching up your changes without discussing it first :)
12:19:05 efried alex_xu So I assume you're at least close to done for the evening at this point. (What time zone are you in?) Want to talk about what's in progress, and how I can most effectively take over?
12:19:53 alex_xu efried: yea, I will upload a version, and I think I can write some todo note in the code
12:20:09 alex_xu basically, I want to add more unittest for next step
12:20:37 alex_xu and then overall to look at the code, and see if there is anything need to be adjust
12:21:11 efried alex_xu The ones about _get_provider_ids_with_any_resource returning incorrectly when there are exhausted inventories in play?
12:21:38 alex_xu efried: I totally rewrite that sql
12:21:59 alex_xu currently, what I'm doing is rewrite the comments...and add more unittests
12:22:50 artom_ kaisers1, ping?
12:22:52 alex_xu efried: how about I write some todo note in the commit message, then you can continue those todo, or fix anything you found when review the code?
12:23:03 efried alex_xu Perfect.
12:23:04 kaisers_ artom_: pong Hi
12:24:11 alex_xu efried: cool, let us try how was that
12:25:08 efried alex_xu 很好 :)
12:25:35 artom_ kaisers_, hey, do you still run quobyte ci with dynamic_ownership = 0 in libvirt conf?
12:29:27 efried jaypipes These failures are weird http://logs.openstack.org/93/385693/58/check/openstack-tox-py27/786b250/testr_results.html.gz -- you on top of it or want me to debug?
12:29:37 jaypipes efried: on it already.
12:29:41 efried jaypipes coo
12:30:16 kaisers_ artom_: i think the setup did not change, yes. why?
12:31:03 efried jaypipes Oh, the headers. I was misreading those as being part of the endpoint filter. Phew, not crazy.
12:31:11 artom_ kaisers_, we've run into an interesting side effect of the workaround we put in place for that
12:31:48 artom_ https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3033 specifically
12:32:14 artom_ If the compute node dies ungracefully, instances can't be started again because of permission denied on console.log
12:32:22 artom_ We can probably hack something around that
12:32:40 artom_ But I was kinda hoping the original reason for the original workaround had gone away
12:34:39 kaisers_ artom_: hmm, yeah, would be great to get rid of that whole thing. I think i've an open idea on how to improve on that but currently i'm not coming 'round to implement that, at least not in the next 5-8 weeks
12:35:11 artom_ kaisers_, does the idea depend on knowledge of quobyte? Otherwise I'm game :)
12:36:48 kaisers_ artom_: only marginally i think. I've to re-check my notes. I think it was centered around the idea to give a specific tag to libvirt which should ensure Quobyte is understood as a shared file system and libvirt should refrain from touching the files

Earlier   Later