Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-11
11:41:32 artom sean-k-mooney, make it Depends-on on the patch below it
11:41:41 sean-k-mooney <<<<<< HEAD
11:41:43 sean-k-mooney import fixtures
11:41:45 sean-k-mooney =======
11:41:46 artom I'd rather make mriedem's and dansmith's job easier at this point
11:41:47 sean-k-mooney import itertools
11:41:49 sean-k-mooney >>>>>>> Functional tests for NUMA live migration
11:41:59 sean-k-mooney ya ok i can do that
11:42:13 openstackgerrit Luyao Zhong proposed openstack/nova master: libvirt: Support VM creation with vpmems and vpmems cleanup https://review.opendev.org/678455
11:42:41 sean-k-mooney both fixure and itertools are need by the way and its in alphabetical order so we jsut need to remove the conflict markers.
11:43:52 openstackgerrit Luyao Zhong proposed openstack/nova master: Parse vpmem related flavor extra spec https://review.opendev.org/678456
11:46:13 openstackgerrit Luyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces https://review.opendev.org/679640
11:47:32 openstackgerrit Luyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory https://review.opendev.org/678470
11:49:34 efried stephenfin: commented. Sorry for being dense here.
11:51:34 openstackgerrit Luyao Zhong proposed openstack/nova master: objects: use all_things_equal from objects.base https://review.opendev.org/681397
11:58:51 luyao sean-k-mooney: I gave some wrong infomation about vpmem yestoday, so sorry to misleading you. I clarified at here https://review.opendev.org/#/c/678455/24/nova/virt/libvirt/config.py@3180
12:00:59 sean-k-mooney ok so we dont need to subtract and it should be fine to just have 2KB lables since they are just markers
12:01:15 sean-k-mooney to denote the start and end of the namespace right?
12:02:48 luyao sean-k-mooney: yes, I think so
12:05:54 sean-k-mooney cool
12:07:56 efried luyao: Any update on the vpmem CI?
12:13:39 yaawang Hi, could anyone review this patch, it's part of vCPU models selection. https://review.opendev.org/#/c/670298
12:16:21 efried yaawang: I've been staying clear of that one because Alex is representing. bauzas or gibi_fly, might you have room for that ^
12:17:14 efried kashyap: Could you please clarify your opinion on https://review.opendev.org/#/c/678453/27/nova/virt/libvirt/driver.py@447 -- should we use InternalError to be consistent, or go rogue and use InvalidConfig?
12:19:51 efried stephenfin: also ^ when you get back
12:19:53 luyao efried: I know Dolpher and Rui is trying to apply the comunity patches then trigger the tests. Besides, I'm not very clear about that.
12:20:17 efried luyao: okay, thanks.
12:22:14 efried http://52.27.155.124/55/678455/28/check/pmem-tempest-plugin-filtered/7336479/job-output.txt.gz @ 2019-09-11 12:14:29.162146 looks like we're still getting PS13
12:22:22 efried that completed less than 10 minutes ago.
12:25:00 sean-k-mooney luyao: efried how is the intel ci running? if its using zuul v3 i dont really see how it difficult to remote the presetp that is hardcoding the patch.
12:25:30 sean-k-mooney it would not be too hard to make it skip it the nova repo did not have teh changeid of the pmem patches in the git log either.
12:25:55 efried sean-k-mooney: agreed, I don't think it's hard, I just think the owners aren't up yet.
12:25:57 sean-k-mooney the repos will be set up before your main playbook runs
12:26:03 kashyap efried: Looking
12:26:20 sean-k-mooney ok so there are no public repos with the job definitions?
12:26:21 kashyap efried: I'd say InternalError for now, for consistency's sake.
12:26:27 sean-k-mooney its managed internally?
12:26:37 efried kashyap: ack, thanks. luyao ---^
12:26:44 efried sean-k-mooney: I have no idea.
12:26:47 sean-k-mooney i mean that fine but if there is we could porbaly fix it
12:26:56 kashyap efried: And I agree with your point there, in a future commit, it can be changed
12:27:22 efried sean-k-mooney: https://github.com/intel/Intel-OpenStack-CI-jobs/
12:27:46 luyao kashyap: okay, I'll change it cake to InternalError. :)
12:28:08 sean-k-mooney ok its not mnaged via gerrit so we cant use depens on to test job changes
12:28:17 sean-k-mooney unless they are using gerrithub
12:29:26 sean-k-mooney that woudl be a no
12:29:29 kashyap luyao: Thanks
12:32:00 luyao efried, sean-k-mooney: Rui told me just now, them have a patch, but they have no permission to merge it into CI , waiting for matt to merge, then we can appy the latest patches and do the tests
12:32:35 efried luyao: Matt who? Merge where?
12:32:45 sean-k-mooney ok i was just looking at the repo to see if i could write one
12:32:49 sean-k-mooney i did not see it in that repo
12:33:11 luyao efried: Merge ti CI-jobs I think? I don't know about CI
12:33:14 sean-k-mooney any way we coudl get efried or alex_xu added to the people that can merge to it if its going to run against nova
12:34:29 luyao efried: Matt is helping setup CI, I saw he is the intel ci job repo owner
12:35:01 efried Matt who? (Last name?)
12:35:21 sean-k-mooney efried: https://github.com/matt-welch
12:35:31 efried okay.
12:35:59 efried sean-k-mooney: how does one find out who's got merge perms on a github repo?
12:36:01 sean-k-mooney i dont see the hardcoding in that repo
12:36:20 sean-k-mooney no idea buyt that is the mat that has merged things
12:36:22 luyao efried: Matt Welch
12:36:24 sean-k-mooney you can see it in the org
12:36:32 sean-k-mooney but im not a memebr of the intel org anymore
12:36:35 efried looks like he's the only one who has merged things.
12:37:06 efried ugh, and he's west coast, which probably means he won't be up for another several hours.
12:37:27 sean-k-mooney im not sure if this hardcoding is in that repo or in the tempest plugin repo
12:38:16 efried sean-k-mooney: https://github.com/intel/Intel-OpenStack-CI-jobs/blob/master/roles/upgrade-libvirt-qemu/tasks/main.yaml#L105-L108
12:38:23 efried seems like a weird place for it, but whatevs.
12:38:37 sean-k-mooney ah that is why i have not found it it does not have pmem in the name
12:39:10 sean-k-mooney well the task has
12:40:09 sean-k-mooney ya there are btter ways to do that
12:40:11 sean-k-mooney oh
12:40:29 sean-k-mooney i wonder if we can use a pull request in the depens on
12:40:47 sean-k-mooney that should work if they have zuul set up correctlyly
12:41:14 efried brb
12:42:58 stephenfin efried: sean-k-mooney or mriedem are you people RE: InternalError or InvalidConfig. It was the former's comment but the latter agreed
12:43:08 stephenfin *your
12:43:54 efried stephenfin: Sorry, I'm failing to parse that
12:44:05 efried oh, got it.
12:44:30 efried sean-k-mooney: Could you please clarify your opinion on https://review.opendev.org/#/c/678453/27/nova/virt/libvirt/driver.py@447 -- should we use InternalError to be consistent, or go rogue and use InvalidConfig?
12:45:10 sean-k-mooney well its not an internal error but i dont really care
12:45:11 stephenfin bauzas: replied on https://review.opendev.org/#/c/675571 (tl;dr: I spotted it and removed it - should have been a different patch/called out in the commit message but it's done now)
12:45:19 sean-k-mooney we proably shoudl change them all to invalid config
12:45:27 sean-k-mooney we can do that in U
12:45:31 stephenfin efried: I vote do the new thing and fix the old things later
12:45:57 efried sigh
12:45:59 sean-k-mooney iternal error implies the something in nova broke and it did not. this is user error
12:46:26 stephenfin foolish consistency and all that
12:47:11 efried luyao: Looks like kashyap is outvoted ^ so please just fix the docstring and we'll move on.
12:47:14 sean-k-mooney efried: from a time perspecitve i dont think this is important but i also dont think internal error is correct for config errors
12:47:38 sean-k-mooney so ill be happy with whatever ye choose
12:47:42 efried sean-k-mooney: no argument that InvalidConfig is better. The only argument to use InternalError is consistency.
12:48:37 openstackgerrit Chris Dent proposed openstack/os-resource-classes master: WIP: Build pdf docs https://review.opendev.org/681463
12:49:00 kashyap Yeah, maybe in this case being 'consistent' isn't worth it. I don't know - whoever has super strong opinion on it (seems like stephenfin has)
12:49:11 sean-k-mooney doing something consitenly wrong does not make it correct
12:49:37 efried no, it just makes it predictable for the operator
12:49:58 sean-k-mooney but two days before freatre freeze i dont really want to block on that
12:50:11 sean-k-mooney true
12:50:12 kashyap sean-k-mooney: Sure :-). I do see the good argument for doing the right thing with InternalConfig
12:50:22 sean-k-mooney if i was an operator i would want to see invalide config

Earlier   Later