Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-26
09:51:50 bauzas sahid: in that change, I'll focus on reporting the total number of possible mediated devices, which will be the sum up of what availableInstances reports + the sum of the mediated devices that belong to the same physical device
09:51:52 gibi jaypipes: do we assume that the user of the report clean alway tries creating thing first and bails out if placement is older than 1.11 ?
09:52:11 jaypipes gibi: yeah, I need to change that to have get_resource_provider() send 1.11 too
09:52:14 bauzas sahid: oh my bad, a misunderstanding
09:52:14 gibi jaypipes: s/clean/client/
09:52:39 bauzas sahid: yeah, I want to get the total number of possible mediated devices to be created, including the allocated mdevs
09:52:53 gibi jaypipes: OK, then it would be easier to set a minimum version for the whole report client
09:52:58 bauzas sahid: the fact they are assigned to the guest is unrelated with that change
09:53:08 jaypipes gibi: ack, as edleafe said.
09:53:40 sahid bauzas: so you just have to ask libvirt to get list the mdev devices, filter them by mdev_type
09:53:48 sahid and use len() to get the total
09:54:25 bauzas sahid: yup
09:54:30 gibi jaypipes: will you do that in the current patch or as a followup? (/me triest to figure out what to vote on the current patch)
09:54:33 bauzas for the allocated part
09:54:34 sahid bauzas: what you are trying to do with availableinstance does not work
09:54:48 bauzas available will give me the left amount
09:54:57 sahid off course not
09:55:06 jaypipes gibi: doing it now...
09:55:15 sahid since when operator will allocate all the mdev, that value will be 0
09:55:21 bauzas what I need to report from the inventory is the total amount of VGPUs a specific resource provider can create
09:55:23 gibi jaypipes: colle, then I will check back later
09:55:27 sahid you do not need of it
09:55:34 gibi jaypipes: s/colle/cool/
09:55:45 bauzas sahid: ah, I see your point
09:55:57 bauzas sahid: you were expecting the mdev to be manually created by the operator ?
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

Earlier   Later