13:00:49 <jpena> #startmeeting rpm_packaging 13:00:50 <openstack> Meeting started Wed May 9 13:00:49 2018 UTC and is due to finish in 60 minutes. The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:53 <openstack> The meeting name has been set to 'rpm_packaging' 13:00:54 <jpena> ping toabctl, dirk, apevec, aplanas, IgorYozhikov, jpena, jruzicka, number80, kaslcrof, ykarel 13:01:03 <jpena> Remember to add items to the agenda: https://etherpad.openstack.org/p/openstack-rpm-packaging 13:01:25 <jruzicka> o/ 13:01:31 <jpena> #chair jruzicka 13:01:31 <openstack> Current chairs: jpena jruzicka 13:01:47 <toabctl> hi 13:01:57 <jpena> #chair toabctl 13:01:57 <openstack> Current chairs: jpena jruzicka toabctl 13:03:29 <toabctl> jpena, I don't have topics for today 13:03:57 <jpena> #topic Reviews 13:04:05 <jpena> we have a couple reviews to look after 13:04:42 <jpena> https://review.openstack.org/555906 (cinder) and https://review.openstack.org/566856 (keystone) 13:05:02 <jpena> I'll go through some other reviews, I see we have several for master 13:05:10 <toabctl> ok. me too 13:05:19 <toabctl> and I'll package python-zunclient which is now neede for mistral 13:06:19 <jpena> good 13:09:06 <jpena> #topic open floor 13:09:41 <jruzicka> I see renderspec templating continue to work well... nice :) 13:09:42 <toabctl> jpena, I'll be out for 3 month 13:10:14 <toabctl> I might join next week but after that, don't expect me to do anything until 22.8. 13:10:28 <jpena> toabctl: wow, that's a long holiday :) 13:10:32 <jruzicka> toabctl, whoa, brutal holiday 13:10:35 <toabctl> jpena, parental leave 13:10:44 <jpena> ah, congratulations then 13:10:45 <jruzicka> I was starting to figure that out :) 13:10:53 <toabctl> thx :) 13:10:59 <toabctl> so not exactly holidays ;) 13:11:17 <jruzicka> toabctl, right, but not regular work either ;) 13:11:25 <jruzicka> enjoy the beginning of new cycle ;) 13:11:47 <toabctl> sure. and having a break from all that crazy computer stuff is not bad tbh :) 13:12:11 <toabctl> anyway - just wanted to mention it so you don't wonder where I am 13:12:14 <jruzicka> it feels like unplugging a cable from spine to me ;) 13:12:20 <jruzicka> change is always good 13:13:03 <ykarel_> o/ 13:13:10 <jruzicka> toabctl, thanks for the info 13:13:44 <jpena> anything else to discuss? 13:14:03 <toabctl> not from my side 13:14:33 <openstackgerrit> Merged openstack/rpm-packaging master: Remove unnecessary BRs for keystone https://review.openstack.org/566856 13:14:33 <openstackgerrit> Merged openstack/rpm-packaging master: Update reno to 2.9.1 https://review.openstack.org/566024 13:14:40 <ykarel> can i get some eyes on https://review.openstack.org/#/c/566310/ 13:15:04 <ykarel> starting to use singlespec for services ^^ 13:15:44 <jpena> that's a good one. From what I saw, it looks like we'll need some changes in singlespec to make that work (due to not having a main python-glance package), but I'm not fully familiar with the macros 13:17:40 <apevec> or alternative, get rid of macros, let renderspec do all the work 13:17:44 <ykarel> jpena, yup that can be fixed i think, i am working around it locally, will make it cleaner and push 13:18:03 <apevec> I was going to have a closer look at renderspec to see if that's doable 13:18:07 <apevec> jruzicka, ^wdyt 13:18:34 <apevec> jpena, maybe I should write a spec, do we have them for rpm-packaging? 13:18:56 <jpena> apevec: we've never used them afaik 13:19:25 <jruzicka> apevec, I personally dislike macros as they are distro specific and hard to distribute 13:19:43 <apevec> ok, then maybe just some docs with use-story description in the repo? 13:20:06 <jruzicka> apevec, I personally would try to have everything in generic platform independent renderspec, but I'm not a big packager so I don't get to see the advantages of macros 13:21:12 <ykarel> if we can go backward, with what bring both renderspec and macros to do the job, may be pros, cons are already known for it 13:21:13 <apevec> I think singlespec macros is just what suse already had and for suse renderspec would still spit them in the output .spec 13:21:16 <jpena> apevec: we have some more of that in https://github.com/openstack/renderspec/blob/master/doc/source/usage.rst 13:21:49 <apevec> jpena, ok, so I'll try to push my thoughts as a review there 13:22:20 <jruzicka> apevec, sounds good, tag me as a reviewer. I need to start monitoring upstream gerrit again... 13:22:30 <toabctl> apevec, imo the question is really if we want to have a python2 *and* python3 version for services 13:23:19 <toabctl> dirk and me tried to exercise it with cinder as example here: https://etherpad.openstack.org/p/openstack-rpm-packaging-singlespec-services 13:24:42 * jruzicka needs to run errands before another meeting, will read backlog later 13:25:41 <toabctl> so independent of macros vs. renderspec vs. something else, which binary packages would you expect from cinder (or any other service) that supports python2 and python3 ? 13:26:02 <toabctl> and what is the usecase of having eg. openstack-cinder-volume-py2 and openstack-cinder-volume-py3 ? 13:26:02 <apevec> we need py3 only for services 13:26:18 <toabctl> apevec, yes. so we can just package the services for python3 :) 13:26:54 <ykarel> but in rocky don't we need python2? 13:26:58 <openstackgerrit> Merged openstack/rpm-packaging master: [keystone] Switch to stestr https://review.openstack.org/566941 13:27:26 <toabctl> ykarel, I would say it's 13:27:48 <toabctl> up to us what we want. it would be nice to have python2 and python3, but if we only provide python3, fine with me 13:28:53 <openstackgerrit> Thomas Bechtold proposed openstack/rpm-packaging master: python-zunclient: Initial packaging https://review.openstack.org/567220 13:30:34 <ykarel> hmm, seeing the current case of singlespec, there is some work needed to get it work for services, 13:30:54 <ykarel> but not sure how to get python3 run on rhel7/centos7 13:31:34 <ykarel> and yes getting only python3 would be cleaner and easier 13:31:38 <ykarel> apevec, ^^ 13:32:52 <ykarel> who all are consumers of the packages generated from rpm-packaging? 13:34:00 <ykarel> if those do not need py2 versions we can get rid of it 13:36:06 <jpena> afaik, our packages are used by SUSE, and just openstack-macros by RDO (with plans to expand that) 13:37:39 <ykarel> Do SUSE needs py2 version? 13:37:40 <toabctl> ykarel, SUSE uses the libs and the client packages. but not the services currently 13:37:58 <toabctl> ykarel, for the clients and libs, currently yes. but having the service py3 only would be ok 13:38:37 <ykarel> toabctl, Ok, so we can go with py3 only spec, not depending on singlespec, right? 13:46:59 <toabctl> yes 13:47:58 <ykarel> toabctl, Ok Thanks. I will focus on it from tomorrow. Already seeing some issues with py3 packages, but those can be fixed 13:49:02 <jpena> #agreed focus on py3 for services 13:49:14 <jpena> Any other topic to discuss? 13:50:03 * ykarel nothing from my side 13:50:37 <jpena> ok, let's get 10 minutes back, then 13:50:40 <jpena> #endmeeting