21:02:04 <dhellmann> #startmeeting crossproject
21:02:05 <openstack> Meeting started Tue Apr 14 21:02:04 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:09 <openstack> The meeting name has been set to 'crossproject'
21:02:12 <tpatil> HI
21:02:14 <ttx> courtesy PTL ping: devananda, dhellmann, morganfainberg, notmyname, eglynn, nikhil_k, thingee, asalkeld, david-lyle, mestery, SlickNik, SergeyLukjanov, mikal: around ?
21:02:17 <thingee> o/
21:02:17 <david-lyle> o/
21:02:20 <mestery> i/
21:02:20 <fungi> howdy
21:02:21 <mestery> o/ even
21:02:21 <notmyname> hello
21:02:22 <devananda> \o
21:02:22 <dhellmann> ttx: thanks
21:02:23 <krtaylor> o/
21:02:26 <jogo> o/
21:02:33 <ttx> I'll be around, watching swift patches in gate
21:02:36 <stevebaker> \o
21:02:37 <dstanek> hello
21:02:55 <etoews> hi
21:02:58 <bknudson> ??
21:03:02 <dhellmann> cool, let's get started
21:03:05 <dhellmann> #topic Any Kilo release red flags ?
21:03:12 <nikhil_k> o/
21:03:18 <morganfainberg> o/
21:03:22 <mikal> Hi
21:03:32 <dhellmann> are there any issues that would delay release candidates, require new candidates, delay branching, etc.?
21:03:49 <mikal> I think we'll need a RC2 in nova
21:03:50 <dhellmann> gordc/eglynn are looking at some things with the ceilometer client
21:03:52 <notmyname> swift is waiting on the last patches to make it through the gate right now
21:04:01 <notmyname> #link https://review.openstack.org/#/c/172573/
21:04:20 <notmyname> when that lands, we'll have an RC
21:04:30 <dhellmann> notmyname: cool
21:04:46 <dhellmann> ttx and I are going to be working on the requirements repo branch tomorrow
21:05:05 <ttx> we'll need RC2s for everyone
21:05:14 <mikal> dhellmann: nova has two critica bugs marked as kilo-rc-potential at the moment
21:05:16 <ttx> (maybe not swift)
21:05:26 <bknudson> you cappin' 'em cap'n?
21:05:31 <ttx> mikal: we plan to open a RC2 window for nova at end of week
21:05:32 <dhellmann> mikal: ok
21:05:41 <ttx> as discussed with john
21:05:41 <dhellmann> bknudson: yeah
21:05:52 <mikal> ttx: can we announce that on the list so people know the timeline for the yet-to-be-fixed bugs?
21:06:09 <ttx> mikal: the trick is.. as soon as you mention a RC2 publicly people stop testing RC1. Go wonder
21:06:18 <SergeyLukjanov> o/
21:06:18 <fungi> according to https://status.rackspace.com/ the gate weather could be a little unfavorable, so just a heads up
21:06:31 <dhellmann> fungi: thanks
21:06:54 <fungi> since i know many of you are waiting for final patches to land before tagging things
21:06:57 <ttx> mikal: you can say that it would be better to fix known issues by EOW so that they can be backported back to any RC2 that might be coming though
21:07:05 <thingee> ttx: that would help with the potential rc bug we talked about in 1on1 for cinder.
21:07:12 <thingee> ttps://bugs.launchpad.net/cinder/+bug/1421492
21:07:21 <mikal> ttx: ok
21:07:41 <gordc> dhellmann:  regarding ceilometerclient, i'll sync with eglynn but we'll probably looking at cutting ceilometerclient 1.0.14 unless we find any breaking changes since last release.
21:07:51 <dhellmann> gordc: sounds good
21:08:13 <dhellmann> ok, are there any other issues we need to raise before we move on?
21:08:25 <thingee> clarification, are we still bumping cinder to 1.1.2?
21:08:30 <thingee> cinderclient
21:08:50 <ttx> thingee: why do you need that bump for ?
21:08:51 <thingee> I've been a bit confused in the ML and playing catch up after pycon
21:09:01 <dhellmann> thingee: we don't usually bump the minimum for patch releases
21:09:11 <thingee> k thanks
21:09:29 <thingee> ttx: I don't have anything pressing. just people angry for the sake of a new release.
21:09:31 <dhellmann> thingee: the current requirement is >=1.1.0 and we'd cap that as >=1.1.0,<1.2.0 so 1.1.2 could be used if there
21:09:53 <ttx> thingee; you would rather do a 1.2.0 after we cut the stable/kilo branch
21:10:05 <thingee> ttx: got it
21:10:05 <ttx> if it's a featureful release
21:10:10 <thingee> yup it is
21:10:17 <dhellmann> ah, yeah, that should definitely wait
21:10:45 <ttx> FWIW next cycle we'll more aggressively adopt the Oslo model everywhere
21:11:06 <ttx> i.e. branch earlier
21:11:24 <ttx> everywhere = for every openstack lib
21:11:28 <dhellmann> right, in general we want to release clients early and often, just like the other libs
21:11:53 <thingee> dhellmann: I plan to imrpove this in my process. and sorry to people who were angry with me this morning.
21:12:01 <dhellmann> one of my early tasks for liberty will be to document the release tools we have put in place to make lib releases easier, so we can be consistent with things like release notes
21:12:02 <fungi> everywhere should = everything in global-requirements.txt
21:12:11 <fungi> which we also host in our gerrit, that is
21:12:18 <dhellmann> fungi: right
21:12:37 <mestery> dhellmann: ++
21:12:59 <dhellmann> so let's talk about some specs now
21:13:01 <dhellmann> #topic cross-project spec: Return request ID to caller
21:13:06 <dhellmann> #link https://review.openstack.org/156508
21:13:08 <tpatil> We have submitted a new patch set  to log request ID mappings across service boundaries
21:13:17 <tpatil> We have worked as per Doug’s suggestion to store x-openstack-request-id in the thread local storage of the client. Then exposed get_openstack_request_id method to retrieve this request id to the caller
21:13:20 * rockyg Thanks dhellmann!
21:13:32 <tpatil> Advantages of this proposed design
21:13:42 <tpatil> 1) Doesn’t break compatibility (if the service doesn’t require logging request id mapping then also it can use the newer version of the client)
21:13:49 * dhellmann needs to read the latest draft of the spec
21:13:51 <tpatil> 2) Minimal changes to the python-*client code.
21:14:14 <tpatil> Request everyone to please review the specs
21:14:23 <tpatil> We have already implemented this proposed design in python-cinderclient
21:14:30 <tpatil> Add support to return request_id to the calling service
21:14:32 <dhellmann> tpatil: it sounds like my concerns were addressed
21:14:33 <tpatil> #link https://review.openstack.org/#/c/173199/
21:14:41 <bknudson> seems like this could be handled in the keystoneclient session code.
21:14:46 <tpatil> dhellman: Yes
21:14:50 <dhellmann> tpatil: have you identified any issues implementing this outside of cinder, where the tools (particularly on the server side) might be different?
21:14:51 <tpatil> log request-id mapping of nova and cinder
21:14:58 <tpatil> #link https://review.openstack.org/#/c/173234
21:15:05 <mtreinish> oh, wasn't this an old nova spec/bp from like a year ago?
21:15:17 <morganfainberg> bknudson, agreed this looks like something that could be in session
21:15:22 <mtreinish> I thought there was some work done on getting this with glanceclient before
21:15:29 <tpatil> yes, we have done testing with nova. Also tested in multi thread environment.
21:15:36 <bknudson> a single python API call could result in multiple requests... e.g., if your session got a fresh token.
21:16:14 <dhellmann> lots of good points, please post comments on the review
21:16:15 <tpatil> dhellman: We haven't found any issues there
21:16:24 <tpatil> sure
21:16:28 <rockyg> a cross project session for this would be great -- especially to get ops folks to give their log needs
21:16:48 <thingee> tpatil: I'm happy to see this this is now returning from the explicit get_request_openstack_id()
21:16:58 <thingee> tpatil: instead of just from calls like list()
21:16:59 <tpatil> Should I propose a session to address these changes?
21:17:06 <dhellmann> rockyg: we'll be talking about how to propose sessions in a bit
21:17:12 <tpatil> ok
21:17:27 <dhellmann> tpatil: you're welcome to propose it, yes (I can't promise whether we'll have time for it)
21:17:52 <mtreinish> also we've had this session at least once in the past (I think in HK) and it just never has been pushed to completion
21:18:08 <tpatil> ok, I will submit a session
21:18:16 <mtreinish> that's why this is about mapping ids instead of letting clients set the id
21:18:25 <bknudson> trick is we can't trust the client.
21:18:37 <dhellmann> right
21:18:38 <mtreinish> yep
21:18:46 <bknudson> and maybe that just means not accepting a really long request ID.
21:19:18 <mtreinish> bknudson: no I think mapping is the right solution here, just get the services to log request ids between rest calls to other things
21:19:34 <mtreinish> I was just giving historical background
21:19:44 <bknudson> right, the danger is if it's a really long request ID then that's a DoS on your logs.
21:19:48 <dhellmann> it sounds like there are several people here with insight into the problem and its history, so please do post comments on the review to help nudge it in the right direction
21:20:06 <rockyg> ++
21:20:34 <mtreinish> bknudson: is that a real concern, everything should be using the same oslo lib for getting the req-id
21:20:37 <mtreinish> dhellmann: sure will do
21:21:34 <dhellmann> mtreinish: thanks
21:21:45 <dhellmann> so let's move on to the next spec...
21:21:50 <dhellmann> #topic cross-project spec: OpenStack wide Error Codes for Log Messages
21:21:54 <tpatil> bknudson: we can make this configurable if you don't need to log request id mapping.
21:21:54 <dhellmann> #link https://review.openstack.org/#/c/172552/
21:22:22 <rockyg> Lots of great comments I need to incorporate in.
21:22:43 <dhellmann> This is the one from rockyg and jokke_ about creating standard message identifiers
21:22:49 <rockyg> Tomorrow's log_wg meeting will get clarity on some of that
21:23:07 <dhellmann> yes, there's a good bit of feedback in the comments right now
21:24:05 <dhellmann> rockyg: I think the thing to keep in mind here is to keep the solution simple, to avoid needing to do a lot of coordination or making lots of application-level changes
21:24:44 <rockyg> agreed.  And being specific.
21:25:12 <dhellmann> we should also think about whether there are ways to use data we already have, like the logger module name and exception class name, to avoid requiring us to produce the results we want with less work
21:25:19 <rockyg> A definitions section should help.
21:25:22 <dhellmann> ++
21:25:34 <rockyg> ++
21:25:53 <dhellmann> also, we need some volunteers to sign up to do some of the work -- my name is there only for related work in oslo.log :-)
21:26:29 <rockyg> I think once we have a solid spec and some example code, we can get more volunteers.
21:26:51 <rockyg> I'm also hoping this can be done as a "while you're in there
21:27:06 <rockyg> kind of thing.  So old doesn't break new.
21:27:15 <rockyg> Or vice versa?
21:27:38 <dhellmann> rockyg: ok. I'd be reluctant to approve a spec without someone signed up to implement it, but we can address that when the other issues are handled
21:28:07 <rockyg> dhellmann: right, but we might want to get per project sign-ups
21:28:52 <dhellmann> rockyg: I'd also like to see if we can figure out a way to meet the requirements without having to touch lots of messages, so think about (and describe) the ultimate goal, as well as the proposed implementation
21:29:15 <dhellmann> rockyg: yep, you should be starting to get some support from projects now -- that's the whole point of this cross-project spec process
21:29:20 <rockyg> I'll be recruiting heavily at the summit, too
21:29:57 <rockyg> Also, great idea, dhellmann. if we can sprignboard on what oslo.log already knows, so much the better.
21:29:58 <bknudson> is there going to be a library for it?
21:30:30 <dhellmann> bknudson: once we figure out what "it" is, I would expect most common pieces to go into oslo.log. It's not yet clear that there needs to be any coding, though.
21:30:47 <dhellmann> it's also not clear that oslo.log is the best place, if we're talking about errors returned through the REST API
21:31:17 <dhellmann> shall we move on to summit planning?
21:31:22 <dhellmann> #topic Design Summit Cross-project sessions brainstorming
21:31:48 <dhellmann> ttx has set up a google doc to hold session topics, since the etherpad we used last time got pretty messy and hard to work with
21:31:49 <dhellmann> #link submit a session proposal http://goo.gl/forms/S69HM6XEeb
21:32:03 <dhellmann> that form feeds data into a spreadsheet:
21:32:04 <dhellmann> #link review submission proposals https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit?usp=sharing
21:32:16 <dhellmann> the spreadsheet is locked, but anyone should be able to leave comments
21:32:52 <dhellmann> please keep in mind that we want these sessions to be about more than one project, usually more than 2
21:33:03 <geoffarnold> I'm concerned that we may be treating two different types of issues as "cross-project": initiatives involving work in a couple of projects, and housekeeping stuff affecting all the projects (like version IDs and RC coordination
21:33:11 <ttx> So if you have a cross-project issue that could use some F2F time to see a quick resolution, ple�ase consider adding it
21:33:19 <dhellmann> we have finite space and time, so we'll probably end up giving priority to broader topics, but they still need to have very clear and focused proposals
21:33:36 <etoews> is there a deadline for submissions?
21:33:42 <dhellmann> geoffarnold: yes, we'll sort that out when we review the proposals
21:33:48 <geoffarnold> thx
21:33:52 <dhellmann> geoffarnold: asking for a session does not guarantee that it is given :-)
21:33:58 <geoffarnold> of course!
21:34:06 <geoffarnold> I've been around long enough.................
21:34:10 <ttx> etoews: let me see what I put on that ML post
21:34:15 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/061070.html
21:34:24 <ttx> "We expect to process those starting the week of April 27, so it would be
21:34:24 <dhellmann> etoews: deadline is 26 Apr
21:34:24 <ttx> great to submit your suggestions before EOD April 26."
21:34:46 <etoews> ttx: you might want to add that deadline to the google form too
21:34:47 <ttx> That doesn't mean we won't take anythgin after that, but anything submitted after that might just be ignored.
21:35:00 <dhellmann> geoffarnold: k, we share a concern on this point
21:35:02 <stevebaker> ttx: are there sessions where operators and developers intermingle?
21:35:14 <dhellmann> stevebaker: there's an entire operators track this time around
21:35:20 <dhellmann> (again)
21:35:20 <ttx> stevebaker: all sessions ?
21:35:49 <ttx> Also we have the possibility to add sessions to multiple tracks this time around
21:35:58 <stevebaker> i mean about specific topics that concern operators *and* developers
21:36:08 <dhellmann> stevebaker: there's a draft agenda for the operator sessions at http://lists.openstack.org/pipermail/openstack-operators/2015-April/006730.html
21:36:11 <rockyg> ttx, stevebaker: well, when there isn't a more pressing session in an ops or dev track....
21:36:12 <ttx> so if you have a specific session you'd like lots of ops to come, you have the possibility to make it appear on the ops list
21:36:26 <rockyg> ttx: which is great!
21:36:39 <stevebaker> ttx: ah, ok
21:36:51 <rockyg> adn vice versa.
21:37:00 <dhellmann> ttx: nice
21:37:12 <ttx> Ops have sessions all Tuesday all Wednesday though, so don't expect miracles.
21:37:26 <ttx> I didn't make a lot of progress in the mastering of Timespace bending
21:37:30 <dhellmann> hmm, yeah, what happened to monday?
21:37:39 <ttx> Monday, no design summit
21:37:51 <ttx> and now Ops is in Design Summit, same days
21:37:51 <dhellmann> isn't that when we had the ops sessions last time?
21:37:54 <dhellmann> oh
21:37:55 <anteaya> it used to be ops day
21:38:00 <anteaya> :(
21:38:00 <ttx> That was a separate event
21:38:01 <geoffarnold> Is Friday going to be working sessions, like Paris, or what?
21:38:13 <ttx> yes, Friday is workign sessions only
21:39:17 <dhellmann> are there any other summit questions?
21:40:07 <dhellmann> #topic Open discussion & announcements
21:40:16 <dhellmann> does anyone have anything else to share?
21:41:11 <rockyg> question for doug: which chat rooms can you usually be found?
21:41:31 <dhellmann> rockyg: I'm usually in most of them, I think. #openstack-dev and #openstack-oslo are always easy
21:42:03 <rockyg> thnx
21:42:06 <fungi> i've also caught him skulking around #openstack-infra
21:42:17 <fungi> and #openstack-qa
21:42:23 <fungi> you know, all the important channels ;_
21:42:30 <dhellmann> fungi: you're telling all my secrets
21:42:58 <dhellmann> if there's nothing else to discuss other than my irc habits, I think we can say we're done
21:43:00 <rockyg> fungi: you're making dhellmann blush...
21:43:24 <dhellmann> thank you all, and please look at the cross-project specs mentioned here and the others proposed that we might need to hash out at the summit
21:43:40 <rockyg> Thanks!
21:43:42 <dhellmann> enjoy your extra 15 minutes :-)
21:43:57 <dhellmann> #endmeeting