20:03:06 <Rockyg> #startmeeting log_wg
20:03:07 <openstack> Meeting started Wed Apr  1 20:03:06 2015 UTC and is due to finish in 60 minutes.  The chair is Rockyg. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:10 <openstack> The meeting name has been set to 'log_wg'
20:03:17 <bknudson> hi
20:03:30 <Nikolay_St> o/
20:03:41 <Rockyg> Hey there.  We have a new attendee...ekudryashova
20:04:02 <Rockyg> I believe she started the API error codes debate on the ML
20:04:13 <jokke_> o/
20:04:32 <Rockyg> Yay, jokke_ !
20:04:47 <Rockyg> So, old business
20:04:48 <jokke_> "It's alive!" :P
20:04:55 <Rockyg> #topic old business
20:05:46 <Rockyg> I got swamped at work and haven't gotten the spec in.  jokke_: if I email it to you, can you push it to git review?  I haen't had time to get that working on the new 'puter
20:06:40 <Rockyg> It's not as complete as I'd like it, but getting it out there with comments is more important as the meat is all there
20:06:46 <jokke_> Rockyg: sure, I'll try to find time for that
20:07:06 <ekudryashova> Yes, I'm interesting in error-codes direction. Also while we have freeze and all of thoose things I'll be glad to help with improving log consistency. If you have some "todo" lists for this please share with me
20:07:37 <Rockyg> jokke_:  Thanks.  Should just be the add to cloned repository and git review
20:08:30 <Rockyg> ekudryashova:  Reviewing the spec will go a long way.  We also are looking to get some other focused specs out there.
20:08:30 <jokke_> Rockyg: cool, sure
20:09:08 <jokke_> ekudryashova: good to see you here. Maybe we get that one finally moving as well
20:09:14 <Rockyg> Any other old business?
20:10:09 <Rockyg> OK.  New business
20:10:27 <Rockyg> #topic API logging spec available
20:10:57 <Rockyg> Everett Toews just pushed out a spec and we need to jump on it.
20:11:10 <jokke_> do we have a link?
20:11:53 <Rockyg> #link  https://review.openstack.org/167793
20:12:08 <Rockyg> "A guideline for errors"
20:12:13 <bknudson> clippy go away
20:12:53 <Rockyg> This is for format in the message body, the "payload"
20:13:49 <Nikolay_St> I've taken a look at it. Looks good at first glance
20:13:50 <bknudson> hopefully all the projects can use this and have a consistent error document...
20:13:53 <jokke_> I'll review that after this meeting
20:14:01 <Rockyg> bknudson:  how come I get clippy, too?
20:14:02 <bknudson> clients need to understand it, too.
20:14:28 <bknudson> and CLI
20:14:29 <Rockyg> I think devs and ops do, too ;-)
20:14:31 <jokke_> 4/1/15 :)
20:15:12 <bknudson> there's a couple of reasons that the error doc from keystone is generally useless --
20:15:16 <Rockyg> This proposal is for all APIs across OpenStack willing to play nice and head towards consistency
20:15:17 <bknudson> 1) don't want to give away info
20:15:28 <bknudson> 2) poor code design so we don't always have the right error
20:15:42 <bknudson> errors in keystone are generally pretty basic, though... user didn't exist or whatever.
20:16:25 <bknudson> I like that it's a list of errors since if you're doing input validation there can be multiple errors
20:16:59 <bknudson> although we'd need to enhance input validation to get a list of problems rather than just a generic 400 error.
20:17:20 <Rockyg> bknudson:  ++
20:17:40 <Nikolay_St> bknudson: you're right
20:17:54 <Rockyg> So, everyone, please review and *comment*  Once you comment, you'll get  notification of all comments and changes
20:18:26 <Rockyg> We can discuss progress at next meeting, or add to the ml thread
20:18:58 <Rockyg> And we need to advertise to ops ml once we think it's ready for their input
20:19:28 <Rockyg> anything else on this?
20:20:20 <jokke_> could someone decode that spec for me and tell what the heck is proposed?
20:22:01 <bknudson> it's the document that gets returned when there's an error...
20:22:13 <bknudson> currently I think every service does their own thing.
20:22:36 <bknudson> e.g., if the server returns a 500 error or 400 or whatever.
20:22:51 <Rockyg> It looks like error codes *in error body* is being proposed?
20:23:22 <Rockyg> Or am I misreading?
20:23:31 <Nikolay_St> i tjink not
20:23:59 <bknudson> yes, error codes in the entity-body of the response.
20:24:21 <Rockyg> Hmmm.  error codes should be part of header with body containing details of error instance
20:24:32 <bknudson> the 500 or 400 code in the status line doesn't provide enough info.
20:24:49 <ekudryashova> In my opinion the biggest fix there is every project will return one type payload(json) instead of string, dict or everything else returned now in response
20:26:19 <jokke_> I'm surprised that it's not proposed to be base64 encoded for even worse readability ;)
20:26:36 <Rockyg> ekudryashova: error codes aren't in guidelines *yet*  That's what our spec (out soon) will be
20:27:13 <Rockyg> Well, let's get our spec out there and post to the thread as part of the response?
20:27:33 <ekudryashova> They is in payload, as I understood they not actually pay attention on structure of code itself and let it be another question
20:28:03 <Rockyg> Ah.  I think you are right
20:29:15 <Rockyg> ekudryashova: So, what we are attempting to do is define a structure for error messages through a series of cross project specs.  One is error codes.  Another is referrer ids
20:30:15 <Rockyg> We need someone to write the second.  There is a dev who already proposed a project specific spec for that that we should work with
20:30:48 <Rockyg> I think referrer IDs will need to be part of the payload, not header
20:31:05 <Rockyg> anyway, let's get our spec out and make a bunch of comments on this one.
20:31:16 <jokke_> ++
20:31:47 <Rockyg> #topic hacking rules for oslo.log
20:32:26 <Rockyg> New ml thread on this.  appears a number of projects have hacking rules for log messages, and the discussion started yesterday on this.
20:33:33 <Rockyg> ekudryashova: have you seen the wiki and etherpads for logging group?
20:34:14 <ekudryashova> Rockyg: I saw wiki but no etherpads
20:34:57 <Rockyg> Ah.  the etherpads actually have more detail on the general consensus of where to go with getting logs more consistent and better
20:36:19 <Rockyg> I think they are all linked on the main working group page:  #link https://wiki.openstack.org/wiki/LogWorkingGroup
20:36:39 <Rockyg> I was/am trying to summarize them into something more consistent/readable
20:36:49 <ekudryashova> Thanks, will take a look
20:37:19 <Rockyg> But, they help in getting on the same page and asking questions/suggesting actions
20:37:49 <jokke_> so Rockyg about the hacking rules, what about it or was this just to promote the ml conv?
20:38:57 <Rockyg> So, the thread has a list of checks that Cinder has put in.  Neutron says they have some, too.  I think maybe we can propose a list of these in a cross project spec
20:39:06 <Rockyg> Then the projects can take them or not
20:39:21 <bknudson> these changes are going to go in the global hacking checks
20:39:34 <Rockyg> And we add new ones as specs get approved
20:39:39 <Nikolay_St> Rockyg: where we can read about it??
20:39:50 <Rockyg> Lemme find the link to the mail....
20:39:53 <bknudson> at least in keystone we try to enforce all the global hacking checks.
20:41:19 <Rockyg> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/060299.html
20:42:14 <Rockyg> and #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/060361.html
20:42:45 <Rockyg> This could be a good, focused spec that ekudryashova could put together.
20:43:28 <Rockyg> Should move through cross project quickly.  shouldn't be too controversial.
20:44:01 <ekudryashova> Ok, give me a details and I'll be glad to make it
20:44:10 <Rockyg> Then, they could go in the global and projects could turn on or off as they like.
20:45:05 <Rockyg> ekudryashova: let's take the details to email... I might be slow until Monday.  Taking Friday off and in-house conference tomorrow.
20:45:46 <ekudryashova> Rockyg: Thanks, will wait for email
20:46:05 <Rockyg> Anyway, #action ekudryashova to put together spec with hacking rules for oslo.log stuff
20:46:31 <Rockyg> #action ekudryashova to put together spec with hacking rules for oslo.log stuff
20:46:58 <Rockyg> #action ekudryashova to put together spec with hacking rules for oslo.log stuff
20:47:18 <Rockyg> Hmmm.  Why doesn't that take?  Anyway, next topic
20:47:29 <Rockyg> #topic Summit planning
20:47:53 <Rockyg> We've got to think about two tracks:  Ops and dev
20:48:18 <jokke_> ++
20:48:52 <Rockyg> I think on Ops, we should plan to provide status of current efforts, then get some consensus on next items to focus effort on
20:48:57 <jokke_> do we have any possibility to actually gather together and make a proper battle plan for Liberty? :P
20:49:19 <Nikolay_St> I don't have plans to go on summit
20:49:38 <Nikolay_St> other guys from Sahara has it as I know
20:49:45 <Rockyg> We could meet Sunday or Monday and do some tactical planning, but I think we need to get strategy before then.
20:50:18 <Rockyg> nikolay_St: sorry to hear that.
20:50:39 <Rockyg> So, I think we need to go for a cross project slot for dev.  do we need more than one?
20:51:41 <Rockyg> Anyone?
20:51:53 <Rockyg> And, one slot or two for ops?
20:52:33 <Rockyg> And, do we target projects to socialize our specs?
20:52:43 <Rockyg> I know we don't have to worry about glance;-)
20:53:18 <Rockyg> crickets
20:53:43 <Rockyg> tumbleweeds
20:54:05 <jokke_> I'll be arriving to Vancouver Fri evening and have my talk at Mon (I think it was one of the last sessions) so I can meet up FE. earlier Mon (Long lunch maybe)
20:54:18 <bknudson> I'd try to attend a logging session.
20:54:25 <Nikolay_St> I think Sahara is interesting :)
20:55:02 <Rockyg> OK.  bknudson: can you socialize the specs we have out by then to Keystone?
20:55:13 <bknudson> sure.
20:55:33 <Rockyg> Cool.
20:55:40 <jokke_> Rockyg: I'd like to have x-proj slot and ops slot ... best case scenario would be x-proj slot, ops slot, x-proj slot but either of the x-proj slots could be replaced by unofficial
20:56:28 <Rockyg> I know we can get an ops slot.  Teh xproject slot is a bit more iffy.  I'll go out to the ops etherpad and put up a proposal
20:56:45 <jokke_> so that we could give ops update where we are, plan future and get their feedback and after that get togther and fix that feedback into the L-plans for us
20:57:10 <Rockyg> jokke_ that sounds great.
20:57:56 <Rockyg> I think we need to educate ourselves on the current state of oslo.log and the syslog RFC.  Then we can see where we are and where we want to be.
20:58:17 <Rockyg> oslo.log has a lot more documentation now, from a dev perspective.
20:59:22 <jokke_> Rockyg: ok, I clearly need update myself on oslo.log
20:59:24 <Rockyg> syslog allows for *too much* flexibility, so we need to see what might be the right set of constraints to make logs consistent and usable to the collection of projects that is OpenStack.
20:59:48 <Rockyg> Yeah.  FYI: oslo.log is now 1.0.0 released
21:00:32 <jokke_> well with bit tent, don't hold your breath waiting that to happen, but if we could get the core services to reasonable state, that would be good
21:00:41 <Rockyg> #link http://docs.openstack.org/developer/oslo.log/
21:01:13 <jokke_> problem seems to be that few projects and ever fewer people really seems to care about logging on our dev community
21:01:24 <Rockyg> jokke_: yeah.  I'm calling them foundational projects to get away from core
21:02:06 <Rockyg> Folks, with the Product Team out there now, logs are going to get more attention.
21:02:37 <jokke_> sorry to interrupt, but is there someone waiting for next slot, we're over time
21:02:38 <Rockyg> There will be more and more pushback to getting the projects more usable and productizable.
21:02:55 <Rockyg> Oops!  No one, but let's call it.
21:02:58 <Rockyg> #endmeeting