14:01:30 <markwash> #startmeeting glance
14:01:31 <openstack> Meeting started Thu Jun  6 14:01:30 2013 UTC.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:35 <openstack> The meeting name has been set to 'glance'
14:01:45 <ameade> yo
14:01:54 <markwash> so, time change seems to work okay for east coast
14:02:04 <jbresnah> wave
14:02:10 <zhiyan1> yes :) thanks
14:02:16 <markwash> jbresnah: hi!
14:02:22 <zhiyan1> hi jbresnah
14:02:24 <iccha> it must be really early for PST ppl
14:02:24 <markwash> jbresnah: glad you could make it!
14:02:30 <rosmaita> jbresnah gets the worst time for a meeting award
14:02:36 <markwash> iccha: not really, worst for hawaii
14:02:37 <iccha> dedication and love for glance jbresnah
14:03:00 <markwash> but this way zhiyan1 can be here more easily, (though it is pretty late!)
14:03:12 <zhiyan1> :)
14:03:16 * jbresnah is taking coffee intravenously
14:03:18 <markwash> so anybody got anything they want to add to the informal agenda for today?
14:03:35 <zhiyan1> yes, yes, cinder-glance-store..
14:03:41 <markwash> zhiyan1: check
14:03:58 <markwash> #link https://wiki.openstack.org/wiki/Meetings/Glance#Agenda_for_Next_Meeting
14:04:11 <markwash> has the rough outlines, I'm most interested in ongoing blueprints today
14:04:32 <iccha> esheffield: and me just have some updates on documentation, not much though
14:04:43 <markwash> cool
14:04:52 <jbresnah> I would like to talk about the multiple locations bp if possible
14:05:15 <markwash> jbresnah: deal
14:05:29 <zhiyan1> yes, cool
14:05:40 <rosmaita> if there is time i would like to mention import/export/clone
14:05:43 <markwash> for zhiyan1's glance-cinder-driver work, there is this etherpad
14:05:45 <markwash> #link https://etherpad.openstack.org/linked-template-image
14:05:45 <flaper87> o/
14:05:56 <markwash> folks might want to take a look through that before we get to it later on in the meeting
14:05:57 <zhiyan1> hi flaper87.
14:06:03 <flaper87> zhiyan1: hey :)
14:06:05 <zhiyan1> thanks mark, yes, thatis:)
14:06:10 * nikhil is eavsdroppping
14:06:36 <markwash> #topic New Blueprints (fast-style!)
14:07:08 <markwash> Is anyone in interested in checking the sanity of a few blueprints this week?
14:07:20 <flaper87> o/
14:07:22 <markwash> specifically to help out marking them as approved
14:07:24 <jbresnah> sure, any in particular?
14:07:29 <iccha> i thought we already though cross id was sane
14:07:35 <flaper87> jbresnah: dude, you're awake
14:07:37 <flaper87> T_T
14:07:43 <flaper87> go to sleep
14:07:43 <markwash> first there is
14:07:44 <flaper87> :P
14:07:46 <markwash> #link https://blueprints.launchpad.net/glance/+spec/ability-to-separate-snapshots-and-images
14:07:49 <jbresnah> flaper87: partially
14:08:05 <markwash> second there is
14:08:08 <markwash> #link https://blueprints.launchpad.net/glance/+spec/cross-service-request-id
14:08:39 <flaper87> markwash: there's a thread in the mailing list about the cross-service-...
14:08:44 <markwash> and as a third option there is
14:08:45 <markwash> #link https://blueprints.launchpad.net/glance/+spec/use-oslo-common-db-code
14:09:01 <rosmaita> first one: can this just be done with metadata and the back end sorts things out?
14:09:03 * markwash looks
14:09:05 <flaper87> I'll take the last one
14:09:10 <flaper87> :D
14:09:43 <markwash> rosmaita: possibly
14:09:55 <jbresnah> markwash: I put out comments on the first 2
14:10:08 <ameade> are we talking about the 1st one yet?
14:10:17 <rosmaita> because there are a lot more use cases than just RAID level
14:10:23 <ameade> or all of them at once :P
14:10:24 <jbresnah> i think the second is a solid idea, and seems to be going on in other OS projects
14:10:32 <iccha> +1 jbresnah
14:10:34 <flaper87> jbresnah: it is
14:10:47 <markwash> +1 jbresnah
14:10:56 <rosmaita> +1 jbresnah
14:11:07 <markwash> it looks like we have plenty of interest
14:11:18 <jbresnah> so i would say we can call the second one approved
14:11:23 <flaper87> hahaha
14:11:25 <flaper87> :D
14:11:29 <markwash> I think the task here for each one is either to get more feedback, or to just yell at me to approve it
14:11:41 <markwash> yeah +1 I'm approving the request id one now
14:11:43 <ameade> +1 on the 2nd, am I crazy markwash or didn't we implement that together a long time ago?
14:11:53 <markwash> yeah I thought we did :-)
14:13:00 <markwash> okay looks good for new bps
14:13:05 <zhiyan1> seems use-oslo-common-db-code is good to approval also, marwash?
14:13:12 <zhiyan1> sorry, markwash
14:13:16 <markwash> no worries!
14:13:28 <markwash> the oslo-common-db-code one is still a little unclear to me
14:13:29 <flaper87> zhiyan1: I'd like to have more info about that one
14:13:37 <flaper87> how he's planning to do it
14:13:40 <flaper87> the impact
14:13:40 <markwash> I'm hesitant about "common db" code because glance is very coupled to its schema still
14:13:46 <iccha> yeah what implications it entails
14:13:51 <zhiyan1> is those code ready in oslo?
14:13:56 <markwash> and I don't want us to suddenly be very coupled with all the other projects schema as well
14:13:57 <zhiyan1> i'm not sure for that
14:13:59 <flaper87> zhiyan1: yup, most of it
14:14:07 <mclaren> markwash: also if we want to look at zero downtime with glance it may complicate it?
14:14:13 <zhiyan1> ok, just port code and landing down to glance, right? ..
14:14:17 <mclaren> ie with glance first
14:14:19 <markwash> mclaren: o/ !
14:14:20 <flaper87> TBH, that one sounds more like Ith release to me, but I'll get more feedback
14:14:31 <markwash> zhiyan1: it just may not be the right idea yet
14:14:34 <zhiyan1> flaper87: goot it
14:15:03 <markwash> #topic Blueprints in progress
14:15:09 <zhiyan1> seems, we need feedback to make sure it work well then to landing :)
14:15:16 <markwash> jbresnah, want to talk about multiple locations?
14:15:33 <jbresnah> yeah
14:15:35 <ameade> did we ever decide on bp #1?
14:15:52 <markwash> ameade, no, I think some folks were going to look into it more closely?
14:15:58 <markwash> should I have actioned somebody?
14:16:10 <jbresnah> markwash: i put a question on it
14:16:10 <flaper87> markwash: me for #3
14:16:33 <jbresnah> i can chase it a bit more, but maybe i can talk it out with ameade first
14:16:38 <jbresnah> i may be missing the intention
14:16:53 <markwash> #action flaper87 evaluate use-oslo-common-db-code
14:17:35 <markwash> #action jbresnah continue evaluating ability-to-separate-snapshots-and-images once there is feedback
14:17:44 <markwash> seems like we're good
14:17:55 <markwash> others feel free to participate in those
14:18:16 <jbresnah> cool
14:18:40 * markwash yields to jbresnah about multiple locations
14:18:41 <zhiyan1> jbresnah, could you pls talk about multiple locations? i really need it
14:18:45 <zhiyan1> :)
14:18:58 <jbresnah> i have a patch out there that i added comments to
14:19:06 <jbresnah> i have not had a chance yet to see if anyone replied
14:19:24 <jbresnah> has anyone had a chance to see it?
14:19:25 <zhiyan1> https://review.openstack.org/#/c/30517/  ?
14:19:34 <jbresnah> no, i abandoned that
14:19:42 <zhiyan1> yes, which one? sorry
14:19:43 <jbresnah> https://review.openstack.org/#/c/31591/
14:20:00 <jbresnah> markwash had thoughts on how to do it with PATCH
14:20:02 <markwash> jbresnah: ah, good point about the restriction of multiple slashes
14:20:03 <jbresnah> which i agree with
14:20:06 <zhiyan1> cool, i will check it later
14:20:14 <jbresnah> just need to finalize the API
14:20:17 <jbresnah> i also have:
14:20:24 <markwash> I originally put in that restriction because I thoguht json-pointer was a bit much to implement
14:20:27 <jbresnah> https://review.openstack.org/#/c/31306/
14:20:40 <markwash> I think we could remove the restriction now but it might take some more code
14:21:10 <jbresnah> markwash: is it openstack policy tho?
14:21:17 <jbresnah> | http://docs.openstack.org/api/openstack-image-service/2.0/content/restricted-json-pointers.html
14:21:39 <markwash> jbresnah: no no, I just wrote that as a CYA kind of thing
14:21:43 <jbresnah> i could hard code a special case for /locations/ somewhat easily
14:21:48 <jbresnah> heh ok
14:21:53 <markwash> the new format would be backwards compatible
14:22:10 <markwash> so I think this is all great progress
14:22:22 <markwash> and I'll keep reviewing!
14:22:37 <jbresnah> markwash: so should i loosen the restriction?
14:22:48 <markwash> jbresnah: yes I think so
14:22:54 <jbresnah> in the general case?
14:23:22 <markwash> jbresnah: that would be okay but we probably have to put in some code restrictions to make sure most properties can only be strings
14:23:42 <markwash> I don't think we want to support requests that add user properties that are lists or json objects
14:23:44 <jbresnah> actually i ran into something with that yesterday
14:23:49 <jbresnah> i think there are restrictions there
14:23:57 <markwash> okay cool
14:24:01 <jbresnah> i was trying to implement the last way, where the list is changed all at once
14:24:07 <zhiyan1> one sample question jbresnah, is this 'remove: [{"remove": "add", "path": "/locations", "value": <url>}]' should be this 'remove: [{"op": "remove", "path": "/locations", "value": <url>}]' ?
14:24:14 <jbresnah> and errors come back saying it can only be a string, i didn't get far into it
14:24:25 <markwash> lets talk about it later today in #openstack-glance
14:24:33 <jbresnah> cool
14:24:40 <mclaren> dumb question: do these locations contain credentials? if so do they pick up the metadata_encryption setting?
14:24:49 <jbresnah> zhiyan1: yeah that seems right
14:24:56 <markwash> mclaren: I think they should pick up the encryption setting
14:25:00 <mclaren> thx
14:25:07 <jbresnah> mclaren: yeah they should
14:25:11 <markwash> some of that should have already been done maybe? but I'll check again
14:25:37 <markwash> so folks should keep reviewing multiple locations code
14:25:38 <zhiyan1> markwash: could you pls show me the url about metadata_encryption ?
14:25:38 <jbresnah> mclaren: they could contain such info, that is up to the admin adding the location
14:26:02 <jbresnah> mclaren: we sort of changed the approach and there is a bit of a buyer-beware attitude with this one
14:26:03 <mclaren> gotcha
14:26:03 * flaper87 needs to dig more into multiple-locations
14:26:34 <markwash> zhiyan1: can you remind me after the meeting? I'll dig around and find it
14:26:36 <jbresnah> zhiyan1: at some point i would like to talk to you about your interest in this bp
14:26:42 <zhiyan1> sure
14:26:58 <jbresnah> zhiyan1: cool, i want to make sure i am addressing all needs
14:27:01 <markwash> anything else on multiple locations? next is glance-cinder-driver
14:27:15 <zhiyan1> yes, for glance-cinder-store, if you checked https://etherpad.openstack.org/linked-template-image , there are some dependencies for implementation, and all about cinder: attach volume to host / direct volume IO.
14:27:19 <jbresnah> markwash: i think that is good for here, just some follow up convos
14:27:55 <zhiyan1> so, i dont want to blocked from that, can can dev now...so, i have talked a lot of glance-cinder-store before with mark :) , and seems there a three choice for me..
14:28:12 <zhiyan1> A simple approach:
14:28:13 <zhiyan1> 1) upload image to glance non-cinder store
14:28:13 <zhiyan1> 2) tell cinder to create a volume from that image
14:28:13 <zhiyan1> 3) register the image to cinder store, use image id (from step 1) + volume id (from step 2) as the location
14:28:13 <zhiyan1> (each step is a separate api call)
14:28:21 <zhiyan1> B. multi-locations approach
14:28:25 <zhiyan1> C. final solution
14:28:29 <zhiyan1> after cinder have a pretty method to support attach volume to host / direct volume io (base on 'brick'/cinder-agent, in H3 or I1), i will change the cinder store driver to read/write image data from remote volume driectly but not separate handling..
14:29:29 <markwash> cool
14:29:49 <markwash> in the multi locations approach
14:29:53 <zhiyan1> :), so jbresnah: i'm just now sure about #B
14:30:04 <markwash> the idea is that you create the image with a non-cinder store
14:30:10 <markwash> then ask cinder to create a volume from it
14:30:17 <zhiyan1> how to let glance-cinder-store match your plan? or any thoughts/comments?
14:30:26 <markwash> and then register the cinder volume as a location on the image
14:30:37 <zhiyan1> markwash: yes, that of #A plan
14:30:42 <markwash> the caveat is that the cinder store location would *not* support getting image data directly
14:30:56 <iccha> so B is an improvement over approach A ? with addition pf multiple locations?
14:31:18 <markwash> zhiyan1: I thought I was describing plan B
14:31:19 <zhiyan1> iccha: i think, yes
14:31:25 <zhiyan1> yes, pls
14:31:48 <jbresnah> i do not quite have my head around this yet, sorry
14:31:55 <flaper87> mmh, cinder-store changes how glance's stores work, IMHO. I'm not fully against it but we need to figure it out a bit better
14:32:21 <iccha> who will ask cinder to create volume from glance? is it glance or user?
14:32:30 <zhiyan1> api user
14:32:52 <flaper87> My first comment is that multiple-locations is a must for it to happen - assuming I got the idea right.
14:33:06 <jbresnah> does cinder act as a glance client at that point or does it have special privledges?
14:33:08 <markwash> flaper87: yeah, thats my concern as well. it seems strange to have a location that you can't really "get"
14:33:29 <flaper87> can the cinder location be a property of the image?
14:33:32 <zhiyan1> flaper87: yes, yes, i'd like address C# plan directly , but i check with cinder team from two weekly meeting, not sure there is a clear plan to address what i/cinder-store need
14:33:32 <markwash> flaper87: but I think it could be fine if we figure out a clean way to do it
14:33:36 <flaper87> instad of a separate store ?
14:33:55 <flaper87> instead*
14:33:57 <jbresnah> markwash: why can you not get it?
14:34:00 <markwash> flaper87: yes, actually it can be a property of the image, in the form of a block device mapping property
14:34:22 <markwash> jbresnah: because the only way to get it right now is to attach the volume as a device directly to the glance api host
14:34:26 <flaper87> markwash: that makes more sense to me than having a separate store
14:34:31 <markwash> which may be okay too, but feels super squicky to me
14:34:51 <zhiyan1> jbresnah:cinder volume as a image, so it's glance's client. but i don't think there's a special privledges for cinder..
14:35:22 <jbresnah> is the end use case so nova can find a volume to boot via glance?
14:35:33 <flaper87> jbresnah: think so
14:35:39 <markwash> jbresnah: basically
14:35:49 <flaper87> ok, I got it right then
14:35:52 <jbresnah> so someone can 'get' the volume?
14:35:54 <iccha> would the cinder store know that this image exists in glance other stores? or does glance become central point of authoirty over images/volume images now?
14:35:56 <markwash> I think there is a constraint that the image should be bootable the "normal" way too
14:35:59 <jbresnah> it just depends on where they are and what they can do?
14:36:41 <markwash> iccha: in proposal B, glance stores the info in the locations table, cinder just treats the volume as usual
14:37:02 <markwash> jbresnah: well, they can't download it through the http api
14:37:03 <flaper87> markwash: iccha wich I think makes more sense
14:37:39 <jbresnah> markwash: oh i see, so if it is the only location then it changes glance's assumed functionality
14:37:50 <markwash> jbresnah: right
14:38:07 <markwash> so maybe we just make it explicit that stores that can't download can't be the only locations ?
14:38:13 <markwash> wow I failed at explicit I think
14:38:20 <flaper87> lol
14:38:31 <markwash> images must have at least one location that can be downloaded from to be active
14:38:43 <markwash> that is fewer negatives
14:38:48 <iccha> should we have additional info along with location to indicate store type or downloadable or not kind of information?
14:38:57 <jbresnah> i think this is a fallout from the marriage of registry/replica service and data transfer service
14:39:02 <flaper87> I think this shouldn't be used as a store and that services consuming images should check if the image has a "volume" property
14:39:17 <jbresnah> i dont see it as horrible to have a EWECANTSERVETHATDATA
14:39:18 <zhiyan1> markwash: we need keep forward-compatible i think, need support download, so justa localtion is not ok
14:39:35 <jbresnah> ... i probably should have used spaces
14:39:40 <markwash> haha
14:40:11 <markwash> zhiyan1: it seems so strange though for people to want to download a volume from glance
14:40:12 <iccha> it might be ok to image info which locations you cant download from as long as there is a way to indicate downloadable locations vs not volumes etc
14:40:22 <iccha> because glance is image registry service basically right
14:40:38 <jbresnah> so far i like having it as just another location, and throwing an error if you try to download it with only that location available
14:40:51 <jbresnah> but i think i need to understand hte nova use case better
14:40:58 <esheffield> +1 jbresnah
14:41:35 <jbresnah> iccha: yeah there should be a way to check if something is available for download
14:42:14 <jbresnah> how does nova boot from a volume now?  a specific flag saying use thing volume ID instead of an image ID?
14:42:42 <markwash> something like that, but I don't recall exactly
14:42:45 <flaper87> I don't think that just throwing an error when trying the service tries to download the image is good enough
14:42:49 <jbresnah> and is the idea to make it always an image ID and pick the volume from that image ID in certain cases?
14:42:50 <zhiyan1> jbresnah: this change not cover boot-from-volume, client need give volume id
14:42:55 <flaper87> the location should contain that info, somehow
14:43:08 <mclaren> have we considered a /volumes resource?
14:43:18 <jbresnah> i am confused because a volume boot has such different semantics over an image
14:43:38 <jbresnah> so nova couldnt just pick a volume from glance without the use specifically saying to
14:43:58 <markwash> mclaren: not that I know of
14:44:02 <jbresnah> so i think i dont get the use case
14:44:16 <markwash> should we maybe have a followup discussion?
14:44:20 <markwash> give folks more time to prepare?
14:44:23 <flaper87> markwash: +1
14:44:27 <markwash> okay cool
14:44:38 <iccha> +1
14:44:49 <zhiyan1> ok, thanks
14:44:50 <markwash> #action markwash schedule a followup meeting about the cinder store (at a time that is convenient to zhiyan please!)
14:45:05 <markwash> There were several other ongoing blueprints
14:45:15 <zhiyan1> thanks guys :)
14:45:28 <flaper87> zhiyan1: thank you
14:45:34 <markwash> #topic async processing
14:45:45 <markwash> I added a random assortment of ideas in code https://review.openstack.org/#/c/31874/1
14:45:58 <markwash> let me know if you want me to add you as a reviewer, it is a draft so its restricted
14:46:04 <flaper87> markwash: I commented on that draft few minutes ago
14:46:09 <markwash> and also its pretty unclear still how some important parts would work
14:46:24 <markwash> cool!
14:46:24 <ameade> markwash: add meh
14:46:45 <esheffield> markwash: I'd like to see that too
14:47:02 <zhiyan1> markwash, pls add me?
14:47:08 <markwash> sure
14:47:14 <rosmaita> and me and nikhil
14:47:18 <nikhil> +1
14:47:20 <markwash> nikhil is on it
14:47:34 <mclaren> markwash: me too if you can, thanks
14:47:42 <markwash> okay I'm going to resubmit it as not a draft :-)
14:47:47 <nikhil> I see that it's giving read only error in gerrit markwash
14:47:50 <markwash> and jenkins can just deal
14:47:53 <nikhil> thanks
14:47:57 <flaper87> markwash: or, you could charge $10 for adding folks
14:48:00 <markwash> haha
14:48:01 <flaper87> :D
14:48:13 <nikhil> or just link us to ur github branch ?
14:48:16 <markwash> #topic documentation
14:48:18 <nikhil> markwash: ^^
14:48:30 <markwash> iccha, esheffield updates about docs
14:48:31 <markwash> ?
14:48:34 <iccha> https://etherpad.openstack.org/glance_v1_vs_v2
14:48:56 <markwash> looks like new stuff at the top?
14:49:07 <iccha> the top part of etherpad has list of places where glance / image services documentation resides and how out of date/ missing info/incorrect info is listed
14:49:12 <markwash> #link https://etherpad.openstack.org/glance_v1_vs_v2
14:49:26 <iccha> and also what the new documentation may need
14:49:53 <markwash> looks pretty good!
14:50:20 <zhiyan1> yes,yes, seems good
14:50:33 <iccha> the basic skeletal work of v1 vs v2 exists below, would be great to have ppl add in any info missed, or any other quirks or differences they have noticed in v2 vs v1 for ppl who would like to switch to be aware of
14:50:37 <jbresnah> iccha: for v2 update it would be nice to see something about how "Content-Type: application/openstack-images-v2.0-json-patch and "Content-Type: application/openstack-images-v2.1-json-patch differ
14:50:44 <markwash> I'll review that some more and then maybe we can figure out which thing we want to do next
14:51:10 <zhiyan1> shall we push some encoding hits to the doc?
14:51:37 <zhiyan1> probable somebady use non-ascii code string as the properties or some fields :)
14:51:50 <iccha> yes sure feel free to add anything you think which should be there
14:51:59 <iccha> this is a very rough repository of all our collective knowledge
14:51:59 <markwash> jbresnah: yeah hmm.. we should really push people in the direction of v2.1 and just ask that they never think about v2.0 if possible
14:52:00 <markwash> hmm
14:52:11 <flaper87> lol
14:52:15 <markwash> v2.0 was compatible with draft 03 of the json-patch spec
14:52:24 <markwash> v2.1 is compatible with the approved rfc version
14:52:28 <markwash> 6902 I think?
14:52:31 <iccha> jbresnah: that ll be great to add , are u volunteering to add it to etherpad :p
14:52:38 <markwash> :-D
14:52:40 <flaper87> iccha: he is
14:52:42 <flaper87> :D
14:52:52 <jbresnah> iccha: heh, i would but i asked because i need to learn the differences!
14:52:52 <markwash> #topic import export clone
14:53:03 <markwash> rosmaita: a little bit of time. . .
14:53:22 <rosmaita> ok, thanks, i think we're mostly agreed that a new resource is ok
14:53:42 <rosmaita> so post to /images/actions and get back a location
14:53:48 <rosmaita> like /images/actions/UUID
14:53:54 <rosmaita> then you poll the UUID
14:53:59 <rosmaita> what you get back ...
14:54:24 <rosmaita> depends on what was in your request, something like { "import" : "stuff" }
14:54:31 <rosmaita> likewise for export, clone
14:54:49 <rosmaita> and what you get when you  poll the UUID coudl be different too
14:54:57 <rosmaita> that's actually my quyestions
14:55:10 <zhiyan1> rosmaia: actually, i really not get the benefits from upload/download to import/export :) sorry for that, i have checked your wiki, but ..
14:55:15 <nikhil> +1
14:55:19 <nikhil> rosmaita: +1
14:55:19 <rosmaita> in nova actions, there are 9, 7 dont return bodies
14:55:21 <markwash> rosmaita: I had some thoughts in code about what an action would look like
14:55:29 <rosmaita> the 2 that do return different bodies
14:55:36 <rosmaita> markwash: cool
14:55:44 <markwash> should be able to see it here in https://review.openstack.org/#/c/31874/1 now
14:56:41 <esheffield> rosmaita: is the UUID basically an action identifier or the UUID of the image on which the action was taken? I assume the former?
14:56:58 <rosmaita> action identifier
14:57:04 <nikhil> markwash: yeah
14:57:06 <nikhil> thanks
14:57:33 <markwash> zhiyan1: the main benefit is that upload directly sets the data with no modifications
14:57:49 <markwash> zhiyan1: import and export allow the format to change or for other lengthy processing to take place
14:58:05 <rosmaita> zhiyan1: have u seen the mailing list discussion?
14:58:14 <zhiyan1> yes, but not catch them...
14:58:31 <zhiyan1> week ago, right?
14:58:37 <markwash> (2 minutes left)
14:58:39 <rosmaita> right
14:58:51 <flaper87> :(
14:58:58 <zhiyan1> sorry, rosmaita, seems i need pick it up :(
14:58:59 <rosmaita> zhiyan1: we cna talk in openstack-glance after mtg if you like
14:59:12 <markwash> flaper87: did I skip you?
14:59:13 <zhiyan1> goood :) thanks rosmaita.
14:59:27 <flaper87> markwash: yup, registry-driver :D
14:59:32 <markwash> #topic registry driver
14:59:39 <zhiyan1> :) 30s
14:59:48 <markwash> I don't *think* there is anyone after us
14:59:49 <flaper87> very quick, I'd love some feedback about this: http://lists.openstack.org/pipermail/openstack-dev/2013-June/009839.html
14:59:55 <markwash> and won't turn into a pumpkin for another hour
15:00:29 * ameade secretly just watched said disney movie
15:00:31 <flaper87> the driver is *almost* done, I need to finish some tests that are being blocked by the fact that we don't have a way to deserialize datetimes
15:00:57 <markwash> russelb seemed to be poo-poo-ing that for some reason
15:01:02 <jbresnah> heh ameade
15:01:06 <zhiyan1> yes, you means primitive call right?
15:01:06 <flaper87> so, I was thinking we could do something like nova does (convert strtime into datetime in the db_api function)
15:01:33 <markwash> in json, it seems like datetimes should be objects that self-identify somehow
15:01:33 <flaper87> markwash: some reason that 1) I still don't get 2) I disagree with what I got
15:02:05 <markwash> flaper87: nod
15:02:12 <flaper87> I don't think we need to define new models just to serialize / deserialize datetimes (which is what he's suggesting
15:02:23 <flaper87> the other thing, that implementation won't land 'til H-3
15:02:26 <flaper87> which is bad for us
15:02:54 <flaper87> so, my suggestions are: 1) Implement datetime deserialization 2) do it in the sqlalchemy driver when needed
15:03:06 <flaper87> #2 is the easiest
15:03:11 <flaper87> but not the best, IMHO
15:03:15 <flaper87> that's just a workaround
15:03:42 <markwash> so do you want feedback on the ML or here or some other way?
15:03:48 <ameade> i can't figure why a strtime would be getting to the sqlalchemy layer
15:03:58 <ameade> but i haven't been paying much attention to this
15:04:10 <flaper87> both work for me, but if we do it in the m-l we better make sure to find a consensus
15:04:31 <ameade> oh rpc stuff right?
15:04:35 <markwash> flaper87: then I better just talk to you in #openstack-glance :-)
15:04:40 <flaper87> markwash: +1
15:04:59 <flaper87> ameade: yup rpc stuff
15:05:01 <flaper87> :(
15:05:04 <markwash> #topic quick open discussion
15:05:06 <flaper87> I mean, :)
15:05:08 <flaper87> :D
15:05:18 <flaper87> can I say, We rock ?
15:05:21 <flaper87> ok, I said it
15:05:24 <markwash> does this meeting time work out okay?
15:05:34 <ameade> flaper87: we should just have all the services on one node :P
15:05:37 <markwash> we had mclaren and zhiyan so that part was great
15:05:38 <ameade> markwash: +1
15:05:40 <mclaren> this time is great for me
15:05:49 <iccha> yup i agree good to have eveyrone included
15:05:55 <nikhil> +1
15:06:00 <zhiyan1> :)
15:06:06 * flaper87 thinks that jbresnah felt asleep again
15:06:13 <markwash> jbresnah: can you deal with this once every two weeks?
15:06:15 <flaper87> works for me, though
15:06:18 <ameade> i dunno about having everyone here but the time is good
15:06:25 <ameade> :P
15:06:28 <markwash> haha
15:06:31 <flaper87> ameade: lol
15:06:34 <rosmaita> +1
15:06:47 <markwash> okay cool, Imma call it
15:06:49 <jbresnah> markwash: yeah probably
15:06:58 <markwash> :-)
15:06:59 <ameade> peace out
15:07:02 <markwash> #endmeeting