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