14:00:23 <jokke_> #startmeeting glance
14:00:24 <openstack> Meeting started Thu Oct 18 14:00:23 2018 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:27 <openstack> The meeting name has been set to 'glance'
14:00:29 <jokke_> #topic roll-call
14:00:34 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:37 <jokke_> o/
14:00:47 <LiangFang> hi
14:00:53 <rosmaita> o/
14:00:54 <Luzi> o/
14:01:01 <rosmaita> abhishek is on holiday today
14:01:47 <jokke_> yeah
14:02:01 <jokke_> I guess we're all here then
14:02:09 <jokke_> #topic updates
14:03:59 <jokke_> more of a quick clarification before I merge this https://review.openstack.org/#/c/597648/
14:04:52 <jokke_> As it's not obvious from the spec, is the validation_data going to be part of the location patch call?
14:05:36 <rosmaita> Yes, it's a new write-only element of the image schema
14:05:45 <rosmaita> but it's an optional element
14:05:45 <jokke_> like we discussed, or is it going to be it's own endpoint and how does the final version affect our mime?
14:05:48 <jokke_> ok
14:05:57 <rosmaita> no change to mime type for patch
14:06:23 <jokke_> ok, so touching the parent object is ok with the json-patch?
14:06:24 <rosmaita> it's an optional element, but all 3 of checksum, os_hash_algo, os_hash_value are required
14:06:42 <rosmaita> yeah, as far as i can tell, it's OK
14:07:28 <jokke_> and how is this gonna affect if there is no supported hash-algo configured in glance?
14:07:44 <rosmaita> ummm ... i forget
14:08:01 <rosmaita> i think you get a 4xx of some type
14:08:11 <rosmaita> may be worth asking that on the spec, tough
14:08:15 <rosmaita> *though
14:08:34 <rosmaita> to be clear, though ...
14:08:38 <jokke_> so if the hash-algo is not configured this is just gonna fail, you're not going to be able to set just checksum
14:08:54 <rosmaita> the user making the call can specify a different hash_algo than is configured in glance
14:09:06 <rosmaita> just has to be a recognized hash_algo
14:09:25 <rosmaita> iain somehow convinced me that was a good idea
14:09:51 <rosmaita> i was thinking we should only allow configured algo, but then we'd need a way to tell the user what that was, maybe a new /v2/info/hash_algo call
14:09:54 <jokke_> ok, I won't be merging it yet today then and will put my questions in there
14:10:29 <jokke_> lets move on, we have a lot in agenda
14:10:53 <jokke_> #topic periodic test patches
14:11:13 <jokke_> so I ninja approved the comment on the store (I think it was store)
14:11:30 <rosmaita> ty
14:13:07 <jokke_> You had anything else on this?
14:13:49 <rosmaita> nope
14:14:17 <jokke_> #link  https://review.openstack.org/#/c/599837/
14:14:22 <jokke_> #link  https://review.openstack.org/#/c/599844
14:14:54 <jokke_> #topic specify image size to avoid resize on backend
14:15:08 <LiangFang> hi
14:15:31 <LiangFang> about this BP, I created the patch for solution2
14:15:51 <LiangFang> do you have a chance to try this?:)
14:16:13 <LiangFang> Implementation(glance part) https://review.openstack.org/#/c/609997/
14:16:23 <LiangFang> Implementation(cinder part) https://review.openstack.org/#/c/609994/
14:16:37 <LiangFang> spec: https://review.openstack.org/#/c/608400/
14:17:11 <LiangFang> If you guys accept solution 2, then I will begin to update the spec
14:17:12 <jokke_> No i have not tried it yet
14:17:20 <LiangFang> OK
14:17:42 <lixiaoy1> do we need a spec for solution 2?
14:18:23 <LiangFang> How do you think? erno and rosmaita
14:18:35 <LiangFang> do we need a spec for solution 2?
14:19:20 <lixiaoy1> as it is to update glance logic about updating the field size.
14:19:46 <jokke_> so if we're going to chenge the behavior we will need at least spec lite for it. We will also need python-glanceclient change I think
14:20:06 <rosmaita> LiangFang: sorry, i was distracted
14:20:13 <LiangFang> solution 2 don't need glanceclient to change
14:20:30 <jokke_> I recall us having a lot of logic in the client around this but it likely was for the v1 api as I don't think V2 has ever supported setting the size
14:20:48 <imacdonn> this is actually rather similar to the validation_data thing
14:20:51 <LiangFang> this is the solution 1
14:21:05 <rosmaita> solution 2 is to update via json?
14:21:14 <LiangFang> solution 2 is:
14:21:45 <LiangFang> cinder try to update the image size after created the image but before uploading the image data
14:22:35 <LiangFang> solution 1 is convey the image size in the http header with the image data in one http request
14:23:04 <jokke_> LiangFang: so we will need this into the client as the user will face the very same issue doing for example image-upload
14:24:03 <jokke_> with image-import we stage the data always in the API node first so we know the size, with image-upload we might know the size at the time of making the call
14:24:32 <LiangFang> yes
14:25:05 <LiangFang> when cinder trying to upload image, it also know the size
14:25:48 <jokke_> yes, what I'm saying is that this is by no means cinder specific problem and we should not make just cinder specific solution for it
14:25:53 <LiangFang> as you said, glance client may need do the similar thing
14:26:19 <LiangFang> OK
14:26:58 <LiangFang> glance client may also need to call "update" to set the image size
14:27:01 <jokke_> but I'll try to dig into it today and give some detailed feedback on the review
14:27:08 <LiangFang> before uploading
14:27:18 <LiangFang> thank you very much
14:27:50 <jokke_> and we need to figure out also if we should fail the upload/import in the case size has been set and it does not match with the payload delivered
14:27:55 <LiangFang> I also will take a look at glance client about this
14:28:00 <jokke_> thanks
14:28:20 <jokke_> ok, the next one is yours as well I think
14:28:26 <LiangFang> yes
14:28:34 <jokke_> #topic save and show store info
14:28:36 <LiangFang> this is about the store info save and show
14:28:58 <LiangFang> this is just a small enhancement from our partner
14:29:47 <LiangFang> things is that: when have multiple backend, we may want to know the backend type, rbd or file
14:29:50 <jokke_> #link  https://review.openstack.org/#/c/605006/
14:29:54 <jokke_> #link  https://review.openstack.org/#/c/605014
14:30:06 <LiangFang> glance -v image-list
14:30:30 <rosmaita> there is a stores info call in rocky
14:30:30 <LiangFang> this patch want to show the store infor in this cmd
14:31:06 <rosmaita> https://developer.openstack.org/api-ref/image/v2/index.html#list-stores
14:31:07 <LiangFang> yes, but store info call only show how many stores in glance
14:32:22 <LiangFang> If the store info displayed in glance -v image-list, then it will be easier for user to know the backend type of the image reside
14:32:41 <imacdonn> is this something that there should be policy control over? maybe a cloud provider doesn't want their users knowing backend details
14:33:12 <rosmaita> yes, the deployer can explain that as part of the store description
14:33:20 <rosmaita> it will show up in the info call
14:33:33 <jokke_> So the store ID is specifically not linked with the driver to avoid leaking backend information
14:33:43 <rosmaita> exactly
14:33:57 <LiangFang> OK
14:34:10 <LiangFang> how do you think lisa
14:34:12 <jokke_> it should be safe to show that, but nothing else
14:34:28 <jokke_> the details exposed are visible from the info call
14:34:32 <lixiaoy1> reasonable to not lead backend info
14:34:55 <lixiaoy1> so can we just allow admin to see the info?
14:35:07 <jokke_> sec
14:35:19 <LiangFang> glance image-show can also see the backend info, but it is for one image
14:36:15 <rosmaita> i think we need a spec for this to explain the use case and why the current features aren't sufficient
14:36:17 <jokke_> #link https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/multi-store.html
14:36:32 <LiangFang> OK
14:37:55 <jokke_> if we do not show the '"store": ["reliable"]' which is returned from the creation response, that is the extent we should go with show as well
14:38:31 <jokke_> user has then the info call to see the details of that store exposed by the deployment if they don't remember it out of their head
14:40:12 <lixiaoy1> jokke_: does glance already have the interface to show store info?
14:40:36 <rosmaita> #link https://developer.openstack.org/api-ref/image/v2/index.html#list-stores
14:41:03 <jokke_> I thought it was there, but based on your proposal I think it might be missing?
14:41:30 <jokke_> I thought we returned the store ids
14:41:42 <lixiaoy1> from the link list-stores, the response includes store lists which has id, description, and default
14:43:00 <jokke_> yes, that does exist for sure
14:43:44 <jokke_> so if the detailed listing and show does not provide the list of store ids, that's something we indeed should add
14:43:51 <jokke_> but not the full store details
14:44:26 <LiangFang> is list store the same as "glance stores-info"
14:44:27 <LiangFang> ?
14:44:47 <jokke_> sorry, yes stores-info not list-stores
14:44:53 <rosmaita> well, one is the API call and the other is handled by the CLI
14:45:23 <jokke_> in client
14:45:38 <LiangFang> OK, glance stores-info show something like:
14:45:39 <LiangFang> | stores   | [{"default": "true", "id": "ceph"}, {"id": "locallvm"}] |
14:45:45 <LiangFang> this is my environment
14:45:48 <jokke_> rosmaita: I thought we returned the store id's image is in
14:46:20 <rosmaita> jokke_: i believe it does appear on the image response
14:46:38 <rosmaita> LiangFang: could be that the description is not configured in your environment
14:46:49 <rosmaita> or could be that the client does not display it
14:46:50 <jokke_> LiangFang: yes, and the image-show should give you "stores": ["ceph"] if the store was not specified
14:47:28 <LiangFang> glance -v image-show 0de67910-661e-4a2c-b5de-bcdc4d4a62db
14:47:47 <LiangFang> and it seems no store id
14:48:16 <jokke_> ok, yes we should fix that
14:48:28 <jokke_> that is bug I believe
14:49:12 <jokke_> we're running out of time, lets move forward and continue this investigation offline
14:49:17 <LiangFang> I will update more info in the review
14:49:21 <LiangFang> OK
14:49:23 <LiangFang> thanks
14:49:30 <jokke_> #topic image encryption spec
14:49:47 <Luzi> we still would appreciate some feedback on our spec and answering any questions there.
14:49:48 <jokke_> #link https://review.openstack.org/#/c/609667/
14:50:10 <Luzi> and as already mentioned in the ML, we created an etherpad to discuss the location for the proposed image encryption code:
14:50:23 <Luzi> #link library discussion https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption
14:50:57 <Luzi> we would like to recieve input and comments from all involved projects, so please participate if possible :)
14:51:47 <Luzi> to make this short: that's all i think
14:53:08 <jokke_> ok, thanks. Looking the spec discussion it seems that there has been some question about scenarios thrown around already. Lets just make sure that the spec is very clear about the scope
14:53:55 <jokke_> I'd hate to see bunch of security bugs appearing just because we provided new security feature that doesn't fill it's expectations
14:54:31 <Luzi> jokke_, we will keep this in mind :)
14:54:38 <jokke_> so everyone interested, please review and participate
14:54:43 <rosmaita> i still think having glance/cinder/etc have a dependency on openstackSDK seems crazy, but i am having trouble articulating what is so wrong
14:54:53 <jokke_> moving on to last topic of the day
14:55:04 <jokke_> #topic upgrade check
14:55:07 <jokke_> #link https://review.openstack.org/#/c/610661/
14:56:36 <rosmaita> i put this topic on as a point of information
14:57:09 <jokke_> So yes, I have eyeballed the discussion and I kind of fail to see the importance of this so it has not been at the top of my priority list
14:57:12 <rosmaita> do we have anyone on the glance side particularly interested in this stein comunity goal?
14:57:51 <jokke_> If we have time to dig into it or someone stepping up who is heavily invested into the topic, great
14:58:27 <jokke_> if both of the above fail, we likely will fail the community goal as well
14:58:56 <jokke_> time check, last minute
14:58:59 <rosmaita> i got the impression from mriedem's email that he's willing to work on it with a bit of guidance from someone on the glance side
14:59:18 <jokke_> rosmaita: yeah, that was the discussion we had in PTG
14:59:20 <rosmaita> i think lbragstad is interested in just getting the scaffolding in place
14:59:48 <lixiaoy1> jokke_: this feature, do you mean upgrade check?
15:00:20 <jokke_> so if Matt finds lbragstad's base work useful to continue on, great
15:00:25 <jokke_> lixiaoy1: yes
15:00:39 <jokke_> we're out of the time. We can continue on #openstack-glance
15:00:42 <jokke_> thanks all!
15:00:48 <jokke_> #endmeeting