14:00:10 #startmeeting glance 14:00:11 Meeting started Thu Feb 6 14:00:10 2020 UTC and is due to finish in 60 minutes. The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:15 The meeting name has been set to 'glance' 14:00:15 #topic roll call 14:00:22 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:26 o/ 14:01:12 o/ 14:01:16 o/ 14:01:24 \o 14:01:43 Lets start 14:01:49 #topic Updates 14:02:31 I have requested a round table with 6 seats for Vancouver PTG 14:02:40 cool 14:02:55 Hopefully we all able to make for the PTG :D 14:03:23 #topic release/periodic jobs update 14:03:38 M2 release is next week 14:04:02 and we need to get multiple imports and copy existing images patches in anyhow 14:04:10 Kindly put some efforts in review 14:04:17 will review them today 14:04:45 I want to tag a release around Tuesday EOD 14:04:46 jokke_, great 14:04:57 rosmaita, kindly have a look as well 14:05:31 As milestone release is near, we have started hitting parser error again 14:05:58 daily once/twice zuul jobs are fails with parser error 14:06:25 So, we need to keep this in mind as well 14:06:35 We have very less time now 14:07:04 kk 14:07:16 Moving ahead 14:07:29 #topic deprecate 'checksum' this cycle? 14:07:44 rosmaita, floor is your 14:07:58 s/your/yours 14:08:25 between, I went through the logs of last meeting and had general idea about this discussion 14:08:46 yes, i guess the logs said it all 14:08:54 If we want to deprecate checksum this cycle, we should do it now 14:09:18 yes, i think we should deprecate in the sense that it will no longer be populated 14:09:27 but we keep the 'checksum' in hte image response 14:09:34 for backward compat 14:09:42 That seems safe. 14:09:49 I like the idea and keeping the image property for backward compatibility 14:09:56 ++ 14:10:01 i guess the other option would be 14:10:12 glance checks to see if md5 is available 14:10:17 and computes it if possible? 14:10:25 probably better to just stop using it, i think 14:10:35 First one is simple and better 14:10:46 ok, works for me 14:10:46 we will have to make some changes in the client 14:10:52 I agree, people are compaining more and more about us doing it and depending on md5 libs 14:11:03 the client will have to fail gracefully if md5 is not around 14:11:24 yes 14:11:34 but it should probably still support computing md5 if that's all that's on the image 14:11:49 the client should handle already not having md5 just fine as it's not in all images 14:12:04 +1 14:12:19 no, what i mean is md5 is there but the os_hash stuff is not 14:12:28 then client will try to compute the hash 14:12:40 and crash & burn if it cannot do it 14:13:12 s/md5/checksum/ 14:13:21 not sure if i was clear there? 14:14:01 this you are talking about legacy images, right? 14:14:15 right 14:14:49 yep, that behaviour might be something worth of asking from operators. I think it would be bad to not check if the checksum is available but there might be other opinions 14:15:10 good idea 14:15:27 we have some kind of option now about use md5 as a last resort or something 14:15:34 i don't remember 14:15:47 I need to check as well 14:16:00 we just revert checking if checksum is there in cases multihash is not 14:16:09 anyone volunteer for doing operators survey? 14:16:44 what exactly would we be asking? 14:18:12 what should be ideal way if checksum is there and os_hash is not available 14:18:30 I think 2 questions: 1) Do we want to expect that md5 checksum is computable if that's the only thing image has and fail if we can calculate it. 2) Do we want to have checksum around at all after deprecation or should we do db migration and get rid of it all together 14:18:50 "fail if we can't calculate it" 14:19:48 here's what we have now: 14:19:51 --allow-md5-fallback If os_hash_algo and os_hash_value properties are 14:19:51 available on the image, they will be used to validate 14:19:51 the downloaded image data. If the indicated secure 14:19:51 hash algorithm is not available on the client, the 14:19:51 download will fail. Use this flag to indicate that in 14:19:52 such a case the legacy MD5 image checksum should be 14:19:52 used to validate the downloaded data. You can also set 14:19:53 the environment variable OS_IMAGE_ALLOW_MD5_FALLBACK 14:19:53 to any value to activate this option. 14:20:22 i think we should keep that behavior 14:20:41 next question is, what to do when md5 not available? 14:20:49 i think we fail the download by default 14:21:03 but we will have to also have an override 14:21:11 because otherwise the user is completely screwed 14:22:03 nope, if md5 is not there we just accept the image 14:22:22 that seems counterintuitive 14:22:52 what other option do we have? 14:22:57 jokke_: when you say "md5 is not there" do you mean the algorithm or the checksum property? 14:23:49 ah, the property 14:24:18 ok, so the situation is: no multihash, there *is* a checksum, but the algorithm is not available 14:24:37 i don't think we want to silently accept the download without some kind of warning 14:25:22 current behavior is: if multihash/checksum properties exist, and download succeeds, then something was verified 14:25:31 i dont' think we want to break that 14:26:23 my point exactly, so I think we should fail if no multihash, but checksum and no md5 lib 14:26:35 or we should just get rid of checksum all together 14:27:05 later founds more reasonable to me 14:27:06 ok, i misunderstood your comment (09:22:03 AM) jokke_: nope, if md5 is not there we just accept the image 14:28:06 yeah, sorry so "if not multihash or checksum properties" 14:28:29 I guess as jokke_ suggested we should do the survey 14:28:34 so the issue is, if i am a user and my system doesn't have the md5 algo, and i want to download an image, and it only has 'checksum' ... it will fail 14:28:44 do we want any way to override that? 14:28:54 i guess you can just do a direct API call 14:28:55 I think it should 14:29:15 yes, agree about the fail; question is do we allow an override in the client 14:29:49 (sorry to be a PITA, but we have to be really clear about what we are asking if we do a survey) 14:30:13 like you said, there is the expectation currently that if we have hash in the image and download succeeds, it has been verified 14:30:57 right, and if it fails, you figure a network disruption or something and try again 14:31:19 but in this case there will be no chance of a retry succeeding 14:31:40 yep ... and if you happen to just be desktop user downloading the image for what ever reason and you land to the situation where it fails due no md5, you can fix your system :P 14:31:41 i guess, the answer is: ask your system admin to install md5 ! 14:31:50 ok, we agree then 14:32:27 cool 14:32:48 rosmaita, could you please create the survey? 14:33:23 i dont' think there's anything to ask anymore? 14:33:49 fine 14:33:50 we will just fail when verification data exists, but there is no algorithm present to do the validation 14:33:55 same as current behavior 14:34:02 well there is still the question do we want to keep checksum and that md5 stuff in the system at all 14:34:19 well, the 'checksum' field definitely yes 14:34:26 or do we want to get rid of it when deprecated and free up the space from db 14:34:29 but i thought we agreed just no pupulating ti at all 14:34:43 we can't get rid of it unless we have a migration path 14:34:57 and it will be a nightmare to convert all this crap to sha512 14:34:59 which might be cumbersome 14:35:10 i don't think any backend supports direct computation 14:35:19 you will have to download, compute, and set the properties 14:35:28 (whicih you arent' allowed to set) 14:35:35 i mean, an admin would have to do that 14:35:43 when was it we implemented multihash? 14:35:44 it's just one small column 14:35:54 stein, maybe? 14:35:57 possibly rocky 14:36:05 rocky 14:36:36 anyway, i think we have to continue to compute it in ussuri 14:36:36 it tagged along with multiple stores 14:36:45 yes 14:37:05 key thing is to get the word out that it will not be computed or populated in victoria 14:37:45 and that is why we should do it quickly 14:37:54 well if we deprecate it now, and give one cycle, we can stop doing it in X 14:38:17 that is actual deprecation policy IMO 14:38:24 mhm 14:38:48 yes, if deprecated in U can be removed in V 14:39:09 it will still exist in U 14:39:14 that satisfies the policy 14:39:19 ok 14:39:25 Moving ahead, as we have more topics to discuss 14:39:47 In short we all agree to deprecate the checksum this cycle 14:39:59 #topic Multiple store import plugins 14:40:30 These two patches are very much important and needs to get merged before Tuesday 14:40:37 multiple import impl - https://review.opendev.org/667132 14:40:47 #link https://review.opendev.org/667132 14:41:12 I guess yebinama is on leave but he promised to have a look if there are any review comments 14:41:53 I have verified his patch, still need some doc changes but we can do it in separate patch 14:42:14 Tested functionally with 2 ceph and 3 file stores 14:42:31 and another one is; Copying existing image impl 14:42:40 #link https://review.opendev.org/696457 14:42:54 This one is depends on former patch 14:43:27 Everything is complete with doc changes, functional tests (including revert check) as well as release notes 14:43:43 Please, please review :D 14:43:52 Moving ahead; 14:44:04 #topic puppet-tripleo needs glance release to get merged 14:44:27 So tripleo guys are working on adding multiple stores support in deployment 14:44:40 but they are stuck as they need latest glance release 14:44:51 I thought it was glance_store they had issue with, not glance service 14:45:32 nope, it's glance which was not returning unicode value for store id 14:45:57 Unfortunately I have been testing everything on py3 so never encountered this issue 14:46:04 #link https://review.opendev.org/704373 14:46:14 see the last comment on the patch 14:46:54 We need to release M2 on time to unblock them 14:47:32 Moving ahead; 14:47:37 #topic U Community Goal: Project PTL & Contrib Docs Update 14:47:46 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012364.html 14:48:09 We already have contributors guide, development policies in our repo 14:48:18 yup 14:48:21 so do we need to follow this community goal? 14:49:25 I guess we are good 14:49:32 I assume you can just mark it as complete 14:49:47 we have the release guide as well 14:50:08 Ok, I will revert to that mail as well after marking it as complete 14:50:33 That was my take too - that we already had what we needed. 14:50:49 cool 14:51:11 I will revert back to mail with appropriate links 14:51:39 #topic Open Discussion 14:51:42 there should be storybord or bug for that somewhere you need to go and mark done 14:52:01 jokke_, yes that is mentioned in the mail 14:52:06 I will do it 14:52:29 guys please review the patches 14:52:36 ok quick question. Anyone has a problem if I try to squeeze uncompress plugin in still this cycle? Seems that lots of image providers are doing compressed images which makes web-download useless 14:53:04 fine by me 14:53:19 no objection here 14:53:39 gr8 14:53:44 tht's all from me 14:54:08 rosmaita, smcginnis anything from you? 14:54:25 Nothing from me. 14:54:35 nope -- should i do a spec lite for checksum deprecation? 14:54:54 yes, that will be good 14:54:58 i think there will be no code change, just a release note 14:55:19 ok, i'll get that moving 14:55:25 thanks 14:55:30 Thank you all 14:55:38 Keep reviewing :D 14:55:51 thanks! o7 14:56:24 I will be online during night time from tomorrow 14:56:40 till M2 release 14:56:55 Thank you again!! 14:57:00 Have a good day 14:57:00 Thanks! 14:57:08 #endmeeting