12:00:12 <tonyb> #startmeeting requirements
12:00:13 <openstack> Meeting started Wed Jul 26 12:00:12 2017 UTC and is due to finish in 60 minutes.  The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:16 <openstack> The meeting name has been set to 'requirements'
12:00:20 <tonyb> #topic roll call
12:00:30 <prometheanfire> o/
12:00:56 <coolsvap> o/
12:01:48 <tonyb> number80, dirk, toabctl, smcginnis: Requirements meeting ping
12:01:59 <dirk> o/
12:02:26 <tonyb> I've been up since 5am so I'm ready for bed ;P
12:02:39 <prometheanfire> keep it quick :P
12:02:41 <tonyb> #topic Any controversies in the Queue?
12:02:45 <prometheanfire> I woke up 5 min ago
12:02:48 <tonyb> pysnmp
12:02:53 <tonyb> #link https://review.openstack.org/486722
12:02:57 <prometheanfire> https://review.openstack.org/486722
12:03:04 <tonyb> snap
12:03:10 <prometheanfire> lol
12:03:16 <coolsvap> i also got the same
12:03:40 <tonyb> okay discuss, what's wrong with blocking 4.3.8?
12:03:55 <prometheanfire> I don't think we should block why pypi itself already blocks
12:04:08 <prometheanfire> the blocking in gr should be known bad versions
12:04:16 <prometheanfire> not incompat versions
12:04:32 <tonyb> where is it blocked in pypi?
12:04:43 <prometheanfire> blocked on install
12:04:54 <dirk> prometheanfire: you mean constraints?
12:05:04 <dirk> prometheanfire: think about the users, for a second. they won't install with constraints applied
12:05:26 <prometheanfire> ya, that's the problem
12:05:46 <tonyb> prometheanfire: I don't follow where is pypi blocking it?
12:05:58 <dirk> tonyb: the -c upper-constraints.txt parameter
12:06:08 <prometheanfire> all those blocks there are there because of version mismatch (the same reason we want to block it now)
12:06:42 <dims> o/ sorry showing up late
12:06:45 <prometheanfire> when pyasn1 has their release we should unblock those
12:07:27 <dirk> prometheanfire: agreed
12:07:45 <dirk> prometheanfire: is there a problem with adding the blocking now and removing it later?
12:07:46 <tonyb> prometheanfire: so you're saying we shouldn't add this block 'cause we *may* have to undo it later?
12:08:07 <prometheanfire> I do get that it's useful for the end users, but we need to track when we should undo it is all
12:08:34 <prometheanfire> that's why I have a -1, not -2
12:09:10 <dirk> prometheanfire: so a comment fixes it for you?
12:09:52 <prometheanfire> a bug would be better, along with the comment, but ya
12:09:53 <tonyb> dirk: can you add a comment? # remove the 4.2.3[45678] blocks when u-c contains pyasn1 > 0.2.4 ?
12:10:00 <tonyb> only with the rigth version numbers?
12:10:25 <prometheanfire> think those are the right version numbers lol
12:10:29 <dirk> tonyb: done
12:11:09 <tonyb> dirk: Thanks.
12:11:14 <prometheanfire> that was all I had
12:11:31 <tonyb> so now that we've done that I suspect that there is only a 50% chnace we'll do that thing
12:11:44 <prometheanfire> dirk: not blacklisted, unreleasesd :P
12:11:54 <tonyb> (remove the blocks)
12:12:09 <prometheanfire> tonyb: that's why I like bugs
12:12:14 <tonyb> No 0.2.3 is released
12:12:33 <prometheanfire> but is known bad, I'm talking about 0.2.4
12:12:42 <tonyb> prometheanfire: So open a bug and add a Related-Bug: to the commit message
12:12:58 <prometheanfire> ya
12:12:58 * dirk mentions that there is already a bug
12:13:21 <dirk> prometheanfire: 0.2.4 is unreleased, 0.2.3 is released. pysnmp requires >= 0.2.3
12:13:36 <prometheanfire> and 0.2.3 is a bad release
12:13:39 <tonyb> prometheanfire: it's more about once we freeze then we don't get the constratints updates and we don't generally change them like that on a stable branch
12:14:09 <dirk> tonyb: there wasn't anyone screaming for the newest pysnmp release so I think we'll survive
12:14:28 <prometheanfire> dirk: we can use that bug, just need to add ourselves
12:15:19 <prometheanfire> tonyb: good point, I was hoping asn1 would have it's release, they said end of july...
12:15:52 <dirk> we might want to ping them and clean all of it up before stable/ branching kicks in
12:16:07 <prometheanfire> them?
12:16:07 <tonyb> prometheanfire: we can hope but the freeze is ~36hours away
12:16:16 <prometheanfire> tonyb: yep
12:16:58 <etingof> prometheanfire, hey, I'm planning to release 0.2.4 soonish
12:17:22 <dirk> tonyb: it looks like only ironic and networking-bgp is affected so we might be able to clean it up with a FFE
12:17:38 <tonyb> etingof: cool.
12:17:39 <dirk> it doesn't require rereleasing any client/lib dependencies
12:17:48 <prometheanfire> etingof: heh, commented :D https://github.com/etingof/pyasn1/issues/36
12:18:01 <tonyb> dirk: really okay that surprises me a little
12:18:26 <prometheanfire> tonyb: ya, it's not used much
12:18:36 <tonyb> I suspect a lot of this is moot as we'er not going to propgate/release the chnage before pike releases anyway
12:20:16 <prometheanfire> so, freeze is coming up
12:20:44 <tonyb> #topic Freeze announcement tomorrow comes into effect ~0000 Saturday 29th
12:20:57 <tonyb> Yeah the freeze is this week
12:21:23 <tonyb> I'm going to remind people tomororw and then lock down the queue on (my) Saturday morning
12:21:35 <dirk> it's chilly here anyway already
12:22:03 <tonyb> anything that comes in after that that has an impact on the release will get a procedural -2 and the "please ask for an FFE" comment
12:22:24 <prometheanfire> yep
12:22:29 <tonyb> dirk: Yeah as releases slow down we're really only left with the bot chnages
12:23:14 <dirk> tonyb: sorry, I was commenting about the weather :)
12:23:22 <tonyb> dirk: LOL
12:23:45 <tonyb> isn't it summer/sping for you?
12:24:23 <tonyb> #topic Open Discussion
12:24:38 <tonyb> anyone have anything?
12:25:13 <dirk> at some point we might want to review the requirements etherpad/tasks again
12:25:16 <dirk> or bug list
12:25:28 <tonyb> dirk: this is true
12:25:34 <coolsvap> and the 2x+2 discussion
12:25:40 * coolsvap feels at some later meeting maybe
12:26:05 <prometheanfire> I'm fine with 2x+2
12:26:17 <coolsvap> I am also fine with 2x+2
12:26:42 * tonyb thoughts that's what we'd been doing for the last year anyway ;P
12:26:52 <tonyb> clearly me recollection of that meeting is flawed
12:26:56 <coolsvap> tonyb: yes
12:27:09 <dirk> ah, one uninformed announcement, the keystoneauth1 update broke troveclient:
12:27:21 <tonyb> I don't really mind which we pick as long as we pick one and document it
12:27:58 <tonyb> dirk: link?
12:27:59 <prometheanfire> dirk: 4.0.1?
12:28:27 <dirk> tonyb: https://review.openstack.org/#/c/485964/
12:28:36 <prometheanfire> the main concern I have with 2x+2 is the core count we have, but I think we are all active enough
12:28:57 <dirk> tonyb: I think we weren't certain about uc-bot changes
12:29:05 <prometheanfire> or 3.0.1
12:29:16 <dirk> tonyb: at some point I think we said passing CI + 1x+1 would be enough
12:29:48 <dirk> that reminds me.. at the last PTG I took the action item to add the functional tests from projects to the uc-reviews checks
12:30:03 <dirk> and nova-func-* has been a major source of instability and annoyance
12:30:15 <tonyb> dirk: Yeah :(
12:30:20 <dirk> I wonder if we want to remove it again, fix it, or live with it (and add more, e.g. cinder might be interesting)
12:30:24 <tonyb> back to the keystone thing.
12:30:51 <prometheanfire> other clients have similiar fails?
12:31:01 <prometheanfire> aka, is it a keystoneauth1 bug or a troveclient bug
12:31:03 <tonyb> can we get the keystone team to look at it, it seems like an API change but I could be wrong
12:31:11 <prometheanfire> ^
12:31:24 <tonyb> I don't want to revert the u-c change without investigation
12:33:04 <tonyb> Oh it was a bigger jump that I thought
12:34:24 <dirk> tonyb: I'veonly seen it with troveclient
12:34:33 <tonyb> we didn't sit on 3.0.0 at all and the 3.0.1 u-c change seemed to merge quickly
12:34:50 <dirk> tonyb: but from rpm-packaging point of view we're in a death spiral (not able to rebuild anything with all the newest versions), so there is definitely some followup releases needed
12:35:02 <tonyb> okay well maybe tobctl can fix it in trove
12:35:04 <dirk> I guess troveclient needs fixed and release
12:37:02 <tonyb> dirk: That'd be better than us backing out the g-r change this close to release/freeze
12:37:26 <dirk> yep, I guess we want to drop a note in #openstack-release
12:38:09 <tonyb> dirk: Yeah, dims should notice ^^^ now that I've pinged him ;P
12:38:48 * dims peeks
12:39:15 * amrith wakes up when he hears 'trove'
12:39:59 <amrith> dirk, tonyb, what's the trove connection?
12:40:06 <tonyb> amrith: See bug https://bugs.launchpad.net/python-troveclient/+bug/1706538
12:40:06 <openstack> Launchpad bug 1706538 in python-troveclient ""ValueError: Expecting a string None" with keystoneauth 3.0.1" [Undecided,New]
12:40:06 <dims> troveclient was released last night
12:40:57 <tonyb> dims: Yeah we may need another as it doesn't work with what we have in g-r / u-c
12:40:59 <dims> dirk : tonyb : traffic was on -dev ML about keystoneauth, treated that as a must-need-thing for pike
12:41:28 <dims> tonyb : need to get keystone folks to look at it first
12:41:43 <tonyb> dims: Yup that's what I said
12:41:48 <dims> ack thanks :)
12:42:29 <amrith> dims, yes, I pushed that yesterday
12:42:43 <amrith> are you saying that someone needs to fix troveclient or this is something that'll be fixed elsewhere?
12:43:02 <tonyb> amrith: right now we don't know where it needs to be fixed
12:43:04 <dims> amrith : dunno yet, let's use keystone channel to determine that
12:43:34 <tonyb> amrith: it was affects troveclient but if it's an unintentional API break in keystone then clearly that where it needs fixing
12:43:51 <amrith> tonyb the odds that trove screwed up are high (just saying)
12:44:00 <tonyb> amrith: ;P
12:44:03 <amrith> we are a little behind the 8-ball
12:44:10 <amrith> not the magic 8 ball mind you
12:44:51 <amrith> ok, so is the issue that now keystone auth requires an expiry time on tokens necessarily?
12:45:05 <dims> tonyb : little backstory for the record, 3.0.0 broke keystonemiddleware badly, hence the rush to 3.0.1
12:45:10 <amrith> seems that way, in the past there was no way to do that
12:45:16 <amrith> so we just upped the default
12:45:22 <amrith> sorry, dims, let's go to #openstack-keystone
12:45:29 <amrith> and bitch about this there
12:46:07 <tonyb> okay now they've gone ;D
12:46:15 <tonyb> anything else?
12:46:29 <amrith> no tonyb I'm still here :)
12:46:36 <tonyb> amrith: LOL
12:46:47 <coolsvap> nothing from my side
12:46:55 <tonyb> amrith: Its IRC and OpenStack everyone is everywhere ;P
12:47:06 <amrith> dims on the other hand, he's gone
12:47:25 <dims> still here :)
12:47:33 <prometheanfire> orly
12:48:03 <tonyb> At this point I think we shoudl stop logging and call it done?
12:48:10 <coolsvap> yes
12:48:22 <tonyb> dirk, prometheanfire ?
12:48:36 <dirk> tonyb: +1
12:48:39 <dirk> sorry, +2
12:48:45 <tonyb> good enough for me
12:48:51 <tonyb> #endmeeting