14:00:41 <abhishekk> #startmeeting glance
14:00:41 <openstack> Meeting started Thu Aug  1 14:00:41 2019 UTC and is due to finish in 60 minutes.  The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:44 <openstack> The meeting name has been set to 'glance'
14:00:58 <abhishekk> #topic roll call
14:01:02 <abhishekk> o/
14:01:36 <zhengMa> hi
14:01:41 <mhen> o/
14:01:50 <rosmaita> o/
14:01:56 <abhishekk> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:02:15 <abhishekk> jokke_, is away this week, so I will be chairing the meeting
14:02:29 <abhishekk> we have pretty small agenda today
14:02:35 <davee_> o/
14:03:07 <abhishekk> #topic release/periodic jobs update
14:03:30 <abhishekk> So we have an priority patches etherpad
14:03:41 <abhishekk> #link https://etherpad.openstack.org/p/Glance-Train-MileStone-2-Release-Plan
14:03:51 <abhishekk> Need reviews for them
14:04:24 <abhishekk> I have added ToDo list section on line #29
14:04:30 <abhishekk> Kindly have a look
14:05:04 <abhishekk> As we are not able to get all patches merge today and tomorrow I would like to push the release to next week
14:05:09 <abhishekk> rosmaita, ^^^
14:05:28 <rosmaita> ok
14:05:44 <abhishekk> Requesting all the members to review the patches from etherpad
14:06:07 <abhishekk> Regarding periodic jobs, one failure due to timeout during last week
14:07:14 <abhishekk> I have a feeling that once we remove registry code we will not able to see this error again
14:07:22 <davee_> abhishekk:  can you clarify what is meant by the Configuration regeneration?
14:08:03 <davee_> I didn't see a link to any documentation
14:08:20 <abhishekk> davee_, for each milestone release we regenerate the configuration files and add it as a sample to the source code
14:08:35 <rosmaita> davee_: https://docs.openstack.org/glance/latest/contributor/refreshing-configs.html#when-to-refresh-the-sample-configuration-files
14:08:48 <davee_> thank you
14:08:48 <abhishekk> rosmaita, thank you
14:09:47 <abhishekk> The reason I was saying that getting rid of registry will get rid of this error is that, when a functional test fails the error log attaches api as well as registry logs to it as well
14:10:08 <abhishekk> and as we are not using registry anymore these logs were useless to attach
14:10:24 <rosmaita> that will be nice
14:11:16 <abhishekk> So once we have sorted out milestone 2, I will try whether it is possible in tests to not to attach registry logs to failure trace
14:11:25 <abhishekk> That's it from this topic
14:11:47 <rosmaita> ok, i was just looking over the etherpad, will try to get my reviews updated today
14:11:57 <abhishekk> rosmaita, great
14:12:23 <abhishekk> #topic Open discussion
14:12:26 <rosmaita> jokke_ is back, right, just had a conflict for this meeting?
14:13:20 <abhishekk> rosmaita, jokke_ is somewhere in Europe to attend the wedding, he will be back on Monday
14:13:35 <rosmaita> oh, ok, i have not been paying attention
14:13:40 <zhengMa> rosmaita: hi, I have seen your comments
14:14:04 <rosmaita> well, i can have everything reviewed by monday for sure, then he can do a final look, and we should be ready to release next week
14:14:18 <abhishekk> is it possible for you to ping Sean
14:14:26 <rosmaita> zhengMa: cool, looks like your email and patch to nova had good results
14:14:53 <abhishekk> rosmaita, yep, that sounds good
14:15:01 <rosmaita> abhishekk: i think he is back, but i'd kind of like jokke_ to review since he's more familiar with the direction the multibackend is going
14:15:17 <abhishekk> Till then I will update the documentation for cache related changes
14:15:23 <abhishekk> rosmaita, ack
14:15:49 <rosmaita> abhishekk: do you want me to draft the release notes patch?
14:15:58 <rosmaita> or do you have one?
14:15:59 <abhishekk> that will be awesome
14:16:42 <rosmaita> jokke_ mentioned somewhere that we should bump the API version, have you discussed that with him?
14:16:42 <abhishekk> The plan is to avoid the milestone 3 release and make M2 as a release candidate
14:16:46 <abhishekk> if possible
14:17:15 <abhishekk> we have already bumped API version for multistore
14:17:17 <rosmaita> ok, i have not given up on removing owner_is_tenant in Train, though
14:17:54 <abhishekk> I guess he was talking about moving cache operations under v2 API where API bump might be needed
14:18:08 <rosmaita> ok, that would def need a bump
14:18:33 <abhishekk> rosmaita, ack, in that case and if we found any issues in M2 then we will release M3
14:18:54 <rosmaita> sounds good
14:19:11 <abhishekk> great
14:19:20 <abhishekk> anyone has anything to discuss
14:19:25 <rosmaita> i guess jokke_ could make an ML announcement about an early RC available for testing to give multistore a workout
14:19:31 <mhen> o/
14:19:57 <abhishekk> rosmaita, right
14:20:11 <abhishekk> mhen, you want to add anything
14:20:39 <mhen> I'd like to discuss a small topic concerning the image encryption contribution
14:20:56 <abhishekk> mhen, please go ahead
14:21:32 <mhen> https://review.opendev.org/#/c/609667/
14:21:58 <mhen> rosmaita, you suggested to re-use 'min_disk' or 'virtual_size' instead of introducing 'os_decrypt_size'
14:22:00 <rosmaita> some jerk keeps putting -1s on that patch
14:22:03 <rosmaita> :)
14:22:14 <rosmaita> mhen: just wondering whether that would be ok
14:22:30 <mhen> that's what I want to discuss on a general level
14:22:53 <rosmaita> good, i just wanted to make sure we looked at it
14:23:04 <rosmaita> them not being suitable is a perfectly ok answer
14:23:28 <mhen> I'm not aware of the entire scope of their usages across the components
14:23:38 <abhishekk> mhen, could you please also add your specs in etherpad https://etherpad.openstack.org/p/Glance-Train-MileStone-2-Release-Plan
14:24:08 <rosmaita> well, min_disk can be used by nova to reject builds on flavors that don't satisfy that size in GB
14:24:47 <rosmaita> it's mostly used for windows images where you need a lot of disk for the VM to perform well
14:25:12 <rosmaita> but it's a very rough measure, in GB
14:25:26 <rosmaita> virtual_size -- i don't know that anyone uses it
14:25:37 <rosmaita> glance doesn't populate it, an admin has to
14:25:50 <rosmaita> or maybe a regular user
14:26:18 <mhen> in our setup (queens) we mostly observed virtual_size to be not specified
14:26:26 <rosmaita> that's right
14:26:48 <rosmaita> it never got used after it was added
14:26:53 <mhen> I would prefer to re-use that one if I had to choose between either
14:27:06 <rosmaita> ok, but only if it makes sense
14:27:17 <abhishekk> I haven't seen use of virtual_size as well
14:27:42 <rosmaita> now that i think about it, virtual_size is not appropriate
14:28:01 <mhen> is there any definition of those values
14:28:09 <mhen> that actually state what they are meant to express?
14:28:11 <rosmaita> maybe in the image schema?
14:29:13 <abhishekk> it just states virtual_size of image in bytes
14:29:23 <rosmaita> https://docs.openstack.org/api-ref/image/v2/index.html?expanded=show-image-schema-detail#image-schemas
14:29:40 <rosmaita> "Virtual size of image in bytes"
14:29:46 <rosmaita> :)
14:30:00 <rosmaita> min_disk: "Amount of disk space (in GB) required to boot image."
14:30:42 <rosmaita> i think that if it would be useful to have an exact byte count of the decrypted payload, then you should introduce your new field
14:31:14 <mhen> I vaguely remember we use decrypt_size both as an upper as well as a lower boundary for some checks (not entirely sure right now), so min_disk would be kinda inappropriate
14:31:18 <abhishekk> +1
14:31:46 <rosmaita> ok, that works for me
14:32:21 <mhen> okay, we will look into virtual_size and then conclude whether a new field is necessary or not
14:32:46 <rosmaita> actually, don't bother, just introduce the new field
14:33:04 <rosmaita> i could see both being needed if virtual_size starts being used
14:33:36 <rosmaita> i don't know why i'm being so parsimonious about the metadata, they're really cheap because they won't be in the images table
14:34:04 <abhishekk> :D
14:34:23 <mhen> rosmaita, it's fine. We appreciate your intent to make this as streamlined to the usual workflow as possible.
14:34:42 <rosmaita> mhen: what did you think about the config option situation?
14:35:38 <mhen> rosmaita, will reply to that. In short: we can omit the new config entry for disabling unencrypted images if we have the possibility to do so via the container_formats entry.
14:36:11 <rosmaita> ok, sounds good
14:36:13 <mhen> regarding the unavailability of public images in that case: yes, that will be a limitation for now.
14:36:47 <rosmaita> ok
14:36:52 <mhen> but the provider has to consciously configure that setting - so they should be aware of the consequences
14:37:08 <mhen> we just need to remember to put them into the docs :)
14:37:29 <rosmaita> my only other concern was a clear explanation of the 'os_encrypt_format' field
14:38:34 <mhen> I agree that the naming is a bit inappropriate
14:38:42 <mhen> will reply on the spec about that
14:38:58 <rosmaita> great
14:39:31 <mhen> thanks for your input!
14:40:34 <abhishekk> should we conclude?
14:40:50 <abhishekk> unless anything to discuss further
14:41:22 <rosmaita> nothing from me
14:41:56 <mhen> yes, that was all :)
14:42:09 <abhishekk> davee_, zhengMa ??
14:42:15 <davee_> I'm good
14:42:35 <abhishekk> Cool
14:42:43 <abhishekk> Thank you all, see you next week
14:42:51 <zhengMa> I'm good
14:42:54 <davee_> o/
14:42:55 <zhengMa> Thank you
14:42:56 <abhishekk> DON'T forge to review patches :D
14:42:59 <rosmaita> ok, bye everyone
14:43:03 <zhengMa> bye!
14:43:11 <davee_> bye
14:43:14 <abhishekk> #endmeeting