12:59:49 #startmeeting rpm_packaging 12:59:51 Meeting started Thu Sep 22 12:59:49 2016 UTC and is due to finish in 60 minutes. The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:59:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:59:54 The meeting name has been set to 'rpm_packaging' 12:59:57 #topic roll call 13:00:01 #chair IgorYozhikov 13:00:02 Current chairs: IgorYozhikov number80 13:00:15 o/ 13:00:16 hey 13:00:19 #chair dirk 13:00:19 Current chairs: IgorYozhikov dirk number80 13:00:19 o/ 13:00:26 #chair jruzicka 13:00:26 Current chairs: IgorYozhikov dirk jruzicka number80 13:00:39 let's wait few more minutes 13:00:47 ok 13:01:00 o/ 13:02:48 #chair jpena 13:02:49 Current chairs: IgorYozhikov dirk jpena jruzicka number80 13:03:08 I guess we can't expect more guests 13:03:29 #topic welcome newcomers 13:03:49 as you saw this morning, we have two new contributors, Tony Xu and linbing 13:03:58 does anyone of you know them? 13:04:13 I would assume they're sleeping by now :) 13:04:39 Well, I think it would be nice if someone could contact them and mentor them 13:05:00 especially as they're in a very different tz as most of us 13:05:16 number80, yes I also saw 13:05:43 #action number80 send them a welcome email 13:05:57 they uploaded a lot 13:06:05 #topic Design Summit fishbowl follow-up 13:06:39 number80: nice idea 13:07:08 yes, I'm happy that new folks showed up :) 13:07:44 not much change from last week, so I put a (incomplete) proposal for goals 13:08:15 as not everyone will be at Barcelona Summit, I'd like people to give more thoughts about these goals 13:08:16 thats actually a good topic 13:08:24 I would like to vote the existing 3rd party gates as voting 13:08:27 even before the summit 13:08:38 because last week we merged something that broke the suse ci (probably by accident=) 13:08:40 dirk: that's fine with me 13:08:57 and since we're always testing everything, every other review is currently listed as failed 13:09:25 dirk: let's start by a formal thread on the list, and ask for a vote during next week meeting? 13:09:42 but I agree that if we can, let's do it asap 13:09:45 works for me 13:09:52 well, its just asking the infra guys to set the flag 13:10:05 I guess as a PTL you can just ask :) 13:10:05 dirk, why not, we spoke about voting more then half year ago 13:10:18 #action number80 RFC on list to promote third-party CI as voting gates + schedule vote for next week meeting 13:10:49 IgorYozhikov: I'd like to give time to your MOS CI teammates to participate in the discussion too 13:11:06 but I'm +2 to promote both MOS and SUSE CI 13:11:22 number80, me to 13:11:51 there were not so much issues related to misconfiguration 13:11:59 so let's make them voting 13:12:00 excellent 13:12:10 anything else about goals? 13:12:39 I need to speak with zigo about possibility of co-session 13:13:05 IgorYozhikov: zigo_ answered dirk's email and he said he preferred a separate fishbowl for debian packaging 13:13:13 but he'll join us for our fishbowl 13:13:15 o i c 13:13:26 number80, thanx 13:13:45 what do you think about the minimal cloud goal? 13:14:09 I'd like to focus on small set of services so that we iron out tooling issues 13:14:21 number80, r u about to do packages for core components? 13:14:44 plus horizon 13:15:10 IgorYozhikov: I think that we need a proof of concept, because we may hit limitations in renderspec 13:15:12 nova glance cinder neutron keystone horizon 13:15:16 IgorYozhikov: ack 13:15:42 not sure if you guys saw it, but the sessions are scheduled 13:15:53 dirk, already? 13:15:53 deb and rpm packaging fishbowl is thursday late afternoon 13:15:58 nope, will check 13:16:01 Why can't we try to set it for Newton? 13:16:02 and our work sessions are friday morning 13:16:21 astsmtl: minimal cloud? it's quite late 13:17:00 We can try, and if there is not enough time we will move it to next release. 13:17:02 number80, will this minimal cloud have a some kind of deployment test? 13:17:15 just not only core packages 13:17:33 might be AIO node? 13:18:17 IgorYozhikov: yes, but if we managed to deploy AIO using our packages, multi-node shouldn't be hard 13:18:26 yep 13:19:10 long term - single -> multi -> ha 13:19:18 *nods* 13:19:26 #topic stable/newton branch 13:19:27 not it became more || less clear 4 me 13:19:40 thank you dirk for adding the topic 13:19:47 so I was trying to get everything merged now for cutting stable/newton branch 13:19:59 is there anything that we still want to get in? 13:20:26 otherwise I'd say after the django_openstack_auth fix is in we're branching and then open up for merging all the new stuff that is post-newton 13:20:44 I'd like to have https://review.openstack.org/#/c/343335/ too if possible 13:21:36 dirk: btw, could you explain me how branching is done? 13:21:41 https://review.openstack.org/#/c/374679/ ? 13:22:00 number80: sure 13:22:03 IgorYozhikov: non-essential for newton, but we can backport 13:22:17 number80: we can do that right after the meeting 13:22:26 dirk: ack 13:22:41 anything else on that topic? 13:23:35 no from my side 13:24:02 then, we can move to reviews 13:24:27 #topic packages reviews 13:24:35 https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open 13:24:58 we've got a lot of them now :) 13:25:37 I looked through a couple or them 13:25:37 Yeah, but except the ones mentioned above, they won't be in newton cut :) 13:25:51 fair enough 13:26:17 yep 13:26:22 should we abandon the duplicated ones? 13:26:48 jpena: yes, I'm finishing it right now 13:27:08 Yes, let's have our newcomers focusing on the ones 13:27:34 I was postponing that review for master until we cut newton 13:27:40 so let me suggest one thing: we finish those two reviews 13:27:41 also it will be good if they will come to our irc 13:27:46 branch 13:27:48 and then go forward 13:27:54 dirk: wfm 13:28:05 ++ 13:28:48 after branching anything required could be cherry-picked || back-ported 13:28:53 to stable/newton 13:29:04 *nods* 13:30:29 sound good to me 13:30:40 astsmtl, please check our CI readiness for branching 13:31:38 number80, dirk, and here I have a question 13:32:22 go ahead 13:32:38 if we are going to cut new branches - will be correct to use same dependencies for current young master and releasing stable/newton 13:32:55 or not 13:33:20 considering that g-r has already changed between master and stable/newton, we'll shortly update our local copy too 13:33:41 yeah 13:33:45 I am undecided on that a bit 13:33:59 I am tempted to swtich to requirements/ version and not have copy 13:34:04 I'm asking from perspective of packages set as Requires: 13:34:07 Are we supposed to rebuild all packages on CI right after branching? 13:34:28 dirk: that'd be better indeed 13:34:30 Or we are going to bump release with CR's? 13:35:09 dirk: what do you think about embedding distro overrides files instead and just clone requirements as-is? 13:35:51 astsmtl: I'd recommend that, but you can just fork current repo with existing rpms 13:36:06 repo = binary rpms repo I mean 13:36:34 You recommend rebuild without CR's, right? 13:37:24 no release bump between master and newton AFAIK 13:38:07 number80, just rebuild to separate binary repo || just regenerate from master, right? 13:39:01 i'd say opention 1. 13:39:20 ok :) 13:40:07 let's move to next topic 13:40:25 number80: I am not sure what you mean by distro overrides? 13:40:51 dirk: well, we overrides few stuff in upstream g-r like pytz 13:41:10 RHEL7 has an older pytz than in g-r but with backports 13:41:29 so we override this by providing a separate requirements file 13:43:06 number80: ah, I see 13:43:10 number80, and that is why in rh packages *reqs.txt are deleted during build stage? 13:43:30 number80: do we have already a merge capability in renderspec? 13:43:33 I'm about package specs 13:43:42 e.g. add something like --requirements $foo --requirements $vendor-foo ? 13:43:46 IgorYozhikov: yes, but it's partial answer, some requirements files have optional stuff and it breaks builds if we don't have them 13:43:57 dirk: yes, should be easier to maintain 13:44:20 dirk: yes 13:44:43 I'm not 100% sure, it's by design, but the order matters when you pass requirements files 13:46:17 number80: works for me actually 13:46:26 ack 13:46:31 the main reason I objected to that originally was because we couldn't control when stuff in requirements/ merges 13:46:43 which could break our ci at arbitrary intervals 13:47:03 which is why I wanted to have a copy that we can test and then merge 13:47:42 that was the most sensible decision, we needed to get our CI maturing before adding more entropy 13:48:23 well, the funny part is that the fuel ci isn't using it :) 13:48:46 Yep 13:49:10 (/me suggests to move to the next topics before we run out of time) 13:49:20 I'm skipping pymod2pkg as there's no review 13:49:31 #topic renderspec reviews 13:49:33 https://review.openstack.org/#/q/project:openstack/renderspec+status:open 13:49:49 here, I'd like to hear the Mirantis opinion on https://review.openstack.org/370906 13:49:55 https://review.openstack.org/#/c/368262/1 is no brainer 13:50:17 I see it's merged now, and my plan was to add the block to every spec file, so we can fix the requirement issues in RDO builds 13:50:43 yay 13:51:02 when discussing it with jruzicka, he mentioned that if that's an issue we can have a 3rd flavor (suse,fedora,mos) 13:51:08 jpena: most MOS packages respect this pattern too 13:51:30 number80: ack then, just wanted to be on the safe side 13:51:35 but yes, having a mos flavor is always an option 13:52:12 IgorYozhikov: ^ 13:52:13 TBH, I don't understand the need to remove requirements.txt. Only pip performs automatic installation of dependepncies. 13:52:13 yup let's keep it together until explicit reason to split emerges 13:52:55 astsmtl, due to magicks of pbr, the requirements are passed as install_requires 13:52:55 astsmtl: if you keep it around, pbr will try to install whatever is in requirements even optional stuff or update versions if package version is lower 13:53:04 (Also pbr can be installed automatically, but it's a strong requirement anyway.) 13:53:12 jpena, use 1 #!/usr/bin/python 13:53:12 2 # This script is used for additional checks for versions of dependencies. 13:53:12 3 13:53:12 4 import sys 13:53:12 5 from pkg_resources import require 13:53:15 6 13:53:16 which means that the app will refuse to launch because arbitrary version comparision fails 13:53:17 7 13:53:19 8 def test_check_requirements_conflicts(req): 13:53:21 9 try: 13:53:23 10 require(req) 13:53:25 11 except Exception as e: 13:53:26 dude 13:53:27 12 print str(e) 13:53:29 13 exit(1) 13:53:31 14 13:53:33 15 test_check_requirements_conflicts(sys.argv[1]) 13:53:40 if deletion of reqs.txt will not affect this test - looks fine 13:53:52 since koji has no internet access (a prerequisite for reproducible builds), builds will fail as pip can't download eggs from the internet 13:54:21 IgorYozhikov: it shouldn't fail 13:54:37 * dirk has to run 13:54:42 jruzicka, number80 Never saw this. 13:54:43 astsmtl, IOW deleting reqs.txt stops version enforcing through python version 13:54:44 number80: I'll ping you in a bit regarding the branching 13:55:00 since that's package manager job, we disable it 13:55:06 number80, we run this test in package post install stage 13:55:08 dirk: ack 13:55:34 astsmtl: that's very common issue in python packaging for Fedora/CentOS and friends 13:55:34 and test shows us if something went wrong from perspective of python 13:55:49 Version enforcing is another case, and here you can remove requirements.txt but you can also patch it. 13:55:54 ack 13:55:59 out of time 13:56:48 astsmtl: patching it is a possibility, but it has drawbacks too 13:56:59 its redundant 13:57:06 number80, just try to python setup.py {build,install} anything where there are missing dependencies. Nothing is downloaded. 13:57:07 but as jruzicka pointed out, let's move the discussion to the usual channel 13:57:09 we already have dependency management in our package manager 13:57:37 astsmtl: I have failed builds in koji that says the contrary 13:57:54 Please, show me. 13:57:57 you can tell pbr not to download anything 13:58:07 but the version enforcing still continues 13:58:08 jruzicka: interesting 13:58:25 astsmtl: can we continue the discussion on the list? 13:58:33 Ofc. 13:58:57 we're running out of time 13:59:12 thank you for attending, and see you next week (or in the channel) 13:59:22 #endmeeting