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