12:59:58 <dirk> #startmeeting rpm_packaging
12:59:59 <openstack> Meeting started Thu Sep 15 12:59:58 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:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:02 <openstack> The meeting name has been set to 'rpm_packaging'
13:00:03 <dirk> ping dirk toabctl IgorYozhikov number80 jruzicka
13:00:08 <number80> awesome!
13:00:10 <number80> o/
13:00:13 <dirk> #chair IgorYozhikov  number80
13:00:14 <openstack> Current chairs: IgorYozhikov dirk number80
13:00:16 <jruzicka> o/
13:00:22 <dirk> #topic roll call
13:00:27 <number80> o/
13:00:42 <number80> #chair jruzicka
13:00:43 <openstack> Current chairs: IgorYozhikov dirk jruzicka number80
13:00:49 <dirk> please update / add agenda items to
13:00:56 <dirk> #link https://etherpad.openstack.org/p/openstack-rpm-packaging
13:01:05 <dirk> toabctl is on vacation this week
13:01:08 <jpena|lunch> o/
13:02:23 <number80> #chair jpena
13:02:23 <openstack> Current chairs: IgorYozhikov dirk jpena jruzicka number80
13:06:09 <dirk> #topic PTL for Ocata
13:06:18 <dirk> reminder, this week is PTL self-nomination
13:06:34 <dirk> I haven't checked, did anyone already send a nomination to the list?
13:06:42 <dirk> we need to send one by sunday iirc
13:06:56 <dirk> I can do it one more cycle but am also happy to pass it on
13:07:16 <IgorYozhikov> dirk, no, I didn't send anything yet
13:07:56 <dirk> any questions? :)
13:08:38 <dirk> if there is more than one self-nomation an election will be held amonst the core group
13:08:43 <number80> I will be sending a candidacy
13:09:15 <jruzicka> dramatic! :)
13:09:16 * IgorYozhikov not sure about this cycle, but will think
13:09:28 <dirk> #topic Barcelona Design Summit Fishbowl + Work Sessions
13:09:37 <dirk> So preliminary allocation results are available
13:10:10 <dirk> we have 1 fishbowl (40 min) and 2 work sessions (40 min each) allocated for RPM Packaging
13:10:32 <dirk> I asked in the comments to co-share this with packaging-deb in case there is a need for space/time limitations
13:10:48 <dirk> I am not 100% sure what happened to that comment, I need to clarify
13:11:01 <dirk> #action dirk clarify whether work sessions are co-shared with packaging-deb
13:11:17 <IgorYozhikov> sounds good, dirk, could you post a link for events topics?
13:11:38 <IgorYozhikov> or it is not available now
13:11:40 <dirk> We need to think about fish bowl discussion items and agenda
13:12:14 <number80> I thinking setting Ocata goals should be one of them, and 3rd party CI
13:12:15 <dirk> IgorYozhikov: you mean the conference schedule? I think it isn't done yet (at least thats how I read the email=
13:12:26 <dirk> we could start with an etherpad
13:12:32 <IgorYozhikov> dirk, thanx, got it
13:12:35 <number80> IgorYozhikov: will there be a MOS CI representative in Barcelona?
13:12:58 <IgorYozhikov> number80, not sure, will check who will be there
13:13:10 <IgorYozhikov> right after this meeting
13:13:40 <dirk> I suggest the start the etherpad for ocata once we have clarification whether it is co-located with packaging-deb
13:14:36 <number80> ack
13:14:48 <dirk> I added a small reminder section to the openstack-rpm-packaging etherpad for now
13:14:55 <dirk> any questions?
13:15:05 <number80> for now, it's good
13:15:17 <IgorYozhikov> do we need a separate etherpad for this?
13:15:20 <number80> Yes, a reminder section would be useful for long-running topics
13:15:32 <IgorYozhikov> 4 example https://etherpad.openstack.org/p/rpm-packaging-ocata
13:15:55 <dirk> IgorYozhikov: well, creating an etherpad is "standard" for fishbowl sessions to capture the meeting agenda and meeting minutes (unconference style)
13:16:18 <dirk> I think ocata-* is the common prefix, but I haven't checked (last time it was the airport code which is .. weird)
13:16:46 <dirk> but I didn't want to create an ocata-rpm-packaging yet because it might be ocata-rpm-and-deb-packaging instead :)
13:16:59 <IgorYozhikov> o i c
13:17:16 <number80> yep
13:17:29 <dirk> #topic  Packaging of non-OpenStack hosted OpenStack dependencies (e.g. XStatic-*)
13:17:44 <dirk> a crazy idea I had this morning while reviewing/updating the python-XStatic mess
13:17:56 <dirk> do we want to move those and other things that are only-pypi also to rpm-packaging?
13:18:11 <IgorYozhikov> and here I have a question
13:19:41 <IgorYozhikov> about xstatics - keep embeded js,css,etc inside or, which is more complicated, to use all embed as external packages
13:19:57 <IgorYozhikov> as Requires: jsxxxxxx
13:20:26 <IgorYozhikov> I have such experience - eating a lot of time :(
13:20:58 <IgorYozhikov> and that is why i'm asking if we will decide to package xtatics
13:21:49 <dirk> i'm not 100% sure I get the question, but we just package python-XStatic-<FOO> as one package, all in one
13:22:01 <dirk> (we==SUSE downstream)
13:22:16 <dirk> I guess there is not a lot of distribution difference in there so I'd be happy to move it to rpm-packaging
13:22:28 <IgorYozhikov> dirk, yes, we do the same in MOS
13:22:33 <dirk> I was just wondering whether we want to have those templates under openstack/ directory or under some new toplevel, e.g. pypi/
13:22:58 <IgorYozhikov> we tried to separate them in the past and get back to aio package
13:23:29 <IgorYozhikov> dirk, yes, looks like pypi will be more suitable
13:24:02 <IgorYozhikov> also we can add another projects there not only xtatics in case of necessity
13:24:15 <number80> dirk: I'd say nope for packaging them in this project
13:24:45 <number80> most of them are autogenerated and are not moving fast
13:25:05 <number80> and they also bundle javascript ...
13:25:50 <number80> so we'd be responsible of security updates
13:26:14 <dirk> yeah, shared burden :)
13:26:27 <dirk> well, ok, not strong feeling either way, we can revisit that topic later..
13:26:42 <dirk> #agreed not package non-openstack hosted python deps for now  in common rpm-packaging
13:27:00 <dirk> #topic Support for additional sources (distro specific)
13:27:38 <astsmtl> MOS CI now supports pactching (didn't test it yet :P).
13:28:05 <dirk> great!
13:28:12 <dirk> what can possibly go wrong ;)
13:28:15 <astsmtl> It takes all SourceN and PatchN entries and makes them available from %{_sourcedir}.
13:28:20 <dirk> I did not get to that, I'll look into that.
13:29:01 <IgorYozhikov> dirk, number80 and here I want to ask about systemd unit files
13:29:09 <astsmtl> Now we can use this feature to create pacakges for services which contain many additional sources.
13:29:10 <dirk> astsmtl: I'll adapt SUSE CI then. it shouldn't be difficult, just a tweak somewhere
13:29:17 <astsmtl> Cool.
13:29:41 <astsmtl> The second question is about distro specific files and how to handle them.
13:30:05 <number80> astsmtl: I'd say conditionals
13:30:07 <IgorYozhikov> previously there was concern that unit files will be suitable for SUSE and Fedora
13:30:19 <number80> we can adapt renderspec to hide the irrelevant one
13:31:11 <number80> or we can add a new template macro
13:31:20 <astsmtl> The other option is separate directories and additional logic in CI to take sources from correct directory.
13:31:20 <IgorYozhikov> number80, may be a special context function instead of conditionals?
13:31:52 <IgorYozhikov> like SourceN:  {SOMEVENDOR}/foo.service?
13:32:30 <number80> could work, yes
13:32:30 <IgorYozhikov> and rendespec will substitute SOMEVENDOR with suse || fedora 4 example
13:32:55 <dirk> yeah, I think that was the original idea
13:33:01 <dirk> we didn't implement it yet afaik though
13:33:21 <dirk> I'm not 100% sure it fits into renderspec, as it currently doesn't copy around additional files
13:33:24 <jruzicka> we can make spec-style (==vendor) available in renderspec
13:33:28 <dirk> and we could just do it
13:33:39 <dirk> Source: %{vendor}-openstack-foobar.service
13:33:53 <dirk> and then have rpm expansion do its magic
13:34:10 <astsmtl> Then all files will reside in spec directory.
13:34:27 <dirk> it might fight into renderspec if we want to use jinja2 templating for the sources itself (e.g. a service.j2 that is rendered)
13:34:35 <dirk> astsmtl: yes..
13:35:33 <astsmtl> I prefer separate directories. It requires one variable in context plus a little bit of logic on CI side, which is probably already implemented on our CI.
13:36:28 <number80> quick question, do you have specific guidelines on service files?
13:36:30 <astsmtl> We do it like: if [ -f $source ] ; cp ... ; else curl ... ; fi
13:36:47 <number80> the only one I can think of in RDO is to enforce restart on-failure
13:36:54 <IgorYozhikov> number80, in mos we use mostly centos
13:37:30 <astsmtl> We don't have any guidelines, restarts are welcome.
13:37:45 <jruzicka> separate dirs for dist-specific files sound good to me
13:37:45 <dirk> number80: nice idea, we're not using that yet
13:37:58 <dirk> service files are sort of not our priority anyway since we use pacemaker resources
13:38:04 <dirk> so anything that works is fine
13:38:35 <number80> dirk: yep, pacemaker override package service files
13:39:09 <dirk> astsmtl: works for me as well
13:39:25 <dirk> astsmtl: we would need to implement some lint checker that verifies that for all vendors the same set of files are available
13:39:42 <dirk> hmm, or depending on spec.j2 conditionals.
13:39:47 <astsmtl> Some may be exluded by conditional.
13:40:43 <astsmtl> We can try the following approach: implement package with common sources first, if some debate arises - use distro specific.
13:42:19 <dirk> works for me
13:42:26 <dirk> time to move on?
13:42:29 <astsmtl> dirk, you mentioned using renderspec as rendereverything.
13:42:45 <dirk> astsmtl: yes?
13:43:01 <astsmtl> This is also interesting approach, but I have no firm opinion. :)
13:43:29 <astsmtl> Maybe some else has?
13:43:34 <astsmtl> someone
13:43:36 <jruzicka> more specifically?
13:43:49 <jruzicka> render what else expect specfile?
13:44:05 <astsmtl> Render services like specs.
13:44:11 <jruzicka> From what?
13:44:19 <astsmtl> From service templates.
13:44:23 <jruzicka> Like having .service templates?
13:44:24 <jruzicka> ah
13:44:34 <astsmtl> Wrap all distro specific part in conditinals etc...
13:44:57 * jruzicka thinks
13:45:30 <jruzicka> Trying with common files and making it possile to "fork" into distro specific dirs sounds better I guess
13:45:39 <astsmtl> I think it's more complex, so we should start with what we discussed before.
13:45:52 <astsmtl> Good!
13:45:54 <jruzicka> templating might get complicated when the files diverge too much
13:46:03 <dirk> I suggest the pramatic approach, start with common files only
13:46:10 <dirk> when the need arises, we need to come up with a solution
13:46:11 <IgorYozhikov> agreed on 1st way?
13:46:11 <jruzicka> yes and then extend
13:46:52 <IgorYozhikov> if yes - lets do files 1st
13:47:02 <jruzicka> yup
13:47:07 <astsmtl> #agreed Common sources first, distro specific if need arises.
13:47:15 <IgorYozhikov> cool
13:47:28 <dirk> #topic Discuss mini
13:47:34 <IgorYozhikov> yes
13:47:38 <dirk> #link https://wiki.openstack.org/wiki/Rpm-packaging/packages-bootstrapping
13:47:41 <IgorYozhikov> I'll be quick here
13:48:25 <IgorYozhikov> I just started and want to ask - am I right with why we need to do mini?
13:49:33 <jruzicka> yes, we got problems with unpackaged/fresh test requirements in RDO
13:49:35 <dirk> IgorYozhikov: I would summarize it as "cyclic build requires that need to be tied into pieces for bootstrap"
13:50:03 <jruzicka> way to disable it without nuking sound good
13:50:15 <astsmtl> Are there any cases of _runtime_ cyclic dependencies?
13:50:16 <IgorYozhikov> dirk, thank you, will add this and continue work on document
13:51:08 <jpena> astsmtl, there shouldn't be a case of runtime cyclic dependencies (at least I haven't found any)
13:51:26 <IgorYozhikov> if there are no more questions here - we can move further
13:51:53 <dirk> #topic package reviews
13:52:06 <dirk> is there anything that you want to bring up?
13:52:31 <dirk> it looks like we've been not bad at reducing the list of open reviews
13:52:36 <dirk> thanks to everyone involved
13:53:03 <IgorYozhikov> https://review.openstack.org/#/c/339458/24/openstack/taskflow/taskflow.spec.j2 looks fine
13:53:27 <jpena> number80: we have an issue with networkx.drawing there ^^
13:54:42 <dirk> jpena: question, is the experimental rdo/red hat gate state visible somewhere?
13:55:15 <number80> jpena: I think it's due that we're not building the network-graph package
13:55:17 <jpena> dirk: we have http://209.132.178.209/repos/status_report.html, not a gate as such but just building the current repo
13:55:56 <jpena> I need to sort out a couple details with number80 (dependency packages) before we can have a gate
13:56:02 <dirk> ok
13:56:09 <dirk> looking forward to that :)
13:56:16 <dirk> is there some dns name pointing to that ip?
13:56:20 <number80> well, building this one on EL7 will be painful as it has a billions of bytes of deps :)
13:56:21 * dirk is not that good with numbers anymore
13:56:21 <jpena> and I try to run the current code against every commit I review
13:56:40 <jpena> dirk: no dns yet
13:56:45 <number80> dirk: sadly, no, it's hosted on some cloud
13:56:54 <astsmtl> Building python-networkx-drawing on CentOS 7 was easy.
13:56:55 <dirk> #link RDO build status http://209.132.178.209/repos/status_report.html
13:57:10 <dirk> #topic open discussion
13:57:14 <number80> astsmtl: you're probably missing many runtime deps
13:57:23 <dirk> T-2 min until we have to close this down here.. sorry
13:57:28 <dirk> anything urgent?
13:58:02 <number80> (building it is easy but since it's python, some deps only appear when you try to run the code)
13:58:03 <IgorYozhikov> nope from my side :)
13:58:03 <astsmtl> I just took last Fedora package, and moved drawing out of conditionals on with_gdal.
13:58:28 <number80> AFAIK, networkx.drawing is only used in a 2-line methods of taskflow that nobody use
13:59:11 <dirk> #endmeeting