21:00:58 <thingee> #startmeeting crossproject 21:00:59 <russellb> o/ 21:00:59 <openstack> Meeting started Tue Sep 15 21:00:58 2015 UTC and is due to finish in 60 minutes. The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:02 <openstack> The meeting name has been set to 'crossproject' 21:01:09 <dhellmann> o/ 21:01:09 <thingee> #link Agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting 21:01:13 <jroll> \o 21:01:14 <lifeless> lets see if I get tagged :) 21:01:19 <ttx> thingee: heh, looks like we'll have to talk tomorrow 21:01:19 <tpatil> Hi 21:01:20 <EmilienM> o/ 21:01:22 <smcginnis> Hi 21:01:22 <jokke_> o/ 21:01:24 <thingee> courtesy ping for david-lyle flaper87 dims dtroyer johnthetubaguy rakhmerov 21:01:24 <thingee> courtesy ping for smelikyan morganfainberg adrian_otto bswartz slagle 21:01:24 <thingee> courtesy ping for adrian_otto mestery kiall jeblair thinrichs j^2 stevebaker 21:01:24 <thingee> courtesy ping for mtreinish Daisy Piet notmyname ttx isviridov gordc SlickNik 21:01:24 <thingee> courtesy ping for cloudnull loquacities thingee hyakuhei redrobot dirk TravT 21:01:25 <thingee> courtesy ping for vipul lifeless annegentle SergeyLukjanov devananda boris-42 nikhil_k 21:01:32 <stevebaker> \o 21:01:36 <Piet> Howdy 21:01:37 <j^2> o= 21:01:38 <TravT> o/ 21:01:40 <loquacities> o/ 21:01:40 <j^2> o/ 21:01:40 <johnthetubaguy> o/ 21:01:42 <kzaitsev_mb> o/ 21:01:48 <docaedo> o/ 21:01:50 <mestery> o/ 21:01:56 <david-lyle> o/ 21:01:58 <thingee> Looks like I'll be running the show today! 21:02:00 <Rockyg> I'm stil heee-eeere! 21:02:05 <lifeless> thingee: \o/ I did! 21:02:06 <gordc> o/ 21:02:28 <mestery> lifeless: lol :) 21:02:32 <thingee> #topic review past action items 21:02:35 <thingee> johnthetubaguy to add string freeze description into project team guide 21:02:38 <lifeless> mestery: I am *so* easily made happy 21:02:41 <thingee> johnthetubaguy: how'd that go johnthetubaguy 21:02:43 <mestery> lol 21:02:46 <SheenaG> o/ 21:02:50 <johnthetubaguy> I have a patch up, let me get the link 21:03:12 <johnthetubaguy> https://review.openstack.org/#/c/223011/ 21:03:22 <johnthetubaguy> got some fix ups, but its mostly there 21:03:27 <johnthetubaguy> updated the wiki 21:03:34 <johnthetubaguy> and send a note on the ML about it 21:03:36 <thingee> #link https://review.openstack.org/#/c/223011/ 21:03:49 <ttx> johnthetubaguy: I'll review it, it's on my TODO list 21:04:09 <johnthetubaguy> #link https://wiki.openstack.org/wiki/StringFreeze 21:04:10 <redrobot> o/ 21:04:13 <johnthetubaguy> ttx: thanks 21:04:28 <rbradfor> 0/ 21:04:28 <thingee> #action ttx to review string freeze to Common Cycle with milestones doc update 21:04:42 <ttx> wow such pressure 21:04:48 <ttx> much work 21:04:56 <thingee> holding you to it 21:05:09 <johnthetubaguy> :) 21:05:23 <thingee> Base feature deprecation policy 21:05:32 <thingee> no sean dague though 21:05:48 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html 21:05:58 <thingee> #link https://review.openstack.org/#/c/207467/ 21:06:05 <ttx> yep, will propose a new patchset based on discussion asap 21:06:23 <ttx> we just wrapped it at the TC meeting before 21:06:29 <ttx> and on the thread 21:06:38 <thingee> ttx: excellent 21:07:01 <thingee> #info base feature deprecation policy discussed being wrapped in last TC meeting 21:07:18 <thingee> #action ttx to propose new patch set for base feature deprecation policy 21:07:51 <thingee> #topic Centralized Code Coverage Index/Stats 21:07:54 <thingee> rbradfor: hi 21:08:00 <rbradfor> Hi. 21:08:04 <thingee> #link https://review.openstack.org/#/c/221494/ 21:08:13 <ttx> thingee: you skipped announcements ? 21:08:26 <thingee> ttx: you're right 21:08:33 * ttx stands by 21:08:36 <thingee> rbradfor: give me a second 21:08:40 <thingee> we'll circle back 21:08:44 <ttx> you can #undo twice 21:08:44 <thingee> #undo 21:08:45 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x9c02210> 21:08:54 <thingee> #undo 21:08:55 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa34c0d0> 21:08:59 <ttx> magic 21:09:02 <ttx> Orwellian 21:09:23 <thingee> #topic Team announcements (horizontal, vertical, diagonal) 21:09:27 <ttx> On the release management front, we are one month before the end of the liberty dev cycle 21:09:35 <ttx> At this stage, projects using the milestones should have implemented the remaining FFEs 21:09:40 <ttx> And be working actively on their RC1 bug lists 21:09:46 <ttx> Most projects are, some are late though 21:10:10 <ttx> goal is to start tagging RC1s early next week 21:10:15 <ttx> In other news, we now have a website clearly describing deliverables in each release cycle, with version numbers and all 21:10:22 <ttx> #link http://docs.openstack.org/releases/ 21:10:30 <ttx> That's kind of useful in the big tent with denormalized versioning across components 21:10:39 <ttx> If you're more the YAML type or want to write your own tool, that data lives in openstack/releases 21:10:41 <thingee> #info For release management goal is to start tagging RC1s early next week 21:11:09 <ttx> #info projects must wrap up the remaining FFEs in the coming days and start bruning their RC bugs lists 21:11:10 <thingee> #info we now have a website clearly describing deliverables in each release cycle, with version numbers and all 21:11:17 <johnthetubaguy> ttx: that website is quite beautiful, top job 21:11:18 <thingee> #link http://docs.openstack.org/releases/ 21:11:19 <bknudson> what's the difference between deprecated and eol? 21:11:25 <ttx> johnthetubaguy: credits: dhellmann 21:11:44 <ttx> bknudson: good question, that was impotred from the wiki page 21:11:45 <thingee> #info projects must wrap up the remaining FFEs in the coming days and start bruning their RC bugs lists 21:11:58 <bknudson> I assume deprecated means it's still supported 21:12:18 <ttx> hmm, probably mean the same, we should mark them all EOL 21:12:33 <ttx> I think "deprecated" meant "nobody in his sane mind would run this" 21:12:59 * jroll glances at the feature deprecation policy with that in mind :) 21:13:04 <ttx> yeah, it's copied from https://wiki.openstack.org/wiki/Releases 21:13:23 <ttx> A-C should just be EOL as well 21:13:49 <ttx> that's all I had 21:14:09 <thingee> anyone else with their team announcements? 21:14:28 * jokke_ really likes the releases page 21:14:53 <thingee> alright lets move on! 21:15:21 <thingee> #topic Centralized Code Coverage Index/Stats 21:15:28 <thingee> rbradfor: hey lets try this again, no hard feelings? 21:15:29 <rbradfor> thingee, thanks 21:15:32 <rbradfor> np 21:15:39 <rbradfor> following my discussion a few weeks ago I posted to ML. Thanks to fungi: for great feedback. I have written a spec I would like feedback on. 21:15:39 <thingee> #link https://review.openstack.org/#/c/221494/ 21:15:54 <rbradfor> My spec includes a link for a working prototype at http://demo.ronaldbradford.com/cover/ which has auto populated over the last week 38 projects run in Zuul. 21:16:48 <jroll> the demo is really nice, btw 21:16:55 <rbradfor> additional suggestion from dhellmann: was to enable a project rollup. 21:16:58 <bknudson> projects should be ranked by coverage so we can see who's winning. 21:17:13 <rbradfor> jroll, thanks. The next step is posting stats to graphite and being able to show graphs over time. 21:17:50 <rbradfor> bknudson, we need greater participation having a post gate check for coverage in project-config/tree/zuul/layout.yaml 21:17:53 <thingee> #info working prototype available 21:17:59 <thingee> #link http://demo.ronaldbradford.com/cover/ 21:18:27 <rbradfor> anybody on individual projects that could facilitate that will help it's later inclusion. 21:18:39 <fungi> rbradfor: by the way, the fix for our log indexes is proposed, which should allow simplification and dropping your present json scraping mechanism 21:18:44 <annegentle> ok I'll ask, what's coverage in this context? 21:18:48 <fungi> #link https://review.openstack.org/214207 21:18:56 <rbradfor> bknudson, I feel adding some sorting filters woul enable users to filter as they like. 21:19:15 <rbradfor> annegentle, this is the tox -e cover report for a project 21:19:22 <annegentle> rbradfor: ok thanks 21:19:25 <bknudson> so if keystonemiddlware isn't in the list it's because we're missing the post job? 21:19:25 <fungi> annegentle: the result of running the "cover" utility against a python-based repo's unit tests 21:19:35 <rbradfor> however a {project}-coverage gate is needed in either check: or post: gates to be captured 21:19:59 <rbradfor> bknudson, checking, if there have been no zuul jobs in past week it would also not show 21:20:25 <rbradfor> fungi, thanks. The process will be simplified with log indexes fix. It's not a pre-requisite, but a much nicer to have 21:20:26 <Rockyg> rbradfor, have you looked at sonarqube for the dashboards? It's gpl 21:20:41 <thingee> #info next step is posting stats to graphite and being able to show graphs over time 21:20:42 <fungi> it's also possible the coverage job runs are broken for some projects. since they run after merge they're often not really looked at closely and do sometimes just fall apart 21:20:44 <rbradfor> the added benefit is I can then generate data back 4 months (fungi: is that right amount) 21:20:56 <fungi> rbradfor: at the moment, yes 21:21:14 <rbradfor> fungi, however I cannot post to graphite with a historical date/time I suspect. 21:21:32 <thingee> rbradfor: when is the plan for post gate check? 21:21:33 <rbradfor> current layout.yaml for Zuul 21:21:35 <rbradfor> #link http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml 21:21:39 <johnthetubaguy> I have a feeling the nova one got killed due to lack of love 21:21:44 <thingee> #link http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml 21:21:57 <fungi> rbradfor: not sure whether we could fake that to backpopulate or would just need to start injecting trending metrics into graphite going forward 21:22:28 <rbradfor> bknudson, keystonemiddleware has post gate for coverage now. 21:22:34 <bknudson> ok 21:22:49 <rbradfor> fungi, I think just going forward, but we could look at them for novelty factor. 21:22:56 <bknudson> maybe it's just we haven't been able to merge anything for a while 21:23:12 <thingee> rbradfor: ok so you're asking for individuals within projects to submit the changes to layout.yaml for their project? 21:23:45 <rbradfor> thingee, the spec can more forward regardless, but interested parties here that like the report can request changes 21:24:02 <rbradfor> thingee, the impact is if it fails as fungi: has stated it's likely blocking merge. 21:24:16 <rbradfor> however there are non-voting gates for various projects in check: 21:25:01 <rbradfor> Question is, should the default {project}-coverage be non-voting always, and you need to override that for voting. Thats outside of this spec scope but something to promote more projects listed. 21:25:11 <fungi> well, lots of projects don't gate on coverage jobs because they can take a long time to run. this is why most of it is happening after changes merge at the moment 21:25:24 <rbradfor> ^^ 21:25:30 <bknudson> voting post job seems useless 21:25:39 <clarkb> and the timing differences can make the jobs fail 21:25:50 <fungi> there's no voting post-merge, just publication of results 21:26:02 <thingee> #info waiting for patch to land to fix post gate checks 21:26:02 <clarkb> which are arguably good to catch the problem is that they are not determinisitic so hard to debug 21:26:04 <thingee> #link #link https://review.openstack.org/214207 21:26:06 <thingee> whoa 21:26:24 <fungi> i heard you like links so i put a link in your link 21:26:39 <thingee> #info Question is, should the default {project}-coverage be non-voting always, and you need to override that for voting. Thats outside of this spec scope but something to promote more projects listed. 21:26:58 <thingee> rbradfor: anything else we should check on for next week? 21:27:10 <thingee> rbradfor: actions 21:27:20 <rbradfor> thingee, I'm just hoping for feedback, and approval so I can look at getting this implemented. 21:27:30 <jokke_> rbradfor: will we have that same week limit after this is implemented or is it just your demo page? 21:27:44 <bknudson> I like it since I like to keep the coverage up when doing reviews 21:27:46 <rbradfor> link is as infra defines. 21:28:07 <rbradfor> it will likely be logs.openstack.org/something 21:28:24 <thingee> rbradfor: great thanks, we have the spec in the logs so we'll check back next week on the status. 21:28:32 <rbradfor> thingee, thanks 21:28:35 <bknudson> competitors will use this info to say that openstack is immature and not tested 21:28:56 <thingee> #topic Return request ID to caller 21:29:00 <rbradfor> bknudson, there are a lot of things we can discuss about coverage, it's uses, benefits etc. 21:29:07 <tpatil> Hi 21:29:07 <thingee> #link https://review.openstack.org/#/c/156508/ 21:29:14 <tpatil> This spec has gone through several iterations and it’s ready for the approval 21:29:16 <tpatil> Got one +2 from ttx, need one more +2 from core reviewer 21:29:30 <tpatil> We are ready with the implementation code as per the proposed spec design. So as soon as spec is approved, we can start uploading the patches for review 21:29:38 * thingee notes that doing a diff from his last on ps12 shows the whole thing new 21:29:41 <bknudson> is there sample code? 21:30:10 <tpatil> bknudson: not uploaded yet, but we can do that soon if you would like to check it 21:30:35 <bknudson> tpatil: sure, I'd take a quick look. 21:30:47 <tpatil> bknudson: ok 21:30:51 <thingee> I think with the current approvals, we can be close to wrapping this up again, ttx? 21:31:19 <tpatil> Request everyone to please review the spec so that we can move one step ahead 21:32:01 <ttx> looking 21:32:27 <ttx> yep, we could place it on the docket for final approval at the TC next week, if it continues on the consensual trends 21:32:40 * ttx makes a note 21:33:03 <tpatil> ttx: thanks 21:33:19 <thingee> #info currently has one +2. will be placed on the docket for final approval with TC next week assuming it continues consensual trends 21:33:24 <thingee> ttx: thanks 21:33:26 <thingee> tpatil: thank you 21:33:38 <tpatil> thingee: Thank you 21:34:07 <thingee> #topic Refactoring testr and tox 21:34:09 <thingee> lifeless: hi 21:34:12 <thingee> #link https://review.openstack.org/#/c/218070/ 21:35:30 <lifeless> hi 21:35:42 <lifeless> so testr is currently run within each venv 21:35:43 <bknudson> does tox -e py27 still work? 21:36:33 <lifeless> bknudson: so thats one of the discussion points 21:36:42 <lifeless> bknudson: we could say 'testr run -p py27' 21:36:55 <lifeless> bknudson: or 'tox -e testr -- run -p py27' 21:37:18 <lifeless> bknudson: and separately, what should 'tox -e py27' do - should it run the tests in subunit mode, which is what testr needs 21:37:21 <fungi> though in either case, only after installing testr manually on your system 21:37:30 <lifeless> bknudson: or should it run them in testtools.run mode 21:37:32 <lifeless> fungi: no 21:37:36 <lifeless> fungi: I think you misread the spec 21:37:44 * fungi reads again 21:37:49 <lifeless> fungi: testr will be installed by a tox environment 21:38:09 <lifeless> fungi: 'tox -e testr' will get a venv with testr in it 21:38:28 <dhellmann> o_O 21:38:49 <jroll> there's still a cognitive overhead for devs to switch 21:38:52 <dhellmann> that solves the dev setup issue 21:38:54 <dhellmann> what's the benefit of changing this? 21:38:57 <jroll> which we should not ignore 21:39:07 <fungi> ahh, i did indeed misread. i thought you wanted to preinstall testr on our job workers, not install it at job runtime via tox 21:39:09 <ttx> jroll: ++ 21:39:55 <bknudson> if we could make it even less typing, e.g, tox py27 that would be nice... e.g., if the default venv is the testr one. 21:40:11 <bknudson> and it handled the argument handling. 21:41:05 <jroll> thinking about it more, if testr is just calling back into the tox, is there any reason 'tox -e -py27' wouldn't continue to work? 21:41:38 <lifeless> jroll: yes, we can't ignore it 21:42:04 <lifeless> jroll: so - for testr to be in a constant python environment (which it should be) 21:42:08 <jroll> (maybe the tox.ini file is changing significantly in a way that doesn't allow 'tox -epy27' to continue working, hard to tell from the spec) 21:42:14 <lifeless> jroll: we need tox targets that run the tests and output subunit 21:42:28 <lifeless> jroll: so either new targets, this becomes a parallel infrastructure 21:42:39 <lifeless> jroll: or we repurpose things and its a refactoring 21:42:57 <lifeless> jroll: right now its in draft mode - we need more input and thoughts on it 21:43:04 <ttx> I missed that "tox -e py27" wouldn't work anymore 21:43:06 <jroll> lifeless: I tend to like the former, so the current method keeps working for devs while they migrate to the new thing 21:43:17 <jroll> lifeless: maybe a subunit-py27 is what testr calls into 21:43:47 <clarkb> keep in mind some projects do not trstr 21:43:49 <lifeless> jroll: and eventually subunit-py27-constraints 21:43:51 <jroll> and then we can deprecate or whatever if we feel the need, if the cost of maintaining both is too high 21:44:07 <clarkb> this effectively doubles infras supported interface count 21:44:14 <lifeless> jroll: per clarkb's point, we have to consider that some projects aren't yet, or can't yet, or don't want to, use testr 21:44:27 <jroll> sure. 21:44:37 <lifeless> so there's cognitive overhead there 21:44:59 <jroll> lifeless: right, additional overhead that doesn't exist today 21:45:01 <clarkb> horizon and swift for example 21:45:32 <fungi> are they both using nose, or using separate things? 21:45:44 <lifeless> django and testr have not been fully glued together 21:45:53 <lifeless> swift is still nose 21:45:56 <clarkb> horizon uses a wrapper thing and swift is nose 21:46:11 <clarkb> I think horizon is nose under the covers 21:46:22 <david-lyle> indeed 21:46:28 <dhellmann> at least one of the oslo libs is still using nose, too. stevedore or cliff or both. 21:46:30 <lifeless> it may be useful to remember that testr is both a data store (testr load, testr failing etc) and the meta-runner (testr run, testr list-tests) 21:47:05 <jroll> right, so in general (IMHO) 'tox -e py27' should always work, because best I can tell it works in most/all projects 21:47:06 <lifeless> so I've got some good feedback here. I need to iterate on the spec 21:47:36 <thingee> lifeless: great :) 21:47:37 <lifeless> I don't know if its possible to make tox -e py27 indirect via another tox instance 21:47:51 <lifeless> please do all provide thoughts on the spec 21:48:02 <lifeless> I'll update it later this week 21:48:09 <lifeless> aiming for another discussion next meeting 21:48:35 <thingee> #info good thoughts in today's meeting with this, we'll bring this up next week again 21:48:36 <jroll> cool, thanks :) 21:48:48 <thingee> #action lifeless to follow through with another iteration 21:48:56 <thingee> lifeless: thanks 21:49:04 <thingee> #topic open discussion 21:49:08 <kfox1111> I've got a topic. 21:49:22 <kfox1111> I posted the email as we talked about the other week: 21:49:24 <thingee> kfox1111: you have the floor 21:49:27 <kfox1111> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074126.html 21:49:34 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074126.html 21:49:46 <kfox1111> no responses. 21:50:07 <kfox1111> I also moved the spec from nova-specs to the cross project repo here: 21:50:11 <kfox1111> #link https://review.openstack.org/#/c/222293/ 21:50:36 <redrobot> kfox1111 I think it's an important problem to solve. 21:50:55 <johnthetubaguy> kfox1111: I think I have quite a few comments on the original Nova spec 21:50:56 <redrobot> kfox1111 it's on the security team radar as well... 21:51:12 <johnthetubaguy> redrobot: +1 to the security team radar 21:51:26 <kfox1111> If nothing else, if you think your project is affected by the lack of this feature, please weigh in. 21:51:26 <thingee> #info Instance Users for Cloud Interaction - sometimes instance need to interact with cloud serivces 21:51:50 <thingee> #info spec was moved from nova spec to cross project 21:51:52 <thingee> #link https://review.openstack.org/#/c/222293/ 21:51:56 <kfox1111> johnthetubaguy: I tried to address the comments when I moved it over. Hopefully I didn't drop any. 21:52:13 <lifeless> oo yes 21:52:23 <lifeless> this is an important tricky issue 21:52:42 <johnthetubaguy> kfox1111: I still think the best way forward is to not work on Nova changes, and first agree the mechanism, in general 21:52:44 <thingee> #info original nova spec comments should be addressed in cross project spec 21:52:46 <thingee> #link https://review.openstack.org/#/c/186617 21:52:49 <kfox1111> it would be really nice if we can get as many affected groups in the same room at the summit if we can. 21:52:52 <johnthetubaguy> kfox1111: I should probably write up my comments better I guess 21:52:58 <jroll> this would be a great summit topic 21:53:16 <thingee> kfox1111: https://etherpad.openstack.org/p/mitaka-cross-project-session-planning 21:53:27 <kfox1111> johnthetubaguy: Like I commented, I'm ok with it being out of nova, but the final solution must meet all the issues raised in the spec. 21:53:38 <redrobot> I'm hoping the TC will pick it up for the cross-project-session 21:53:38 <johnthetubaguy> kfox1111: agreed with that 21:53:47 <kfox1111> so far folks are mostly proposing solutions that aren't viable. :/ 21:54:14 <thingee> kfox1111: my bad, you already have it listed 21:54:57 <thingee> #info instance users for cloud interaction is proposed to cross project sessions at the summit 21:55:47 <lifeless> redrobot: we're going to do a call for topics soon for that, but I"ll add it now 21:56:01 <kfox1111> thanks. :) 21:56:07 <Rockyg> thingee, kfox1111 -- I added it to the cross project session planning proposals with kfox1111 as the presenter. You gonna be in Tokyo? 21:56:08 <lifeless> ah its already there 21:56:12 <thingee> lifeless: should be on the etherpad 21:56:17 <thingee> :) 21:56:42 <kfox1111> Rockyg: thanks. yeah, I'll be there. 21:56:49 <thingee> kfox1111: excellent 21:56:53 <jokke_> o/ 21:57:04 <thingee> kfox1111: viable solutions needed, anything else? 21:57:25 <kfox1111> nope. just eyes on the problem. Thanks. :) 21:57:40 <thingee> kfox1111: thank you 21:57:56 <thingee> anything else before we come to a close? 21:58:00 <jokke_> o/ 21:58:05 <jokke_> quick one 21:58:11 <thingee> jokke_: go for it 21:58:36 <jokke_> Big hand to dhellmann for digging into the Glance situation and hallway discussions here http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html 21:58:50 <thingee> jokke_: +1 thank you dhellmann 21:58:54 <Rockyg> ++ 21:58:56 <jokke_> If you're affected by glance, please please read and chip in 21:59:14 <jokke_> now we need all the feedback we can to make the right decisions 21:59:28 <thingee> #info glance contributors please read discussion with dhellmann's priority proposal 21:59:30 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html 21:59:52 <johnthetubaguy> yes, +1, I have promised to respond from the Nova side, given the impact on what we are doing 22:00:06 <thingee> ok thanks everyone!! 22:00:07 <dhellmann> yes, please also consider the similar ramifications for your project and defcore 22:00:20 <thingee> #endmeeting