14:02:30 <markwash__> #startmeeting glance
14:02:31 <openstack> Meeting started Thu Sep 11 14:02:30 2014 UTC and is due to finish in 60 minutes.  The chair is markwash__. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:35 <openstack> The meeting name has been set to 'glance'
14:02:38 <markwash__> hi everybody
14:02:45 <flaper87> o/
14:02:59 <zhiyan> o/
14:03:09 <jokke_> ehlo
14:03:19 <TravT> o/
14:03:23 <nikhil_k> o/
14:03:26 <lakshmiS> o/
14:03:35 <radek> hi there!
14:04:04 <ativelkov> o/
14:04:08 <markwash__> I added a little bit the agenda
14:04:21 <markwash__> https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:04:34 <markwash__> a few things that came up recently regarding our release(s)
14:04:44 <markwash__> so I'll jump right in
14:05:05 <markwash__> #topic client release
14:05:24 <markwash__> flaper87: thanks for releasing the client!
14:05:28 <flaper87> np
14:05:36 <markwash__> lakshmiS: what's the status of the bug fix?
14:06:14 <lakshmiS> markwash__: Just saw some few comments from zhiyah. will address it this morning
14:06:38 <flaper87> lakshmiS++
14:06:38 <markwash__> okay. let's do that pronto, or fall back to the other fix if we have to
14:06:53 * flaper87 is ready to release the client whenever that fix lands
14:07:03 <markwash__> I think each day with a problem with the client release is a day of pain for some nontrivial chunk of the world
14:07:26 <jokke_> that might take time ... looks like gate is stuck
14:07:32 <mclaren> should we take a look at putting https://review.openstack.org/#/c/115236/ in too? Or is that feature creep :-)
14:07:49 <zhiyan> +1!
14:07:51 <markwash__> jokke_: maybe we can ask for a bump when it passes check from the infra guys?
14:07:51 <mclaren> (that's the one where you get no help message if you didn't enter creds)
14:08:22 <flaper87> if that's a bug fix, I'd be happy to land it and then do the switch to i18n
14:08:36 <markwash__> flaper87: +1
14:08:38 <flaper87> it's really trivial and it does fix a bug
14:08:39 <jokke_> +1
14:08:42 <zhiyan> i'm open on it as well.
14:08:50 <markwash__> it looks simple enough to land
14:09:01 * flaper87 just +@'d
14:09:04 <TravT> i have a question on the client release.  it seems the zuul tempest tests didn't pick up backwards compatibility issues until the client was actually released.  is there a better process or something here to follow in the future?
14:09:05 <flaper87> +2'd, that is
14:09:33 <markwash__> TravT: I was wondering as well
14:09:48 <mclaren> yeah, running against the last stable release would be nice
14:09:55 <markwash__> mclaren: +1
14:10:15 <TravT> markwash__: I asked david-lyle about this and he said he's seen this happen to a number of the clients.
14:10:21 <jokke_> while waiting that to happen, do it with devstack ;)
14:10:23 <flaper87> mclaren: we can add a gate for that
14:10:33 <flaper87> it should be quite easy to do
14:10:49 <TravT> flaper87: +1 if we can automate, would be good
14:11:07 <markwash__> adding it to the gate would be perfect
14:11:14 <flaper87> I'm doing some work on that for Zaqar so, I'm happy to take glanceclient's too
14:11:17 <mclaren> flaper87 really? great! I'd assumed it would be hard, but that's just 'cos I wouldn't know how to do it ;-)
14:11:29 <markwash__> my early morning memory doesn't give me any more info about this particular problem
14:11:50 <markwash__> flaper87: <3
14:12:06 * flaper87 feels loved
14:12:22 <jokke_> *grouphug*
14:12:23 <markwash__> I'll also mention it in project meetings next week
14:12:26 <markwash__> lol
14:12:43 <markwash__> any other client release issues / thoughts before we move on?
14:12:54 * TravT pats flaper87 on the back
14:13:21 <markwash__> #topic juno rc1 status
14:13:35 <markwash__> so we "released" juno-3 last week
14:13:39 <markwash__> and made some FFEs
14:13:41 <markwash__> and landed a lot of them
14:14:04 <markwash__> #link https://launchpad.net/glance/+milestone/juno-rc1
14:14:07 <flaper87> thanks to everyone who helped me with reviews
14:14:16 <flaper87> just sayin'
14:14:18 <flaper87> :)
14:14:39 <markwash__> one quick question I had was about the remaining work on async processing
14:14:49 <markwash__> is there a new bp / spec for what's needed next?
14:14:57 <markwash__> there's still some patches out linked against this bp I think
14:15:06 <markwash__> nikhil_k / arnaud ^^
14:15:14 <nikhil_k> no bp yet mark
14:15:36 <arnaud> I am working on the task flow part markwash__ (I can create another spec)
14:15:37 <nikhil_k> there is 1 taskflow patch in glance
14:15:40 <jokke_> markwash__: also the spec folder has been waiting to land for a week nopw :D
14:15:51 <nikhil_k> and another glance client
14:16:05 <flaper87> I don't want to hijack the topic but  are we going to ahve a session about async workers at the summit? I think it'd be worth it.
14:16:07 <arnaud> also, I am 60% of the introspection code where we already had a BP for that in LP
14:16:18 <flaper87> I'm curious about a status udpate and future work
14:16:23 <arnaud> s/am/have
14:16:28 <flaper87> Mostly because I want to help
14:16:36 <flaper87> but I can do my homework and lookup that info myself
14:16:39 <flaper87> :D
14:17:17 <markwash__> sounds fine to me
14:17:21 <markwash__> :-)
14:17:48 <markwash__> arnaud rosmaita there are a few easy spec changes up for review if you get a chance
14:17:52 <markwash__> https://review.openstack.org/#/c/115807/ in particular
14:17:57 <markwash__> or I can ninja it now
14:17:58 <markwash__> :-)
14:18:00 <arnaud> sounds good
14:18:21 <markwash__> dhellmann also proposed some changes that add an RSS feed for when specs are updated/added
14:18:24 <markwash__> which seems kinda nifty
14:18:36 <markwash__> and each change is tiny and trivially easy to review
14:18:44 <markwash__> okay
14:18:48 <markwash__> back to juno rc1
14:18:58 <markwash__> so it looks like things there are mostly in order
14:19:05 <markwash__> the remaining "FFE" is jokke_ 's
14:19:24 <jokke_> markwash__: put that in the agenda as you had some concerns
14:19:43 <markwash__> and as we go through the bug day, we'll want to end up targeting release blockers at the rc1 milestone so we know to prioritize
14:19:49 <zhiyan> markwash__: do you think we can make conf-auto-gen change in juno as well? change just needds reveiw
14:20:26 <zhiyan> actually i see it's a bug instead of a feature ( there 's a bug report for it)
14:21:08 <markwash__> zhiyan: I think it probably could go in rc1
14:21:19 <markwash__> zhiyan: can you link the review again
14:21:28 <markwash__> anybody else have concerns about that review for rc1 ?
14:21:59 <zhiyan> https://review.openstack.org/#/c/104476/
14:22:23 <jokke_> I'm for it
14:22:34 <zhiyan> i will rebase it asap (due to https://review.openstack.org/#/c/120036/ )
14:22:56 <markwash__> zhiyan: I like the approach that was taken, having the separate opts module that aggregates lists of options
14:23:11 <markwash__> rather than having to group them where they are declared
14:23:20 <markwash__> okay great
14:23:29 <markwash__> any other thoughts about rc1 ?
14:23:44 <zhiyan> markwash__: good to know. and probably next step i can ask some education from infa team, to do that work in gate for each +Aed patch.
14:24:10 <markwash__> zhiyan: yes, that sounds good
14:24:24 <markwash__> is it time to talk about bug day?
14:24:26 <markwash__> I think maybe it is!
14:24:29 <markwash__> #topic bug day!
14:24:39 <jokke_> \\o \o/ o// o/7
14:25:03 <markwash__> etherpad for bug day rallying / tracking
14:25:11 <markwash__> #link https://etherpad.openstack.org/p/glancebugday
14:25:56 <markwash__> if everybody who is working together on bugs can add their nick(ish) to the top of that etherpad it will help
14:26:26 <markwash__> and there are lots of things we need to do, but I think our priorities are cleanup and triaging bugs that sound really bad
14:26:32 <markwash__> in case they are release blockers
14:28:02 <markwash__> heh, well that's about all I have about bug day except thanks
14:28:05 <jokke_> what we do about those historical ones?
14:28:27 <markwash__> thanks everybody who is breaking away from their regular stuff to improve the health of our project :-)
14:28:32 <markwash__> jokke_: historical ?
14:28:49 <jokke_> markwash__: there is like "wishlist" stuff from 2012 etc.
14:29:07 <jokke_> just sort by bug nr.
14:29:13 <markwash__> jokke_: lol
14:29:18 <markwash__> still wishing!
14:29:48 <markwash__> you can mark anything that you think should be closed as 'propose-close' tag
14:29:56 <markwash__> and I will periodically sweep through that list with a flamethrower
14:29:57 <jokke_> could we add "dream-on" tag that can be put on wishlisted ones that has not been done in two releases? :P
14:30:36 <jokke_> markwash__: cool
14:30:51 <TravT> jokke_: unicorn tag?
14:31:03 <jokke_> TravT: yeah ... it's that unicorn release
14:31:17 <markwash__> haha
14:31:43 <jokke_> markwash__: don't laugh ... U comes pretty fast on this release speed ;D
14:31:51 <markwash__> any other thoughts about bug day before we move on? :-)
14:32:42 <markwash__> we can keep coordinating in #openstack-glance and on the etherpad, feel free to throw whatever you want up there
14:33:02 <markwash__> #topic glance logging rework
14:33:16 <markwash__> jokke_: this is your ffe-ature right?
14:33:21 <jokke_> yeah
14:33:31 <jokke_> I'll start by shooting with a cannon
14:33:58 <markwash__> fire away
14:34:21 <zhiyan> (love 70-200)
14:34:22 <jokke_> So our logging guidelines states that all that operators might care should be INFO+ & INFO should not contain error related messages
14:34:52 <jokke_> thus, the bump up is quite heavy
14:36:01 <markwash__> I'm totally with that approach
14:36:16 <zhiyan> jokke_: may i know what's 'INFO+' ?
14:36:31 <markwash__> my question on the patch is, are 400 responses "errors" from the operators perspective?
14:36:41 <jokke_> zhiyan: LOG.{info, warn, error, exception, critical}
14:37:07 <zhiyan> what's the different with IINFO
14:37:14 <zhiyan> INFO*
14:37:31 <markwash__> I feel like they're usually just user errors and an operator can receive them at info level
14:37:59 <markwash__> it feels about on par with "this request succeeded": "this request failed because the user typed in the wrong string for container format"
14:38:38 <jokke_> markwash__: well that's the thing, is user error no error ... the example from the logging was that INFO should be preserved for stuff like "This part of service started" "SIGHUP reladed configs" "New store added"
14:39:22 <markwash__> jokke_: where do we put "POST /foo response 200" ?
14:39:34 <jokke_> markwash__: DEBUG ;)
14:40:23 <jokke_> markwash__: IMHO supportability wise, operator should be able to configure logging to WARN+ and still be able to support the users
14:40:53 <jokke_> markwash__: and that would just clean the startups, etc away
14:40:53 <markwash__> jokke_: ah neat I like that perspective
14:41:22 <markwash__> is there any tie breaker who can come in and save the day?
14:42:48 <markwash__> alas
14:42:49 <jokke_> guys! now is good time to chip in.
14:43:46 <TravT> Well I agree with jokke_ on the perspective that errors should not be info...
14:44:01 <TravT> but the user error seems a little low at debug
14:44:27 <markwash__> I guess the question is "are 'user errors' errors"
14:44:52 <markwash__> jokke_: would you mind if I fired off a quick email to the ML with that question?
14:45:25 <markwash__> I'm *almost* happy to roll over on this issue but just not quite there ;-)
14:45:27 <jokke_> I tried to look them bit in the line, that errors user might come to operator complaining that glance does not work, goes to warn and stuff where user should get sufficient message on their face telling, don't be stupid goes to debug
14:45:46 <jokke_> although, looking the questions in the non-dev mailinglist, it might not be enough ;)
14:46:13 <markwash__> yeah, I agree that the reporting of user errors shouldn't just go to debug
14:46:25 <markwash__> I guess we are a little verbose about user errors sometimes though
14:47:06 <jokke_> markwash__: that I could agree ... maybe we should revisit overall our message content (again) ;)
14:47:21 <markwash__> so some of the more extraneous messages about user errors in a given request lifecycle could be debug if the main ones are >debug
14:47:51 <markwash__> jokke_: okay I'll send an email and if we meet more stony silence you win :-)
14:48:04 <jokke_> markwash__: fine by me :)
14:48:14 <markwash__> :-)
14:48:16 <jokke_> markwash__: mailwars ;)
14:48:22 <markwash__> next up!
14:48:22 <mclaren> fwiw I think most operators run with debug (to get stack traces etc) http://lists.openstack.org/pipermail/openstack-operators/2014-March/004156.html
14:48:39 <markwash__> #topic functional tests and tempest
14:49:17 <jokke_> markwash__: this was mine also
14:49:40 <jokke_> looking the mailing list there seems to be projects moving their functional tests away from tempest
14:49:49 <markwash__> yeah
14:49:51 <jokke_> should we rething us moving in there
14:49:55 <markwash__> I noticed that trend as well
14:49:59 <jokke_> rethink
14:50:06 <zhiyan> i noticed some discussion as well
14:50:25 <markwash__> we could be bravely contrary, but probably ought not :-)
14:50:47 <jokke_> trying to swim up the waterfall?
14:51:06 <TravT> one line summary? why are they moving away from tempest?
14:51:56 <markwash__> I think the idea is that tempest is not scaling well in terms of maintaining tests. . .
14:52:00 <jokke_> TravT: one contributor seems to be at least getting reviews and stuff accepted in ... tempest folks apparently just do not know projects well enough to dare to jump in
14:52:15 <zhiyan> a proposed feature needs related functional cases cover it
14:52:28 <jokke_> zhiyan: and that
14:52:49 <TravT> thx
14:53:08 <markwash__> yeah I think its just a more sensible way of doing things if the original coder / group is the same one doing the functional tests too
14:53:16 <zhiyan> if feature code and testing code are separated, it may take trouble
14:53:28 <markwash__> but the challenge for projects is to maintain different ways running the whole system for certain tests
14:53:55 <markwash__> maybe tempest can become a helper for the setup of bigger functional tests, and we import them as a library?
14:53:58 <zhiyan> so i personally think a in-tree functional testing way is better the separated one
14:54:08 <markwash__> zhiyan: +1
14:54:09 <TravT> definitely better if the original coder / group provides functional tests.
14:55:09 <markwash__> for us, the question is just how to share system-level setup code with other projects, and how to separate / include functional testing concerns with the tests that run on developers laptops
14:55:10 <zhiyan> btw, i think this case just is similar with rally one
14:55:25 <zhiyan> in-tree plugins for load testing
14:56:06 <zhiyan> seems it's a cross-project question/issue, iiuc
14:56:50 <markwash__> zhiyan: yes, definitely cross project
14:57:09 <markwash__> so I'm curious if anyone has followed the discussion closely enough to know what steps we should take
14:57:15 <markwash__> and when
14:57:27 <markwash__> I haven't followed it as closely
14:57:28 <zhiyan> markwash__: so ,not sure if sean likes to give advice
14:57:38 <markwash__> oh, also we're about out of time
14:58:16 <markwash__> let's bump the remainder of this topic to next week
14:58:18 <jokke_> I haven't been following close enough either
14:58:22 <markwash__> #topic open discussion
14:58:34 <markwash__> re bug day: let's go get 'em !
14:58:57 <zhiyan> markwash__: do you think we should finish this list in Juno cycle ? https://etherpad.openstack.org/p/backports-glance.store
14:59:27 <jokke_> markwash__: when we should carve the rc1 out?
14:59:27 <TravT> i have question on bug tags.  will take to openstack-glance
14:59:48 <markwash__> zhiyan: yikes looks like we should
15:00:08 <zhiyan> good to know markwash__ , i'm just a little worried on fucntion regression
15:00:16 <jokke_> +1
15:00:21 <jokke_> we're on time
15:00:28 <zhiyan> thanks
15:00:35 <markwash__> thanks everybody
15:00:39 <jokke_> thanks!
15:00:41 <markwash__> #endmeeting