| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-26 | |||
| 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 | |
| 12:36:59 | kaisers_ | artom_: but that's from clouded memory | |
| 12:37:03 | kaisers_ | pun not intended | |
| 12:37:23 | artom_ | kaisers_, ah, Dan Berrange's comment | |
| 12:37:26 | artom_ | I've read that | |
| 12:37:38 | artom_ | That wouldn't be in nova code though, correct? | |
| 12:37:49 | kaisers_ | artom_: yep, that's what i thought | |
| 12:37:57 | kaisers_ | artom_: i think it should be in nova | |
| 12:38:10 | kaisers_ | The libvirt xml would have to contain the tag iirc | |
| 12:38:27 | artom_ | kaisers_, ah? I'll try to read up on that | |
| 12:39:56 | kaisers_ | artom_: i think i started on that some time ago but had a hard time determining how exactly the tag has to look like | |
| 12:41:00 | artom_ | kaisers_, alright, I'll try and figure out what exact shape the fix should take | |