14:34:29 <markwash> #startmeeting glance
14:34:30 <openstack> Meeting started Thu Feb 27 14:34:29 2014 UTC and is due to finish in 60 minutes.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:34:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:34:34 <openstack> The meeting name has been set to 'glance'
14:34:55 * IgorYozhikov is now away: went away...
14:36:40 <markwash> shall we start here?
14:36:57 <arnaud__> yes
14:36:59 <zhiyan> yes, thanks
14:37:04 <markwash> can we get a quick roll call?
14:37:37 <ativelkov> o/
14:38:02 <jbernard> o/
14:38:21 <markwash> anybody else? rosmaita ?
14:38:39 <markwash> okay
14:38:42 <markwash> sorry I'm late today
14:39:02 <markwash> it sounds like you guys were already talking about artifacts stuff
14:39:10 <ativelkov> yes
14:39:11 <markwash> any status updates, there have been some good email discussions
14:40:05 <ativelkov> Well, I didn't have much time to work on the APIs themselves, unfortunately, but got some questions on artifact dependencies which I wanted to discuss
14:40:22 <markwash> okay cool
14:40:33 <ativelkov> Plan to come back to the API design on the next week
14:40:54 <markwash> jbernard: it seems like based on our conversations, cinder support is an early requirement for instance templates for you
14:41:05 <markwash> correct?
14:41:05 <jbernard> for me at least, yes
14:41:07 <ativelkov> #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/028073.html - chain about the dependencies
14:41:24 <markwash> jbernard: that does make a lot of sense
14:42:01 <markwash> ativelkov: jbernard: it seemed like maybe you two had a solution for including cinder where cinder references just weren't artifacts, they were regular attributes, and their behavior was plugin or client specific
14:42:07 <jbernard> yeah, the feature would be incomplete without it
14:42:33 <markwash> s/client specific/client defined/
14:42:35 <ativelkov> That's how I see it. The plugin can put the locks, do the volume validation etc.
14:43:04 <markwash> jbernard: does that idea sound like it could work? is there some alternative you prefer?
14:43:36 <jbernard> it sounds reasonable to me
14:43:44 <ativelkov> However we may introduce an artifact type "cinder volume" which will not have any binary backing - just an immutable metadata attribute referencing the volume in cinder
14:44:17 <ativelkov> and store this artifact in glance, and then have a dependency between "instance template" and this "cinder volume"
14:44:27 <markwash> ativelkov: it would be nice if we could do that, however if the glance service doesn't own the cinder volume it seems it would have integrity problems
14:44:36 <jbernard> it will probably require some cinder enhancements - immutable or reference counted volumes perhaps
14:44:42 <markwash> yeah
14:44:52 <markwash> so maybe that could be a follow up approach
14:45:15 <zhiyan> jbernard: currently cinder support readonly a volume
14:45:32 <markwash> zhiyan: but the owner can still delete that volume, correct?
14:45:35 <markwash> that's the issue
14:45:35 <jbernard> yes, but there is no mechanism to describe external references
14:45:37 <zhiyan> yes
14:46:13 <ativelkov> Well, it's the question of agreements. Glance does not own the image binaries if they are put into swift, right? So, somebody can delete the image from swift and this will cause the integrity problems. But we just assume that nobody will do that
14:46:14 <zhiyan> to make the volume be immutable, but volumen entry can still be deleted
14:46:28 <markwash> ativelkov: generally glance owns them today
14:46:56 <ativelkov> Even if they are stored externally, e.g. in swift?
14:47:23 <markwash> yes
14:47:30 <markwash> the single tenant swift store does not use user credentials
14:48:01 <ativelkov> ah, didn't know that
14:48:38 <zhiyan> ativelkov: so do you think we can make the artifact metadata be consistent via a periodical checking
14:48:56 <markwash> periodic checking of what?
14:49:09 <zhiyan> markwash: for a volume, in this case
14:49:21 <markwash> zhiyan: I don't think that's the kind of consistency we're looking for
14:49:27 <ativelkov> I am not sure about "periodic"
14:49:30 <markwash> we want consistency such that the reference never changes
14:49:36 <markwash> not that the reference is always accurate
14:49:38 <markwash> well we want that too
14:49:42 <markwash> immutable, and accurate
14:49:54 <ativelkov> We may make plugins responsible for ensuring the validity of their artifacts
14:50:09 <arnaud__> tbh, I think at this point we are going too specific where the design for the basic is there yet
14:50:28 <markwash> well, and perhaps we should move on
14:50:46 <markwash> there is one other item on the agenda for today
14:50:58 <markwash> #topic removing sensitive info from locations
14:51:32 <markwash> rosmaita and I were looking at this blueprint again in last weeks drivers meeting
14:52:08 <markwash> it seemed like at the mini summit there was a recognition that just removing credentials from locations wouldn't solve our problems like I imagined
14:52:33 <markwash> it definitely solves the problem of making credential management a bit simpler in terms of changing passwords on swift accounts
14:53:02 <markwash> however, it adds to problems with distributing credentials around a deployment
14:53:36 <markwash> and it doesn't really help as much with the client direct download story, because it requires all of those clients to somehow have the same credentials stored locally
14:54:23 <markwash> so the question in my mind is, do we still want to do it just for a solution to the first problem?
14:54:43 <rosmaita> +1 first prob only
14:55:14 <rosmaita> i still think credentials should be managed by keystone, if a client needs them, that's wehre they should come from
14:55:16 <flwang> markwash: are you ware of any other backend will be impacted by this https://bugs.launchpad.net/glance/+bug/1275062 ?
14:55:18 <arnaud__> the first pb is solved by iccha_'s review, that's correct markwash?
14:55:28 <markwash> arnaud__: yes
14:55:59 <markwash> flwang: I'm actually not sure, I think it is mostly swift
14:56:06 <zhiyan> tbh i have a question, can keystone help us, i mean save credentials to keystone, and glance.store query them when needed?
14:56:31 <markwash> zhiyan: it seemed that perhaps barbican was going to help solve that problem
14:56:51 <markwash> but what we need is not just secure key storage
14:56:54 <markwash> but also key sharing
14:57:03 <flwang> markwash: but the problem code is happening at common part, not swift specific, that makes me nervous
14:57:38 <markwash> flwang: perhaps we should make a pass through the code to see if other stores would be vulnerable as well
14:57:48 <markwash> and how, in general, other stores are using credentials
14:57:50 <flwang> markwash: +1
14:57:52 <markwash> just as a general survey
14:58:05 <markwash> we have 2 or 3 minutes now
14:58:08 <flwang> markwash: it would be nice
14:58:34 <flwang> anybody know is there any other store will contain the credential in the location?
14:58:47 <markwash> rosmaita: okay, perhaps I can take another look at barbican and see how it fits this story, and we can unblock this bp
14:58:50 <flwang> sheepdog, gridfs, rbd
14:58:50 <arnaud__> s3?
14:59:17 <markwash> can someone volunteer to look at that and follow up next week?
14:59:30 <flwang> markwash: I will do that
14:59:32 <markwash> #topic community images
14:59:46 <markwash> did we settle on 'community' as the least bad? that was about where I was. . .
14:59:56 <markwash> least bad name, that is
15:00:01 <rosmaita> +1
15:00:22 <markwash> hmm, we need to clear out for the next meeting
15:00:34 <markwash> okay, guys thanks! sorry I was late
15:00:36 <markwash> #endmeeting