Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-14
13:03:15 openstackgerrit Eric Fried proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138
13:03:16 openstackgerrit Eric Fried proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
13:03:16 openstackgerrit Eric Fried proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
13:03:17 openstackgerrit Eric Fried proposed openstack/nova master: Reformat _get_all_with_shared https://review.openstack.org/512799
13:03:33 efried gibi ^ includes re-inserting that busted dependency in the middle.
13:06:15 openstackgerrit Eric Fried proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
13:06:15 openstackgerrit Eric Fried proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138
13:06:16 openstackgerrit Eric Fried proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
13:06:16 openstackgerrit Eric Fried proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
13:06:17 openstackgerrit Eric Fried proposed openstack/nova master: Reformat _get_all_with_shared https://review.openstack.org/512799
13:06:21 efried Dang, missed a rename, fixed ^
13:08:23 gibi efried: your https://review.openstack.org/#/c/514092 bounced back from the gate as it needs a rebase and a unit test fix
13:09:03 efried gibi Thanks, on it.
13:12:56 openstackgerrit Eric Fried proposed openstack/nova master: placement: AllocCands.get_by_{filters => requests} https://review.openstack.org/514092
13:13:00 efried gibi ^ hecho
13:13:05 efried jaypipes Welcome back!
13:13:17 jaypipes efried: heh, thanks :)
13:13:49 alex_xu jaypipes: good morning!
13:13:58 jaypipes alex_xu: is it? :)
13:14:10 efried Friday jaypipes open patches: 13; merge conflicts: 12. Tuesday jaypipes open patches: 13; merge conflicts: 1
13:14:14 efried I'd say that's a good morning.
13:14:29 alex_xu sounds like all of us are wating for you :)
13:14:29 jaypipes efried: oh, excellent :)
13:14:54 jaypipes alex_xu: yeah, had a "lovely" new-hire training session up in Tampa yesterday ...
13:15:12 alex_xu jaypipes: efried, just want to show you this patch https://review.openstack.org/519081
13:15:28 alex_xu new-hire training is always lovely
13:16:43 openstackgerrit Eric Fried proposed openstack/nova master: placement: AllocCands.get_by_{filters => requests} https://review.openstack.org/514092
13:16:44 alex_xu jaypipes: efried I didn't some test last week on 1w rps and probably 70% loads on each rp, then I found that sql is faster than the current one. The current one will spend 1.7s in my env, the new sql just spend 0.7s
13:16:52 alex_xu s/didn't/did/...
13:17:33 efried alex_xu It was on my list to look at. I wanted to scrutinize the functional test a bit.
13:17:46 jaypipes alex_xu: what is 1w rps?
13:18:05 alex_xu efried: ok, thanks
13:18:17 alex_xu jaypipes: 10000 resource providers...
13:21:38 jaypipes alex_xu: can you put your DB setup into a pastebin please? # rps, inventory records used per rc, number of allocations used per rp, etc
13:22:22 alex_xu jaypipes: ok
13:26:49 alex_xu jaypipes: here is https://pastebin.com/kPMtEcQb, i just copy the variables from my script
13:27:48 jaypipes alex_xu: k, thank you sir :) I'll run benchmarks later today.
13:29:50 alex_xu jaypipes: cool
13:30:27 alex_xu jaypipes: also a non-shared version at https://review.openstack.org/#/c/516778/6/nova/objects/resource_provider.py@2518
13:31:13 jaypipes alex_xu: k
13:31:18 efried alex_xu I rebased your patch on top of the pending series - the one with all the extra tests in it - and it's failing some stuff.
13:32:28 efried alex_xu There are a number of cases where it's returning zero candidates.
13:32:43 jaypipes alex_xu: sum(invs.resource_class_id) is not what you're looking for there. I believe you're looking for count(distinct invs.resource_class_id)
13:35:18 alex_xu jaypipes: oops, that is true
13:35:30 alex_xu jaypipes: but it shoudl works with count
13:35:36 jaypipes alex_xu: yep.
13:35:47 alex_xu efried: sorry, which patch?
13:35:57 efried https://review.openstack.org/#/c/519081/
13:35:58 jaypipes alex_xu: I'll benchmark later today. I have a dentist appointment shortly and will set up benchmarks after that
13:36:11 alex_xu jaypipes: ok, no problem
13:37:07 alex_xu efried: ok, I will try to debug them
13:37:43 efried alex_xu Note that some of the test cases are highlighting bugs, so the current 'expected' value is wrong - but the correct 'expected' value is in the comments, and it still ain't []
13:38:06 alex_xu efried: got it, thanks
13:42:33 sean-k-mooney jaypipes: o/
13:43:11 gibi efried: thanks for the fix on the get_by_requests refactor patch. I'm +2.
13:43:14 sean-k-mooney jaypipes: can i get you to weigh in on a matter of os-vif policy. specifcally https://review.openstack.org/#/c/484386/ and the extention of our public api.
13:43:54 gibi efried: Do you agree to move https://review.openstack.org/#/c/518633/ top of Jay's series as that will decrease the amount of visible bugs in the patch?
13:44:10 sean-k-mooney jaypipes: i -2'd the previous itteration that added a shared implementation to os-vif.common
13:44:36 sean-k-mooney jaypipes: it has now been split but sahid dislikes the code duplication in tree this causes
13:45:56 sean-k-mooney as a counter proposal the only path i see forward to not extend the publci api and avoid duplication is to have a os-vif.internal and use an assertion to ensure that no one else can import it like this http://paste.openstack.org/show/626267/. toughts?
13:51:34 efried gibi I was just looking at that. In general I'm in favor of moving any test patches on top of that series, as it does seem to be resolving *some* issues.
13:52:31 efried gibi As we were discussing above, I'm also in favor of putting things like refactors on top of that series because the extra tests will flush out more bugs.
13:52:51 efried (refactors of the prod code)
13:52:58 gibi efried: cool. If you move that there I can quickly re-review and +2 it :)
14:19:03 gibi edleafe: welcome back
14:20:45 bauzas edleafe: hope you didn't get sick and your IRC bouncer is fine, unlike me
14:21:15 bauzas oh, and my corp phone died too
14:23:18 edleafe bauzas: znc was humming along nicely in my absence
14:23:33 edleafe don't know if I can read back that much :)
14:23:50 bauzas hah
14:25:07 sean-k-mooney has anyone stacked on centos 7.4 recently
14:30:51 kashyap Do people do that often? I thought most do it only with Debian / Ubuntu / Fedora
14:31:13 openstackgerrit Eric Fried proposed openstack/nova master: Test allocation candidates: multiple aggregates https://review.openstack.org/518633
14:31:21 efried gibi ^ That was... interesting.
14:36:03 sean-k-mooney kashyap: stack with centos?
14:36:26 bhagyashris mriedem: Hi, I have one doubt regarding the instance snapshot. When I create the instance snapshot using the nova image-create <server-id> <snapshot-name> the it only creates the plain image that means it only calls the image-create and not image-upload and the image remains in queued status so How can I create instance snapshot in active state.
14:36:33 sean-k-mooney kashyap: i normally do all my dev on ubuntu but i need to use centos currently because reasons....
14:37:46 kashyap sean-k-mooney: Yeah
14:38:14 gibi efried: did you encountered you type of problems during the rebase?
14:38:17 kashyap sean-k-mooney: Might be also want check on #openstack-qa channel
14:38:25 sean-k-mooney kashyap: fedora is rather fragile as its a bit too bleading edge
14:38:33 efried gibi The test results changed rather dramatically.
14:38:43 kashyap sean-k-mooney: Yeah, bled this morning, trying to shave a yak.
14:38:49 efried gibi The good news is that all the results now at least seem to have the proper resources in them.
14:39:02 efried gibi I think the problems are now limited to crossing aggregates.
14:39:56 sean-k-mooney kashyap: im currently hitting a issue with nova that is proably unrelated to centos to be honest just have not seen it last time i stacked on ubuntu. devstack is not finding the nova compute agent in the cells db and devstack is failing because of this
14:40:47 gibi efried: I feel that is actually a good news. From having multiple problems we managed to go done to one single issue
14:41:19 efried gibi Oh, definitely agree.
14:41:23 efried Just made for a tough rebase :)
14:42:31 kashyap sean-k-mooney: I see, afraid I don't know the cause of it.
14:42:48 mriedem bhagyashris: something probably failed server-side, because nova-compute will upload the image data to glance
14:44:09 sean-k-mooney kashyap: im restacking with reclone=true to make sure eveything is uptodate but basically im seeing openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host silpixa00385232 --service nova-compute -c ID -f value fail.
14:44:30 kashyap sean-k-mooney: In the past 'reclone=true' screwed me up. Let me dig up the reason, I recall writing it down why it's "bad"
14:44:40 kashyap IIRC, it messes up with Git remotes
14:45:21 sean-k-mooney kashyap: hehe i have been using devstack for 4 years i know why it can be bad but in this case its safe enough as it will just do a git pull on all the repos in /opt/stack
14:45:40 bhagyashris mriedem: but there is no optional parameter --file at the time of creation of instance snapshot so thats why the snapshot created at glance is in queued state
14:45:45 kashyap sean-k-mooney: Ah, okay, you're well-scarred then.
14:46:09 mriedem bhagyashris: i think you might be misunderstanding what the nova image-create operation does
14:46:17 mriedem it's not the same as glance image-create and image-upload
14:46:37 sean-k-mooney kashyap: enough so to be imune to the fact it will happliy destroy your system if you dont speak to it firmly form time to time yes

Earlier   Later