15:01:31 <trown> #startmeeting RDO meeting (2015-11-18)
15:01:31 <zodbot> Meeting started Wed Nov 18 15:01:31 2015 UTC.  The chair is trown. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:36 <dtantsur> o/
15:01:54 <number80> o/
15:01:58 <jpena> o/
15:02:04 <trown> #chair dtantsur number80 apevec trown rbowen jpena
15:02:04 <zodbot> Current chairs: apevec dtantsur jpena number80 rbowen trown
15:02:15 <apevec> o/
15:02:23 <Pavo> o/
15:02:28 <trown> #chair Pavo
15:02:28 <zodbot> Current chairs: Pavo apevec dtantsur jpena number80 rbowen trown
15:02:54 <trown> looks like we have a full agenda today
15:03:19 <trown> #topic RDO Day @ FOSDEM - https://www.rdoproject.org/blog/2015/11/rdo-community-day-fosdem/ - Registration and CFP open. Pass it on.
15:03:33 * dtantsur already submitted a talk
15:03:40 <number80> dtantsur++
15:03:40 <zodbot> number80: Karma for divius changed to 1 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:03:43 <rbowen> We have a total of one sessions submitted so far
15:03:45 <rbowen> dtantsur++
15:03:47 <apevec> rbowen, do hosts like me and number80 need to register at eventbrite?
15:04:02 <rbowen> Yes, please register at eventbrite, so that the CentOS people can know how many to expect.
15:04:12 <number80> rbowen: I'm just lazy at writing abstracts :)
15:04:29 <rbowen> Also, we need to probably start a discussion about what sessions we want. We don't need detailed abstracts, because most of this is open discussion rather than formal presentations.
15:04:30 <eggmaster> o/
15:04:37 <trown> #chair eggmaster
15:04:37 <zodbot> Current chairs: Pavo apevec dtantsur eggmaster jpena number80 rbowen trown
15:04:50 <rbowen> So perhaps I'll put up an etherpad like we have done for the other community meetups.
15:05:02 <rbowen> I don't want to get there and sit around staring at each other.
15:05:23 <rbowen> So if you have suggested topics, not necessarily presentations, please feel free to submit those.
15:05:30 <rbowen> EOL
15:05:50 <trown> ok, moving on
15:06:00 <trown> #topic delorean reviews proposal: yanking (abandon with a message?) all reviews that are older than > 2 months (aka older than oct, 15 w/o updates)
15:06:00 <number80> ack
15:06:10 <dtantsur> rbowen, how much time is each talk at the RDO day?
15:06:15 <dtantsur> (sorry for late question)
15:06:21 <number80> yeah, we have many old reviews that are not active anymore
15:06:36 <number80> so I suggest that we abandon them (with a message off course, as suggested)
15:06:37 <rbowen> At the moment I'm assuming 1 hour sessions, but it really depends on how many sessions we have and whether they need that long.
15:06:51 <rbowen> dtantsur: At the moment, you're speaking all. day. long. ;-)
15:07:06 <trown> number80: ya I see no issue with that... it is really not hard to resubmit the review if someone wants
15:07:07 <dtantsur> lol, good :) we're gonna talk about troubleshooting, it's gonna take time..
15:07:45 <apevec> number80, ack, what would be a polite message?
15:08:05 <apevec> "This review has been inactive more than XXX.
15:08:15 <apevec> Please reopen it when you have an update."
15:08:16 <apevec> ?
15:08:28 <apevec> I've seen messages like this upstream
15:08:30 <number80> exactly
15:08:51 * kashyap lurks
15:09:02 <apevec> it could be scripted, who is gerrit api guru??
15:09:18 <jruzicka> +1
15:09:20 <csim> "review are like tamagotchi, they die if you do not care for tham, and this one was not cared for"
15:09:27 <trown> apevec: number80, maybe include something like "Reach out on #rdo or rdo-list if you need assistance with your change"
15:09:29 <jruzicka> :D
15:09:35 <eggmaster> +1 sgtm
15:09:36 <number80> trown: works for me
15:09:58 <trown> #chair jruzicka kashyap csim
15:09:58 <zodbot> Current chairs: Pavo apevec csim dtantsur eggmaster jpena jruzicka kashyap number80 rbowen trown
15:10:23 <apevec> trown, ack
15:10:40 <number80> #agreed automate old reviews abandon in gerrithub for packages reviews
15:11:00 <Pavo> #agreed
15:11:14 <trown> anyone knows how to set that up in gerrit?
15:11:50 <apevec> it would be a script using gerrit cli
15:11:53 <number80> trown: not me, but I can look at it, just giving everyone a chance to do it
15:11:55 <apevec> not in gerrit itself
15:13:02 <number80> no volunteer?
15:13:30 <apevec> kashyap, what's the best gerrit cli tool lately?
15:13:37 <apevec> number80, I can take it
15:13:49 <number80> apevec: ack, I already created a card in trello
15:13:53 <number80> https://trello.com/c/JaQ5AG7i/107-automate-old-packages-review-abandon-in-gerrithub
15:14:04 <apevec> if nothing else, I'll base it on https://github.com/openstack-infra/release-tools/blob/master/stable_freeze.py
15:14:11 <number80> apevec: wfm
15:14:12 <apevec> which basically wraps ssh gerrit ...
15:14:22 <trown> awesome, thanks apevec
15:14:48 <trown> #action apevec https://trello.com/c/JaQ5AG7i/107-automate-old-packages-review-abandon-in-gerrithub
15:15:16 <trown> #topic Retiring openstack services from F24, suggested steps
15:16:13 <trown> apevec: number80 is this one of your topics?
15:16:26 <number80> Yeah, we're reaching deadlines to retire packages
15:16:44 <number80> so I'll provide a list and then ask every package maintainers to retire their package
15:16:50 <apevec> plan is there, now we need to execute
15:17:20 <apevec> tl;dr push Fedora master to openstack-packages rdo-liberty
15:17:27 <apevec> then retire in pkgdb
15:17:38 <apevec> NB fedpkg retire must be done by package owner
15:17:51 <apevec> last I tried co-owner didn't work
15:18:00 <number80> Yes
15:18:03 <trown> ok good to know
15:18:23 <apevec> number80, we need to come up with the unified retire message
15:18:39 <number80> apevec: yes
15:19:02 <number80> I'll work on an announcement draft (needs to push myself to write more)
15:19:06 <apevec> e.g. when I retired Folsom in EPEL6 http://pkgs.fedoraproject.org/cgit/openstack-nova.git/commit/?h=el6
15:19:07 <trown> #info https://trello.com/c/9pJ3CPDM/90-ensure-that-all-openstack-packages-are-dropped-from-f24
15:19:29 <number80> apevec: thanks for the pointer!
15:19:46 <apevec> number80, I'm sure you'll come up with better wording
15:19:58 <number80> #action number80 execute plan to retire OpenStack service from F24
15:20:08 <number80> not sure, but it's good exercise for me
15:20:09 <apevec> also need pointers to RDO
15:20:34 <apevec> number80, yeah, note this might end up in lwn
15:20:36 <number80> apevec: yes, I plan to encourage people who wants to have openstack working on Fedora to help out on delorean instead
15:20:41 <apevec> or register, gasp
15:21:13 <number80> It'll be proof-read before sending for sure :)
15:21:23 <trown> ok on to the next item
15:21:28 <trown> #topic Mitaka clients (and Oslo) in Liberty
15:22:08 <Pavo> what are Mitaka Clients and Oslo?
15:22:15 <apevec> so background
15:22:38 <apevec> Pavo, releases of openstack clients and Oslo libraries from master branch
15:22:42 <trown> so all of the client packages (python-keystoneclient) and oslo libraries in Mitaka
15:22:53 <apevec> during current Mitaka cycle
15:22:53 <Pavo> oh ok
15:23:08 <apevec> previously, stable/* branches had upper cap for oslo and clients
15:23:18 <apevec> but this made a mess instead of taming it
15:23:36 <apevec> so starting stable/liberty there aren't upper limits in requirements.txt
15:23:58 <apevec> instead, there CI job bumping releases to the latest in upper-constraints.txt
15:24:12 <apevec> and rest of CI stable jobs then use it
15:24:18 * apevec finds links
15:24:40 <apevec> #info https://github.com/openstack/requirements/blob/stable/liberty/upper-constraints.txt
15:24:56 <apevec> and https://github.com/openstack/requirements/blob/stable/liberty/global-requirements.txt
15:24:58 <apevec> vs
15:25:19 <apevec> https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L62-L77
15:25:55 <apevec> so thing is that CI job bumping u-c just takes latest from pypi
15:26:05 <apevec> end if it works, it is bumped
15:26:24 <apevec> so we already have Mitaka release for at least keystoneclient used in upstream stable/liberty CI
15:26:46 <apevec> so, what should we do in RDO?
15:27:13 <apevec> since we follow upstream, we should take what's tested upstream
15:27:30 <number80> apevec: we should try the fun path: updating clients (though we have CI as a safe net)
15:27:31 <apevec> now, the risk is that CI u-c job is not covering all edges
15:28:05 <jpena> apevec: what would happen if we discover an issue downstream? Would upstream cap the requirements to a lower version?
15:28:29 <apevec> number80, yeah, if we limit client updates to their stable/liberty releases, we're basically not following upstream stable...
15:28:45 <apevec> jpena, that I'm not sure
15:29:32 <number80> apevec: I meant the latest one in upp-constraints.txt
15:29:57 <apevec> yes, that's what upstream stable CI is using
15:30:33 <apevec> there were some cases where u-c was not enforced (some *aas jobs iirc) but that will be fixed
15:30:57 <apevec> jpena, I guess we need to add our CI votes on u-c reviews
15:31:18 <number80> *nods*
15:31:20 <trown> apevec: jpena, ya we need a RDO third party CI
15:31:28 <trown> I think adarazs is close on it
15:31:48 <adarazs> yup, working on it :)
15:31:51 <apevec> but trouble is, we can't use liberty delorean, where we build clients from stable branches
15:32:04 <apevec> we'd need combination:
15:32:14 <apevec> services from liberty + clients from master
15:32:29 <trown> apevec: ya that is the part that is hard for me to figure out...
15:32:46 <apevec> basically separate repo for clients that number80 proposed
15:32:48 <trown> apevec: well not from master per se... we need specific versions from u-c
15:32:56 <apevec> trown, oh right
15:33:05 <apevec> so even more fun
15:34:26 <trown> I think that will not work with delorean
15:34:28 <apevec> #link https://review.openstack.org/#/q/project:openstack/requirements+branch:stable/liberty+topic:openstack/requirements/constraints,n,z
15:34:49 <trown> we at least would have to add a new feature to delorean to build a specific version
15:34:49 <apevec> ^ that's u-c bumping bot reviews
15:34:52 <number80> trown: no, with a specific delorean instance + rdoinfo database, we can work out something
15:35:23 <apevec> trown, I had some ugly patch to make delorean accept a tag
15:35:25 <apevec> vs branch
15:35:29 <trown> number80: how would rdoinfo help to make sure we have a specific version...
15:35:42 <trown> ya we would need something like that
15:35:43 <apevec> it's just git reference, basically
15:35:50 <number80> trown: we can pin version in telling delorean to use a specific branch
15:35:56 <apevec> but there are some assumption in delorean it's branch
15:36:06 <number80> or by using apevec patch :)
15:36:09 <apevec> number80, not branch, tag
15:36:19 <number80> ack
15:36:21 <apevec> I'll try to find it
15:36:25 <trown> number80: right, but the version we need is > stable/liberty < master potentially
15:36:50 <number80> trown: yup, but it's doable
15:36:56 <apevec> I used it once to build milestone in delorean
15:38:37 <trown> I kind of think we are fine with liberty clients for liberty... If upstream is backporting stuff into stable/liberty that requires mitaka clients they are not doing it right
15:39:29 <trown> I do like the idea of splitting clients/oslo from the service repo though
15:40:48 <trown> in any case we should probably move on... 3 more topics yet to cover
15:40:53 <number80> Just as a note, we always have the possibility to extend a discussion on a list, if we're hesitating
15:41:16 <trown> number80: good point, I think that would be a good list discussion
15:41:48 <jpena> +1 to that, I'd like to give it a good thought too
15:42:08 <trown> ok moving on then
15:42:13 <trown> #topic Missing dependencies
15:44:02 <trown> number80: I think the link for the sphinxcontrib-pecanwsme review is wrong
15:44:24 <number80> trown: there's no review for that
15:44:28 <trown> number80: it points to the IPA review...
15:44:48 <number80> yeah, because it requires it
15:45:04 <number80> IPA requires sphinxcontrib-pecanwsme
15:45:16 <trown> ah ya, for IPA I just did not build the docs because that was missing
15:45:32 <number80> (geez, they like naming their software by putting other software names together recently)
15:45:45 <number80> ack
15:46:00 <number80> is anybody working on sphinxcontrib-pecanwsme ?
15:46:15 <jpena> I can take it
15:46:30 <number80> jpena++
15:46:30 <zodbot> number80: Karma for jpena changed to 3 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:46:30 <gpocentek> I can probably hvae a look at this one too
15:46:32 <trown> awesome! thanks jpena
15:46:46 <chandankumar> \o/
15:46:48 <number80> gpocentek: you can do the review or exchange roles with jpena
15:47:00 <number80> reviews require at least 2 people :)
15:47:08 <number80> (and not just 2 accounts)
15:47:08 <rickflare> can someone help me out with a router issue
15:47:15 <rickflare> I have created my br-ex
15:47:21 <rickflare> and given it a good ip
15:47:21 <trown> #action jpena to do package review for sphinxcontrib-pecanwsme
15:47:25 <number80> rickflare: just wait few minutes after the end of the meeting
15:47:28 <gpocentek> not sure I'll be the best reviewer but I can try :)
15:47:29 <rickflare> ahh
15:47:29 <trown> rickflare: after the meeting please
15:47:30 <rickflare> woops
15:47:31 <rickflare> sorry
15:47:43 <jpena> which reminds me I need a reviewer for requestexceptions
15:48:04 <number80> jpena: if you don't get anyone just ping me
15:48:10 <jpena> number80: ok
15:48:20 <chandankumar> jpena: i can help in review
15:48:27 <number80> :)
15:48:46 <trown> ok the other one listed in this topic is python2-yaql
15:48:53 <trown> is there a review up for that?
15:49:09 <number80> looks like apevec and mflobo fixed it => http://cbs.centos.org/koji/buildinfo?buildID=7851
15:49:14 <number80> trown: it's already in Feodra
15:49:22 <trown> oh it was just version bump
15:49:28 <trown> cool, ya that looks good
15:49:50 <mflobo> yep, thanks to apevec to guied me :)
15:50:18 <trown> ok on to the two new package items
15:50:27 <trown> #topic new package mistral
15:51:08 <trown> is there a review up for mistral?
15:51:13 <number80> trown: yes
15:51:21 <number80> https://bugzilla.redhat.com/show_bug.cgi?id=1272524
15:51:34 <number80> https://bugzilla.redhat.com/show_bug.cgi?id=1272530 (client)
15:51:49 <trown> #link mistral review https://bugzilla.redhat.com/show_bug.cgi?id=1272524
15:52:01 <trown> #link mistralclient review https://bugzilla.redhat.com/show_bug.cgi?id=1272530
15:53:06 <number80> it requires some work but dprince already fixed most of the issues in delorean build
15:53:25 <trown> ya looks like it should be good to go with newer python2-yaql
15:53:49 <number80> I'll needinfo all the reviews that need feedback
15:54:03 <dprince> number80: will post mistralclient shortly as well
15:54:20 <number80> dprince: in delorean?
15:54:25 <dprince> number80: the mistral build seems to be building and (briefly tested) functionally working
15:54:30 <dprince> number80: yes, delorean
15:54:33 <number80> ack
15:54:35 <number80> dprince++
15:54:36 <zodbot> number80: Karma for dprince changed to 1 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:54:49 <trown> ok last agenda item
15:54:59 <trown> #topic new package for cloudkitty
15:55:18 <trown> looks like we just need a formal review there
15:55:31 <gpocentek> and a successful build :)
15:55:59 <gpocentek> I just received a build failure mail
15:56:16 * chandankumar will compile a list of new openstack dependencies by next meeting.
15:56:29 <trown> ah ok, so the spec file is still a WIP then
15:56:36 <gpocentek> looks like a dependency problem: http://trunk.rdoproject.org/f24/2c/4a/2c4a4e90d5aed3d4e13d4e375035d10d40365cb0_d85ae3a0/
15:57:29 <jpena> oh, this python-fasteners issue is what I discussed with mrunge earlier today
15:57:32 <trown> hmm that is f24 master... which I think has no CI against it
15:58:17 <trown> looks to be building fine in centos7 master http://trunk.rdoproject.org/centos7/report.html
15:58:37 <trown> as well as centos7 liberty http://trunk.rdoproject.org/centos7-liberty/report.html
15:59:29 <trown> ok anyone have anything else?
15:59:34 <trown> #topic open floor
16:00:07 <apevec> jpena, why does fasteners shows up only in f24?
16:00:38 <jpena> apevec: because it was just rebuilt for rawhide, and in the process the spec changed, creating the python2 subpackage without a python-fasteners provides
16:00:55 <apevec> ah we have older version
16:01:00 <apevec> for EL7
16:01:19 <apevec> we should probably update now that it's been fixed
16:02:19 <trown> ok number80 kindly volunteered to chair the next meeting
16:02:31 <trown> thanks everyone
16:02:34 <trown> #endmeeting