14:09:33 #startmeeting glance 14:09:34 Meeting started Thu Mar 27 14:09:33 2014 UTC and is due to finish in 60 minutes. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:09:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:09:38 The meeting name has been set to 'glance' 14:09:43 hi glance folks 14:09:47 sorry for the delay! 14:09:48 hi 14:09:49 o/ 14:09:50 hey 14:10:01 o/ 14:10:10 o/ 14:10:22 o/ 14:11:10 so I've got one update and then I think we should open up to some more topic suggestions 14:11:20 #topic opening up juno development 14:11:53 we are *so* close to opening up juno development, which will mean that feature work in master will no longer be frozen 14:12:01 wooo 14:12:09 There are a few blockers I know of 14:12:17 https://review.openstack.org/#/c/75898/ 14:12:37 https://review.openstack.org/#/c/75865/ 14:13:45 it looks like we might also need to address https://bugs.launchpad.net/glance/+bug/1298039 14:13:53 but that should be relatively easy (?) 14:14:02 (I'm just seeing it for the first time now) 14:14:21 https://review.openstack.org/#/c/83007/ 14:14:36 then we must land https://review.openstack.org/#/c/83133/ to give the signal to ttx to cut the release and open up juno 14:14:49 thanks zhiyan 14:15:01 markwash: thank you 14:15:27 markwash: and probably https://review.openstack.org/#/c/80674/ 14:15:53 once we open up juno, if there are any majorly complex changes, it might be worth waiting a little bit of time (one or two weeks) before we land them, just because it will be easier to backport fixes if we find any major bugs in the next week 14:15:56 +1 for the last one 14:17:01 okay looks like there is a bit more to be discussed around that last one 14:17:21 for the moment, any more questions about opening up juno development? 14:18:13 looks like a no, okay! 14:18:21 #topic agenda spike 14:19:05 I saw a note about tasks and taskflow on the agenda, do folks want to talk about that now, or defer to the later time and just report back on the discussion? 14:19:23 not sure if harlowja_away is here yet 14:19:47 okay cool, we can just wait. I'll try to at least lurk during that, if you guys have it in the #openstack-glance channel 14:20:00 other agenda suggestions 14:20:32 I have one 14:20:37 Can we discuss a bit about tags? 14:20:45 may be ameade1 can pitch in 14:20:52 it should not take long 14:20:57 jokke_: any question about tags? 14:21:38 * markwash jots down 14:21:44 flwang: yeah few ... they kind of fell on my lap as we have a person doing some v2 testing 14:21:55 it's about incorrect response for some of the calls. like HEAD on /images/details giving 500 <- courtesy ameade1 14:22:06 any other items before we jump in? 14:22:40 would like to reiterate on the nova bp in gerrit :) 14:23:02 sorry for the break in, but it would be nice if we can land task client code in https://review.openstack.org/#/c/48850/ 14:23:27 lol ok so what are we talking about? 14:23:38 ameade1: atm we're just listing things we *want* to talk about 14:23:46 markwash: i would like to know folks' toughs around auto glance.conf.sample generation 14:24:16 s/toughs/thought 14:24:32 zhiyan: +1 i have some thoughts around that 14:24:42 wow, seems like we should have a pre-meeting to jot all this down to the agenda etherpad 14:24:58 ameade1: folks: https://review.openstack.org/#/c/83327/ 14:25:27 the psutil thing shall be fixed in requirements and then synced back. If you confirm it i can approve https://review.openstack.org/#/c/81373/ 14:25:50 markwash: there is a thread on it on openstack-dev fwiw 14:25:52 okay, I added some notes to our agenda so we can roll forward 14:25:57 ttx: thanks for the heads up 14:26:08 #topic image tags (jokke_) 14:26:16 jokke_: care to introduce the topic? 14:26:44 yeah 14:27:15 So we are testing Image API v2 and and our testing person came back to me telling that all his tag related tests failed 14:27:50 so I have been digging into it past few days and realized that the tags operations in glance/api/v2/images.py were not implemented 14:28:36 I've trying to get those done, but effectively it seems that all the tests touching tags are treating them as regular property so they fell apart 14:28:56 ah I see 14:29:12 jokke_: so PATCH was added after tags, and didn't work for them yet 14:29:21 markwash: yes 14:29:24 we've been slowly moving the support for PATCH out to other attributes 14:29:36 but were there failures other than PATCH? 14:30:13 jokke_: good catch 14:30:30 The first was the set() passed to jsonutils.dumps() 14:30:39 I have WIP https://review.openstack.org/#/c/83046/ 14:31:12 my local changes seems to work with glance client well at the moment, but breaks the old tests 14:31:53 jokke_: would it make sense to separate the set() serialization fix from the patch functionality additions? 14:32:18 it seems like fixing set() serialization is a bug fix rather than an additional feature, which makes it higher priority at this point 14:32:36 So one question I had was do we want to be able to change the tags at once with something like {'op': 'replace', 'path': ['tags'], 'value': ['ping', 'pong']} 14:32:52 markwash: I can split it out to get it landing asap if wanted 14:33:28 jokke_: one other note on that front, I think it would be great if we *weren't* passing a set to the wsgi logic. Rather whatever serializer class that is returning a set right now should return a list I guess 14:33:58 so a slight tweak to that fix may be in order, if others agree 14:34:35 jokke_: I think we probably should support replacing /tags completely, if there are no particular difficulties you've seen? 14:34:54 jokke_: what is the problem, again? 14:35:04 PATCH for tags used to work 14:35:05 markwash: I agree, but bit like with the MultiDict I prefer having the sanitizer there even we would not hit on it even accidentally for next weeks/months instead of getting 500 out of the server 14:35:18 rosmaita: +1 i thought replace worked for tags 14:35:35 replace definitely does 14:35:40 markwash: I believe it could be easier to implement than cange all the tests around there 14:35:44 jokke_: fair point 14:37:11 rosmaita: okay, so is there any bug currently with replace? 14:37:22 no, don't think so 14:37:25 okay phew 14:37:41 and please forgive me for any ignorance ... I'm new guy on the loop. Name is Erno Kuvaja and I started to work with Glance full time just 3 -4weeks back 14:37:52 rosmaita: I certainly doubt so 14:37:57 jokke_: welcome! 14:38:07 all right I think that's settled then, fix the serializer and the wsgi serialization as bugs, add /tags/X support to PATCH in juno 14:38:12 jokke_: welcome! 14:38:13 welcome :) 14:38:31 rosmaita: As there is comment on the code that the tags part is not implemented yet 14:38:34 ;) 14:38:41 so you can't "add" /tags because it's a protected element 14:38:47 you cannot delete it, either 14:38:56 but you can replace the /tags with [] 14:39:04 which deletes all the tags 14:39:31 let's not get too bogged down now with what could just be bug reports 14:39:53 nikhil__: I think you had a brief note about some 500 errors you found? 14:40:18 well, ameade1 found HEAD on /images/details giving 500s 14:40:37 #link https://bugs.launchpad.net/glance/+bug/1297358 14:40:42 I'd a suggestion around different calls for Glance API giving back Allow header 14:40:57 like the above one 14:41:21 it stems from the MP https://review.openstack.org/#/c/78050/ 14:41:21 it would be cool to really iron out the api responses without adding too much complexity 14:42:09 it sure would be great if routes mapper would handle that for us 14:42:10 this is not a bug (on a bigger picture) however, a good usability experience 14:42:21 markwash: +1 14:42:24 the 500 error is probably some bug somewhere in our wsgi stack 14:42:27 yeah 14:43:06 it looks like this bug report is in order, can you add a comment about the allow header, nikhil 14:43:14 sure 14:43:18 it looks like the Allow header is required for a 405 so we'd better make sure its there 14:43:33 next! 14:43:44 #topic gerrit blueprints (arnaud__) 14:44:32 yeah: so did you guys got the time to look at what is happening for nova? what are your thoughts about it? 14:45:06 context: nova is going to use gerrit+launchpad for blueprints: gerrit as a way to iterate through the design 14:45:12 arnaud__: is that bp template really to use now? 14:45:18 not yet 14:45:27 several patches are out for review 14:45:33 to modify it 14:45:34 I skimmed throught that ML thread but didn't come out with as clear a picture as I wanted 14:45:38 but I think it is not too far 14:45:54 would they be using that process in juno? 14:45:57 (I think I just got lost in the comments) 14:46:00 ameade1: yes 14:46:10 should we let them try it out for awhile and work out the kinks? 14:46:38 +1 14:46:46 ameade1: sounds reasonable :) 14:46:53 i was going to try to prepare one (for 33409 stuff), but seems other comments say stop 14:47:09 ameade1: +1 from me 14:47:21 ok! so seems we have an answer :) 14:47:24 :-) 14:47:40 #topic task code for the client (flwang) 14:48:11 markwash: ameade has +2ed, so I need another bless on that 14:48:23 and it would be nice if anybody can help verify that :) 14:48:26 flwang: can you share the link? 14:49:14 https://review.openstack.org/#/c/48850/ 14:50:02 quick thought, is v2 the default version in glance yet? 14:50:07 do folks feel like the task stuff in the api is in the state where exposing it in the client makes sense? 14:50:10 or 'current' version? 14:51:09 YES! 14:51:13 markwash: i dont think it adds much more confusion than having it in the api 14:51:26 ameade1: +1 14:52:14 seems like a consensus of sorts. . if there are no objections then I'm fine with it 14:52:51 sounds like there are none :-) 14:52:58 next up! 14:53:08 #topic config generation (zhiyan) 14:53:21 zhiyan: can you give a little background and then I want to ask a question about it 14:54:19 ok, time always tight. i listed the benefits in the commit message: https://review.openstack.org/#/c/83327/ 14:55:35 jgriffith was working fairly late yesterday due to jenkins using a different version of the check sample config script which completely broke the gate for cinder 14:55:44 also, there is a ML thread about this too 14:56:24 i'm not to read up on either though 14:56:44 zhiyan: so my question is, how do we deal with different configs for different executables ? 14:57:24 I'm not very familiar with how the config generation works 14:57:36 markwash: good point. from nova and cinder (probably other projects), seems deployer need to take care that by themself. 14:58:03 #link http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg20428.html 14:58:23 ameade1: thanks 14:58:26 ameade1: thanks, i just can't find it out .. 14:58:36 #link https://review.openstack.org/#/c/83233/ 14:59:29 i *think* what happened with cinder yesterday is that config options changed in keystoneclient and that changed what the sample config looked like so the sample in master was out of sync 14:59:51 i'd like to avoid issues such as this in glance so i just want to make sure we understand them 14:59:56 gotcha 15:00:06 and i think even we go "sample config files should be ignored " way, the change #83233 is fine since i added genconf testenv for tox 15:00:33 ameade1: yes, keystoneclient 0.7.0 updated configs 15:00:48 zhiyan: It seemed like nova has just one config file and you are supposed to sort out for yourself how to split it up among the nova services, is that right? 15:01:18 markwash: time's up. we can talk this more in team irc? 15:01:56 let's close out for now in any case 15:02:00 thanks folks! sorry I was late 15:02:06 at least I was in the right room this time! :-) 15:02:07 Thanks 15:02:09 #endmeeting