15:06:05 <number80> #startmeeting RDO packaging meeting (2015-01-04)
15:06:06 <zodbot> Meeting started Wed Feb  4 15:06:05 2015 UTC.  The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:06:11 <number80> #topic roll call
15:06:21 * apevec says hi
15:06:27 <laudo> ihrachyshka_: I am trying to understand why packstack did create /etc/sysconfig/network-scripts/ifcfg-br-ex on the controller (I did set config_neutron_ovs_bridge_mappings and bridge_interfaces) but not on the nova node. So I thought it might be related to the CONFIG_NOVA_COMPUTE_PRIVIF and CONFIG_NOVA_NETWORK_PRIVIF
15:06:28 <number80> today's agenda: http://boulevard69.com/envoye-se-faire-cuire-un-oeuf-il-finit-gagnant-de-top-chef/
15:06:34 <weshay_> helloo
15:06:37 <apevec> #info agenda at https://etherpad.openstack.org/p/RDO-Packaging
15:06:42 <number80> laudo: please wait until the meeting is finished ;)
15:07:05 <eggmaster> slinabery present
15:07:08 <laudo> meaning if CONFIG_NOVA_COMPUTE_PRIVIF and CONFIG_NOVA_NETWORK_PRIVIF would be wrong, packstack would not create the config file? Is that assumption wrong?
15:07:21 <laudo> number80: ok :-)
15:07:32 <number80> anyone else ?
15:07:39 <ihrachyshka_> o/
15:07:47 * larsks waves.
15:07:50 <gchamoul> \o/
15:07:55 * rbowen is here.
15:07:56 <DV> heya
15:08:12 <gchamoul> DV: :-p
15:08:21 <DV> Gael !!!
15:08:40 <number80> may we start with today's topic
15:08:46 <kbsingh> hello
15:08:51 <number80> :)
15:08:54 <apevec> number80, ack
15:09:10 <number80> #topic 2014.2.2 Juno updates
15:09:27 <apevec> 2014.2.2 upstream stable release is scheduled for Thursday
15:09:47 <apevec> it would be nice if package owner could rebase on Fri/Mon
15:10:00 <apevec> if not, I'll do mindless mass-rebase on Tue
15:10:14 <number80> I'm ready, and also ready to do builds on CBS
15:10:16 <apevec> so we should have updates by next meeting on Wed
15:10:23 <apevec> in RDO Juno repo
15:10:55 <number80> #action RDO packages maintainers are invited to rebase their packages on Friday/Monday
15:11:02 <apevec> stable updates should be unexpected but if package owners notice something weird (e.g. bump in requirements!) please let us know
15:11:09 <apevec> err
15:11:17 <apevec> s/unexpected/unexciting/ !!
15:12:27 <apevec> BTW as a test, you could take candidate tarballs from tarballs.openstack.org
15:12:40 <apevec> e.g.
15:13:00 <apevec> http://tarballs.openstack.org/keystone/keystone-stable-juno.tar.gz
15:13:08 * ihrachyshka_ is too lazy for that
15:13:33 <apevec> then wait for the tags to come :)
15:14:30 <apevec> ok, that's all I had for this topic
15:14:41 <apevec> anyone to add?
15:15:09 <eggmaster> apevec: 2 questions. Does this mean RDO update CI should expect onslaught of triggers from `rdopkg update` (and when)? Does rdopkg/rdoupdate tool require update to handle new CBS build source, and where are those tools hosted nowadays? (I guess that's more like 4 questions)
15:15:38 <apevec> eggmaster, good questions
15:15:54 <eggmaster> Reason for first question is that I am going to move off jobs off lousy old jenkins and onto lousy new jenkins ;)
15:16:02 <eggmaster> wondering how urgent I should make that.
15:16:40 <apevec> re. onslaught: yes, expect rdopkg updates soon after release is pushed upstream
15:16:56 <apevec> eggmaster, so would be good to have that move today
15:17:14 <apevec> is it a little bit less lousy?
15:17:15 * weshay_ would jump for joy
15:17:34 <eggmaster> I think I'm able to work on that today.
15:17:55 <apevec> re. CBS builds - what I was suggesting, before rdopkg works with CBS directly,
15:18:02 <eggmaster> it should be a lot less lousy but it's all relative ;)
15:18:07 <apevec> is for pkg owners to push only Fedora part of the update
15:18:27 <apevec> then number80/me do CBS builds and amend the update to include EL7 builds
15:18:45 <apevec> number80, could we try that with 2014.2.2 ?
15:19:08 <number80> apevec: works for me
15:19:18 <apevec> ah wait, still need rdopkg to at least know how to d/l builds from CBS
15:19:22 <eggmaster> yeah
15:19:28 <apevec> jruzicka, ^ can we have that quickly?
15:19:36 <apevec> should be just mere koji -p cbs
15:19:40 <apevec> with appropriate koji.cfg
15:19:57 <weshay_> can someone define CBS
15:19:58 <apevec> i.e. buildinfo/ download-build work w/o client cert
15:20:05 <number80> jruzicka should have his credentials by now
15:20:06 <apevec> weshay_, centos koji
15:20:21 <eggmaster> apevec: also, RDO update CI will trigger off first review, not sure how amending the update will play.
15:20:22 <apevec> number80, we really don't need credentials for update CI
15:20:45 <number80> ok
15:20:46 <apevec> eggmaster, hrmpf, can we just implement CI 2.0 then :)
15:20:53 <jruzicka> oh, sorry
15:20:56 <jruzicka> got lost in expense report
15:21:08 <eggmaster> apevec: heh, not sure that would solve it either
15:21:08 <jruzicka> yeah, I can create CBS bsource very quickly
15:21:31 <apevec> jruzicka, cool, let's do that
15:21:44 <jruzicka> number80, should I? my request is still new: http://bugs.centos.org/view.php?id=8161
15:22:04 <eggmaster> apevec: it would probably be cleaner w/existing setup to just do two `rdopkg update`s, one with Fedora builds, then a subsequent one with CBS builds.
15:22:07 <eggmaster> iiuc
15:22:14 <number80> it's still missing the ack from cloud SIG member, I'll do it right now
15:22:24 <apevec> eggmaster, ok, let's do separate updates then
15:22:44 <kbsingh> i cab then track the req too
15:23:05 <jruzicka> number80, thanks.
15:23:33 <apevec> ok, lemme summarize
15:23:48 <apevec> #info pkg owners to submit only Fedora builds with rdopkg update
15:24:01 <apevec> #info CBS builds for EL7 by hguemar/apevec in a separate rdopkg update
15:24:49 <apevec> #action jruzicka to create CBS bsource very quickly
15:24:51 <number80> apevec: a separate update or amending the original update ?
15:24:58 <apevec> number80, separate
15:25:04 <apevec> so it triggers Phase1
15:25:04 <number80> ack
15:25:27 <rbowen> How about EL6. Anyone here from that effort today?
15:25:32 <alphacc> yes
15:25:37 <apevec> rbowen, next topic!
15:25:42 <rbowen> oh, ok. Sorry. :-)
15:25:49 <apevec> actually above should've all been #action
15:26:05 <number80> #topic Juno/EL6 builds
15:26:09 <apevec> #action All package owners to submit only Fedora builds with rdopkg update
15:26:26 <number80> #undo
15:26:26 <zodbot> Removing item from minutes: ACTION by apevec at 15:26:09 : All package owners to submit only Fedora builds with rdopkg update
15:26:27 <number80> #undo
15:26:27 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x89da710>
15:26:32 <apevec> #action hguemar/apevec to do CBS builds for EL7 and submita separate rdopkg update
15:26:46 <apevec> #action All package owners to submit only Fedora builds with rdopkg update
15:26:57 <apevec> number80, ok should be good now
15:27:02 <number80> #topic Juno/EL6 builds
15:27:38 <apevec> ok, so first thing:
15:27:44 <apevec> to facilitate this, we'll be moving primary RDO dist-git to github/openstack for all releases
15:27:48 <apevec> err
15:27:57 <apevec> github/openstack-packages
15:28:09 <apevec> i.e. Delorean repos where we currently have f20-master branches
15:28:23 <apevec> there will be one branch per openstack release
15:28:24 <kbsingh> lets take /openstack :)
15:28:34 <apevec> i.e. juno icehouse etc
15:28:43 <apevec> kbsingh, openstack-packages is good enough :)
15:29:11 <apevec> we'll then have something scripted to sync to Fedora branches
15:29:21 <apevec> icehouse -> f21
15:29:24 <kbsingh> you mean juno6 icehouse6 etc ? or are dist conditionals all losded in spec conditionals
15:29:26 <apevec> juno -> f22
15:29:28 <weshay_> apevec, are there additional delorean servers?
15:29:42 <apevec> kbsingh, dist conditionals in spec
15:29:54 <gchamoul> weshay_: it will need to !
15:29:54 <kbsingh> ok
15:29:56 <apevec> I want one spec to build on all targets, we have examples how to do this
15:29:57 <alphacc> ok
15:30:10 <apevec> weshay_, delorean will use only f20-master
15:30:28 <apevec> i.e. Delorean mission stays to track trunk
15:30:41 <apevec> we'll just share repo
15:30:43 <apevec> s
15:30:58 <kbsingh> felorian is the nightly upstream build ?
15:31:06 <number80> kbsingh: yes
15:31:13 <kbsingh> delorian even
15:31:17 <apevec> kbsingh, it builds new RPMs on each upstream commit
15:31:27 <kbsingh> ok
15:31:48 <gchamoul> apevec: delorean now has the possibility to build centos7 https://review.gerrithub.io/#/c/214819/
15:31:59 <apevec> it's also early warning system for packaging changes required by upstream changes
15:32:06 <apevec> e.g. new dep popping up
15:32:20 <jruzicka> I'm looking at howto integrate delorean to rdopkg to make interacting with it easy
15:32:24 <apevec> or new code which breaks the builds as unpackages files...
15:32:30 <apevec> jruzicka, ack!
15:32:34 <jruzicka> It's nice to be able to run it locally, but
15:32:43 <jruzicka> for most cases I reckong it would be sufficient to do
15:32:55 <jruzicka> rdopkg dclone $package
15:32:58 <apevec> gchamoul, very good!
15:33:12 <jruzicka> to get delorean dist-git, modify it and then just push it and see if it builds
15:33:36 <apevec> jruzicka, ok, let's stay to the topic (EL6 Juno)
15:33:41 <jruzicka> oh, sorry
15:33:55 <apevec> so EL6 folks, would this setup work for you?
15:34:02 <apevec> there will be no FPCA to sign :)
15:34:12 <apevec> alphacc, ^ anyone else?
15:34:14 <alphacc> yes
15:34:32 <alphacc> legal approved fpca so I am fine with it now ;)
15:34:38 <apevec> ah :)
15:34:38 <kbsingh> we can host builds in cbs. no fpca to sign either
15:34:53 <apevec> kbsingh, yep, we want to move all EL* builds to CBS
15:35:00 <apevec> and disable current Copr we have
15:35:21 <alphacc> I can do the el6 build in cbs, as soon I know where to grab upstream and send pr.
15:35:22 <kbsingh> cool
15:35:23 <apevec> alphacc, who else was interested to work on EL6 Juno?
15:35:40 <alphacc> rhill from ubisoft
15:35:44 <apevec> alphacc, do you want to start with specific package?
15:35:53 <apevec> openstack-nova I'd guess?
15:35:56 <alphacc> apevec: nova ceilometer
15:35:58 <apevec> and what about clients
15:36:06 <alphacc> cleints make sense
15:36:13 <alphacc> neutron for the end ;)
15:36:38 <weshay_> apevec, I take it we need CI on juno el6 in the near future?
15:36:56 <number80> apevec: I volunteered for the clients
15:37:00 <apevec> alphacc, in Fedora master openstack-nova.spec removed all %if el6 stuff, so you'd need to go back in git history to take them back
15:37:23 <apevec> weshay_, yeah, once we have some builds
15:37:28 <eggmaster> apevec: OT, added trello card for moving jobs https://trello.com/c/10D5ue3E
15:37:39 <apevec> but also, we need to see how much we actually need in EL6 Juno
15:37:39 <alphacc> apevec: ok I can dig, so let's try to do nova first and see how it goes.
15:37:43 <number80> the question is now to know which python stack we will be using on EL6
15:37:48 <eggmaster> apevec: I need to clear working on this with my team lead (he says after committing to work on it...)
15:37:52 <apevec> alphacc, maybe nova and clients would be enough?
15:38:02 <alphacc> apevec: not for us
15:38:11 <apevec> if you can upgrade controllers to EL7
15:38:15 <apevec> ah, ok then not
15:38:31 <alphacc> But I can come back with a wishlist in order
15:38:32 <apevec> I thought you would keep only computes on EL6
15:38:51 <alphacc> apevec: yes but may need neutron for the migration
15:38:54 <apevec> alphacc, ack
15:39:03 <alphacc> and ceilometer I guess
15:39:15 <apevec> ok, lemme try to summarize
15:39:28 <number80> #chairs
15:39:37 <number80> #chair
15:39:37 <zodbot> Current chairs: number80
15:39:41 <number80> #chair apevec
15:39:41 <zodbot> Current chairs: apevec number80
15:40:03 <apevec> #info EL6 Juno will be developed in github/openstack-packages/  juno branch (to be created)
15:40:19 <apevec> #info with %dist conditionals in spec
15:40:36 <apevec> #info lookup in fedora openstack-nova git history for examples
15:41:10 <apevec> #action alphacc will come back with a wishlist in order of pacakges to build for EL6 Juno
15:41:33 <alphacc> And I'll start this week with nova
15:41:42 <apevec> #info nova ceilometer for start, may need neutron for the migration
15:41:56 <jruzicka> I'll help with clients in order to test rdopkg working with EL6 builds
15:42:01 <apevec> #action alphacc will  start this week with nova
15:42:08 <number80> great
15:42:21 <apevec> #action jruzicka will help number80 with clients in order to test rdopkg working with EL6 builds
15:42:27 <apevec> what did I miss?
15:43:16 <apevec> oh yes
15:43:28 <apevec> #info alphacc's legal approved FPCA!
15:43:30 <alphacc> I'll try to speak with all interested party, and get them to work too
15:43:37 <rbowen> Sweet
15:43:42 <apevec> alphacc, cool
15:44:10 <apevec> #action alphacc will make all interested party to work too
15:44:11 * alphacc todolist looks more busy now, thx
15:44:19 <apevec> paraphrased :)
15:44:22 <gchamoul> :)
15:45:03 <apevec> #action apevec to create openstack-packages juno branch from f22/master
15:45:48 <apevec> alphacc, todolist are only real perpetum mobile...
15:46:05 <apevec> they never stop
15:46:27 <apevec> ok, anything else for EL6 Juno topic?
15:46:41 <alphacc> not on my side
15:46:50 <apevec> let's move no
15:46:51 <apevec> on
15:46:55 <apevec> #topic Follow-up delorean repo test
15:47:09 <apevec> gchamoul, any luck w/ packstack opm in Delorean?
15:47:29 <apevec> jenkins job is still failing
15:47:47 <apevec> weshay_, ^ could we move it to public jenkins?
15:48:05 <weshay_> we'd need a public delorean
15:48:14 <gchamoul> apevec: well openstack-packages/opm and packstack should be updated soon by delorean
15:48:14 <apevec> weshay_, it is public
15:48:23 <apevec> delorean is hosted on OS1 public
15:48:39 <gchamoul> packstack is now failing in keystone installation ...
15:48:50 * gchamoul is debugging
15:49:11 <apevec> rbowen, I saw we have dns alias for .rdoproject.org but that seems to be a wildcard?
15:49:11 <weshay_> apevec, yes we can run it in public then
15:49:25 <apevec> rbowen, was the plan to create an A record?
15:49:52 <rbowen> apevec: Yeah, and I still haven't heard back regarding the A record. I'll ask again right away. The wildcard points to the web server, I believe.
15:50:32 <apevec> #info Delorean (trunk Kilo RPMs) repo is http://209.132.178.33/repos/current/
15:50:44 <apevec> #info warning may eat kittens!
15:51:09 <apevec> #info gchamoul  is debugging Packstack / puppet-modules in Delorean repo
15:51:44 <apevec> gchamoul, hmm, opm is still 2014.2 in current delorean repo
15:51:58 <apevec> and my changes was merged, why it wasn't picked up?
15:52:09 <apevec> ah, Delorean code
15:52:13 <gchamoul> apevec: yes !
15:52:19 <apevec> it doesn't refresh itself!
15:52:22 <apevec> derekh, ^
15:52:27 <gchamoul> apevec: don't think !
15:52:36 <gchamoul> derekh: ^^
15:52:54 <apevec> #action apevec to check with derekh about Delorean refreshing itself
15:53:58 <apevec> #action rbowen will ask again about DNS A record for trunk.rdoproject.org to point to current Delorean IP 209.132.178.33
15:54:24 <rbowen> ok, turns out that there is a ticket, and it was waiting on misc. He's doing it now.
15:54:25 <apevec> #action gchamoul will debug Packstack / puppet-modules in Delorean repo
15:54:38 <apevec> rbowen, excellent
15:55:09 <apevec> #action weshay_ to move Delorean CI job to http://prod-rdojenkins.rhcloud.com/
15:55:34 <jruzicka> \o/
15:55:54 <apevec> #info Kilo-2 this week, we want to publish working Delorean snapshot to rdo.fedorapeople.org/openstack-trunk
15:56:06 <gchamoul> :S
15:56:15 <apevec> gchamoul, no pressure :)
15:56:24 <gchamoul> I am ok !
15:56:44 <apevec> ok, did I catch all in infos/actions ?
15:57:37 <apevec> silence means yes
15:57:39 <gchamoul> seems good !
15:57:57 <apevec> we're done for today, unless last-minute topic pops up!
15:58:04 * eggmaster remains conspicuously silent
15:58:29 * number80 's nothing to add
15:58:36 <apevec> ok
15:58:43 <apevec> #endmeeting