12:00:47 <tonyb> #startmeeting requirements
12:00:47 <openstack> Meeting started Wed Jun 22 12:00:47 2016 UTC and is due to finish in 60 minutes.  The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:50 <openstack> The meeting name has been set to 'requirements'
12:00:51 <tonyb> #topic roll call
12:00:56 <coolsvap> o/
12:00:57 <sigmavirus24> o/
12:00:58 <tonyb> Who
12:01:00 <number80> o/
12:01:05 <number80> hguemar
12:01:23 <tonyb> 's here
12:01:26 <prometheanfire> o/
12:01:28 <tonyb> wow laggy
12:02:09 <tonyb> Okay late commers can catch up ....
12:02:17 <tonyb> #topic Any controversies in the Queue?
12:02:33 <tonyb> number80: You had something didn't you?
12:02:36 <coolsvap> I think one showed up right before the meeting
12:02:39 <coolsvap> https://review.openstack.org/325932
12:02:48 <number80> yes
12:02:52 <prometheanfire> selector needs abandoning
12:03:11 <prometheanfire> oh, new
12:03:54 <number80> I checked the project, and though upstream maintainer is still active on other projects in github, he hasn't made a commit, commented a review or issue for a year
12:03:57 <tonyb> prometheanfire: That's the direction it's going but I don't think it's gone yet
12:04:15 <prometheanfire> coolsvap: not really controversial, I think that's a -2 til questions are answered
12:04:24 <prometheanfire> tonyb: ya, I'm just impatient
12:04:31 <tonyb> prometheanfire: hehe
12:04:49 <number80> well, I also sent a review for a linter tool for requirements files
12:05:02 <coolsvap> prometheanfire, ack but concern of number80 is valid which is enough to stop it
12:05:11 <prometheanfire> number80: ya, I like that
12:05:21 <coolsvap> number80, the linter thing is good
12:05:27 <tonyb> WRT sphinx-argparse ... WHat are other projects using to do that thing?
12:05:36 <coreycb> o/
12:05:40 <prometheanfire> coolsvap: those are the questions I'm refrencing (sphinx-argparse)
12:06:03 * tonyb looks forward to reviewing the linter
12:06:03 <coolsvap> currently none
12:06:08 <number80> tonyb: sahara-client
12:06:15 <number80> http://git.openstack.org/cgit/openstack/python-saharaclient/tree/tox.ini#n15
12:06:30 <tonyb> number80: yeah but it's not the first clien that wants to documwnt it's cli
12:06:48 <number80> Yup, not a good reason enough to include it
12:06:48 <sigmavirus24> tonyb: sure, but sphinx has good CLI documentation bits already
12:06:59 <sigmavirus24> tonyb: do they really need to auto-generate their CLI docs?
12:07:08 <sigmavirus24> Does it change so frequently that they need it autogenerated to avoid drift?
12:08:02 <sigmavirus24> I mean look at what flake8 is doing: https://gitlab.com/pycqa/flake8/raw/proposed/3.0/docs/source/user/options.rst
12:09:30 <tonyb> Hmmm If they want to do something "different" and we don't have anythign else that covers that area then I'm okay with that (assuming it is otehrwise okay)
12:09:57 * dims peeks
12:10:00 <tonyb> I guess we'll be looking at python-saharaclient code ;P
12:10:41 <prometheanfire> they py3 aspect means it's still bad though
12:10:48 <tonyb> dims: peeks ate the meetign or the review?
12:10:55 <coolsvap> prometheanfire, +1
12:11:00 <dims> the meeting :)
12:11:09 <number80> *nods*
12:11:42 <sigmavirus24> prometheanfire: so they were testing with tox and Travis CI on python 3
12:11:45 <sigmavirus24> so I think that's wrong
12:12:09 <sigmavirus24> (The last update to the tox.ini was to add Python 3.4)
12:12:15 <prometheanfire> oh, neato
12:12:27 <sigmavirus24> That said, it *is* unmaintained
12:12:41 <sigmavirus24> (That part is clear)
12:12:54 <tonyb> well that'd make it a -1 right there.
12:13:00 <sigmavirus24> So unless someone knows Alex and will volunteer to take it over, I don't think it makes sense to include it
12:13:29 <number80> yup
12:13:41 <tonyb> okay I think we're on the same page there
12:13:56 <tonyb> also the selector thing is "working out"
12:13:59 <sigmavirus24> I mena even minor typographical errors are not being merged: https://github.com/ribozz/sphinx-argparse/pull/35/files
12:14:22 <tonyb> anything else? before we move on?
12:15:05 <tonyb> #topic Tasks from Etherpad
12:15:18 <tonyb> #link https://etherpad.openstack.org/p/requirements-tasks
12:16:17 <tonyb> So thanks to dims we have new requirements cores :)
12:16:30 <dims> tonyb : yay! welcome aboard folks
12:16:55 <tonyb> dims: :)
12:16:57 <sigmavirus24> I would tease you all about poor life decisions, but I don't actually mean it
12:17:16 <tonyb> sigmavirus24: :)
12:17:27 <dims> please figure out who wants to be the PTL in a few weeks and we can get a separate team under governance
12:17:54 <tonyb> dims: hehe you're a funny man :)
12:18:03 <prometheanfire> tonyb: thanks for volunteering
12:18:03 <tonyb> *wants* he says :)
12:18:29 * coolsvap shakes hand with tonyb :)
12:18:42 <dims> LOL
12:18:45 <tonyb> If others are keen then I'm not "mad for power"
12:19:01 <dims> what? no election? tsk tsk
12:19:14 <dims> added another task - "Figure out the best home for the bot/wip script - https://gist.github.com/dims/094ac0e8d8bd8c4a096b6b391157aef5"
12:19:28 <prometheanfire> I do have a question though, about possibly better testing
12:19:45 <tonyb> dims: Yeah that's a good point
12:19:55 <dims> needs a cron that runs overnight and team members should be able to run it on demand (say after fixing up the bot specified review)
12:19:58 <tonyb> prometheanfire: you have the floor
12:20:04 <number80> dims: how about a requirements-bots repo?
12:20:24 <coolsvap> i think all the scripts we have should be in the requirements reop
12:20:26 <prometheanfire> currently we don't merge updated generate constraints until a custom job is run
12:20:45 <tonyb> It's more about the run-time than the code location
12:20:53 <prometheanfire> I think dims runs it?
12:20:53 <number80> ack
12:20:57 <tonyb> I agree we can add it to the repo but ....
12:21:04 <dims> i have a cron and i also run it by hand now.
12:21:17 <dims> when needed
12:21:21 <prometheanfire> is there a way we can trust testing more?
12:21:21 <tonyb> prometheanfire: rigth now that is true.  I think we need a less personal location
12:21:53 <prometheanfire> I think using openstack-ansible might help here, odyssey4me ping
12:21:53 <tonyb> Well we *can* make any change to u-c run extra tests
12:22:05 <coolsvap> dims i think we should add it in repo and add a simple gate task which invokes the script
12:22:20 <tonyb> the issue is havign confidence that we have good coverage ... beyond what dsvm-full gives us
12:22:25 <dims> coolsvap : i'll let you all figure it out :)
12:22:26 <coolsvap> the script is pretty much self driven
12:22:44 <prometheanfire> ya, if we don't trust just dsvm-full then we need to add another test imo
12:22:51 <dims> just tell me when i can switch off my cron :)
12:23:09 <tonyb> dims: will do, thanks for creatign that thing and looking after it
12:23:29 <prometheanfire> atm I don't really touch the automated updates because of the custom testing being done
12:23:54 <tonyb> I did a little analysis in Austin and if we take defcore+horizon+swift we cover abotu 50% of g-r
12:24:19 <prometheanfire> how much does a 'full' osa run cover?
12:24:23 <tonyb> You need to add a bunch of projects t get past that
12:24:28 <prometheanfire> I'd imagine it's a bit more
12:24:51 <tonyb> prometheanfire: we can work on doign that analysis
12:24:59 <tonyb> prometheanfire: short answer is I don't know
12:25:03 <prometheanfire> ya, I guess I'll add a task
12:25:17 <tonyb> prometheanfire: one of the challenges is balancing confidence with gate times
12:25:40 <tonyb> prometheanfire: If you can give me the tempest config I can work it out
12:25:45 <prometheanfire> I'm happy with a longer gate for this
12:25:46 <sigmavirus24> prometheanfire: a "full OSA run" is really undefined
12:25:56 <prometheanfire> sigmavirus24: ya, hence the quotes
12:26:11 <prometheanfire> it was just an idea to get more confidence
12:26:16 <sigmavirus24> because OSA really doesn't have a definition, but it has roles for several projects in varying states of maintenance
12:26:27 <sigmavirus24> prometheanfire: for what it's worth, OSA's tests don't cover nearly enough either
12:26:51 <sigmavirus24> I've found some config templates being egregiously wrong with the gate not noticing that for OSA
12:26:52 <tonyb> We'd probably use stable/mitaka as opposed to master for that reason but I'm making that up as I go along
12:26:57 <prometheanfire> true, but I think we at least cover defcore/horizon/swift
12:27:05 <sigmavirus24> (Because they just test if the service "works")
12:27:18 <prometheanfire> ah, nice
12:27:27 <sigmavirus24> prometheanfire: we could, yes. I still don't think OSA is any better than dvsm
12:27:55 * dims has to run so throwing this for "open discussion" for later - we need to follow up on this http://markmail.org/message/tdw7zzyzbxnkipwe (python-kafka)
12:28:10 <tonyb> dims: noted
12:28:16 <dims> thanks tonyb
12:28:19 <tonyb> dims: do you litterally mean "run" ?
12:29:03 <prometheanfire> yep
12:29:24 <tonyb> Anyway ... prometheanfire did we cover what you wanted to know talk abiyt re testing or did we take a tangent?
12:30:02 <prometheanfire> ya, can you make a todo note?
12:30:18 * prometheanfire needs to look up the bot's commands
12:31:04 <sigmavirus24> prometheanfire: you mean an #action?
12:31:14 <prometheanfire> sure
12:31:21 <tonyb> #action fix testing of constraints changes
12:31:35 <tonyb> prometheanfire: does that cover it?
12:32:34 <tonyb> okay ...
12:32:41 <prometheanfire> yes
12:32:50 <tonyb> #topic Volunteer for next 2 meetings
12:33:06 <tonyb> anyone?
12:33:49 <coolsvap> +1
12:33:51 <prometheanfire> I'll take the second one
12:34:20 <tonyb> okay so coolsvap you're up next week
12:34:35 <dirk> Wfm
12:34:35 <tonyb> prometheanfire: you're next fortnight
12:34:50 * tonyb wanders off to update the etherpad ... please hold
12:34:51 <number80> wfm
12:36:04 <tonyb> #topic Open Discussion
12:36:16 <sigmavirus24> Aww, I thought I had the next meeting
12:36:32 <tonyb> sigmavirus24: Oh yeah ....
12:36:40 <sigmavirus24> No worries
12:36:41 <coolsvap> sigmavirus24, here you go take it
12:36:42 <sigmavirus24> :P
12:36:46 <prometheanfire> I'll have to leave soon, picking kevin up
12:36:50 <tonyb> I'll fix it and add it to the etherpad
12:36:52 <sigmavirus24> prometheanfire: who's kevin?
12:37:02 <sigmavirus24> :P
12:37:36 <tonyb> #link  http://markmail.org/message/tdw7zzyzbxnkipwe
12:37:45 <tonyb> dims: dropped that in
12:38:14 <tonyb> basically we need to work with oslo.messaging and monasca to allow python-kafka to move forward
12:38:25 <coolsvap> tonyb, which etherpad you are updating?
12:38:38 <tonyb> I think rigth now that just means payign attention to the list thread
12:38:52 <prometheanfire> #link https://etherpad.openstack.org/p/requirements-tasks
12:38:54 <tonyb> coolsvap: https://etherpad.openstack.org/p/requirements-tasks
12:39:02 <tonyb> coolsvap: near the bottom
12:39:14 <tonyb> it's very rough as I'm bad with calendars
12:39:48 <tonyb> does anyone have a "gut feel" on the kafka thread?
12:40:23 <prometheanfire> seems we are blocked on the kafka project getting added to projects.txt?
12:40:35 <tonyb> prometheanfire: not quite
12:40:53 <tonyb> prometheanfire: kafka is in there but pinned to 1.x IIRC
12:41:10 <tonyb> oslo.messaging *really* want 2.x but that breaks monasca
12:41:20 <prometheanfire> I get that
12:41:24 <tonyb> monasca are trying to be part of requirements
12:42:00 <prometheanfire> once they are part of requirements they (messaging and monasca) can then work together more 'officially' is what I mean
12:42:00 <tonyb> so we're soft frozen on the kafka requirement
12:42:11 <tonyb> prometheanfire: right
12:42:33 <tonyb> prometheanfire: but *we* need to help them understand what that looks like
12:42:43 <tonyb> and what the pain points are
12:43:08 <prometheanfire> ah
12:43:12 <tonyb> for example can monasca use an abstraction layer to be less tied to 1.x is that any better than doing the 2.x port etc
12:43:16 <prometheanfire> well, ml thread should help
12:43:24 <tonyb> prometheanfire: yup
12:43:31 <dirk> Who from the Oslo.messaging team could help them with that?
12:43:55 <prometheanfire> ok, I have to run, cya tomorrow
12:44:05 <dirk> It seems monasca just doing the jump to 2.x might be a possibility
12:44:12 <prometheanfire> or in a hour or so
12:44:17 <tonyb> prometheanfire: cya
12:44:21 <dirk> If that is easy enough
12:44:33 <prometheanfire> dirk: prefered I think
12:45:01 <tonyb> dirk: right we need to help them asses and be prepared to land compat code in monasca to make that a thing
12:45:15 <tonyb> dirk: clearly we're not the experts yet
12:45:59 <dirk> Yeah, that's true for me at least
12:46:10 <dirk> Maybe a topic for cross.project team?
12:46:19 <dirk> If it cannot be solved quickly
12:47:41 <dirk> I wonder why they consume Kafka directly rather than via Oslo.messaging
12:47:49 <tonyb> dirk: perhaps they can help with the co-ordination but I think the 3 teams will need to do the heavy lifting
12:47:59 <sigmavirus24> dirk: that's a good question
12:48:07 <tonyb> dirk: that's a good question and one we'll need to answer
12:48:09 <sigmavirus24> tonyb: we might need to organize something in #openstack-meeting-cp
12:48:16 <tonyb> sigmavirus24: Yup
12:48:29 * sigmavirus24 wonders if oslo.messaging can be configured for multiple transports
12:48:38 <sigmavirus24> (that could be a reason to not use oslo.messaging for kafka)
12:48:50 <tonyb> Lets keep the thread alive but work on the assumption that monasca will be part of requirements RSN
12:49:00 <dirk> +1
12:49:07 <sigmavirus24> Agreed tonyb
12:49:12 <number80> *nods*
12:49:20 <coolsvap> +1
12:49:26 <tonyb> \o/
12:49:39 <tonyb> Anything else for open discussion?
12:50:24 <dirk> Do we want to talk about the non-master core approver topic?
12:50:43 <tonyb> dirk: Sure 'sup?
12:50:50 <dirk> I think it was on our channel yesterday
12:51:21 <dirk> Whether it is intentional that the approver group for requirements master and stable/ is non overlapping
12:51:39 <dirk> I personally don't care much.. I forgot who brought it ip
12:51:40 <dirk> Up
12:51:54 <tonyb> dirk: I don't *know* the history but I'd assume it's somewhat initentional
12:52:03 <sigmavirus24> I would suspect the same
12:52:22 <tonyb> dirk: in the same way that nova has a diffeent set poepl people (albeit with slightly more overlap)
12:52:25 <sigmavirus24> I would prefer it stay this way for a while too
12:52:51 <sigmavirus24> at least until there's a need for them to overlap
12:53:00 <coolsvap> sigmavirus24, +1
12:53:12 <coolsvap> i would like it to be non-overlapping until required
12:53:29 <tonyb> It would be good to be revieing the stable changes as time permits we could easily grow a requirements-stable-maint team
12:53:31 <dirk> I agree to all of that. I guess the point of the question was that sometimes blocking out a new pypi release should be done quickly to unbreakable gating
12:53:39 <sigmavirus24> No offense to the cores that dims added, but I saw a lot of overeager +1s/+2s on reviews that would be *very* bad for stable/*
12:53:50 <number80> well, the team is fairly new and stable branches is sensitive
12:54:05 <sigmavirus24> dirk: sure, but is the stable/* team too small to be able to react to that?
12:54:18 <dirk> I don't know
12:54:49 <dirk> It seems.we're all in agreement so let's note it down and move on 😉
12:55:11 <tonyb> dirk: well the next thing is # endmeeting so ....
12:55:21 <number80> sigmavirus24: if you have any suggestion on improving reviews, you're welcome to tell us :)
12:55:45 <dirk> Yeah, workflow approval has been pretty quick lately
12:56:10 <dims> good problem to have :)
12:56:12 <dirk> At least for me when I sometimes do other stuff for a.couple of hours
12:56:21 <coolsvap> the approval process we need to revamp to 2*+2 +W
12:56:32 <coolsvap> but we need more active reviewers for that
12:56:34 <number80> sounds sensible
12:57:15 <dirk> coolsvap: I'm happy to do the 2nd +2 when I have time to react
12:57:20 <tonyb> I'm genuinely curious about stable backlogs
12:57:42 <dirk> 10h or so should be an acceptable waiting time unless we just broke everything
12:58:04 <coolsvap> tonyb, we need mentoring by existing stable cores like we had for master
12:58:09 <sigmavirus24> number80: certainly, not sure it needs to be discussed this instant or here
12:58:27 <number80> sigmavirus24: I mean in our usual channel or even by mail
12:58:34 <coolsvap> i think the current core team which stepped up for master can also step up the quality of reviews in stable branches
12:58:50 <tonyb> #action look a stable backlog and review times
12:58:56 <tonyb> we're outta time
12:59:01 <tonyb> Thanks Everyone
12:59:06 <tonyb> #endmeeting