14:00:35 <nikhil_k> #startmeeting glance
14:00:35 <openstack> Meeting started Thu Jul 23 14:00:35 2015 UTC and is due to finish in 60 minutes.  The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:38 <openstack> The meeting name has been set to 'glance'
14:00:39 <ativelkov> o/
14:00:42 <krykowski> o/
14:00:45 <bpoulos> o/
14:00:46 <nikhil_k> #topic agenda
14:00:48 <lakshmiS> o/
14:00:50 <mfedosin> o/
14:00:55 <nikhil_k> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:20 <dshakhray> o/
14:01:57 <flaper87> o/
14:02:01 <hemanthm> o/
14:02:09 <kragniz> o/
14:02:15 <agalkin> o/
14:02:16 <flaper87> (ish)
14:02:26 <flaper87> really bad internet connection where I'm at right now
14:03:19 <rosmaita> o/
14:03:20 <nikhil_k> Thanks all for joining
14:03:32 <nikhil_k> #topic Updates
14:03:38 <nikhil_k> #info mid-cycle
14:03:40 <nikhil_k> #link https://etherpad.openstack.org/p/liberty-glance-mid-cycle-meetup
14:04:10 <nikhil_k> #info We will do a video+audio conf with co-located midcycle
14:04:24 <flaper87> awesome
14:04:28 <nikhil_k> #info This would be our virtual meetup too
14:04:38 <flaper87> is the info for that on the etherpad?
14:04:46 <nikhil_k> #action all: please add your name timezone info against the session interested in
14:04:53 <flaper87> I'll try to be on-line... you know, TZs
14:05:04 <nikhil_k> flaper87: ^
14:05:23 <nikhil_k> We have it spread over 3 days for remote convenience
14:05:42 <nikhil_k> So that people from different tz can find it easier to get some face to face time
14:06:07 <nikhil_k> For the rest of period we will do brainstorming + fun activities if not usual work
14:07:03 <jokke_> o/
14:08:11 <mclaren> Would having some v3 discussion be worthwhile?
14:08:36 <nikhil_k> sure, I have to add some more sessions.
14:08:58 <nikhil_k> mclaren: it would be most likely on thursday 30th
14:09:38 <mclaren> ok, cool. (Hopefully remote will work out ok for ativelkov and mfedosin)
14:10:01 <mfedosin> we have a good Internet connection, so yes :)
14:11:32 <nikhil_k> So, to help schedule the time please add some tz info against your name on each topic interested. Also, if you have conflicts at specfic times/days that would help
14:11:42 <malini_> good morning
14:12:04 <nikhil_k> moving on
14:12:21 <nikhil_k> #topic Glance Registry v2 and RPC calls
14:12:24 <nikhil_k> flaper87: ^
14:12:29 <krykowski> thats me
14:12:34 <krykowski> still digging through rolling upgrade issues, need some clarification
14:12:53 <krykowski> do I understand correctly that registry-v2 service is not required in my setup to have fully working Glance?
14:13:06 <mclaren> correct
14:13:09 <krykowski> it's just used as an optional component in api for accesing data from the database using RPC calls instead of direct access to the database
14:13:13 <krykowski> and despite registry service there are no other RPC communication in the Glance at all, right?
14:13:43 <nikhil_k> yep
14:14:07 <nikhil_k> krykowski: there's a possibility of rpc conn when using tasks (that's optional too)
14:14:28 <krykowski> great news, so I guess it will help a lot in performing rolling upgrades in Glance as we can setup only glance-api
14:15:02 <nikhil_k> krykowski: in case of tasks, you can setup a set of glance-tasks nodes
14:15:33 <mclaren> krykowski: I think it's great someone is thinking about rolling upgrades, it's an important consideration, which maybe hasn't got the attention it deserves
14:15:43 <nikhil_k> However, I think in that particular case I would think we don't need migration
14:15:46 <sabari> o/
14:15:48 <krykowski> woah, is it documented anywhere so I can get a better understanding of it?
14:16:08 <krykowski> I mean the glance-tasks service
14:16:13 <nikhil_k> nope, because that happens proxy via taskflow
14:16:25 <jokke_> krykowski: obviously that means that you can actually consume v2 API only as v1 API still needs the registry
14:16:55 <nikhil_k> krykowski: we can chat offline on that or better yet do it in the mid-cycle and identify if we are not going to touch tasks db-schema
14:18:00 <nikhil_k> flaper87: wanted to do some on the task info, but I think it would be a bad experience for a public cloud given the info fields can be gigantic
14:18:17 <nikhil_k> that was a tentative hint on the migration though
14:18:53 <flaper87> nikhil_k: oh I didn't want to do something on that, I was more asking why we had it
14:19:10 <nikhil_k> flaper87: hush, glad to hear it
14:19:36 <nikhil_k> two conflicting qually qualified use cases for that migration would be a nightmare
14:19:53 <nikhil_k> equally*
14:21:06 <nikhil_k> krykowski: do you have more questions?
14:21:33 <krykowski> nikhil_k: will ping you later about the tasks to better understand it
14:21:39 <krykowski> nikhil_k: for now I'm fine
14:21:52 <nikhil_k> thanks
14:21:54 <nikhil_k> #topic api requests and the req-body
14:22:02 <nikhil_k> bunting: ^
14:22:43 <bunting> Yeah, i am working on a bug, where if you provide a body to a http request when the api does not expect it it 500s
14:22:59 <bunting> I am wondering what the expected responce should be
14:23:11 <bunting> to ignore the body or return some error
14:23:18 <jokke_> bunting: you have a link for that bug?
14:23:29 <bunting> https://bugs.launchpad.net/glance/+bug/1475647
14:23:31 <openstack> Launchpad bug 1475647 in Glance "Returns 500 if a body is included where not expected" [Undecided,New] - Assigned to Niall Bunting (niall-bunting)
14:24:04 <mclaren> kragniz: you had some wisdom on this?
14:24:44 <nikhil_k> bunting: it's bad sematics to pass the body on verbs that ideally don't expect them
14:24:55 <nikhil_k> bunting: but it's possible nonetheless
14:24:57 <kragniz> mclaren: not so much, people seem to be split on what to do in this situation on other projects
14:25:11 <kragniz> sigmavirus24: would probably have a good idea
14:25:31 <sigmavirus24> so
14:25:37 <bunting> nikhil_k: Yeah, i imagine it is never a good idea to go down unexpected paths, as it could lead to future exploits or something
14:25:42 <sigmavirus24> 500 means the server fubar'd when what we want is to say "That was a bad request"
14:25:45 <nikhil_k> bunting: so, I think the wsgi wrapper is possible not expecting that
14:26:14 <kragniz> sigmavirus24: we certainly want to change it from a 500
14:26:19 <jokke_> ++
14:26:20 <mclaren> ok, from memory, it's impossible for us not to read in the full body (wsgi will always read it in)
14:26:24 <sigmavirus24> That said, I looked at the review that bunting did for that bug and it looks like they were preventing against going down paths where we are expecting a body
14:26:29 <jokke_> mclaren: correct
14:26:37 <sigmavirus24> mclaren: right, because wsgi is terrible and everything should be written in Java ;)
14:26:50 <mclaren> so we can either read it in and return 400 or read it in and ignore it
14:27:03 * jokke_ send cruise missile towards sigmavirus24's general location
14:27:08 <nikhil_k> I think body is read uptil a buffer before processing the api req
14:27:39 <sigmavirus24> Ah so that bug is different from the review I saw
14:27:40 <mclaren> sigmavirus24: not Java ... [insert latest hipster language of your choice] ;-)
14:27:48 <sigmavirus24> mclaren: Java is Enterprise
14:27:52 <sigmavirus24> So for a GET like that
14:27:56 <sigmavirus24> I would say ignore it
14:28:05 <jokke_> I do not agree
14:28:06 <sigmavirus24> Ignore it and return a 200 even if that is a bad request
14:28:18 <jokke_> we should fain, not ignore for malformed requests
14:28:26 <jokke_> fail even
14:28:27 <nikhil_k> well, we need to validate the body and not just ignore it
14:28:39 <mclaren> I think ignoring it is probably consistent with some current requests that don't return 500
14:28:41 <nikhil_k> because it can be a dos possibility
14:28:44 <sigmavirus24> So GETs are /allowed/ to have bodies but semantically they have no meaning
14:29:17 <sigmavirus24> jokke_: so considering the RFCs around this, I would say that ignoring a body in a GET is perfectly valid
14:29:28 <sigmavirus24> And in fact a load balancer/proxy would strip it out entirely if Glance were running behind it
14:29:34 <malini_> actually we should detect body, not read all of it -- that is a way of denial of service, quick say malformed.
14:29:46 <mclaren> malini_: we don't have that option, as I mentioned
14:29:54 <kragniz> malini_: we can't do that with the wsgi layer
14:30:02 <nikhil_k> not yet
14:30:18 <mclaren> the library that glance is wrapped in will helpfully read in the entire body (that's out of our control currently)
14:30:46 <mclaren> nikhil_k: is there a plan to change something there?
14:31:01 <nikhil_k> but I agree, this is out of scope for glance given proxies can handle such validation
14:31:31 <nikhil_k> mclaren: nothing yet, some features are using wsme
14:31:47 <mclaren> I guess maybe pinging other projects to see if there is any rough consensus on unexpected bodies in openstack couldn't hurt
14:32:00 <nikhil_k> good cpl topic jokke_
14:32:18 <nikhil_k> bunting: ^
14:32:37 <sigmavirus24> mclaren: already talking in #openstack-api about this
14:32:54 <mclaren> cool
14:32:55 <sigmavirus24> nikhil_k: so I wouldn't say that in order to run glance you need a proxy
14:33:07 <sigmavirus24> That's certainly not something we've ever stated as being part of the ref architecture
14:33:24 <sigmavirus24> I'm merely pointing out that if someone *were* running glance behind such a service, they'd never see a 500
14:33:28 <sigmavirus24> And we can behave the same way
14:33:33 <nikhil_k> sigmavirus24: yep, we can't madate it but it's out of scope for various reasons and having a proxy is good practice for other reasons too
14:33:52 <sigmavirus24> Because it's reasonable as defined by the semantics in RFC 723[0-5] (because I can't remember specifically which)
14:34:11 <nikhil_k> like  auth groups, endpoint validation, other custom headers validations
14:34:44 <sigmavirus24> Sure, but we should still DTRT here
14:34:51 <kragniz> nikhil_k: we shouldn't assume people are running glance behind a proxy, though
14:34:51 <nikhil_k> btw, everyone: it's already on the CPL meeting agenda next week jokke_ mclaren bunting sigmavirus24 #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
14:35:17 <nikhil_k> #link https://review.openstack.org/#/c/184358/
14:35:22 <jokke_> good, so lets postpone any further discussion until we hear wider consensus?
14:35:34 <nikhil_k> it's a good practice is all I have to say
14:36:43 <bunting> Getting consensus from the other projects seems the best course of action for me
14:37:04 <nikhil_k> bunting: do you mind starting a ML thread before that?
14:37:06 <sigmavirus24> nikhil_k: do you know the CPL meeting room/time by chance?
14:37:31 <nikhil_k> sigmavirus24: Tuesdays @ #openstack-meeting 2100UTC (Weekly for 1 hour)
14:37:48 <sabari> so elastic search api allows body in GET requests. So may be it's important in searchlight :)
14:37:50 <sabari> https://www.elastic.co/guide/en/elasticsearch/reference/1.6/search-request-body.html
14:38:10 <nikhil_k> sabari: yeah, it's bit different yet imp case ;)
14:38:17 <sigmavirus24> sabari: Good example
14:38:29 <nikhil_k> Anyways, we should move one for now
14:38:32 <sigmavirus24> agreed
14:38:36 <nikhil_k> #topic Reviews, Bugs and Releases
14:38:56 <nikhil_k> #info Prevent glance-api hangups during connection to rbd
14:39:07 <mfedosin> it's mine
14:39:08 <nikhil_k> #link https://review.openstack.org/#/c/200554/
14:39:21 <sigmavirus24> mfedosin: no it's ours =P You contributed it to the community ;)
14:39:28 <sabari> haha
14:39:44 <mfedosin> sigmavirus24, my topic
14:39:56 <mfedosin> not a bug :)
14:39:58 <bunting> nikhil_k: I will
14:40:05 <mfedosin> flaper87, some time ago I mentioned about hangups in ceph
14:40:13 <jokke_> nikhil_k: we need creative commons license header to the agenda etherpad :P
14:40:20 <mfedosin> so the solution is obvious
14:40:40 <jokke_> don't use it?
14:40:43 <mfedosin> let's add licences in commit messages
14:40:54 <sigmavirus24> jokke_: lol
14:41:06 <kragniz> jokke_: harsh
14:41:11 <sigmavirus24> Solution to hangups in ceph is to add licenses to commit messages... interesting
14:41:19 <sigmavirus24> Ceph truly is a mysterious and glorious beast
14:41:20 <sigmavirus24> =P
14:41:45 <mfedosin> sigmavirus24, stop trolling me :)
14:42:05 <mfedosin> I'm laughing and can't write
14:42:23 <mfedosin> so I have two questions about the commit
14:42:34 <mfedosin> should I add some unit tests there
14:42:54 <mfedosin> and should I add retries in our rbd driver?
14:43:29 <mfedosin> folks in cinder do it not a long time ago
14:43:41 <mfedosin> https://review.openstack.org/#/c/190579/8
14:46:29 <nikhil_k> mfedosin: +1 on unit tests
14:46:33 <sabari> +1 for unit tests. I think retrying connection is a good idea.
14:46:54 <kragniz> mfedosin: I'd say yes on a retry, but I like retries
14:46:54 <nikhil_k> I am not too sure about retries and if, how many. May be ask on operators channel
14:46:55 <mfedosin> sabari, it can be another commit
14:47:12 <jokke_> 0 for the unit tests +1 for the retry, but I'm not convinced if the retry should happen on this change
14:47:45 <sabari> the vmware store has a vmware_api_retry_count
14:47:54 <kragniz> we have retries for the swift store, also
14:48:03 <mfedosin> but ceph doesn't
14:49:03 <jokke_> I think it's one of those things that would be nice to have, but it really does not fix this bug so I don't think it should be done in this change ;)
14:49:40 <mfedosin> so I'm going to add some unit test on that change
14:49:47 <sigmavirus24> kragniz: did we merge swift retries?
14:49:49 <sigmavirus24> I forget now
14:49:49 <sabari> jokke_ agree.
14:49:50 <mfedosin> and then will try add reties
14:49:59 <sigmavirus24> mfedosin: maybe add retries as off by default?
14:50:00 <mfedosin> sigmavirus24, yes
14:50:06 <kragniz> sigmavirus24: before my time
14:50:28 <malini__> mfedosin, most such things have timeout interval and # of retries, and sensible defaults
14:50:47 <mfedosin> sigmavirus24, agree. they can be switched off by default, but can be configured
14:50:58 <sigmavirus24> mfedosin: also, maybe if cinder and glance are doing rbd things like this, there will be other places this is necessary and it will be worth an oslo.rbd library =P
14:51:11 <kragniz> sigmavirus24: https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/swift/store.py#L122-L124
14:51:20 <sigmavirus24> kragniz: ah, I thought you had something to do with swift retries last cycle but I'm probably forgetting
14:51:46 <kragniz> sigmavirus24: I did, that was about a sleep and backoff between retries
14:52:13 <mfedosin> sigmavirus24, btw oslo.rbd is not a bad idea, it prevents serious code duplication
14:52:35 <sigmavirus24> mfedosin: we should mention it at the oslo meeting on Monday
14:52:48 <sigmavirus24> It'll have to go through the incubator first probably, but that's fine
14:52:50 <mfedosin> sigmavirus24, when will it be?
14:53:06 <dims_> mfedosin: sigmavirus24: if you create a core team with who ever you want, either glance or cinder can own the git repo too
14:53:13 <sigmavirus24> dims_: ooo
14:53:20 <sigmavirus24> dims_: why not both? =P
14:53:35 <kragniz> dims_: do you have oslo on highlight or something? :P
14:53:44 <dims_> sigmavirus24: one git repo goes into one project in the governance repo
14:53:49 <dims_> kragniz: yep :)
14:53:57 <sigmavirus24> mfedosin: http://eavesdrop.openstack.org/#Oslo_Team_Meeting
14:54:15 <kragniz> how much code could we remove from our rdb driver, though?
14:54:15 <dims_> practically it does not matter which project owns it as long as folks from both projects are on the core
14:54:17 <mfedosin> okay, I'm going to be there
14:54:24 <kragniz> there's the rdb uri parsing
14:54:54 <nikhil_k> btw, next review is #link https://review.openstack.org/#/c/203679/
14:55:00 <kragniz> I guess there's all the connection stuff, actually
14:55:05 <nikhil_k> any last min objections?
14:55:08 <kragniz> yeah, let's move on
14:55:40 <sabari> +1. It helped a lot to have oslo.vmware in case of the vmware store driver.
14:56:19 <nikhil_k> nothing, we can +A that one then
14:56:28 <nikhil_k> #topic Open Discussion
14:57:10 <nikhil_k> Next week's irc  weekly-meeting is cancelled
14:57:20 <sabari> How about https://review.openstack.org/#/c/181347/ ?
14:57:29 <sabari> I think this needs a migration change too.
14:57:49 <sabari> flaper87: ^
14:58:22 <malini__> https://review.openstack.org/#/c/194868/ and this would like +2, we are making good progress on implementation
14:58:36 <nikhil_k> yep, it needs data correction on the existing old deployments
14:59:16 <nikhil_k> but it's gone now to contradict given that it merged in oslo.db
14:59:33 <jokke_> I'm tempted to block that merge
14:59:43 <jokke_> put a -1 comment in
14:59:53 <jokke_> and there is lots of those what I flagged
14:59:58 <nikhil_k> jokke_: we had deprecated the config a while back
15:00:05 <sabari> nikhil_k: https://review.openstack.org/#/c/75898/7 has all history
15:00:21 <jokke_> nikhil_k: I mean that flake8 change
15:00:25 <jokke_> you just approved
15:00:32 <nikhil_k> jokke_: ohk
15:00:36 <sabari> so I think may be we should fix this for newer deployments and error out on older if they haven't fixed thier tables to utf8
15:00:59 <nikhil_k> mclaren: also +Aed it
15:01:05 <nikhil_k> jokke_: what do you want us to do?
15:01:27 <jokke_> lets continue on -glance we're out of time
15:01:47 <nikhil_k> Thanks all
15:01:50 <shalq> nikhil_k: I have a request to review https://review.openstack.org/#/c/190895/
15:01:50 <malini__> bye everyone!
15:02:02 <nikhil_k> shalq: on #openstack-glance please
15:02:05 <nikhil_k> #endmeeting