14:00:07 <nikhil_k> #startmeeting glance
14:00:08 <openstack> Meeting started Thu Aug 20 14:00:07 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:12 <openstack> The meeting name has been set to 'glance'
14:00:20 <nikhil_k> #topic agenda and roll call
14:00:31 <nikhil_k> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:02:56 <nikhil_k> it would be best to cancle this meeting if no one is around
14:03:16 <bunting> probably so
14:03:41 <bpoulos> o/
14:03:41 <sigmavirus24> o/
14:03:49 <mclaren> o/
14:03:51 <hemanthm> o/
14:03:54 <rosmaita> o/
14:03:59 <sigmavirus24> nikhil_k: just running a couple minutes late, sorry
14:04:07 <nikhil_k> sigmavirus24: np :)
14:04:45 <shalq> what's the first topic ?
14:05:40 <mfedosin> o/
14:05:49 <nikhil_k> I was waiting to see if anyone - ativelkov mfedosin or by anyone else, artifacts related updates can be provided
14:05:57 <harshs> o/
14:06:19 <mfedosin> we're fixing the bugs to adopt artifacts in Murano
14:06:54 <mfedosin> currently I'm implementing filtering by ranges
14:07:33 <mfedosin> Murano needs it to fetch versions like it's done in pip
14:07:57 <mfedosin> for example >=1.0.0, <=2.0.0
14:08:14 <nikhil_k> I think we still need to work out the API
14:08:37 <mfedosin> I think it's a question to Alex
14:08:51 <nikhil_k> yep and since there are no updates on
14:08:52 <nikhil_k> https://etherpad.openstack.org/p/glance-v3-api
14:08:56 <mfedosin> I will publish my proposals next week about API
14:09:22 <nikhil_k> it would be best to get some here or via email
14:09:28 <nikhil_k> that would be good, mfedosin
14:09:33 <mfedosin> independently from existing
14:09:38 <sigmavirus24> is the v3 API spec still in flux?
14:09:53 <sigmavirus24> (question to mfedosin who seems to know what ativelkov is thinking/doing)
14:09:54 <mfedosin> so we can discuss it next Monday
14:10:02 <nikhil_k> sigmavirus24: that's the to-be formal proposal
14:10:16 <nikhil_k> that == etherpad details
14:10:30 <mfedosin> his activity most in Murano
14:10:38 <sigmavirus24> nikhil_k: I mean the spec that was in review for glance-specs around the v3 API
14:10:48 <nikhil_k> ah
14:10:51 <sigmavirus24> The thing is that was still in flux
14:10:55 <sigmavirus24> Even though we've merged v3 API code
14:10:59 <sigmavirus24> And now we have a consumer for that API
14:11:09 <mfedosin> currently he's sitting behind me
14:11:10 <sigmavirus24> And that spec was supposed to change to reflect API wg objects
14:11:13 <sigmavirus24> *objections
14:11:26 <sigmavirus24> But now that will be much harder with murano (prematurely) adopting the API
14:11:34 <nikhil_k> sigmavirus24: right and the EXPERIMENTAL flag would change once those concerns are resolved
14:11:43 <sigmavirus24> nikhil_k: sure
14:11:48 <nikhil_k> and any consumers would need to adopt the same
14:11:52 <sigmavirus24> Just seems like the murano team will get angry at us no matter what happens
14:12:06 <nikhil_k> right, and that clause needs to be clear
14:12:08 <sigmavirus24> (considering they were angry at the summit that artifacts wasn't already merged)
14:12:47 <mfedosin> it's not about Murano team, but our management :)
14:12:53 <nikhil_k> so, question: will murano not be angry if ativelkov is willing to accept this change in the artifacts API?
14:13:03 <mfedosin> and Alex is here to make them not be angry at us
14:13:04 <nikhil_k> there's a bus factor
14:13:10 <sigmavirus24> okay
14:13:11 <nikhil_k> but best of what we have
14:13:23 <nikhil_k> cool
14:13:24 <sigmavirus24> I'm just making sure everyone knows the risks murano is taking right now
14:13:27 <mfedosin> he's a liason between Murano and Glance
14:13:31 <ativelkov> oops, sorry for being late guys. I am right in the middle of murano's voice meeting
14:13:38 <sigmavirus24> hah
14:13:42 <sigmavirus24> no worries ativelkov that's why we have mfedosin
14:13:43 <ativelkov> multitaking i hard for me
14:13:43 <nikhil_k> mfedosin: it would be nice to state that in the wiki
14:13:48 <sigmavirus24> you two do share a datalink between your brains right?
14:14:14 <ativelkov> so, murano is aware about experimental nature of our API
14:14:30 <nikhil_k> mfedosin: ativelkov : can anyone of you please update this etherpad with details about liaisons?
14:14:33 <nikhil_k> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons
14:14:50 <ativelkov> they (actually, we) are ok with v3 API changing any time
14:15:00 <ativelkov> nikhil_k: I will
14:15:03 <nikhil_k> great
14:15:03 <mfedosin> nikhil_k, will be done
14:15:05 <nikhil_k> thanks ativelkov
14:15:11 <nikhil_k> :)
14:15:41 <nikhil_k> sigmavirus24: any more concerns before we move to reviews?
14:15:46 <sigmavirus24> Nope
14:15:48 <ativelkov> So, right now there are a number of bugs in the code which is already merged
14:16:05 <ativelkov> and we'd like them to be fixed before doing the major redesign of v3 API
14:16:15 <ativelkov> both mfedosin and me are working on that
14:16:20 <sigmavirus24> ativelkov: that makes sense, sounded like new features were being added too
14:16:28 <sigmavirus24> that's why I asked about the spec (I haven't had time to check on it yet)
14:16:47 <nikhil_k> ativelkov: so, I think the plan should be keeping v3 experimental for Liberty?
14:16:48 <ativelkov> I've asked the new mmber of our team (Kairat) to move that etherpad to specs
14:16:59 <ativelkov> nikhil_k: I think so, as FF is coming
14:17:00 <nikhil_k> that would be excellent
14:17:21 <nikhil_k> ativelkov: FF is per project
14:17:36 <nikhil_k> and doesn't apply to experimental and non-verlaping features
14:17:44 <ativelkov> ah, that's cool to hear
14:17:51 <mfedosin> I think we should discuss it more detailed on the summit before making api stable
14:18:18 <nikhil_k> cool, sounds like a good plan
14:19:01 <nikhil_k> #topic Reviews, Bugs and Releases
14:19:37 <nikhil_k> https://review.openstack.org/#/c/195820/
14:19:50 <nikhil_k> not sure if this was raised by flaper87 or wko ?
14:21:18 <mclaren> Not sure. It has three +2s
14:22:00 <mclaren> Is there anything in particular blocking it at this point does anyone know?
14:22:05 <nikhil_k> mclaren: I read you got a chance to test this personally
14:22:14 <mclaren> Nope.
14:22:20 <nikhil_k> ah
14:22:24 <mclaren> I can do though if that helps
14:22:38 <nikhil_k> guess I either need to trust eric or force myself to find time for it
14:23:02 <nikhil_k> whoever wants a backport can propose one but likely to not get approved, that's usually true for db migrations
14:23:19 <nikhil_k> mclaren: that would really help!
14:23:31 <mclaren> Ok, np
14:24:08 * mclaren wonders if bunting might do it
14:24:11 <sigmavirus24> wokuma probably added that to the agenda
14:24:42 <nikhil_k> cool
14:24:51 <nikhil_k> great to have awareness about an important patch
14:25:06 <nikhil_k> next one is image-member reuse
14:25:11 <nikhil_k> https://review.openstack.org/#/c/207042/
14:25:18 <nikhil_k> https://review.openstack.org/#/c/190895/
14:25:36 <bunting> I would be up for testing it
14:25:38 <nikhil_k> seems like we don't have any concerns raised on that even after an APIImpact
14:26:21 <mclaren> bunting: cheers :-)
14:26:24 <nikhil_k> I would just amend the spec to include it and merge it
14:26:34 <nikhil_k> bunting: awesome, ty!
14:27:06 <shalq> can core members help review the code in 190895 ?
14:27:26 <sigmavirus24> nikhil_k: I don't think there's been a lot of review for that spec
14:27:40 <sigmavirus24> so I wouldn't say that there haven't been any concerns raise
14:27:41 <sigmavirus24> *raised
14:27:47 <nikhil_k> sigmavirus24: we did a impromptu during one of the drivers' meeting
14:27:51 <sigmavirus24> Ah
14:28:30 <nikhil_k> and people then were okay, we were just giving some time for any last minute red flags. there were none!
14:29:09 <nikhil_k> I can put that up on my review list as I have reviewed it already a couple times and know the change
14:29:17 <nikhil_k> I like what abhishek is suggesting there
14:29:30 <nikhil_k> shalq: so, that minor change should cover it for your patch
14:29:59 <shalq> ok
14:30:03 <nikhil_k> next one is from bpoulos
14:30:04 <nikhil_k> https://review.openstack.org/#/c/183137/
14:30:10 <bpoulos> I would appreciate feedback on the code, especially on two aspects:
14:30:15 <bpoulos> 1. Does the location where the signature verification occurs make sense (ie, right after the checksum is computed)?
14:30:20 <bpoulos> 2. Does the handling of a failed signature verification make sense (ie, set status to killed and delete the image)?
14:30:26 <bpoulos> (I realize I have a few cleanup comments, and I will address them today)
14:31:39 <nikhil_k> bunting: about the delete, the general practice is to not set to deleted and leave it to the user
14:31:57 <nikhil_k> having it in the killed (mostly used for error state) would make more sense
14:32:09 <bpoulos> so just change the status to killed?
14:32:16 <rosmaita> i have a question about #2 ... i thought the glance-side verification was a user convenience, maybe if i upload an image and specify an incorrect signature, i'd prefer to just update the sig, rather than do the entire upload?
14:33:24 <bpoulos> just update the signature, and repeat the verification without doing another upload?
14:33:46 <rosmaita> bpoulos: possibly, though i don't see how you could trigger that
14:33:54 <bpoulos> yeah, that seems pretty round-about
14:33:57 <rosmaita> unless you add a 'validate image' task
14:34:21 <nikhil_k> :)
14:34:41 <bpoulos> in which case, we wouldn't want to set the status to killed when verification failed?
14:35:15 <rosmaita> not sure ... the verification status doesn't really affect the image
14:35:48 <rosmaita> maybe among the metadata you're adding, you add 'glance_verified: true
14:35:53 <rosmaita> or something like that
14:36:03 <bpoulos> as a property?
14:36:08 <rosmaita> yeah
14:36:28 <nikhil_k> that's suseptible to breakage though
14:36:29 <rosmaita> though it would be kind of meaningless except to the original uploader
14:36:30 <bpoulos> alright, so the user could easily decide whether or not to trigger verification?
14:36:56 <bpoulos> i think if the user doesn't want to trigger verification, they can easily provide the properties after the upload completes
14:36:58 <nikhil_k> we need define global prot properties for arbitrary meta for image-signing verification
14:37:21 <bpoulos> nikhil_k: where does that definition go?
14:37:28 <rosmaita> hmmm .... maybe for first implementation, we should just delete the image and decide what makes sense for M
14:37:50 <nikhil_k> bpoulos: and how do we prot the +w mode on that prop after correct validation?
14:37:57 <nikhil_k> yeah
14:38:03 <nikhil_k> wait, why delete
14:38:11 <bpoulos> delete, or just set to killed?
14:38:18 <nikhil_k> it would disappear under the user's node without notice
14:38:24 <nikhil_k> nose*
14:38:53 <rosmaita> so, killed and let the user delete (or re-upload if that bp is impelmented)
14:39:07 <nikhil_k> yeah
14:39:21 <rosmaita> i think we also need to be clear about the status of the metadata on the image
14:39:31 <nikhil_k> not sure what's the best way to convey to the user _why_ the upload failed
14:39:32 <rosmaita> the consumer has to use it to verify everything for themselves
14:39:43 <nikhil_k> right
14:39:58 <nikhil_k> mutating the meta on first write might be a good option
14:40:06 <nikhil_k> but we don't have that granularity
14:40:16 <bpoulos> do we need to protect the properties?
14:40:29 <nikhil_k> bpoulos: if you want to use them for verification
14:40:33 <nikhil_k> yes
14:40:53 <bpoulos> protect as in prevent changing or protect as in define exactly what they are?
14:41:14 <rosmaita> nikhil_k: what would be the implications of allowing a change?
14:41:47 <rosmaita> i'm thinking if it's image-consumer-beware, maybe it doesn't matter?
14:42:04 <nikhil_k> rosmaita: hmm, I think for a shared image. it could be rendered useless by someone who did not intend to mutate the prop
14:42:13 <bpoulos> I think one attack scenario we're considering is that an attacker could delete or modify them -- even if we prevent normal routes of doing so -- but the fact that we have an external CA that limits the valid certificates helps us
14:42:24 <bpoulos> yeah, it could be removed unintentioanlly
14:42:38 <nikhil_k> rosmaita: just loopholes for confusion on the usage, that's all
14:42:38 <bpoulos> and if the client requires the properties, then the client won't be able to boot it
14:43:00 <rosmaita> nikhil_k: agreed
14:43:05 <bpoulos> so the user has to provide them before the upload, or not at all?
14:43:19 <bpoulos> ie, they can't add them after the fact?
14:43:29 <bpoulos> (so that glance doesn't verify, but a client still could)
14:43:36 <rosmaita> it's sounding to me more and more like a task is better suited for this
14:43:40 <nikhil_k> bpoulos: we have somethign already like those and they are called base properties :)
14:43:56 <bpoulos> would we want to make these base properties though?
14:44:00 <nikhil_k> rosmaita: or a migration that adds another base prop
14:44:21 <nikhil_k> bpoulos: the issue is the arbitrary size, right
14:44:35 <nikhil_k> so, (I take the comment back) probably no
14:44:41 <bpoulos> ideally, we'd like to not even be limited to 255
14:44:48 <nikhil_k> yep
14:44:53 <rosmaita> yeah, so cant' predict in advance
14:44:59 <bpoulos> 1024 or 2048 would be even better for signature sizes
14:45:12 <jokke_> ++
14:46:40 <nikhil_k> I think we need to give some time to other reviews posted
14:46:50 <bpoulos> ok :) thanks for discussing image signing for a bit
14:47:04 <nikhil_k> how about we chat on this topic, if needed, after the meeting on -glance
14:47:06 <mclaren> do we have similar behaviour with checksums? where a user can supply the checksum in advance?
14:47:18 <bpoulos> sure, we can continue on -glance
14:47:23 <nikhil_k> it's a base prop though
14:47:56 <mclaren> ok, how bad would adding a new base prop be?
14:48:14 <nikhil_k> I think she wants many such
14:48:23 <nikhil_k> and size of those can be relatively large
14:48:26 <mclaren> ah, ok
14:48:58 <bpoulos> i have four that i'd like to add
14:49:13 <bpoulos> but we can move on to other reviews
14:49:35 <nikhil_k> cool
14:49:38 <nikhil_k> mclaren: next one is yours?
14:49:39 <nikhil_k> https://review.openstack.org/#/c/211086/
14:49:53 <mclaren> oh, not a big deal just a client patch
14:50:11 <nikhil_k> we've had this behavior for along time!
14:50:27 <nikhil_k> but I guess it makes sense to not enforce it during listing
14:51:56 <mfedosin> I agree to +2 it
14:51:58 <rosmaita> or at all ... what's the rationale behind confirming that the info supplied by glance meets the schema?
14:52:32 <mclaren> rosmaita: interesting question. Arguably it's more useful when you're putting stuff in rather than reading it back
14:52:36 <jokke_> rosmaita: point ... who we trust if not our own server ;)
14:52:37 <rosmaita> i mean, unless there's a bug in glance, glance knows what the schema is, and supplies data accordingly
14:53:10 <rosmaita> mclaren: +1 for upload, client should validate, but for download seems pointless
14:53:29 <rosmaita> i mean, what are you going to do? take your business elsewhere?
14:53:30 <nikhil_k> rosmaita: this was introduced when strict enforcement on GET was a thing
14:53:33 <mclaren> well let's agree on list first :-)
14:53:41 <rosmaita> good point
14:54:54 <rosmaita> from the patch, you can see that we already agreed not to validate all the returned images in a list
14:55:07 <rosmaita> so let's just take that to an extreme and not validate any
14:55:35 <jokke_> rosmaita: yeah that validation was killing the v2 performance
14:55:35 <rosmaita> or we could just validate a random one, and drive users crazy
14:55:58 <mfedosin> I think we can add --validate flag to image-list maybe to validate them all
14:56:04 <jokke_> rosmaita: and leave that bug still open, what this change would fix?
14:56:07 <mfedosin> if it's necessary
14:56:13 <nikhil_k> I can think of a reason for validating this during listing but it's not strong enough to break the response. Glance client does on the behalf of the user if the images registered match with the prop articulation as defined by operator needs
14:56:41 <mclaren> mfedosin: an operator may be interested in that I guess
14:56:44 <rosmaita> mfedosin: that's a good compromise
14:56:52 <nikhil_k> yep
14:56:57 <jokke_> mfedosin: wanna propose spec for that? :P
14:57:04 <nikhil_k> but it can be confusing flag
14:57:14 <jokke_> I don't think it should be blocking this going in
14:57:14 <mfedosin> no, it's enough specs for me :)
14:57:19 <nikhil_k> as it overlaps with bpoulos terminology for validation
14:57:25 <rosmaita> i think as long as v1 is around, the glanceclient has to be liberal in what it accepts
14:57:28 <mfedosin> but I can ask Darja to implement it
14:57:40 <nikhil_k> ok, we have a couple mins for that late addition
14:57:57 <nikhil_k> mfedosin: yours?
14:57:58 <nikhil_k> https://review.openstack.org/#/c/200554/
14:58:06 <mfedosin> yep it's mine
14:58:18 <mfedosin> There is a Flavio's concern about adding new config parameter in Glance.
14:58:28 <mfedosin> But for example cinder has it.
14:58:36 <mfedosin> https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/rbd.py#L82
14:58:46 <mfedosin> So I want to hear your opinion - should I abandon it or it's okay?
14:59:19 <mfedosin> Since we have plans to create oslo.rbd project, all these config params will be there and Glance will use them anyway.
14:59:38 <jokke_> I do agree with flaper87's point that it does not make sense to dublicate that. and which one would take preference if you have different values?
14:59:52 <nikhil_k> mfedosin: that sounds better
15:00:05 <nikhil_k> We are out of time.
15:00:10 <nikhil_k> Thanks all!
15:00:15 <mclaren> thanks!
15:00:16 <jokke_> thnx
15:00:16 <mfedosin> okay, thanks :)
15:00:20 <nikhil_k> #endmeeting