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