12:59:49 <number80> #startmeeting rpm_packaging
12:59:51 <openstack> Meeting started Thu Sep 22 12:59:49 2016 UTC and is due to finish in 60 minutes.  The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:59:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:59:54 <openstack> The meeting name has been set to 'rpm_packaging'
12:59:57 <number80> #topic roll call
13:00:01 <number80> #chair IgorYozhikov
13:00:02 <openstack> Current chairs: IgorYozhikov number80
13:00:15 <dirk> o/
13:00:16 <dirk> hey
13:00:19 <number80> #chair dirk
13:00:19 <openstack> Current chairs: IgorYozhikov dirk number80
13:00:19 <jruzicka> o/
13:00:26 <number80> #chair jruzicka
13:00:26 <openstack> Current chairs: IgorYozhikov dirk jruzicka number80
13:00:39 <number80> let's wait few more minutes
13:00:47 <IgorYozhikov> ok
13:01:00 <jpena> o/
13:02:48 <number80> #chair jpena
13:02:49 <openstack> Current chairs: IgorYozhikov dirk jpena jruzicka number80
13:03:08 <number80> I guess we can't expect more guests
13:03:29 <number80> #topic welcome newcomers
13:03:49 <number80> as you saw this morning, we have two new contributors, Tony Xu and linbing
13:03:58 <number80> does anyone of you know them?
13:04:13 <dirk> I would assume they're sleeping by now :)
13:04:39 <number80> Well, I think it would be nice if someone could contact them and mentor them
13:05:00 <number80> especially as they're in a very different tz as most of us
13:05:16 <IgorYozhikov> number80, yes I also saw
13:05:43 <number80> #action number80 send them a welcome email
13:05:57 <IgorYozhikov> they uploaded a lot
13:06:05 <number80> #topic Design Summit fishbowl follow-up
13:06:39 <dirk> number80: nice idea
13:07:08 <number80> yes, I'm happy that new folks showed up :)
13:07:44 <number80> not much change from last week, so I put a (incomplete) proposal for goals
13:08:15 <number80> as not everyone will be at Barcelona Summit, I'd like people to give more thoughts about these goals
13:08:16 <dirk> thats actually  a good topic
13:08:24 <dirk> I would like to vote the existing 3rd party gates as voting
13:08:27 <dirk> even before the summit
13:08:38 <dirk> because last week we merged something that broke the suse ci (probably by accident=)
13:08:40 <number80> dirk: that's fine with me
13:08:57 <dirk> and since we're always testing everything, every other review is currently listed as failed
13:09:25 <number80> dirk: let's start by a formal thread on the list, and ask for a vote during next week meeting?
13:09:42 <number80> but I agree that if we can, let's do it asap
13:09:45 <dirk> works for me
13:09:52 <dirk> well, its just asking the infra guys to set the flag
13:10:05 <dirk> I guess as a PTL you can just ask :)
13:10:05 <IgorYozhikov> dirk, why not, we spoke about voting more then half year ago
13:10:18 <number80> #action number80 RFC on list to promote third-party CI as voting gates + schedule vote for next week meeting
13:10:49 <number80> IgorYozhikov: I'd like to give time to your MOS CI teammates to participate in the discussion too
13:11:06 <number80> but I'm +2 to promote both MOS and SUSE CI
13:11:22 <IgorYozhikov> number80, me to
13:11:51 <IgorYozhikov> there were not so much issues related to misconfiguration
13:11:59 <IgorYozhikov> so let's make them voting
13:12:00 <number80> excellent
13:12:10 <number80> anything else about goals?
13:12:39 <IgorYozhikov> I need to speak with zigo about possibility of co-session
13:13:05 <number80> IgorYozhikov: zigo_ answered dirk's email and he said he preferred a separate fishbowl for debian packaging
13:13:13 <number80> but he'll join us for our fishbowl
13:13:15 <IgorYozhikov> o i c
13:13:26 <IgorYozhikov> number80, thanx
13:13:45 <number80> what do you think about the minimal cloud goal?
13:14:09 <number80> I'd like to focus on small set of services so that we iron out tooling issues
13:14:21 <IgorYozhikov> number80, r u about to do packages for core components?
13:14:44 <IgorYozhikov> plus horizon
13:15:10 <number80> IgorYozhikov: I think that we need a proof of concept, because we may hit limitations in renderspec
13:15:12 <IgorYozhikov> nova glance cinder neutron keystone horizon
13:15:16 <number80> IgorYozhikov: ack
13:15:42 <dirk> not sure if you guys saw it, but the sessions are scheduled
13:15:53 <IgorYozhikov> dirk, already?
13:15:53 <dirk> deb and rpm packaging fishbowl is thursday late afternoon
13:15:58 <IgorYozhikov> nope, will check
13:16:01 <astsmtl> Why can't we try to set it for Newton?
13:16:02 <dirk> and our work sessions are friday morning
13:16:21 <number80> astsmtl: minimal cloud? it's quite late
13:17:00 <astsmtl> We can try, and if there is not enough time we will move it to next release.
13:17:02 <IgorYozhikov> number80, will this minimal cloud have a some kind of deployment test?
13:17:15 <IgorYozhikov> just not only core packages
13:17:33 <IgorYozhikov> might be AIO node?
13:18:17 <number80> IgorYozhikov: yes, but if we managed to deploy AIO using our packages, multi-node shouldn't be hard
13:18:26 <IgorYozhikov> yep
13:19:10 <IgorYozhikov> long term - single -> multi -> ha
13:19:18 <number80> *nods*
13:19:26 <number80> #topic stable/newton branch
13:19:27 <IgorYozhikov> not it became more || less clear 4 me
13:19:40 <number80> thank you dirk for adding the topic
13:19:47 <dirk> so I was trying to get everything merged now for cutting stable/newton branch
13:19:59 <dirk> is there anything that we still want to get in?
13:20:26 <dirk> otherwise I'd say after the django_openstack_auth fix is in we're branching and then open up for merging all the new stuff that is post-newton
13:20:44 <number80> I'd like to have https://review.openstack.org/#/c/343335/ too if possible
13:21:36 <number80> dirk: btw, could you explain me how branching is done?
13:21:41 <IgorYozhikov> https://review.openstack.org/#/c/374679/ ?
13:22:00 <dirk> number80: sure
13:22:03 <number80> IgorYozhikov: non-essential for newton, but we can backport
13:22:17 <dirk> number80: we can do that right after the meeting
13:22:26 <number80> dirk: ack
13:22:41 <number80> anything else on that topic?
13:23:35 <IgorYozhikov> no from my side
13:24:02 <number80> then, we can move to reviews
13:24:27 <number80> #topic packages reviews
13:24:35 <number80> https://review.openstack.org/#/q/project:openstack/rpm-packaging+status:open
13:24:58 <jpena> we've got a lot of them now :)
13:25:37 <IgorYozhikov> I looked through a couple or them
13:25:37 <number80> Yeah, but except the ones mentioned above, they won't be in newton cut :)
13:25:51 <jpena> fair enough
13:26:17 <dirk> yep
13:26:22 <jpena> should we abandon the duplicated ones?
13:26:48 <number80> jpena: yes, I'm finishing it right now
13:27:08 <number80> Yes, let's have our newcomers focusing on the ones
13:27:34 <dirk> I was postponing that review for master until we cut newton
13:27:40 <dirk> so let me suggest one thing: we finish those two reviews
13:27:41 <IgorYozhikov> also it will be good if they will come to our irc
13:27:46 <dirk> branch
13:27:48 <dirk> and then go forward
13:27:54 <number80> dirk: wfm
13:28:05 <IgorYozhikov> ++
13:28:48 <IgorYozhikov> after branching anything required could be cherry-picked || back-ported
13:28:53 <IgorYozhikov> to stable/newton
13:29:04 <number80> *nods*
13:30:29 <jruzicka> sound good to me
13:30:40 <IgorYozhikov> astsmtl, please check our CI readiness for branching
13:31:38 <IgorYozhikov> number80, dirk, and here I have a question
13:32:22 <number80> go ahead
13:32:38 <IgorYozhikov> if we are going to cut new branches - will be correct to use same dependencies for current young master and releasing stable/newton
13:32:55 <IgorYozhikov> or not
13:33:20 <number80> considering that g-r has already changed between master and stable/newton, we'll shortly update our local copy too
13:33:41 <dirk> yeah
13:33:45 <dirk> I am undecided on that a bit
13:33:59 <dirk> I am tempted to swtich to requirements/ version and not have  copy
13:34:04 <IgorYozhikov> I'm asking from perspective of packages set as Requires:
13:34:07 <astsmtl> Are we supposed to rebuild all packages on CI right after branching?
13:34:28 <number80> dirk: that'd be better indeed
13:34:30 <astsmtl> Or we are going to bump release with CR's?
13:35:09 <number80> dirk: what do you think about embedding distro overrides files instead and just clone requirements as-is?
13:35:51 <number80> astsmtl: I'd recommend that, but you can just fork current repo with existing rpms
13:36:06 <number80> repo = binary rpms repo I mean
13:36:34 <astsmtl> You recommend rebuild without CR's, right?
13:37:24 <number80> no release bump between master and newton AFAIK
13:38:07 <IgorYozhikov> number80, just rebuild to separate binary repo || just regenerate from master, right?
13:39:01 <number80> i'd say opention 1.
13:39:20 <IgorYozhikov> ok :)
13:40:07 <number80> let's move to next topic
13:40:25 <dirk> number80: I am not sure what you mean by distro overrides?
13:40:51 <number80> dirk: well, we overrides few stuff in upstream g-r like pytz
13:41:10 <number80> RHEL7 has an older pytz than in g-r but with backports
13:41:29 <number80> so we override this by providing a separate requirements file
13:43:06 <dirk> number80: ah, I see
13:43:10 <IgorYozhikov> number80, and that is why in rh packages *reqs.txt are deleted during build stage?
13:43:30 <dirk> number80: do we have already a merge capability in renderspec?
13:43:33 <IgorYozhikov> I'm about package specs
13:43:42 <dirk> e.g. add something like --requirements $foo --requirements $vendor-foo ?
13:43:46 <number80> IgorYozhikov: yes, but it's partial answer, some requirements files have optional stuff and it breaks builds if we don't have them
13:43:57 <number80> dirk: yes, should be easier to maintain
13:44:20 <number80> dirk: yes
13:44:43 <number80> I'm not 100% sure, it's by design, but the order matters when you pass requirements files
13:46:17 <dirk> number80: works for me actually
13:46:26 <number80> ack
13:46:31 <dirk> the main reason I objected to that originally was because we couldn't control when stuff in requirements/ merges
13:46:43 <dirk> which could break our ci at arbitrary intervals
13:47:03 <dirk> which is why I wanted to have a copy that we can test and then merge
13:47:42 <number80> that was the most sensible decision, we needed to get our CI maturing before adding more entropy
13:48:23 <dirk> well, the funny part is that the fuel ci isn't using it :)
13:48:46 <number80> Yep
13:49:10 <number80> (/me suggests to move to the next topics before we run out of time)
13:49:20 <number80> I'm skipping pymod2pkg as there's no review
13:49:31 <number80> #topic renderspec reviews
13:49:33 <number80> https://review.openstack.org/#/q/project:openstack/renderspec+status:open
13:49:49 <jpena> here, I'd like to hear the Mirantis opinion on https://review.openstack.org/370906
13:49:55 <number80> https://review.openstack.org/#/c/368262/1 is no brainer
13:50:17 <jpena> I see it's merged now, and my plan was to add the block to every spec file, so we can fix the requirement issues in RDO builds
13:50:43 <jruzicka> yay
13:51:02 <jpena> when discussing it with jruzicka, he mentioned that if that's an issue we can have a 3rd flavor (suse,fedora,mos)
13:51:08 <number80> jpena: most MOS packages respect this pattern too
13:51:30 <jpena> number80: ack then, just wanted to be on the safe side
13:51:35 <number80> but yes, having a mos flavor is always an option
13:52:12 <number80> IgorYozhikov: ^
13:52:13 <astsmtl> TBH, I don't understand the need to remove requirements.txt. Only pip performs automatic installation of dependepncies.
13:52:13 <jruzicka> yup let's keep it together until explicit reason to split emerges
13:52:55 <jruzicka> astsmtl, due to magicks of pbr, the requirements are passed as install_requires
13:52:55 <number80> astsmtl: if you keep it around, pbr will try to install whatever is in requirements even optional stuff or update versions if package version is lower
13:53:04 <astsmtl> (Also pbr can be installed automatically, but it's a strong requirement anyway.)
13:53:12 <IgorYozhikov> jpena, use    1 #!/usr/bin/python
13:53:12 <IgorYozhikov> 2 # This script is used for additional checks for versions of dependencies.
13:53:12 <IgorYozhikov> 3
13:53:12 <IgorYozhikov> 4 import sys
13:53:12 <IgorYozhikov> 5 from pkg_resources import require
13:53:15 <IgorYozhikov> 6
13:53:16 <jruzicka> which means that the app will refuse to launch because arbitrary version comparision fails
13:53:17 <IgorYozhikov> 7
13:53:19 <IgorYozhikov> 8 def test_check_requirements_conflicts(req):
13:53:21 <IgorYozhikov> 9     try:
13:53:23 <IgorYozhikov> 10         require(req)
13:53:25 <IgorYozhikov> 11     except Exception as e:
13:53:26 <jruzicka> dude
13:53:27 <IgorYozhikov> 12         print str(e)
13:53:29 <IgorYozhikov> 13         exit(1)
13:53:31 <IgorYozhikov> 14
13:53:33 <IgorYozhikov> 15 test_check_requirements_conflicts(sys.argv[1])
13:53:40 <IgorYozhikov> if deletion of reqs.txt will not affect this test - looks fine
13:53:52 <number80> since koji has no internet access (a prerequisite for reproducible builds), builds will fail as pip can't download eggs from the internet
13:54:21 <number80> IgorYozhikov: it shouldn't fail
13:54:37 * dirk has to run
13:54:42 <astsmtl> jruzicka, number80 Never saw this.
13:54:43 <jruzicka> astsmtl, IOW deleting reqs.txt stops version enforcing through python version
13:54:44 <dirk> number80: I'll ping you in a bit regarding the branching
13:55:00 <jruzicka> since that's package manager job, we disable it
13:55:06 <IgorYozhikov> number80, we run this test in package post install stage
13:55:08 <number80> dirk: ack
13:55:34 <number80> astsmtl: that's very common issue in python packaging for Fedora/CentOS and friends
13:55:34 <IgorYozhikov> and test shows us if something went wrong from perspective of python
13:55:49 <astsmtl> Version enforcing is another case, and here you can remove requirements.txt but you can also patch it.
13:55:54 <number80> ack
13:55:59 <jruzicka> out of time
13:56:48 <number80> astsmtl: patching it is a possibility, but it has drawbacks too
13:56:59 <jruzicka> its redundant
13:57:06 <astsmtl> number80, just try to python setup.py {build,install} anything where there are missing dependencies. Nothing is downloaded.
13:57:07 <number80> but as jruzicka pointed out, let's move the discussion to the usual channel
13:57:09 <jruzicka> we already have dependency management in our package manager
13:57:37 <number80> astsmtl: I have failed builds in koji that says the contrary
13:57:54 <astsmtl> Please, show me.
13:57:57 <jruzicka> you can tell pbr not to download anything
13:58:07 <jruzicka> but the version enforcing still continues
13:58:08 <number80> jruzicka: interesting
13:58:25 <number80> astsmtl: can we continue the discussion on the list?
13:58:33 <astsmtl> Ofc.
13:58:57 <number80> we're running out of time
13:59:12 <number80> thank you for attending, and see you next week (or in the channel)
13:59:22 <number80> #endmeeting