14:00:34 <flaper87> #startmeeting Glance Drivers
14:00:35 <openstack> Meeting started Tue Dec  8 14:00:34 2015 UTC and is due to finish in 60 minutes.  The chair is flaper87. 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_drivers'
14:00:48 <rosmaita> o/
14:00:49 <flaper87> #topic Agenda
14:00:50 <ativelkov> o/
14:00:52 <flaper87> yoooooo!
14:00:53 <jokke_> o/
14:00:57 <flaper87> #link https://etherpad.openstack.org/p/glance-drivers-meeting-agenda
14:01:04 <flaper87> Courtesy Glance Drivers' meeting reminder: nikhil_k, flaper87, sigmavirus24, rosmaita, mclaren, dhellmann, jokke_
14:01:26 <flaper87> just like last week, I have quite some lag in my connection today so, I'm sorry if it takes me a bit to reply
14:01:41 <flaper87> that said, we have a packed agenda for tody
14:01:46 <flaper87> let's get to it
14:01:57 <flaper87> #topic https://review.openstack.org/#/c/249950/4 This could do with some eyes on it (bunting)
14:02:10 <flaper87> #link https://review.openstack.org/#/c/249950/4
14:02:16 * flaper87 should have fixed the topic title
14:02:18 <flaper87> sorry
14:02:20 <flaper87> :D
14:02:23 <bunting> I also emailed the mailing list about that, telling nova about it.
14:02:41 <flaper87> yeah, I think I took a look at it already, not sure if my comments synced
14:02:56 <flaper87> Have other drivers read through it already?
14:03:03 <mclaren_> I have
14:03:14 <rosmaita> not yet
14:03:23 <flaper87> mclaren_: cool, comments?
14:03:32 <mclaren_> It would be nice to get someone from nova to have a quick look, although that needn't be a blocker
14:03:55 <flaper87> ok, what about we get those comments and sync back next week
14:04:03 <mclaren_> I think it's good. Needs buy in from other services for it to be put to use
14:04:05 <flaper87> that way rosmaita and nikhil_k can take a look at it
14:04:46 <rosmaita> ok
14:04:50 <flaper87> btw, as ageneral rule, it'd be awesome if all drivers could go through the agenda before the meeting so that we have already some knowledge about the specs we'll discuss
14:04:57 <flaper87> this is not a complain, btw
14:05:06 <rosmaita> it is a good suggestion though
14:05:14 <flaper87> just something I normally do for this and other meetings and it's worked well for me
14:05:27 <flaper87> ok, moving on
14:05:29 <nikhil_k> hey, sorry I am a bit late. I was out and met some friends on way back.
14:05:38 <flaper87> #topic Swift driver re-authentication spec: https://review.openstack.org/#/c/248681
14:05:53 <flaper87> I assume that's you, mfedosin
14:06:07 <flaper87> that's the second part of the trusts spec
14:06:17 <flaper87> or better, that's the glance-store part of it
14:06:26 <ativelkov> mfedosin is on PTO today, he'll be back next week
14:06:37 <flaper87> ativelkov: ah right, he mentioned that. Thanks for the reminder
14:07:07 <flaper87> I know we're heads down on image process but these specs won't take much time to review and provide feedback too
14:07:11 <flaper87> to*
14:07:22 <jokke_> so if we have trust we cannot use that towards swift?
14:07:27 <flaper87> I think this spec would be nice to have as it's a follow-up on the trusts one
14:08:06 <flaper87> jokke_: we can and that's the plan, AFAIK
14:08:30 <flaper87> we just asked to split this into 2 specs because this part belongs to glance-store
14:08:35 <flaper87> and it depends on the glance one
14:09:14 <flaper87> I'll create a list of specs prio so we can focus on reviewing those
14:09:23 <flaper87> of course , you can contribute to that list
14:09:25 <flaper87> :D
14:09:33 <jokke_> would be great if spec actually mentioned that :P
14:09:44 <flaper87> I've seen more specs coming up now and we need to start focusing on few of them
14:09:44 <nikhil> agreed
14:09:52 <flaper87> jokke_: it does, it mentions the trust id in several parts
14:09:53 <nikhil> it's quite unclear on what the eventual goal is
14:09:59 <flaper87> jokke_: oh, you mean the dependency
14:10:01 <flaper87> yeah
14:10:08 <flaper87> lets comment on the spec :D
14:10:19 <jokke_> ++
14:10:26 <flaper87> The glance one mentioned there would be a specific spec for glance_sotre
14:10:32 <flaper87> this one doesn't have the reverse reference
14:10:39 <nikhil> hmm, I did not find in the problem statement. trusts seems to be mentioned in other places
14:11:00 <nikhil> it does have a ref
14:11:09 <nikhil> look at line 218
14:11:53 <flaper87> right but I meant the reference in the problem statement mentioning why this spec is needed and how it depends /elates to the one in glance
14:12:02 <flaper87> ok, lets put all this on that spec
14:12:11 <nikhil> agreed, that's needed
14:12:21 <flaper87> I'm sure mike will address all this comments as soon as he is back
14:12:44 <flaper87> and if he does it during his PTO, I'll take his place wherever he is and let him take mine as being on PTO would be super cool now :P
14:12:51 <flaper87> anyway, let's move on
14:12:59 <flaper87> #topic mage import refactor: https://review.openstack.org/#/c/232371/
14:13:08 <flaper87> There have been updates but
14:13:29 <flaper87> today, I believe what we want to discuss is the /v2/bikeshed and /ve/images/{id}/bikeshed thing
14:13:37 <flaper87> s/ve/v2/
14:13:48 <flaper87> I expressed my opinion on the spec
14:13:54 <flaper87> and Stuart has donde the same
14:13:54 <mclaren_> can I say one thing?
14:13:55 <flaper87> done*
14:14:02 <flaper87> mclaren_: NO!
14:14:04 * flaper87 ducks
14:14:08 <flaper87> mclaren_: of course
14:14:09 <mclaren_> heh
14:14:38 <mclaren_> Right now I don't really have a solid proposal for an API for the non-integrated-with-image case
14:14:55 <mclaren_> More just some thoughts and observations
14:15:09 <mclaren_> that's it really
14:15:23 <mclaren_> I do agree with Brian
14:15:33 <flaper87> ok, so the /v2/bikeshed is a brainstorm
14:16:12 <mclaren_> well it achieves a specific end
14:16:15 <mclaren_> that I am interested in
14:16:32 <mclaren_> I'm going to cut and paste ...
14:16:36 <mclaren_> Divide your application into distinct features with as little overlap in functionality as possible. The important factor is minimization of interaction points to achieve high cohesion and low coupling.
14:16:51 <mclaren_> I think doing that has practical benefits
14:17:03 <flaper87> my current opinion is that we shouldn't have it as a separate resource as I mentioned on the spec. In the worst case scenario, we can just add it later rather than doing it now
14:17:22 <mclaren_> I agree with Brian that we can make a start on other things, eg the Swift case, and let this percolate for a while
14:17:39 <nikhil> yeah, agree
14:17:56 <nikhil> if we(glance) are at this point where the resource is a problem
14:18:03 <flaper87> I do agree with that statement but I disagree on the bikshed being a separate functionality. This is where, I believe, our POV differ w.r.t the bikeshed thing
14:18:17 <nikhil> I am of opinion that we should leave things be and add a discovery API instead
14:18:27 <rosmaita> i think the key issue is, is there any reason why an end-user should manipulate the bikeshed?
14:18:36 <rosmaita> if not, no need to expose it
14:18:43 <jokke_> rosmaita: ++
14:18:53 <rosmaita> but i think we can get separation of concerns behind the scenes
14:18:54 <flaper87> right, my opinion is that users shouldn't
14:19:03 <flaper87> exactly my point
14:19:05 <nikhil> rosmaita: not right away
14:19:08 <jokke_> while it might make our job initially easier but is it right tihng to do for user?
14:19:20 <nikhil> jokke_: ditto
14:19:33 <rosmaita> nikhil: elaborate?
14:20:08 <nikhil> rosmaita: I assume that we are all of opinion at this point
14:20:09 <mclaren_> are we saying that the bikeshed isn't visible to the user at all?
14:20:22 <nikhil> that the bikeshed won't be used to store immutable entities
14:20:32 <nikhil> basically the input to bikeshed can be changed later
14:20:41 <flaper87> mclaren_: not as a resource. The endpoint under images is so that data can be uploaded to it
14:21:03 <rosmaita> nikhil: +1 no immutable entities in bikeshed
14:21:09 <flaper87> ++
14:21:12 <nikhil> from a user experience POV it would help to overwrite on the bikeshed to make multiple failed attempts successful
14:21:40 <nikhil> so, that is a distributed transation issue
14:21:40 <nikhil> either we way 1 bikeshed per image record
14:21:41 <flaper87> I just don't want to have yet another public resource being added t oglance in Mitaka
14:21:55 <nikhil> or a "single phase" write to bikeshed to enable import
14:21:56 <flaper87> and I don't think we need it for now
14:22:10 <mclaren_> can I be honest?
14:22:14 <rosmaita> quick question: doug indicated on an earlier patch set that there's no prob requiring a user to delete the Image record upon failure
14:22:22 <jokke_> nikhil: I see no reason why we couldn't allow user to PUT again to /v2/images/{ID}/bikeshed before calling the import (either initially when noticing failed upload or after first import try has failed)
14:22:25 <rosmaita> so no need for retries
14:22:28 <flaper87> mclaren_: you always are :D
14:22:43 <flaper87> jokke_: that's one of the goals, yes
14:22:53 <rosmaita> jokke_: that's what i'm asking, do we want to allow that or just keep it simple?
14:22:56 <flaper87> at least I remember us talking about this
14:23:13 <jokke_> rosmaita: for our users it would be the right thing to do
14:23:32 <nikhil> mclaren_: was saying something
14:23:37 <nikhil> ?
14:23:45 <flaper87> I think he's writing
14:23:52 <flaper87> waaaaaaaaaaaaaaaaaaaaaaaaiiiiit for it
14:23:54 <jokke_> I don't know if it's viable goal initially when we are doing this, but I think we should keep it in mind when we desing this
14:23:54 <flaper87> :P
14:24:00 <rosmaita> jokke_: i wonder, because the "hard part" for auser is creating the import call
14:24:00 <mclaren_> nope, trying to figure out how honest I should be :-)
14:24:00 <nikhil> :D
14:24:01 <nikhil> awesome
14:24:08 <flaper87> hahahaha
14:24:10 <flaper87> ok
14:24:12 <rosmaita> mclaren_: +1 for honesty
14:24:20 <flaper87> mclaren_: just be blunt
14:24:22 <flaper87> shoot
14:24:24 <flaper87> we can take it
14:24:24 <rosmaita> (depending on what you say)
14:24:32 <jokke_> mclaren_: totally ... there's never too big toes to step on
14:24:38 <mclaren_> tbh, I need to think about the bikeshed not being visible to users, I hadn't expected that
14:25:01 <flaper87> mclaren_: what do you mean by "not visible" ?
14:25:18 <jokke_> rosmaita: why would it be the hard part?
14:25:22 <nikhil> rosmaita: rofl
14:25:31 <rosmaita> jokke_: most of the configuration is in there
14:26:01 <flaper87> we've 5mins left and other items on the agenda
14:26:05 <nikhil> mclaren_: some more elaboration would be awesome
14:26:10 <flaper87> Can I count on you guys going through them?
14:26:11 <nikhil> I am liking this direction
14:26:12 <flaper87> :)
14:26:14 <mclaren_> flaper87: you can't 'see' it (it's size/checksum) as a user
14:26:40 <jokke_> which bring's my next question about this spec ... do we want separate spec for our client changes? I've not seen a single word around that yet
14:26:44 <nikhil> flaper87: ack
14:26:47 <mclaren_> (I think that's what you meant above)
14:26:59 <flaper87> mclaren_: mmh, not sure I follow, tbh
14:27:03 <rosmaita> ok, i will put up a new patch set, i want to get examples of vhd upload resulting in OVA in Glance (as done at rackspace) and also ova -> qcow2 as outlined on the ova conversion spec
14:27:09 <nikhil> flaper87: etherpad of trello of specs that require earlier feedback
14:27:13 <nikhil> or*
14:27:14 <flaper87> the bikeshed was never meant to be an external resource for users to consume
14:27:23 <flaper87> nikhil: working on that as we speak
14:27:45 <mclaren_> flaper87: so as you envision it a user only knows about an uploaded bikeshed through what - image state?
14:27:48 <flaper87> rosmaita: wait for my next comment, I'm creating the requied bugs to break this down and start working on the spec
14:27:58 <rosmaita> flaper87: ok
14:28:13 <nikhil> rosmaita: "want to get examples of vhd upload resulting in OVA in Glance"<-like
14:28:17 <rosmaita> mclaren_: right, image state
14:28:28 <rosmaita> all communication via the Image object
14:28:52 <flaper87> mclaren_: how did you envision this? As far as I know, this is what we've been discussing since before the summit
14:28:56 <rosmaita> mclaren_: the swift-local would allow "sort of" bikeshed visibility
14:28:58 <flaper87> honest question
14:29:06 <rosmaita> since the blob is in the user's object store account
14:29:08 <flaper87> just want to makes ure we're on the same page
14:29:17 <flaper87> make sure*
14:29:30 <flaper87> ok, 1min left
14:29:37 <flaper87> lets move to our channel and or comment on the spec
14:29:40 <mclaren_> we can discuss after the meeting? What do folks think of making a start on the Swift case?
14:29:41 <flaper87> thanks folks!
14:30:04 <flaper87> mclaren_: thanks for being critical on the proposal. It's super useful
14:30:05 <rosmaita> mclaren_: let's discuss in glance channel
14:30:11 <flaper87> #endmeeting