13:00:08 <dirk> #startmeeting rpm_packaging
13:00:09 <openstack> Meeting started Thu Apr 21 13:00:08 2016 UTC and is due to finish in 60 minutes.  The chair is dirk. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:13 <openstack> The meeting name has been set to 'rpm_packaging'
13:00:33 <dirk> all, please add your meeting topics to https://etherpad.openstack.org/p/openstack-rpm-packaging#
13:02:12 <dirk> mordred: ping?
13:02:28 <toabctl> hi
13:02:51 <mordred> I didn't do it
13:04:39 <dirk> mordred: have some time to discuss the fishbowl session about the rpm&deb packaging?
13:04:56 <mordred> absolutely
13:05:44 <IgorYozhikov> o/
13:05:45 <dirk> great
13:06:06 <mordred> dirk: one of the main things I'd like to talk about is the conceptual difference between packages intended to be uploaded to distros and packages that openstack itself might publish
13:06:30 <dirk> #topic  Fishbowl session (Design summit track)
13:06:41 <mordred> which is a touchy topic for some folks, so possibly a good one for when we can all see each others faces
13:07:01 <dirk> mordred: yeah, a good topic
13:07:36 <dirk> mordred: can you add it to the therpad for the session ?
13:07:40 <dirk> mordred: https://etherpad.openstack.org/p/newton-cross-distro-packaging-discussion
13:07:43 <dirk> #link https://etherpad.openstack.org/p/newton-cross-distro-packaging-discussion
13:07:48 <mordred> and I _think_ (but I might be wrong) that it would be nice if rpms and debs that openstack publishes itself behave similarly, even if the ones we'd upload to the distros might need to be different
13:07:49 <mordred> yup. on eit
13:08:20 <dirk> mordred: I think I sent you a mail about that a few days ago .. would be good if we could somehow structure the fishbowl session topics before it happens
13:08:42 <dirk> mordred: I have an opinion about that :-)
13:09:26 <dirk> mordred: publishing binaries hasn't been a primary focus for the current openstack (rpm) packaging, but I agree it is the next step to take
13:09:39 <dirk> right now we've been mostly busy with building up a relevant code base to make this somewhat useful
13:10:02 <dirk> mordred: I agree with you that we need to have a "standard" binary repo published soemwhere on openstack.org for people to use
13:10:20 <dirk> it is not so simple though if you look into the details
13:10:31 <mordred> yah. I think people will find it useful - although we should also talk about what we are and aren't committing to for people
13:10:34 <mordred> exactly
13:10:54 <dirk> well, having it useful for people is the 2nd step
13:10:57 <mordred> turns out last time we published packages in a repo called "do-not-use" people still used them in production and then filed bugs
13:11:11 <dirk> I think where it would primarily help is adding test coverage for the various config management flavors
13:11:34 <dirk> e.g. it would be a great step forward if changes to ansible,salt,chef,puppet and what not are gated automatically against the "common" openstack packages
13:11:40 <dirk> in a functional/integration test
13:11:47 <mordred> totally agree
13:12:03 <IgorYozhikov> mordred, dirk, agree here, and the question here is - packages for which distros are going to be published ?
13:12:09 <dirk> I'd like to start the discussion around that on the design summit
13:12:30 <dirk> mordred: who else do we need to pull into that ? I guess a few from the infra team?
13:12:54 <dirk> IgorYozhikov: for me it would make sense to not only publish one set of packages but packages for each distro flavor
13:13:11 <dirk> with the renderspec layer we have all the tooling to do that seamlessly
13:13:24 <dirk> but I think I heard mordred  say that he disagrees with that idea ;)
13:13:35 <IgorYozhikov> dirk, I'm about the same
13:13:36 <dirk> there was quite often brought up the topic that there should be only one package
13:14:46 <toabctl> but we already realized that this doesn't work for the rpm world and that's why we have renderspec. just think i.e. about the epoch handling....
13:14:46 <IgorYozhikov> package with a lot of if enif?
13:15:38 <mordred> dirk: wait - which thing do I disagree with?
13:15:56 <dirk> mordred: sorry, I wasn't serious
13:16:00 <mordred> ah. phew
13:16:02 <mordred> :)
13:16:17 <dirk> mordred: the topic on whether there should be only one set of binary packages rather than the "distro flavored" versions of binary packages
13:16:46 <mordred> I kinda think "both" :)
13:16:52 <dirk> I read that out of the topic that you added to the design summit session
13:17:08 <dirk> imho the goal should be that there is absolutely no difference between the packages that openstack publsihes and that downstream distros sue
13:17:24 <mordred> wel.... so that's one of the things I think would be useful to talk about
13:17:29 <dirk> which is why we're trying to get on a common packaging level (plus the abstraction to fulfill downstream packaging policies)
13:17:37 <mordred> because downstream distros have policies on how packages should work
13:17:45 <mordred> which are great, beause the primary output is a consistent distro
13:18:20 <mordred> but for a thing like openstack, some of them, like he debian policy that services should run when you've installed the package - don't make sense ina 100 node deploy using config management
13:19:27 <mordred> so if we can publish, as openstack packages that are friendly to and assume config management, and then figure out how to layer on the extra things that distros need for the distro uploads, _I_ think that would be neat. but other people might totally disagree and I might be wrong
13:20:24 <IgorYozhikov> mordred, if use debian frontend non-interactive - all cinf files will be installed as is
13:20:58 <IgorYozhikov> and could be adjusted by any of configuration management tool
13:21:25 <IgorYozhikov> s/cinf/conf/
13:23:03 <mordred> IgorYozhikov: yes indeed.
13:24:06 <dirk> mordred: well, at least for the SUSE (downstream) packaging  config management friendliness is a must
13:24:19 <mordred> good
13:24:21 <dirk> I'd agree that we should aim for the saim goal in the openstack common rpm packaging
13:24:30 <dirk> s,saim,same,
13:24:56 <dirk> its only getting difficult when we have to do something different in order to fulfill downstream policies
13:25:11 <dirk> because right now the goal is to also have downstream-compatible spec files
13:25:12 <mordred> yah- hopefully so that the only disto-differences as it relates to openstack itself in an install guide are "yum install nova-server" or "apt-get install nova-server" and the rest of the guide should pretty much be the exact same
13:25:25 <mordred> dirk: yah. that's the hard part :)
13:25:41 <dirk> mordred: well, thats why it s good that we have all the relevant people at the summit :-)
13:25:51 <mordred> ++
13:25:55 <IgorYozhikov> yey
13:26:12 <dirk> anything else on that topic? does anyone want to add more stuff to the etherpad for the fishbowl?
13:26:20 <mordred> dirk: do you happen to know the time of the session? I find the schedule very hard to use and want to make sure I don't miss it
13:26:23 <dirk> I think we need to add some more text around the agenda items
13:26:31 <dirk> mordred: thursday something
13:26:32 <dirk> second
13:26:50 <dirk> 2016-04-28 - 11:50
13:27:11 <IgorYozhikov> dirk, I will try to add some text during this weekend
13:27:39 <dirk> #link https://www.openstack.org/summit/austin-2016/summit-schedule/events/9181
13:28:00 <mordred> woot! thanks!
13:28:13 <mordred> and good. it's already on my calendar. I must have found it before
13:28:33 <IgorYozhikov> also, as i mentioned before - we already publish produces from J2 and vanilla code packages - here http://packages.fuel-infra.org/rpm-packaging/master/centos7/os/x86_64/
13:28:42 <IgorYozhikov> repo is 4 CentOS7
13:28:58 <dirk> mordred: well, hopefully it is. aren't you PTL'ing the deb packaging? :)
13:29:08 <mordred> dirk: that's what they tell me :)
13:29:18 <dirk> thats what they told me ;)
13:29:43 <dirk> IgorYozhikov: thank you. I'll also try my best to make it sensible but I guess I'll only get to it somewhen next week
13:30:00 <dirk> can we move on on this topic?
13:30:21 <IgorYozhikov> ok, anyway will meet there
13:30:48 <dirk> #topic AIs review(IgorYozhikov)
13:31:34 <IgorYozhikov> AI 1 - https://wiki.openstack.org/wiki/Rpm-packaging/ContentStyle
13:33:17 <dirk> IgorYozhikov: thanks. this is still with the 1 space between "BuildRequires:" and the value?
13:34:02 <IgorYozhikov> dirk, thanx, will fix it now
13:34:11 <IgorYozhikov> 2 spaces & 2 \n
13:35:02 <IgorYozhikov> AI 2 - AI 2 - https://review.openstack.org/#/c/306556/ - but it is very strange that SUSE CI doesn't reacts on this PR
13:37:16 <dirk> IgorYozhikov: looks like zuul is broken again
13:39:03 <IgorYozhikov> dirk, got it, will you merge this PR or will wait for mark from your zuul when it will get back on-line?
13:40:09 <dirk> IgorYozhikov: I've just kicked it, it started now
13:40:17 <IgorYozhikov> cool
13:40:29 <dirk> at some point I need to understand why this happens :(
13:40:38 <dirk> after a while its just stuck and does nothing
13:40:39 <IgorYozhikov> o i c
13:41:03 <dirk> next AI ?
13:41:20 <dirk> AI dirk  merge https://review.openstack.org/#/c/306556/ once gating checks pass
13:41:24 <dirk> #AI dirk  merge https://review.openstack.org/#/c/306556/ once gating checks pass
13:41:32 <dirk> #action dirk  merge https://review.openstack.org/#/c/306556/ once gating checks pass
13:41:37 * dirk never remembers the right command
13:41:53 <IgorYozhikov> :)
13:43:00 <toabctl> :)
13:43:32 <IgorYozhikov> We have a postponed topic from previous meeting
13:44:17 <IgorYozhikov> of course if we finished with AIs review.
13:45:50 <IgorYozhikov> dirk, could we raise it and discuss ( Using all DB backends within project template as runt-time dependencies)?
13:46:53 <dirk> IgorYozhikov: sure
13:46:59 <dirk> #topic Using all DB backends within project template as runt-time dependencies)
13:47:11 <dirk> I think this was a discussion between toabctl  and you, right?
13:47:43 <IgorYozhikov> ok, a week I raised this question.
13:48:10 <IgorYozhikov> toabctl, you should remember this case with oslo.db
13:49:36 <IgorYozhikov> and the question here: should we add all supported DB backends as run-time dependencies or create a sub-package to handle this situation
13:50:40 <IgorYozhikov> adding of all supported db backends increase amount of dependencies for a particular root project
13:52:10 <toabctl> ah. yes. so we could create a python-oslo.db-postgres package i.e.
13:52:23 <toabctl> which depends on python-oslo.db and also on python-psychopg2
13:52:27 <toabctl> same for mysql
13:52:32 <IgorYozhikov> otherwise if project support postgresql and mysql but mysql was chosen - as default db, our package will install all bindings even which never will be used
13:53:11 <IgorYozhikov> toabctl, yes like sub-package with proper bindings
13:53:13 <toabctl> but not adding any of the dependencies make the package useless imo. so I'm for subpackages or adding all useful deps
13:54:09 <toabctl> dirk: any opinion on that topic? or number80 ?
13:54:18 <IgorYozhikov> so 2 ways: 1 - easier, but heavier from perspective of amount of installed code
13:54:21 <IgorYozhikov> 2
13:54:37 <IgorYozhikov> more flexible
13:54:44 <number80> toabctl: have every package depending on oslo.db
13:55:04 <number80> and oslo.db depends on all pure-python backends
13:55:31 <number80> pure python modules have little to no deps, so adding them is cheap
13:55:39 <toabctl> number80: yeah. also fine for me. I think that's what I suggested during the review iirc
13:56:24 <number80> *nods*
13:57:09 <IgorYozhikov> I'm fine with both approaches, just want that we all agree on something and I'll reflect it in wiki
13:57:16 <dirk> well, even python-PyMySQL is an extra dep that isn't needed if you don't use mysql
13:57:38 <dirk> is there something like Supplements: packageand(postgresql:python-oslo.db) in other distros?
13:59:23 <IgorYozhikov> dirk, r u about - http://www.rpm.org/wiki/PackagerDocs/Dependencies#Weakdependencies
13:59:44 <number80> dirk: Supplements is not supported by older rpm
14:00:16 <dirk> number80: any rpm version you still care about?
14:00:19 <toabctl> number80: do we need to care about older rpm for newton packages?
14:00:26 <dirk> we have that in SUSE for like 5+ years or so
14:00:59 <dirk> number80: at the end of the day its just a small convenience improvement
14:01:14 <dirk> so the plan would be a python-oslo.db-$dbflavor subpackage that is supplementing the related db
14:01:24 <dirk> and that has the correct dependencies
14:01:38 <dirk> if the supplements doesn#t work well then the distro has to install the package manually
14:03:03 <IgorYozhikov> looks like a plan, need to check how it is work
14:03:22 <IgorYozhikov> just never used supplements before
14:04:28 <dirk> IgorYozhikov: short summary is "this package is recommended ot be installed if both package A and B are already installed"
14:04:42 <dirk> in the case of %package foo\nSupplements: packageand(A:B)
14:05:08 <number80> dirk: doesn't fit well with the approach of people installing/setting up manually openstack
14:05:14 <dirk> so you can say things like "I need the python-oslo-db.postgresql package if python-oslo.db is getting installed and postgresql is installed"
14:05:33 <dirk> number80: hmm, how so? not sure I can follow
14:05:46 <dirk> Oh, we're overtime, can we movet he discussion to rpm-packaging channel?
14:05:48 <dirk> #endmeeting