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