15:05:23 <apevec> #startmeeting RDO packaging meeting (2015-04-08)
15:05:23 <zodbot> Meeting started Wed Apr  8 15:05:23 2015 UTC.  The chair is apevec. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:05:31 <apevec> #chair number80 rbowen
15:05:31 <zodbot> Current chairs: apevec number80 rbowen
15:05:40 <apevec> #topic roll call
15:05:42 <number80> o/
15:05:45 <apevec> o/
15:05:52 <rbowen> \o
15:05:55 <apevec> eggmaster, maybe (o) ? :)
15:06:05 <eggmaster> I was thinking \
15:06:11 <eggmaster> raised hand, head elsewhere :)
15:06:14 <eggmaster> anyway
15:06:16 <eggmaster> o/
15:06:18 <apevec> makes sense
15:06:47 <alphacc> o/
15:07:30 <jruzicka> o/
15:08:40 <apevec> ok, quorum reached
15:09:01 <apevec> #topic Review https://trello.com/b/HhXlqdiu/rdo
15:09:13 <apevec> #info CBS tags created
15:09:38 <apevec> number80, now existing builds need to be re-tagged, would you like to take this?
15:10:07 <chandankumar> o/
15:10:23 <alphacc> I can help if needed.
15:10:37 <number80> #action hguemar retag existing builds in CBS
15:11:35 <apevec> alphacc, number80, btw is there any more new about integration between epel and centos?
15:11:40 <morazi> trown, great, thx for the update.
15:11:44 <number80> apevec: nope
15:11:57 <apevec> much if not all we have in -common is epel imports
15:12:05 <apevec> s/we have/we'll have/
15:12:23 <apevec> ok, lemme just look again at tag hierarchy...
15:13:25 <apevec> cbs list-tag-inheritance cloud7-openstack-kilo-el7-build
15:13:37 <apevec> cloud7-openstack-kilo-el7-build (73)
15:13:37 <apevec> ├─buildsys7 (6)
15:13:37 <apevec> ├─cloud7-openstack-kilo-candidate (70)
15:13:38 <apevec> └─cloud7-openstack-common-candidate (65)
15:14:39 <apevec> number80, alphacc - ok, at first I was going to stay that we'd want to inherit from previous release tag too
15:15:04 <number80> great :)
15:15:17 <apevec> but then again inherited would be only non-openstack deps which are in common
15:16:11 <apevec> number80, oh wait, we would have non-openstack deps which might be at different versions for openstack releases
15:16:30 <apevec> upstream is now capping global-requirements on stable/
15:16:43 <number80> apevec: these should be tagged in cloud7-openstack-<release> ?
15:16:51 <apevec> yeah
15:16:56 <alphacc> number80: I think so
15:17:11 <apevec> we'll see as we go
15:17:11 <number80> common is typically the things we don't want to rebuild like erlang toolchain or xemacs
15:17:31 <apevec> ack - i.e. stuff from EPEL
15:17:50 <apevec> heh, xemacs to run OpenStack
15:17:58 <apevec> dependecy hell
15:18:04 <alphacc> :)
15:18:19 <number80> I need to set that as a goal, tracking down stupid runtime deps
15:18:21 <alphacc> I hope there is vim dependency
15:19:13 <number80> alphacc: there are multiple vi modes in *emacs :)
15:19:44 <apevec> #info first Delorean snapshot passing CI http://trunk.rdoproject.org/centos70/latest-RDO-trunk-CI/delorean.repo
15:20:00 <number80> \o/
15:20:03 <apevec> this is currently pointing to Mar27, new deps have broken later snaps
15:20:20 <apevec> they should be passing now, just CI was having issues
15:20:29 <alphacc> great!
15:20:41 <jruzicka> wow, great success
15:21:04 <apevec> #action apevec to post updated latest-RDO-trunk-CI to rdo-list
15:21:14 <apevec> ...once I see green in Jenkins, that is
15:21:59 <apevec> BTW, RC1 started, so it should be getting stable now
15:22:50 <apevec> that brings to the next item, Kilo3 import
15:22:58 <apevec> into Rawhide
15:23:22 <apevec> I've started manually w/ Keystone, looking now at scripting/automating it
15:23:36 <apevec> this might eventually endup in rdopkg of course :)
15:23:45 <apevec> rdo-kitchen-sink?
15:24:02 <number80> apevec: needs help ?
15:24:30 <apevec> number80, I'll ask later once I have a plan
15:24:36 <rbowen> So once we have RDO-trunk green in Jenkins, we can start talking about a test day date, right?
15:24:50 <number80> apevec: ack
15:24:58 <number80> rbowen: +1
15:24:59 <apevec> rbowen, right,
15:25:17 <apevec> I was thinking to wait for all projects to produce RC1
15:25:23 <jruzicka> apevec, as I wrote in the email, please do write down all the steps of import so I can automate it ASAP
15:25:33 <apevec> which are expected this week
15:25:57 <apevec> jruzicka, ack - although as number80 noted, there will always be a manual step for confirmation
15:26:11 <jruzicka> manual step isn't a problem
15:26:19 <jruzicka> dozens of manual steps are problem
15:26:22 <apevec> jruzicka, we still want to keep the job, don't automate just everything :)
15:26:32 <rbowen> :)
15:26:40 <jruzicka> apevec, just don't tell managers how easy it is...
15:26:43 <number80> I'm not against automating verification, less work for me !
15:26:45 <jruzicka> :-p
15:26:57 <jruzicka> On a serious note, there's always more work.
15:27:13 <apevec> yeah, only neverending resources
15:27:26 <apevec> rbowen, so what dates would work for testday ?
15:27:38 <apevec> in 2 weeks?
15:28:02 <apevec> Apr 21-22
15:28:04 <apevec> ?
15:28:10 <rbowen> 2 weeks would be fine. It's important that we have something that mostly works for most people - we don't want everyone to be deeply discouraged.
15:28:15 <rbowen> Looking at calendar ...
15:28:30 <rbowen> 21-22 would work.
15:28:34 <rbowen> I'm out all next week.
15:28:52 <apevec> ok, we'll use next week to stabilize kilo RC builds
15:29:19 <rbowen> We need to have a "test day Quickstart" doc that has the right URLs in it.
15:29:31 <apevec> if all goes well, we could start advertising Wed next week
15:29:41 <apevec> rbowen, ack - I'll write a draft
15:29:44 <rbowen> Are we targeting CentOS7, or 7.1 for this?
15:29:53 <apevec> #action apevec to create "test day Quickstart" doc
15:30:00 <apevec> 7.1 always latest
15:30:01 <number80> rbowen: 7.1, CentOS is now a rolling release
15:30:02 <kashyap> rbowen: CentOS7 latest
15:30:11 <apevec> you can't really install 7.0 anyway
15:30:11 <kashyap> apevec: And, Fedora too, for the experimenters?
15:30:13 <number80> no more minor releases
15:30:23 <apevec> yes, f21 will be supported
15:30:34 <apevec> s/will/need to/
15:31:27 <kashyap> apevec: That means, separate Kilo RPMs located on repos.fp.o, right?
15:31:30 <kashyap> For 21, i.e.
15:31:51 <kashyap> (You noted on the list - for F22, it'll be Kilo.)
15:31:54 <apevec> there's already openstack-kilo but that's currently only new deps for bootstrapping
15:32:33 <apevec> kashyap, yes, I'll ask fesco for a beta freeze exception once we finish importing  Kilo to rawhide
15:32:52 <kashyap> apevec: Today's FESCO meet? (Wednesdays)?
15:32:53 <apevec> by-the-letter we're not allowed to do it in this phase
15:33:04 <apevec> kashyap, not today, still importing
15:33:23 <apevec> I'll target next Wed
15:33:42 <kashyap> apevec: Ah, okay, sorry I meant to say for Wednesdays.
15:33:47 <kashyap> Noted. Thanks.
15:34:05 <kashyap> apevec: And, btw about the "by-the-letter" comment,
15:34:27 <kashyap> It's not some awfully invasive change or something. I don't see a reason why FESCo shouldn't blindly approve this exception.
15:34:37 <kashyap> (Without discussion for the sake of discussion.)
15:34:39 <xelfe> Hi stackers ! Are the trove install via packstack is suppose to work "out of the box"<
15:34:46 <xelfe> ??
15:34:53 <rbowen> #action rbowen Announce test day for April 21-22 on Wednesday if all is well by then.
15:35:13 <apevec> kashyap, that's my thinking, openstack-* are leaf dep and leaving Juno in F22 is a disservice to Fedora users
15:35:32 <apevec> we'd have to retire it in 6 months
15:35:36 <number80> xelfe: it should be (please wait the end of the meeting)
15:35:37 <kashyap> apevec: Yep, your thinking looks very correct to me.
15:35:58 <apevec> I think we're done, just obligatory...
15:36:02 <number80> +1
15:36:03 <apevec> #topic open floor
15:36:14 <apevec> anything else?
15:36:28 * apevec looks at Apr30 column in trello
15:36:41 <apevec> anything new on EL6 juno ?
15:36:45 <number80> apevec: after the kilo release, how about having a retrospective of the new process ?
15:37:03 <alphacc> I built a juno el6 neutron packages, but not tested it yet (no handson exp with neutron, hail to nova-network) I can push patches to ML soon.
15:37:04 <apevec> number80, good idea, please create a trello card before we forget
15:37:16 <number80> apevec: it's been paused, but I should move forward
15:37:17 <number80> ack
15:37:23 <apevec> alphacc, thanks
15:37:34 <apevec> kashyap, ^ do you fancy testing neutron on EL6 ? :)
15:37:35 <kashyap> apevec: Sorry, one more question -- is there a FESCo ticket filed for it yet or plan to do it next week?
15:37:46 <eggmaster> #info rdo ci is working again, queue almost empty. all code is unforked.
15:37:54 <kashyap> apevec: Afraid, no. I'm testing from Git, and last two weeks, it's full of Nova migration bugs, driving me crazy :-)
15:37:56 <apevec> kashyap, not yet, I'll file it once I have Rawhide working
15:38:13 <kashyap> apevec: But, luckily, after lots of staring at git logs of libvirt, etc, found some root cause of a couple of bugs.
15:38:16 <kashyap> Anyhow. . .
15:38:23 <kashyap> apevec: I can test from Rawhide.
15:38:27 <jruzicka> eggmaster++
15:38:30 <apevec> kashyap, sounds fun
15:38:38 <apevec> eggmaster++ thanks!
15:38:39 <imcsk8> xelfe: you have to enable it: --os-trove-install=y
15:38:52 <apevec> eggmaster, btw, job is still not able to vote?
15:39:02 <eggmaster> apevec: not yet
15:39:05 <eggmaster> that's next.
15:39:28 <apevec> and next after next is v2 jobs w/o master-flow ?
15:39:37 <eggmaster> actually, that's all part of 'next'
15:39:44 <apevec> even better
15:39:50 <eggmaster> I see no reason to get the master-flow thing voting, since it seems impossible
15:40:06 <eggmaster> like, I'd rather put the cycles into v2-style job setup
15:40:11 * apevec is tired of clicking 3x to see actually log
15:40:16 <apevec> eggmaster, ack
15:40:17 <eggmaster> already wasted time on that s***
15:40:21 <eggmaster> kk
15:40:24 * number80 added a post-kilo retrospective card in trello
15:40:39 <jruzicka> eggmaster, +1 on that
15:41:19 <apevec> jruzicka had good progress on https://trello.com/c/HoMTaacz/50-provide-tools-for-efficient-requirements-txt-management
15:41:37 <apevec> reqcheck will be great
15:42:01 <jruzicka> apevec, eh, some progres... I'm kinda sick last two weeks and maybe that's why I've been struggling with the reqs automagic
15:42:18 <jruzicka> I have few qeustions about it actually, is now the right time?
15:42:22 <eggmaster> apevec: only remaining one in queue is the o-p-m where we were seeing that odd yum behaviour, I'm going to retrigger to see if it was a one-off (I doubt it). Otherwise, I've merged everything in redhat-openstack/rdo-update
15:42:33 <apevec> jruzicka, sure
15:42:38 <number80> jruzicka: go ahead :)
15:43:04 <jruzicka> so it's about checking if the requiremtns.txt are met in .spec
15:43:05 <apevec> eggmaster, ok, we might need more logging to debug that one
15:43:20 <eggmaster> yeah
15:43:40 <jruzicka> first question is about mapping reqs.txt to rpm names
15:43:48 <apevec> jruzicka, but also if availalble in the yum repos
15:43:54 <rbowen> Did we forget to endmeeting?
15:44:01 <jruzicka> apevec, that's a prerequisite for that as well
15:44:03 <apevec> rbowen, no, let's log it
15:44:23 <jruzicka> so I see two ways
15:44:36 * alphacc & ; thanks for the updates!
15:44:40 <apevec> jruzicka, re. mapping I think Anvil has a map
15:44:43 <jruzicka> 1) do a substring search on Requires for each req from reqs.txt
15:44:47 <jruzicka> apevec, I looked at that
15:44:52 <jruzicka> not very satisfactory
15:45:02 <jruzicka> did anyone used that to some avail?
15:45:23 <apevec> I didn't, just RTFSed
15:45:32 <jruzicka> yeah, I did little RTFS
15:45:38 <jruzicka> and I didn't like what I saw too much
15:45:40 <jruzicka> not too general
15:45:58 <jruzicka> too deep interweaved with the rest of the code I wasn't intersted in
15:46:10 <number80> 2. is ?
15:46:12 <apevec> could just copy that map
15:46:19 <jruzicka> 2) is to do what anvil does
15:46:27 <jruzicka> strict pymodule2rpm
15:46:32 <jruzicka> and checking for that
15:46:38 <apevec> you'll always have special cases
15:46:40 <jruzicka> I reckong this is a thing many people would be interested
15:46:46 <apevec> yes
15:46:55 <jruzicka> so I'm in favor of creating a module for this
15:47:07 <jruzicka> I'll investigate anvil further
15:47:09 <jruzicka> in that case
15:47:17 <number80> I would suggest then 1.5) first transform the reqs in requirements.txt into python-%{pypi_name} and then use a map
15:47:36 <jruzicka> nova -> openstack-nova
15:48:14 <jruzicka> PyYAML -> PyYAML (not python-pyaml or other variants
15:48:21 <jruzicka> that is, there are MANY special cases
15:48:22 <apevec> why there isn't python(module) like perl(module) ...
15:48:33 <jruzicka> this would require some dynamic easily editable map
15:48:38 <jruzicka> much like rdoinfo
15:49:02 <jruzicka> another question is scope, then
15:49:13 <jruzicka> would this be per-distribution, since the releases differ?
15:49:53 <apevec> jruzicka, you mean for other rpm distros?
15:49:55 <jruzicka> pymodule2rpm('six', 'epel-7') -> python-six
15:50:04 <apevec> fedora/rhel should be consistent
15:50:07 <jruzicka> is that the correct signature for such function I reckon?
15:50:08 <number80> jruzicka: at least, we need to have fallback for new deps
15:50:13 <jruzicka> *wonder
15:50:34 <number80> if it's not in the map, doesn't mean it's not already packaged
15:50:52 <apevec> jruzicka, signature looks good
15:50:52 <jruzicka> python- fallback sounds reasonable
15:51:02 <jruzicka> another option, 1) wouldn't need such map, though
15:51:08 <apevec> yes, map should be for exceptions only
15:51:12 <jruzicka> maybe just a much smaller map of exceptions
15:51:15 <jruzicka> yes
15:51:18 <apevec> ack
15:51:20 <jruzicka> but small, becaiuse
15:52:07 <jruzicka> even just searching for the module name as substring covers most cases
15:52:22 <jruzicka> openstack-nova -> check
15:52:28 <jruzicka> python-novaclient -> check
15:52:39 <jruzicka> python-six -> check
15:52:45 <apevec> but "nova" would match python-novaclient too ...
15:52:54 <jruzicka> shortest match preferred ;)
15:53:08 <apevec> that's too magicy
15:53:11 <jruzicka> yes
15:53:13 <jruzicka> I concur
15:53:18 <jruzicka> so a map
15:53:27 <jruzicka> I'm thinking about a correct structure for this map
15:53:40 <apevec> for exception and fallback to pyton-<module>
15:53:51 <jruzicka> yes, so there will be strong mapping
15:54:01 <jruzicka> and if it's not found, one needs to add to the map
15:54:08 <jruzicka> which should be as easy as pull request/git review
15:54:15 <number80> sounds sensible to me
15:54:27 <jruzicka> very well
15:54:53 <apevec> ok, enough talk, I'll close the meeting
15:54:57 <apevec> thanks everyone!
15:55:01 <apevec> #endmeeting