21:00:05 <dhellmann> #startmeeting crossproject
21:00:06 <openstack> Meeting started Tue Feb 17 21:00:05 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:09 <openstack> The meeting name has been set to 'crossproject'
21:00:10 <dhellmann> ttx wasn't sure he would have steady internet today, so he asked me to chair the meeting this week in his place
21:00:14 <thingee> o/
21:00:16 <dhellmann> courtesy ping for mikal notmyname nikhil_k morganfainberg david-lyle mestery thingee
21:00:17 <dhellmann> courtesy ping for eglynn asalkeld SlickNik devananda  jeblair annegentle mtreinish
21:00:17 <dhellmann> courtesy ping for SpamapS ttx flaper87 SergeyLukjanov redrobot kiall bswartz
21:00:17 <asalkeld> o/
21:00:17 <dhellmann> who's around for the crossproject meeting?
21:00:20 <bknudson> hi
21:00:21 <morganfainberg> \_(^_^
21:00:25 <ttx> o/
21:00:27 <mestery> o/
21:00:31 <SlickNik> o/
21:00:32 <mtreinish> o/
21:00:33 <SergeyLukjanov> o/
21:00:37 <bswartz> o/
21:00:40 <david-lyle> o/
21:00:41 <sdague> o/
21:00:43 <notmyname> here
21:00:46 <jokke_> o/
21:00:47 * redrobot is somewhat lurking... at mid-cycle right now.
21:00:52 <jungleboyj> o/
21:01:06 <dhellmann> nice turnout
21:01:08 <dhellmann> Our agenda:
21:01:08 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:01:09 * bknudson is also at mid-cycle
21:01:20 <dhellmann> first a quick announcement
21:01:22 <dhellmann> #topic stable/icehouse freeze
21:01:22 <dhellmann> #info we will be freezing stable/icehouse on Thu Feb 19 for the 2014.1.4 release
21:01:22 <dhellmann> #link https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Ficehouse_releases
21:01:22 <dhellmann> keep that in mind as you are reviewing backports in your projects
21:01:31 <devananda> o/
21:01:41 <dhellmann> is anyone from the stable team here? are you all blocked on anything for that release?
21:02:12 * dhellmann guesses not
21:02:21 <dhellmann> we have one main topic this week
21:02:23 <dhellmann> #topic Testing Guidelines
21:02:23 <adam_g> o/
21:02:30 <dhellmann> #link https://review.openstack.org/#/c/150653/
21:02:30 <eglynn> belated o/
21:02:36 <dhellmann> This is sdague's spec describing guidelines derived from our experience as a project with CI.
21:02:43 <dhellmann> sdague: I'll yield the floor to you to give more detail
21:02:45 <jokke_> dhellmann: I don't think glance has at least anything blocking
21:02:51 <sdague> dhellmann: sure, thanks
21:03:07 <sdague> so what's up there is an early draft, lots of good comments in there which need to be integrated
21:03:18 <nikhil_k> o/
21:04:06 <dhellmann> it looks like jeblair's feedback will make it into the next draft?
21:04:06 <sdague> the inspiration for this was what seemed like a lack of common framework to talk about testing in the project, as people have different levels of experience with it in general, and specifically in our project
21:04:21 <sdague> yeh, jeblair provided a lot of good context material in the last review round
21:04:43 <sdague> that made me realize I think we need more of that, plus some pictures to visualize what "functional testing" means when we say it
21:04:46 * morganfainberg needs to sit down and re-read + the comments on the spec
21:05:03 <sdague> we seem to have taxonomy challenges at times
21:05:13 <dhellmann> ok, it seemed like the other comments were more focused on wording or suggestions within the text, and those were a big broader in scope
21:05:35 <sdague> yeh, so I guess a couple of things for the cross project ask
21:05:54 <sdague> 1) do we believe this kind of spec doc will be helpful for the project going forward
21:06:10 <sdague> 2) are there other big ideas in here that got missed?
21:06:33 <sdague> 3) is my TODO list at the end seem good enough for what should change to get us to a landable state? (assuming point #1)
21:06:54 <ttx> 1) yes
21:06:54 <dhellmann> on point 1, I am generally in favor of writing things down. I think doing that here in the specs repo is better than the wiki for "policy" items (versus how-tos) because it gives everyone a chance to provide the review feedback
21:07:21 <dhellmann> on point 2, I think you have the big items, though I am sure we will amend and revise this over time
21:08:13 <dhellmann> on the todo list, does tempest already support running only a subset of tests as described?
21:08:20 <bknudson> I thought all projects were expected to integrate functional testing (e.g., keystone, python-keystoneclient)
21:08:38 <jroll> sdague: 1) yes, defining our goals is extremely valuable. I think people are unaware of where we want to be in the future with testing.
21:08:39 <sdague> dhellmann: yes, by TODO list I actually meant my final "review"
21:08:50 <eglynn> bknudson: the so-called in-tree func tests, right?
21:08:56 <sdague> as in the changes to the doc I think are needed
21:09:08 <bknudson> eglynn: yes, we've been working on it.
21:09:12 <dhellmann> sdague: ah, got it
21:09:13 <sdague> but tempest does support the subset
21:09:41 <sdague> yeh, I think this is one of those places where we said some words at summits, lots of teams are heading in these directions, some feel more comfortable with it than others
21:09:47 <flaper87> o/
21:09:53 <sdague> and hopefully this provides a baseline to reference
21:09:57 <eglynn> bknudson: seems to be covered by the concept of "co-gating units" in the spec?
21:09:57 <jeblair> o/
21:10:17 <jokke_> sdague: regarding your todo, I totally agree with your fear for bikeshedding if we start picking up examples
21:10:52 <eglynn> bknudson: i.e. the special case of a project "co-gating" just with itself ("keystone ... runs only keystone")
21:11:05 <bknudson> eglynn: yes, the testing spec here makes it clearer what we need to cover with our in-tree functional tests.
21:11:24 <sdague> bknudson: that makes me very happy to hear :)
21:11:24 <eglynn> cool
21:11:33 <sdague> as that was my goal
21:12:20 <sdague> so... I'll plan to do the next draft later this week, please provide other comments in the meanwhile.
21:13:18 <dhellmann> sdague: I expect that some of the implementation of this will run into liberty. Is that your expectation as well?
21:13:33 <sdague> once this is in some acceptable state, I'm going to propose a similar thing for "theory of upgrade" based on what we've heard from ops, as well as the grenade experiences. Hopefully, again to have a baseline for what projects need to think about for being upgrade friendly
21:13:54 <jokke_> ++
21:13:56 <mtreinish> dhellmann: yeah on the subset bit tempest supports it, we might miss a few tests depending on the service filter, but that's a bug which is simple to fix
21:13:58 <jroll> dhellmann: I would agree with that, this is a ton of work to do in a month
21:13:59 <sdague> dhellmann: I think a bunch of the test disagregation may be able to happen during kilo
21:14:11 <jroll> we can certainly make good progress in kilo
21:14:24 <dhellmann> adding the functional tests to projects is likely to take some time
21:14:26 <jroll> but projects are also slamming home features etc and that gets distracting
21:14:29 <sdague> dhellmann: agreed
21:14:38 <sdague> and will be an ongoing thing
21:14:44 <dhellmann> ok, just making sure my expectations matched yours
21:15:35 <sdague> in reality we probably should have a show & tell session in vancouver on project functional testing and what people are doing and what's working out well
21:15:43 <sdague> like the specs one we had in paris
21:15:47 <dhellmann> ++
21:16:03 <jroll> +1
21:16:14 <jroll> a small functional testing framework could be nice too
21:16:20 <jroll> I expect one will come out of this at any rate
21:16:35 <dhellmann> eglynn: what's the one you're using in ceilometer?
21:17:07 <sdague> dhellmann: you mean gabbi, that cdent is building?
21:17:12 <dhellmann> sdague: that's the one
21:17:18 <sdague> yeh, that looks pretty neat
21:17:29 <eglynn> sdague: gabbi is only for declarative API tests
21:17:32 <sdague> yep
21:17:48 <eglynn> i.e. not a fully general-purpose func testing framework
21:17:55 <eglynn> but very nice at what it does :)
21:18:12 <dhellmann> does it plug in to the existing test runner?
21:18:16 <jokke_> glance has pretty well covered in-tree functional testing ... noting fancy just straight forward
21:18:50 <eglynn> dhellmann: yep, that's one of the options ... it's quiet flexible
21:18:57 <sdague> ok, so we're probably starting to drift from the review a bit :)
21:19:20 <sdague> so I'd say, please provide more feedback over the next couple of days, I'll start my new draft on thur/fri
21:20:28 <dhellmann> does anyone want to highlight any comments already made, or ask questions about the content?
21:21:37 <dhellmann> ok, if that's it then, let's move on
21:21:44 <dhellmann> #topic GSoC 2015
21:21:56 <dhellmann> It's that time again. We need Project Ideas and Mentors for Google Summer of Code participants for this year.
21:22:01 <dhellmann> #link https://wiki.openstack.org/wiki/GSoC2015
21:22:09 <dhellmann> Talk to dims or one of the other mentors about project ideas
21:22:36 <dhellmann> keep in mind the time-frame for when students are available might not match up exactly with the release cycle
21:22:54 <dhellmann> also, the project needs to be pretty well defined, but the mentors will be able to help turn ideas into project plans
21:23:07 <dhellmann> questions?
21:23:36 <ttx> dhellmann: what are the deadlines ?
21:23:56 <dhellmann> ttx: great question, and I don't see it there on the wiki page
21:24:06 <dhellmann> dims__: do you know the deadlines for gsoc?
21:24:27 <dhellmann> I'll get him to update the wiki page
21:24:49 <ttx> yes, that would help to get how urgent this is.
21:24:50 <dims__> dhellmann: yes, there's time - http://www.google-melange.com/gsoc/events/google/gsoc2015
21:25:02 <ttx> I think this time around we are not too late
21:25:08 <dims__> right ttx
21:25:11 <vkmc> hey :)
21:25:19 <dims__> hey vkmc
21:25:32 <jokke_> dhellmann: what is the scope? (Like something one person can do in couple of months, something that team of five can do in couple of months, etc.)
21:25:40 <ttx> Feb 20 Mentoring org application deadline
21:25:41 <vkmc> hopefully we are not... we have many students interested
21:25:50 <dims__> we are on #openstack-gsoc if you want to continue conversations later
21:25:51 <dhellmann> dims__, vkmc : do one of you want to answer jokke_ ?
21:25:54 <ttx> that leaves 3 days to make a decision ?
21:26:07 <dims__> jokke_: anything that can be done in one summer
21:26:21 <dims__> one person
21:26:21 <vkmc> jokke_, its expected that the student can finish the task during the internship
21:26:29 <jokke_> thnx
21:26:36 <vkmc> jokke_, but there are cases in where many students kept working afterwards anyway
21:26:38 <dims__> ttx: that's just for the org
21:26:43 <jokke_> so one person 2-3months ... check
21:27:08 <ttx> dims__: but you need mentors to sign up before so that you'e sure you have enough to run it, right ?
21:27:39 <dhellmann> for oslo we talked about the fact that graduating some of the incubated code might be too tricky for a newcomer to handle, but there will be some logging related features that we might be able to get them to work on
21:28:13 <dhellmann> the goal is to find a useful task that isn't just busy work and will improve the project
21:28:15 <dims__> ttx: we don't know how many slots we'll get from google, am sure we can fill them based on what we saw last year
21:28:26 <ttx> dims__: ack
21:28:28 <vkmc> dhellmann, that sounds really good
21:28:35 <dims__> dhellmann: +1
21:29:03 <dhellmann> I'm not sure if the logging stuff by itself is "big" enough, so we'll have to see
21:29:09 <ttx> random idea -- Google recently opensourced a cloud benchmark suite, would be awesome if that supported openstack
21:29:17 <jokke_> +++
21:29:26 <dims__> ttx: awesome, i'll dig it up and add to wiki
21:29:28 <ttx> (they currently support aws and GCE
21:29:37 <ttx> and Azure i think)
21:29:53 <ttx> dims__: it's arguably not an openstack thing though
21:29:54 <vkmc> ttx, +1
21:30:10 <ttx> it's more contribution to the whatveer-it-s-named Goggle project
21:30:19 <thingee> dhellmann: I think we've done fine in the past with gathering project ideas for the gnome outreach. might be the same here https://wiki.openstack.org/wiki/OutreachProgramForWomen/Ideas
21:30:22 <dims__> ttx: good point
21:30:46 <ttx> dims__: I guess we need to wait and see if google files that project for GSoC
21:30:47 <dhellmann> thingee: good cross-over
21:31:07 <ttx> thingee: you mean "outreachy" :)
21:31:49 <dims__> thanks for the time everyone, feel free to hop onto #openstack-gsoc
21:32:11 <dhellmann> dims__: thanks!
21:32:25 <dhellmann> that's all we have on the formal agenda for today
21:32:29 <dhellmann> #topic open discussion
21:32:37 <dhellmann> is there anything else we need to raise this week?
21:32:50 <morganfainberg> I'd just like continued feedback on the no db schema downgrades
21:33:11 <morganfainberg> i've updated the spec to address comments
21:33:13 <morganfainberg> #link https://review.openstack.org/#/
21:33:16 <morganfainberg> whoopse
21:33:25 <morganfainberg> #link https://review.openstack.org/#/c/152337/
21:34:28 <dhellmann> there are several other specs up for review: https://review.openstack.org/#/q/project:openstack%2Fopenstack-specs+is:open,n,z
21:34:57 <ttx> NB: The TC will rubberstamp the CLI sorting args one next Tuesday
21:35:05 <ttx> so last days to disagree
21:35:06 <sdague> the eventlet one seems weird for this repo - https://review.openstack.org/#/c/154642/
21:35:47 <ttx> sdague: it's a bit weird yes -- sounds like it could be a blog post :)
21:36:06 <ttx> but the, a specs is easie rto reference and update
21:36:07 <sdague> yeh, or dev docs somewhere
21:36:09 <jokke_> I'd like to have quick poll around ... I threw an e-mail to the list last week regarding retiring commits from review similar way as Nova is doing that seemed to get quite mixed opinions. Any other project doing that?
21:36:25 <dhellmann> sdague: we don't really have a good place for cross-project dev docs yet
21:36:39 <dhellmann> jokke_: "retiring commits"?
21:36:53 <sdague> dhellmann: should the todo then be working towards that instead of overloading this repo?
21:37:04 <sdague> dhellmann: abandoning them
21:37:06 <jokke_> dhellmann: abandoning commits where nothing has happened for long time
21:37:34 <bswartz> the system used to auto-abandon after 2 weeks -- why did it stop doing that?
21:37:47 <sdague> jokke_: in fairness, the nova policy includes 2 stuck conditions for why we think the commit is likely dead, it's not just old commits
21:38:02 <eglynn> bswartz: only if it had a negative vote already?
21:38:15 <jokke_> sdague: care to enlighten?
21:38:19 <bswartz> oh, perhaps
21:38:42 <thingee> eglynn, bswartz: no I do clean up on patches, and it does not auto abandon even if there are negative votes.
21:38:42 <sdague> jokke_: so if it has a Code-Review<=-2 and is more than 4 weeks old
21:38:52 <sdague> which means a core reviewer has blocked it
21:39:06 <notmyname> in swift we abandon old patches
21:39:12 <sdague> so that's not coming back without a conversation that's apparently not happening
21:39:27 <thingee> notmyname: yeah I just do them when I remember if they're older than a month with no activity.
21:39:31 <sdague> or if jenkins is -1, and again the commit is > 4 weeks without *any* activity
21:39:40 <notmyname> we send an email after a 4 weeks of no activity after a negative review. then we add it to an "abandon" queue two weeks after the email is sent if there's still no activity
21:40:01 <dhellmann> notmyname: do you track that manually?
21:40:02 <sdague> sorry, in the first case it's 4 weeks no activity as well. And no activity, means nothing
21:40:32 <notmyname> dhellmann: nope. one of our cores built the tool to do the emails and the list. (http://abandoner.oliver.net.au/abandoned_changes.html)
21:40:46 <notmyname> dhellmann: so on that, right now, there's 2 that need to be abandoned
21:40:56 <notmyname> and the abandoning is only done by hand. normally by me
21:41:13 <jokke_> sdague: so what I proposed was quite similar as in >4 weeks old, - review (even from jenkins) and try to establish communication to get it moving
21:41:54 <sdague> jokke_: yeh, the nova one is an automatic sweep, but leaves a comment about why it was abandoned and what the person should do to get the patch rolling again
21:41:57 <jokke_> and yes I do agree that it needs to happen by hand to be smart ... logic like that would be bad to automate fully
21:42:07 <jokke_> sdague: ok
21:42:25 <sdague> honestly, in looking at the restores, I think a lot of contributors don't realize that a jenkins -1 bit of code won't get reviewed
21:42:57 <dhellmann> jokke_: this thread? http://lists.openstack.org/pipermail/openstack-dev/2015-February/056829.html
21:43:05 <jokke_> because I think it would be beneficial to not have them in the review for a year ... the objections seemed to be on the line "But we might hurt someones feelings if we abandon their patch after weeks of no response"
21:43:25 <jokke_> dhellmann: that's the one
21:43:52 <dhellmann> ok. as sdague and notmyname have pointed out, I think the thing to be sure of is that it's the submitter who hasn't responded -- and not abandon patches just because they haven't been reviewed
21:44:17 <jokke_> dhellmann: definitely .... that was the intention
21:44:18 <dhellmann> the timelines mentioned, several weeks, seem reasonable as well
21:45:01 <jokke_> my proposal was 5-10 days after reaching out for response, but I'm more than happy to adobt that 2 weeks
21:46:40 <dhellmann> jokke_: well, the other times mentioned for nova and swift were 4 weeks
21:46:42 <jokke_> is this something we want to establish common guide across the projects (if it's wanted to be done) or keep doing it as feel suitable per project workflow?
21:47:01 <notmyname> 4 weeks until we send an alert to the owner. then 2 more until we abandon it
21:47:09 <jokke_> dhellmann: 4 weeks + 2 weeks after reaching out I think was swift
21:47:14 <dhellmann> notmyname: thanks for clarifying, I missed that extra 2 weeks
21:47:25 <dhellmann> I think it's OK to let projects decide this on their own. If it becomes a real problem, we can revisit
21:47:54 <jokke_> thanks for your input. I'll take it back to glance meeting at thu
21:49:22 <dhellmann> sounds good
21:49:40 <dhellmann> is there anything else for this week?
21:50:28 <dhellmann> if no one objects, we can close the meeting a few minutes early, then
21:50:29 * SpamapS just now got courtesy ping
21:50:50 <Rockyg> ++
21:50:53 <SpamapS> did anybody have questions for me?
21:50:58 <dhellmann> SpamapS: it was very courteous, and waited until you weren't busy
21:51:13 <SpamapS> very courteous
21:51:25 <SpamapS> otherwise I have nothing to add and I'm always +1 to shorter meetings
21:51:44 <dhellmann> I don't think there was anything for you, so far
21:52:05 <dhellmann> thank you all for coming, enjoy your 8 minutes of freedom!
21:52:08 <dhellmann> #endmeeting