14:02:38 <number80> #startmeeting RDO packaging meeting minutes (2015-04-01) 14:02:38 <zodbot> Meeting started Wed Apr 1 14:02:38 2015 UTC. The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:02:46 <number80> #topic roll call 14:03:13 <number80> meeting agenda: https://etherpad.openstack.org/p/RDO-Packaging 14:03:25 <number80> trello: https://trello.com/b/HhXlqdiu/rdo 14:03:32 <number80> o/ 14:03:35 <jruzicka> o/ 14:03:38 <larsks> o/ 14:03:39 <rbowen> o/ 14:03:40 <xaeth> o/ 14:03:43 <eggmaster> o/ 14:03:47 <chandankumar> o/ 14:04:01 <Egyptian[Home]> o/ 14:04:03 <Egyptian[Home]> :() 14:04:44 <number80> #chairs jruzicka larsks rbowen eggmaster chandankumar xaeth 14:04:58 <number80> #chair jruzicka larsks rbowen eggmaster chandankumar xaeth 14:04:58 <zodbot> Current chairs: chandankumar eggmaster jruzicka larsks number80 rbowen xaeth 14:05:02 <number80> goo 14:05:34 * kashyap lurking 14:05:44 <number80> let's do the follow-up of last week meeting 14:05:58 <number80> http://meetbot.fedoraproject.org/rdo/2015-03-25/rdo.2015-03-25-15.04.html 14:06:27 <number80> #topic tempest 14:06:33 <number80> eggmaster ? 14:09:39 <number80> let's move to the next topic 14:09:58 <number80> #topic kilo: oslo deps 14:10:58 <number80> #info All the new olso deps were approved and imported 14:10:58 <eggmaster> sry had to step afk 14:11:09 <number80> eggmaster: np, take care :) 14:11:16 <eggmaster> I'm back... 14:11:19 <chandankumar> python-oslo-context, python-debtcollector and python-wrapt is now on QA. 14:11:34 <number80> chandankumar: +1 14:12:02 <number80> I just updated oslo.concurrency on apevec behalf so we should be good with oslo 14:12:11 <number80> then, let's move to the next topic 14:12:18 <number80> #topic tempest in production 14:12:23 <number80> eggmaster: please :) 14:13:24 <eggmaster> #info Fedora builds for juno and kilo tempest RPMs were pushed to RDO production 14:13:46 <number80> awesome 14:14:04 <eggmaster> #info kilo is built from redhat-openstack/tempest master branch which substantially trails upstream 14:16:46 <eggmaster> (full stop) 14:16:52 <number80> thanks 14:17:26 <number80> #topic rdopkg 14:17:28 <eggmaster> I should probably rebase python-tempest-lib to latest upstream release, just to be ready if/when redhat-openstack/tempest master gets updated. 14:17:34 <number80> #undo 14:17:34 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x50c22950> 14:17:51 <number80> ok 14:18:06 <eggmaster> #action eggmaster will rebase python-tempest-lib in Fedora to latest upstream release. 14:18:25 <eggmaster> . 14:20:41 <number80> let's move to the next topic 14:20:47 <number80> #topic rdopkg 14:20:56 <number80> jruzicka: some good news ? :) 14:21:02 <jruzicka> #info rdopkg-0.26 contains new `rdopkg query` action that (repo)queries available package versions on supported RDO distributions a la `rdopkg query juno $PKG` 14:21:29 <jruzicka> how do I "complete" a trello task, btw? 14:21:39 <jruzicka> Move to backlog? Archive? 14:22:05 <number80> jruzicka: put it in Done 14:22:59 <number80> but kudos for the query action, it's simplify our workflow \o/ 14:23:23 <rbowen> jruzicka++ 14:23:27 <jruzicka> #info jruzicka working on rdopkg actions to compare requirements.txt with .spec Requires and check their availability in RDO (using new query action) 14:23:58 <jruzicka> pieces are falling in place ;) 14:24:17 <jruzicka> example 14:25:17 <jruzicka> (err, repoquery takes long, a sec...) 14:26:53 <number80> np 14:27:05 <number80> apevec: you here ? 14:27:16 <jruzicka> here it is 14:27:22 <jruzicka> $ rdopkg query juno python-keystoneclient 14:27:31 <jruzicka> juno/fedora-21 14:27:31 <jruzicka> python-keystoneclient-0.11.1-1.fc22 @ RDO Juno fedora-21 14:27:31 <jruzicka> juno/fedora-20 14:27:31 <jruzicka> python-keystoneclient-0.11.1-1.fc22 @ RDO Juno fedora-20 14:27:32 <jruzicka> python-keystoneclient-0.7.1-2.fc20 @ Fedora 20 Updates 14:27:33 <jruzicka> juno/epel-7 14:27:35 <jruzicka> python-keystoneclient-0.11.1-1.el7.centos @ RDO Juno epel-7 14:27:45 <jruzicka> . 14:27:47 <apevec> here now, meeting is 1500 UTC so in 0,5h right? 14:27:58 <rbowen> apevec: The meeting is ongoing. 14:28:09 <rbowen> Silly time zone changes again this week. 14:28:31 <number80> apevec: my mistake, I completely forgot that we changed hour :< 14:28:41 <apevec> number80, which TZ did you create it ? 14:28:42 <chandankumar> jruzicka, can we get a feature like : rdopkg query <github url>, then it will list following packages are available and following needs to be packaged 14:28:46 <chandankumar> ? 14:28:50 <jruzicka> $ rdopkg query juno/fedora-20 openstack-tempest-juno 14:28:51 <jruzicka> juno/fedora-20 14:28:51 <jruzicka> openstack-tempest-juno-20150319.1.fc22 @ RDO Juno fedora-20 14:28:53 <apevec> UTC is the only safe from daylight saving madness 14:28:59 <number80> apevec: you were right, it's UTC 14:29:09 <jruzicka> takes pretty long time, you might want to use -v 14:29:09 <jruzicka> to see what's going on 14:29:18 <number80> #chair apevec 14:29:18 <zodbot> Current chairs: apevec chandankumar eggmaster jruzicka larsks number80 rbowen xaeth 14:29:28 <apevec> nm, lemme see back log 14:29:59 <jruzicka> apevec, number80: someone should fill in more distrepos in rdoinfo 14:30:00 <number80> apevec: we reviewed tempest with feedback from eggmaster, oslo deps, now rdopkg 14:30:19 <jruzicka> so we can query centos repos for epel-N etc 14:31:03 <apevec> jruzicka, you'll have to tl;dr this for me, but we can take it after the meeting 14:31:25 <jruzicka> for each (osrelease, dist) 14:31:35 <jruzicka> there are some repos defined that are available during installation 14:31:35 <apevec> number80, re. oslo - I've few updates left todo 14:31:48 <apevec> tracked in RDO-Trunk etherpad 14:32:07 <number80> apevec: ack 14:32:12 <jruzicka> these are now contained in rdoinfo as 'distrepos' in releases section 14:32:17 <apevec> concurrency I've sent you the patch, next are vmware and serialization 14:32:19 <jruzicka> I filled those I knew 14:32:35 <jruzicka> but I think you two know better for centos and Fedora.next 14:32:45 <number80> apevec: have you some patch or should I do them ? 14:32:48 <apevec> number80, novaclient was still 2.20 last I checked 14:33:10 <apevec> number80, I've oslo patches locally, I'll push or email you if I don't have acl 14:33:22 <number80> apevec: ack 14:33:35 <jruzicka> #action jruzicka to update verwatch for juno/kilo 14:34:11 <jruzicka> I've updated clients, so you can confirm that novaclient is indeed 2.20: http://jruzicka01.lab.eng.brq.redhat.com/verwatch/pkgs/clients?pf=&rf=juno%7Ckilo#pkg-python-novaclient 14:34:13 <apevec> on RDO-Trunk I've marked as OLD: heatclient novaclient and saharaclient 14:34:30 <apevec> jruzicka, 2.23 is latest, and required for Kilo 14:34:39 <number80> yes, on my list 14:34:50 <eggmaster> #info eggmaster worked on unforking RDO ci, making it run as much like 'vanilla' ci job as possible. Represents substantial progress toward ci v2.0. Code review forthcoming. 14:34:55 <jruzicka> I've updated clients in verwatch I meant :) 14:35:04 <apevec> ah :) 14:35:24 <eggmaster> (this seemed under #rdopkg topic to me) 14:35:28 <number80> puppet4 has eaten my morning :) 14:35:29 <apevec> number80, maybe egafford wants to update saharaclient 14:35:44 <jruzicka> I want to get the `rdopkg reqcheck` ready ASAP, thus I trust in number80's packaging superpowers ;) 14:35:47 <apevec> number80, how bad is it? 14:36:23 <jruzicka> last thing ad rdopkg from me 14:36:23 <apevec> should consider ruby scl for puppet 3.x ? 14:36:27 <number80> apevec: not as bad as I though but sources changed a bit 14:37:03 <number80> I think I'll have a more precise ETA by friday on that matter but we may be able to avoid SCL 14:37:05 <jruzicka> I hope you all noticed the `rdopkg reqdiff` is another piece in the requires management 14:37:20 <jruzicka> you don't even need to pass it versions 14:37:34 <number80> jruzicka++ 14:37:36 <jruzicka> by default, it shows requirements diff between current package version and latest detected 14:38:58 * apevec dnf upgrades to get jruzicka's new-hotness 14:39:32 <jruzicka> hell yeah! :) 14:40:01 <apevec> so it expects "upstream" git remove? 14:40:18 <apevec> err, git remote 14:40:20 <jruzicka> oh yes 14:40:35 <jruzicka> you need to have it there anyway 14:40:49 <jruzicka> you need the tags, specificaly 14:42:28 <apevec> jruzicka, I have it but seems to expect specific remote name, where are those defined/documented? 14:42:40 <jruzicka> apevec, errr, not yet :) 14:43:16 <apevec> rtfs then 14:43:39 <jruzicka> too much functionality I need to write to make the requirements management bearable 14:43:41 <jruzicka> sorry 14:43:50 <jruzicka> I'll update the docs later 14:43:50 <apevec> np 14:44:05 <apevec> anything else for rdopkg topic? 14:44:16 <jruzicka> that's all from me now, but look forward for more ;) 14:44:30 <apevec> eggmaster, maybe short update on rdo update CI - it's getting better 14:44:37 <apevec> and never been closer to v2 ! 14:44:47 <eggmaster> ya, see my #info above ^ 14:44:48 <eggmaster> so, 14:44:58 <apevec> cool 14:45:21 <apevec> #info icehouse 2014.1.4 updates are lined on stage, I'll push them after checking stage CI jobs 14:45:30 <apevec> eggmaster, ^ are they green enough? 14:45:44 <eggmaster> apevec: that's a question for weshay I think 14:45:58 <weshay> I can look 14:45:58 <apevec> ok, I'll check after the meeting 14:46:01 <eggmaster> (tbh I haven't looked, /me looks too) 14:46:17 <apevec> weshay, there might have been fallout from centos7.1 release 14:46:40 <apevec> I've fix in rdo-release https://github.com/redhat-openstack/rdo-release/commit/458134f17be6619a66fae7bf28d46c7b868049d1 14:46:51 <weshay> icehouse stage is mostly red.. fedora20 is green, the rest is red 14:46:52 <apevec> but didn't push it b/c centos-release was fixed 14:47:13 <weshay> oh nice 14:47:14 <apevec> weshay, ok, I'll have a look if that's 7.1 redhat-release issue 14:47:43 <apevec> I guess centos-release update might have not reached mirrors 14:48:11 <apevec> #action apevec to review icehouse stage CI jobs 14:48:57 <apevec> #topic kilo f22 14:49:21 <apevec> number80, so we missed beta freeze but I think I'm going to ask for an exception 14:49:31 <apevec> where to ask, FPC ? 14:49:52 <apevec> number80, we'd make Fedora users dis-service by keeping Juno in f22 14:50:02 <number80> apevec: fesco 14:50:13 <apevec> i.e. we would have to retire it mid-release 14:50:33 <apevec> number80, ok, you'll give me links, I'll take that 14:50:42 <number80> yup 14:50:49 <apevec> #action apevec to ask fesco for OpenStack Kilo in Fedora 22 exception 14:51:28 <apevec> ok, that's it from me, any other topics? 14:51:46 <apevec> #topic open floor 14:52:19 <larsks> apevec: I have a question about selinux and RDO... 14:52:43 <larsks> For released RDO packages (icehouse, juno), where do selinux issues get reported? Against the main distribution selinux-policy package? 14:52:53 <larsks> Should we have an openstack-selinux available? 14:53:03 <larsks> At the moment I think our packages are unusable with selinux enabled. 14:53:07 <apevec> we have RDO/openstack-selinux bz component, so report can start there 14:53:18 <apevec> then we move it as needed 14:53:25 <apevec> larsks, Fedora or EL ? 14:53:34 <larsks> At least on Fedora. Possibly CentOS also. 14:53:41 <apevec> for Fedora we file in Fedora/selinux-policy 14:53:56 <apevec> for EL we carry openstack-selinux rebuilds from RHOS 14:54:03 <larsks> Does it really make sense to file bugs against selinux-policy for "out of tree" packages like RDO? 14:54:06 <larsks> That seems weird to me. 14:54:18 <apevec> (until Lon decides to play upstream first w/ openstack-selinux) 14:54:30 <apevec> larsks, it is not out of tree in Fedora 14:54:49 <apevec> RDO Fedora is really just Fedora N+1 builds 14:55:25 <larsks> Well, sort of. There are already in-tree openstack packstackages, and what if there are conflicts between the in-tree and out-of-tree selinux requirements? 14:55:29 <larsks> Or is that really unlikely? 14:55:52 <apevec> shouldn't be 14:56:16 <apevec> but let's look at it case by case 14:56:21 <number80> apevec: btw, taskflow has a stable branch for kilo (0.7.x), we should make sure that kilo repo doesn't ship 0.8.x 14:56:28 <larsks> Hmm. I think the current arrangement is sub-optimal, because it makes it basically impossible to release RDO packages at the same time as a functional selinux policy. 14:57:04 <apevec> larsks, Fedora should be fast moving, and selinux maintainers are responsive 14:57:29 <apevec> and for EL we have openstack-selinux to compensate RHEL-glacial moves 14:57:35 <larsks> Fair enough. In that case, I could use some help going through all the open rdo bugs and trying to get the selinux errors (a) verified and then (b) moved somewhere appropriate. 14:58:01 <apevec> larsks, but even in EL, selinux team includes openstack policy update into main selinux-policy in the next RHEL update 14:58:02 <rbowen> I was wondering if anyone has had any success with RDO on centOS 7.1. I was going to give it a try today and wondered if anyone already has some notes on workarounds and whatever. 14:58:17 <rbowen> I saw that there were some problems last night and that apevec addressed them. Is all happy now? 14:58:22 <apevec> rbowen, workaround is to insert "release" in redhat-release 14:58:22 <larsks> rbowen: I haven't tried, but it's actually on my list because there were some bzs about that. 14:58:31 <apevec> rbowen, or make it symlink to centos-release 14:58:41 <apevec> rbowen, or install latest centos-release RPM 14:58:51 <rbowen> ok. 14:59:00 <apevec> rbowen, see comment in my rdo-release commit from last night 14:59:20 <rbowen> ok. Thanks. I was going to check that out too. :-) 14:59:41 <apevec> copying here: 14:59:41 <apevec> centos-release restored[1] /etc/redhat-release as a symlink so this change is not necessary but also does not hurt i.e. I won't revert it but won't push rdo-release updates either. 14:59:41 <apevec> [1] https://git.centos.org/commitdiff/rpms!centos-release.git/f3a9a7fb3d640e80ed979be291330537a174d6b9 15:00:07 <apevec> last minute 15:00:13 <apevec> thanks everyone! 15:00:19 <apevec> sorry for TZ mixup :) 15:00:26 <rbowen> Thanks. 15:00:35 <apevec> next week we'll stick to UTC i.e. start at _this_ time 15:00:40 <apevec> #endmeeting