13:00:41 #startmeeting rpm_packaging 13:00:42 Meeting started Thu Jan 26 13:00:41 2017 UTC and is due to finish in 60 minutes. The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:45 The meeting name has been set to 'rpm_packaging' 13:00:46 o/ 13:00:49 number80: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 13:00:51 damn 13:00:54 ping toabctl, dirk, apevec, aplanas, IgorYozhikov, jpena, jruzicka, number80, kaslcrof 13:01:00 o/ 13:01:06 #chair IgorYozhikov jpena dirk 13:01:07 Current chairs: IgorYozhikov dirk jpena number80 13:01:24 agenda is here: https://etherpad.openstack.org/p/openstack-rpm-packaging 13:01:30 suggesting to fill up agenda @ ^^^^^ 13:05:43 number80, if there are no topics, let's review initial nova https://review.openstack.org/#/c/425673/ 13:06:26 2 deps updte - rfc & bandit is on the way and in a couple of hours will be published on MOS CI side 13:06:49 yep 13:07:12 I have to fix cassandra-driver build 13:07:24 do we have some1 from SUSE side today? 13:07:33 RHEL7 is starting to show its age ... 13:07:46 number80: we also need a higher python-kafka version, see https://review.openstack.org/422009 13:08:02 jpena: kafka is a kafkaian build :) 13:08:05 will do 13:08:09 lol 13:08:12 :) 13:08:28 ok nova fails on all CIs 13:08:49 RDO - Error: No Package found for python-bandit 13:09:31 I just build 1.4.0 for MOS & now package is on the way to our repos 13:09:42 we should have bandit ... 13:09:44 IgorYozhikov: the name is bandit in RDO, we need a pymod2pkg update 13:09:55 yep 13:09:58 * jpena creates a quick change 13:11:20 also I want to ask your opinion about %check section 13:12:12 I faced issues while unit tests run related to vif... and decided to exclude all network related tests for nova 13:12:47 so, your opinion here will be appreciated 13:13:14 I'm speaking about : %check 13:13:14 export OS_TEST_PATH=./nova/tests/unit 13:13:14 export PYTHONPATH=. 13:13:14 #python setup.py testr 13:13:14 testr init 13:13:15 testr list-tests | grep -vE '(vif|OVS|Network)' > list 13:13:17 testr run --load-list=list 13:13:51 list of excluded tests - http://paste.openstack.org/show/596494/ 13:14:28 ouch 13:14:33 that's a ong lit 13:16:14 number80, results I've got :Ran 13831 tests in 1549.714s 13:16:15 PASSED (id=0, skips=52) 13:16:43 and this is with excluded net tests 13:17:32 i may have to do something similar with neutron, had 10 tests failing 13:18:43 IgorYozhikov: I suggested that generated list is put in separate file and used as a %SOURCEX 13:18:48 s/used/included/ 13:19:08 it'd be simpler and won't bloat too much spec file 13:19:36 number80, r u suggesting to have a separate tests.list file? 13:19:42 yes 13:20:06 and how to be in case if nova will add or reduce amount of tests in further release? 13:20:27 I mean for exclude tests 13:20:49 didn't get your point :( 13:21:08 I mean we should just use a blacklist rather than a whitelist for tests 13:21:14 why we need to have a list with excluded tests? 13:21:33 I use grep -v for that 13:21:47 * number80 not sure 13:22:00 or we need to elaborate of a particular set of blacklisted tests? 13:22:42 well, in case of nova, you excluded network related tests (which is ok for building in a networkless chroot) 13:23:11 so let's just state explicitly tests that we don't want to run, this way, if nova add new tests they will run 13:23:16 *by default 13:23:56 ok, I'l try to add tests.blacklist file as SOURCEx 13:24:51 hi 13:25:17 dirk, hello :) 13:25:24 we are discussing nova 13:25:47 also found issue in pymod2pkg with bandit 13:26:01 thanx to jpena , fix is on the way - https://review.openstack.org/#/c/425678/1 13:26:52 dirk, could you please also review - https://review.openstack.org/#/c/425673/ 13:27:16 I understand that this commit is big, but this is nova... 13:27:43 * dirk fixes suse ci for nova 13:28:06 anything else related to nova colleagues? 13:29:34 IgorYozhikov: why do you depend on bandit anyway? that looks wrong 13:30:57 dirk, according to test-requirements 13:31:12 sure, but its not used by tests 13:31:19 I can try to run tests without it 13:31:21 its a code checker. only run on the pep8 target, which we don't run 13:31:54 suse ci fixed 13:32:29 great, I'm rebuilding bandit in MOS side with new name 13:32:40 s/in/on/ 13:33:03 also number80 suggested to create so called tests.blacklist file 13:33:29 which will include all network related tests 13:33:36 I prepared a list - http://paste.openstack.org/show/596494/ 13:33:52 it's simpler to blacklist tests that we don't want to run than whitelisting 13:36:35 dirk, any thought about ^^^ 13:36:56 IgorYozhikov: thanks.. no concrete thought.. In my experience the tests might not be runnable because they depend on things that are different in the sdist tarballs 13:37:14 suse used to run unit tests in packaging for those big projects but it was such a pain for so little gain that we gave up on it 13:37:30 especially as it was extraordinarily difficult to get fixes upstrema that were not reproducible in a git checkout 13:38:34 blacklisting broken stuff is an acceptable approach for me 13:38:40 as is not running tests for nova 13:38:46 same like not running tests is.. 13:39:35 well, we should try running tests, and depending the pain, just drop them 13:39:46 make it a SHOULD rather than a MUST 13:40:13 dirk, I can spend some time on debugging of failed tests, but not sure that nova folks will sit near me during this exercise :( 13:40:28 that's why I'm exclude all related to vif & net 13:40:53 IgorYozhikov: yeah, and there are tests that depend on network, and in the suse ci there is no network.. so.. 13:42:04 does it means that current suggested approach for nova looks fine for all(SUSE/RH/MOS)? 13:42:22 unit tests without net stuff 13:43:08 yes sure 13:43:15 this will include 13.8k tests 13:43:44 #agreed on excluding network tests from unit test if possible 13:44:07 next topic? 13:45:28 yes, let's move on 13:47:05 may be branching strategy? 13:47:13 or reviews 13:47:43 yep 13:49:14 branching strategy mgiht be a good one 13:50:14 dirk, when is better time by your opinion. 13:50:51 in mos we create branches after GA of whole OS(libs+clients+services) 13:52:27 IgorYozhikov: I guess sooner the better 13:52:37 some projects already branched 13:52:50 let's branch this week 13:52:58 but we have an insane patch backlog 13:53:06 Yep 13:53:15 which got quite a bit moving today, but until this noon there was literally noone reviewing anything really :( 13:53:37 so g-r freeze is today at 20:00 UTC 13:53:45 we could get stuff in and branch then 13:53:53 I take that we're liberal with adding specfiles to stable/ocata 13:53:58 (adding new specfiles..) 13:54:07 I can crank out a CI for stable/ocata today if wanted 13:54:11 its just a few minutes of work 13:54:39 if the other CI setups are more difficult then I'm fine with waiting a bit with branching 13:54:49 dirk, in MOS we could switch CI right after OS GA 13:54:52 or we leave suse ci as the only voting ci for stable/ocata until the others are there as well.. 13:55:08 For us, it's quite similar, some quick setup is needed 13:55:38 I'll talk to our infra team & get back with results 13:56:07 good 13:56:33 * dirk just created C:O:U:O :) 13:56:38 so ci should be there in a min 13:58:42 Yep 13:58:53 well, we're reaching the hour 13:59:02 anything else before we close the meeting? 13:59:12 nope 13:59:46 ok, thanks for attending and see you on #openstack-rpm-packaging 13:59:50 #endmeeting