12:33:35 <toabctl> #startmeeting rpm_packaging
12:33:36 <openstack> Meeting started Wed Aug 14 12:33:35 2019 UTC and is due to finish in 60 minutes.  The chair is toabctl. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:33:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:33:39 <openstack> The meeting name has been set to 'rpm_packaging'
12:33:42 <toabctl> ping toabctl, dirk, apevec, jpena, jruzicka, number80, kaslcrof, cmurphy
12:33:51 <toabctl> #chair cmurphy jpena dirk toabctl
12:33:51 <openstack> Current chairs: cmurphy dirk jpena toabctl
12:34:05 <jpena> o/
12:34:09 <toabctl> as usual, please add your agenda points to https://etherpad.openstack.org/p/openstack-rpm-packaging
12:34:45 <dirk> o/
12:36:19 <toabctl> ok. let's start
12:36:21 <toabctl> #topic network-l2gateway packaging
12:36:25 <toabctl> dirk, ^^ ?
12:39:02 <dirk> https://review.opendev.org/#/c/668895/ last comment
12:39:22 <dirk> I think since this is a service the package naming should follow openstack-neutron-l2gw with a python3-neutron-l2gw subpackage
12:39:30 <dirk> but Jaime is of different opinion. any comments?
12:41:12 <toabctl> dirk, I would also prefer to have a openstack-neutron-l2gw package
12:41:46 <jpena> the networking-generic-switch and networking-vsphere packages, are they named python-* or openstack-* ?
12:42:01 <jpena> in the RDO side, the convention is python-networking-*
12:43:58 <toabctl> SingleRule('networking-vsphere', 'openstack-neutron-vsphere'),
12:44:27 <toabctl> ^^ from pymod2pkg for both (suse & rdo)
12:47:58 <jpena> generic-switch has no rule, so it defaults to python-networking-*
12:48:11 <toabctl> yeah. I guess that would be the first thing to fix
12:48:29 <toabctl> but then still the question about a subpackage. and I would prefer one
12:48:43 <toabctl> jpena, so do the other rules need fixing for rdo then I guess?
12:48:51 <jpena> toabctl: yes, I just realized
12:49:27 <toabctl> jpena, in rdo, do you have subpackages for the network packages?
12:49:35 <toabctl> eg. when an extra agent is there?
12:50:46 <jpena> for networking-l2gw, yes, we do
12:51:04 <jpena> the main package is python-networking-l2gw, then we have openstack-l2gw-agent for the agent itself
12:51:26 <jpena> see https://github.com/rdo-packages/networking-l2gw-distgit/blob/rpm-master/python-networking-l2gw.spec#L95-L101, for example
12:54:20 <toabctl> hm. ok. dirk is suggesting a different naming if I understand him correctly
12:55:40 <dirk> well, since its python 3, I would suggest to call it python3
12:55:45 <dirk> I am not sure what should be the main package
12:55:57 <dirk> for me the main package probably should be openstack-network*
12:56:00 <dirk> but I'm open to suggestions
12:56:46 <dirk> its just more consistent to like e.g. cinder nova etc
12:58:55 <toabctl> for vsphere we have openstack-neutron-vsphere currently
12:59:18 <toabctl> but we also have python-networking-generic-switch
13:01:29 <toabctl> I think having neutron in the package name would be good (given that this is all neutron related)
13:02:37 <toabctl> but given that RDO is having a subpackage like openstack-l2gw-agent, I wonder how we can handle this with pymod2pkg. I guess we need to hardcode the package names in a %if %else in the .spec file ....
13:05:36 <dirk> jpena: so in RDO, do you still call the python 3.x version of the package python-networking?
13:05:53 <dirk> to be honest I think the way RDO names it is useful input, but what would make sense for us?
13:05:56 <jpena> dirk: no, the spec name is python-networking, but the package itself is python3-networking
13:06:06 <dirk> so the main package name you mean?
13:06:11 <dirk> or the subpackage?
13:06:53 <toabctl> main package is python-%{pypi_name}
13:06:58 <toabctl> see https://github.com/rdo-packages/networking-l2gw-distgit/blob/rpm-master/python-networking-l2gw.spec#L25
13:07:12 <jpena> in the spec we have Name: python-networking-xxx, but there is no package with that name, then we have %package -n python3-networkinx-xxx
13:07:36 <jpena> so there's no main package (at least, not in rpm format)
13:08:11 <dirk> I see
13:08:20 <dirk> but there is also a subpackage called openstack-something-agent ?
13:08:26 <dirk> why not make that subpackage the main package?
13:09:28 <jpena> in this case, there is that subpackage
13:09:47 <jpena> we choose not to do so for consistency with the rest of the networking-* packages, which are all python-networking-x
13:11:32 <dirk> okay, so it sounds like we have a way forward
13:11:52 <dirk> spec.j2 will be called after pypi name, as usual. main package can be then either mapped by pymod2pkg
13:12:06 <dirk> we'll add a subpackage agent and python3-*
13:12:10 <dirk> makes sense?
13:12:21 <toabctl> how do we call the main package?
13:12:39 <dirk> it would then be python-networking-l2gw-agent for fedora rendering of the spec file and openstack-something-l2gw-agent for suse
13:12:50 <dirk> (something being neutron or networking, don't care atm)
13:13:06 <toabctl> ^^ that would be the subpackage name for the agent
13:13:46 <jpena> ok for me
13:14:42 <toabctl> works for me, too
13:14:58 <cmurphy> +1
13:16:53 <toabctl> I think we can comment then on the updated PR
13:17:00 <toabctl> dirk, does that work for you?
13:17:04 <toabctl> ready for the next topic?
13:17:05 <dirk> sure
13:17:07 <dirk> yes
13:17:13 <dirk> sorry, was already talking to Jaime
13:17:22 <toabctl> even better :)
13:17:24 <toabctl> #topic Shanghai project update - does anybody want to do it?
13:17:56 <toabctl> I was asked by mail from Kendall about a project update
13:18:08 <toabctl> is somebody at the summit who could/want to give an update?
13:18:26 <dirk> I'm not
13:18:52 <toabctl> btw. I missed already the question from kendall about PTG attendance :( . I'm sorry for that...
13:18:58 <toabctl> cmurphy, jpena ? are you going?
13:19:04 <jpena> no, I won't be there
13:19:05 <toabctl> and want to give an update there?
13:19:17 <cmurphy> i will probably be going
13:19:20 <toabctl> I guess cmurphy will go but might be busy with keystone...
13:19:24 <cmurphy> not much has changed since the last update though
13:19:29 <toabctl> true
13:19:49 <dirk> we'll add containers ;)
13:21:21 <toabctl> cmurphy, if you want to do the update/status presentation, just ping me. I would need to fill out a form for that
13:21:50 <cmurphy> i don't particularly want to but i can if you guys think it would be worthwhile
13:22:29 <toabctl> I don't know. I have not attended any summit in the last 2 years. no idea how that it nowadays and if it makes sense
13:23:12 <dirk> project updates do make sense
13:25:38 <cmurphy> okay, i can do the update
13:26:37 <dirk> cmurphy++++
13:27:01 <dirk> I suggest we brainstorm an hour on so on the content, and then reply back to kendall
13:27:08 <dirk> if thats in the timeline that kendall expects
13:27:15 <dirk> if we don't have worthwhile content, we scratch it
13:27:31 <toabctl> there are 40 slots - it's  first come, first served
13:27:43 <dirk> I do expect that we might have a couple of folks that contributed so far actually attend this time around
13:27:50 <dirk> so it would be a shame to drop out of it
13:27:55 <dirk> toabctl: yes, 40 slots is a lot
13:27:58 <toabctl> ah. true. good point!
13:28:36 <dirk> we could always join requirements with rpm-pacakging in one slot, both are typically half a halfslot
13:28:37 <toabctl> and cmurphy must confirm that she attends the summit (by mailing to knelson by sunday, 29th september)
13:28:52 <cmurphy> i already confirmed for the keystone slot
13:28:58 <toabctl> ok
13:29:53 <toabctl> ok. so let's do the brainstorming and then we decide
13:30:09 <toabctl> #topic https://review.opendev.org/671573
13:30:12 <toabctl> ^^ dirk? yours?
13:30:16 <jpena> no, it's mine
13:30:20 <jpena> just a quick question about it
13:30:21 <toabctl> oh. sorry
13:30:47 <jpena> should we remove the -common subpackage? I'm fine with it, just want to make sure we all agree, since it was added very recently
13:30:59 <dirk> yeah, I noticed this collission recently
13:31:09 <dirk> I was always planning to switch it to python3 only, but tom was faster with singlespec
13:31:22 <toabctl> yes. it should be removed given that we switch to py3 only
13:31:54 <toabctl> and I'm fine with not adding the Provides/replaces given that we never released a py2/py3 version of the package.
13:31:56 <dirk> how did you manage to workaround the zeroconf problem with the singlespec switch?
13:32:02 <dirk> I was confused about how that passed testing
13:32:14 <jpena> it kept failing for RDO
13:32:23 <jpena> once I moved it to python3 only, it worked fine
13:32:33 <dirk> yeah, should be the same for SUSE
13:32:37 <dirk> there is no python2 version of zeroconf anymore
13:32:47 <dirk> anyway, I'll update the review
13:32:58 <toabctl> dirk, it was passing: https://review.opendev.org/#/c/675366/
13:33:26 <toabctl> maybe the py3only zeroconf switch was afterwards?
13:33:27 <dirk> ah, your review didn't have buildrequires on zeroconf
13:33:34 <dirk> very sneaky, so the package never worked :-)
13:33:44 <toabctl> the python3 did :)
13:33:58 <dirk> no, its been that way for many weeks (at least until my review which was older iirc than yours)
13:35:00 <openstackgerrit> Dirk Mueller proposed openstack/rpm-packaging master: ironic-lib: switch to python3  https://review.opendev.org/671573
13:35:06 <dirk> anything else?
13:35:12 <toabctl> back to the question - I think we agreed on removing the common-package, right?
13:35:27 <toabctl> we are running out of time..
13:35:39 <toabctl> #topic open floor
13:36:20 <toabctl> I have still a question about building containers based on the packages - for that we would not need systemd, logrotate, ...
13:36:31 <dirk> toabctl: its gone
13:36:41 <dirk> (the common package)
13:36:41 <toabctl> dirk, what is gone?
13:36:47 <toabctl> ah. thx
13:37:27 <toabctl> I wonder if we can move logrotate, user/group creation, systemd files to a subpackage and add it as Recommends: to the main package
13:37:38 <toabctl> then we could disable recommends when building containers.
13:37:51 <dirk> why is installing just python3-$foo not enough for container builds? what is missing?
13:38:15 <toabctl> dirk the /usr/bin files that are in eg openstack-nova-api
13:38:37 <toabctl> config files (policy, rootwrap, ...) that are in eg. openstack-nova
13:38:55 <dirk> those are not supposed to be insidet he container?
13:38:59 <dirk> they come from the chart
13:39:09 <toabctl> not all I think
13:39:14 <dirk> entry points is a problem. I agree. we maybe should have all entry points in a subpackage
13:39:28 <dirk> maybe something liek openstack-nova-tools that we also install in container?
13:39:42 <toabctl> api-paste.ini
13:39:55 <dirk> thats coming from the chart
13:39:55 <toabctl> what would be in openstack-nova-tools?
13:40:17 <dirk> nova-manage nova status etc
13:40:21 <toabctl> the /usr/bin files are not in python3-nova .
13:40:35 <toabctl> nova-compute? also openstack-nova-tools ?
13:40:56 <toabctl> then the question would be, why we have all theses openstack-nova-$service subpackages...
13:41:25 <dirk> only for systemd based deployments
13:41:28 <toabctl> openstack-nova-compute has also a polkit file, a modules-load.d file....
13:41:29 <dirk> e.g. OS containers and friends
13:42:41 <toabctl> so where would be /usr/bin/nova-compute ?
13:44:33 <dirk> hmm
13:45:24 <dirk> maybe we can change teh thing to call to python -m nova.cmd.compute instead?
13:45:29 <dirk> and then don't care about the wrapper script?
13:46:26 <toabctl> hm. doesnt' sound very nice imo...
13:47:15 <dirk> yeah, agree
13:47:20 <dirk> I need to think a bit about it
13:47:39 <dirk> wrap it up for today? looks like its only you and me talking ;)
13:47:53 <toabctl> oki :)
13:47:58 <toabctl> thanks for attending
13:47:59 <toabctl> #endmeeting