14:01:26 #startmeeting glance 14:01:27 Log: http://eavesdrop.openstack.org/meetings/glnce/2019/glnce.2019-09-05-14.01.log.html 14:01:28 Meeting started Thu Sep 5 14:01:26 2019 UTC and is due to finish in 60 minutes. The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:32 The meeting name has been set to 'glance' 14:01:34 #topic roll-call 14:01:34 o/ 14:01:37 o/ 14:01:40 o/ 14:02:40 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:03:07 #topic updates 14:03:34 As mentioned in agenda, abhishekk will be serving as PTL for U cycle. GZ!!! 14:03:54 \o/ 14:04:02 thank you :D 14:04:19 I'm not gonna disappear anywhere, just freeing up some time to give other things on my plate the fous they deserve 14:04:28 focus 14:04:31 that is good news 14:04:42 \o/ 14:04:55 i will be reducing my involvement, however, most likely to on-demand reviews 14:04:59 and change of PTL just is pure simply healthy every now and then :D 14:05:26 plus, abhishekk is ready to do it! 14:05:27 rosmaita, congratulations to you as well 14:05:32 ty 14:06:10 I will make sure to get some timely reviews from both of you :P 14:06:13 rosmaita: nothing to celebrate about that for s but hopefully good for you 14:06:38 :D 14:06:47 and sorry for loads of typos ... new keyboard I haven't got used to yet 14:06:59 moving on 14:07:16 #topic release & periodic job updates 14:07:40 So M3 is just a week away 14:07:46 #link https://etherpad.openstack.org/p/glance-train-priority-patches 14:08:20 This is the etherpad where all the important patches are stacked up 14:08:40 jokke_, will let us know about the priorities 14:08:55 Periodic jobs all gree in last week 14:09:58 that's it from me 14:10:19 so first of all, we have still bunch of specs unmerged that are on our list to be included this cycle https://review.opendev.org/#/q/project:openstack/glance-specs+status:open 14:10:29 would really really like some acs on those 14:10:41 ack 14:11:00 moving on 14:11:12 #topic Cinder encryption key delete 14:11:43 #link https://review.opendev.org/#/c/671503/ 14:11:56 I'd really like to see this landing for m3 14:12:38 as usual I have no problem writing the reno for that 14:13:20 Code looks good to me, even tested it in local environment 14:14:07 ok, moving on 14:14:14 #topic cluster awareness 14:14:40 for us to work on the caching api we would need to get the cluster comms moving. 14:14:55 The spec is still sitting without reviews 14:15:13 #link https://review.opendev.org/#/c/664956/ 14:16:12 we've been testing the patch stability extensively with abhishekk due to lots of early gate failures due to it, but they were pretty much all failing differently and all local testing seems stable 14:16:43 so I'm more confident that the initial patch is ready to land and to be built on top of 14:18:26 smcginnis & rosmaita: specially looking input from you guys on the spec and also Cyrils spec for the cache api ... as usual we want to make sure no-one has big concerns before merging those specs 14:18:56 Will try to take a look today. 14:19:04 greatly appreciated 14:19:06 ok 14:19:25 #topic Image import configs 14:19:42 So I thought this was easy issue to fix 14:20:05 uh oh 14:20:12 We decided to go with it's own config file due to the glance-api.conf being insanely bloated 14:20:56 well, the reality is that it's very very difficult to get oslo_config to load multiple config files with anything else than the config folder option 14:21:25 which absolutely blows everything if there is multiple config files with same keys in the folder 14:21:41 like -scrubber.conf etc. 14:22:06 it works if you specifically pick which files you want, though? 14:22:13 nope 14:22:18 so that's the second problem 14:22:39 if you specify multiple --config-file options, it picks up the first and ignores the rest 14:23:04 oslo_config also has ways to find config files, but not dynamically load them 14:23:52 so we can't even ask oslo_config to pick up the glance-image-import-conf from "same or any logical location" where configs are loaded and parse it 14:24:14 not that this helps, but that seems like a bug ... have you talked to ben nemec? 14:24:25 I went to the lenghts of trying to add it to the config file list and reload the configs after but yet again it just gets thrown away and ignored 14:25:03 I have not yet 14:25:27 it might be bug, but like you said it doesn't hep us atm. 14:25:52 so the short term thing for image import, is just include that stuff in glance-api.conf 14:26:03 We spent about a week with abhishekk banging our heads agains the wall to figure out all this on something I thought was quick and easy fix 14:26:26 yes 14:27:12 there are those two options, either we dumb all that to the already bloated -api.conf and call it good or we document how to properly use the --config-dir option and stick with that unless we figure out if we have other options 14:27:50 and that's why I wanted to bring this up 14:28:05 I prefer the later but what do you rest think? 14:28:19 i am against the config-dir 14:28:31 our etc/ is really bloated with files 14:28:49 for all the command line utilities 14:28:49 +1 14:29:15 yes so that makes the devstack usecase more difficult 14:29:37 which is fundamentally broken already so I don't really care about that too much 14:29:41 i think we just move the stuff to glance-api.conf, using the same groups (which we know does work) and i can write an upgrade note 14:30:16 this will be easy 14:30:18 if we decide to stick with the single config file, I really want to start cleaning that bloat away 14:30:47 well, i am against the "bloat cleaning" because that's actually documentation 14:30:53 I'm fine with single config file, but then we really need to get rid of that boilerplate crap that osic pushed in there 14:31:07 unless you want to maintain serious config docs 14:31:09 up to you 14:32:38 (sorry, I am dropping, felling uneasy) 14:32:45 we have quite a lot of that in place and yes I'd rather have readable config files and decent documentation than neither 14:32:50 abhishekk: feel better! talk to you soon 14:32:55 take care abhishekk 14:32:56 please drop me mail in case urgency 14:33:14 jokke_: well, think of the sample conf as a document, not a actual config file 14:34:45 well that's not really the case ... it has loads of comments in the config file, which of about 50% (line wise, not character wise) is actually useful 14:35:40 like my point is, our glance-api.conf is ~6000 lines 14:36:10 but so what? you don't have to actually use that one if you don't want to ... look at the devstack glance-api.conf 14:36:18 it's like 20 lines 14:36:36 but it's useless unless you already know what the options mean 14:36:42 anyway, we are getting off track 14:36:58 are you going to put up a patch to remove the image import conf ? 14:38:04 that is one option unless I find other sensible way to do it 14:38:19 ok, there is some time 14:38:26 it's def a bugfix, not a feature 14:38:33 yeah, that's literally like last option I want to do 14:39:18 but I keep poking it 14:39:26 lets move on 14:39:34 sounds good 14:39:45 #topic python 3 testing community goal 14:40:30 not much other than what's on the agenda 14:40:53 need an approval on https://review.opendev.org/#/c/664475/13 14:41:08 #link https://review.opendev.org/#/c/664475/13 14:41:19 the other patch is 14:41:23 #link https://review.opendev.org/#/c/664477/ 14:41:39 yeah 14:42:16 i don't know if my concern is valid 14:42:32 so the classifier question is two folded 14:43:20 we have defined already that we do not expect the ssl to work and we do expect people using other methods to terminate ssl before the service 14:43:50 I think the best thing to do would be to remove the ssl support all together and call it good 14:44:12 that makes a lot of sense 14:44:15 but I do share your concern 14:44:45 do we want to classify the py3 fully supported before we have removed the ssl? 14:44:57 that's a much harder question 14:45:02 i really don't know 14:45:26 I'm fine with either way, but perhaps worth of addressing wider community with that as form of ML thread 14:45:32 ? 14:45:42 yeah, that's a good idea 14:46:02 #action jokke writes a ML thread about Glance SSL and py3 classifier 14:46:17 excellent 14:46:21 #topic the md5 situation 14:46:34 this was from you as well 14:46:52 yeah, here's the deal 14:47:13 i think this is a client problem first 14:47:38 md5 is considered insecure 14:47:51 Are you talking about the client cache file naming or our actual data checksums> 14:48:00 first, just the client not crashing 14:48:14 what i mean is, some systems don't include md5 at all 14:48:32 so if you're running glanceclient, i think you can run into nonrecoverable errors 14:48:45 we check for os_hash* first, and use if it's there 14:49:17 but we have the fallback 14:49:36 so you're talking about the payload checksums now? 14:49:37 i don't think that terminates gracefully if md5 can't be found 14:49:50 yeah, sorry, the download 14:49:57 i don't think we compute on the upload? 14:50:08 most likely not. We did not implement any fallback for the fallback 14:50:48 yeah, that was my recollection, i wrote that code, just assumed that md5 would be there 14:50:59 as the multi-hash is fairly recent addition and we wanted to address the security cocern of the hashes in the way we don't break upgrades 14:51:11 concern 14:51:15 i guess the other thing is i don't remember when the md5 thing gets created 14:51:25 because that's were the failure will occur 14:51:46 but i guess this is a bug (if it actually is a problem), so doesn't have to be fixed before next week 14:51:56 I can't remember if we dropped it to be done if the os_hash is done or if we ended up populating both 14:52:11 yeah, i need to look at the code 14:52:27 but it will also be a problem for glance itself at some point 14:53:24 So any action on payload hashing will not remove the client depending on md5 14:54:19 as we use md5 hashes on the client cache file naming 14:55:08 crap 14:55:29 So we do have dependency to md5 for foreeeable future 14:55:36 foreseeable 14:55:48 the problem is that RHEL carries a patch or two that allow md5 as long as you use an flag indicating this is not a security implication 14:55:58 but i don't think upstream python/linux likes it 14:56:08 and the later thing has nothing to do with security measures 14:56:12 looks like the preferred solution is just to remove md5 completely 14:56:53 so even though it's an OK use security-wise, we won't be able to do it 14:57:05 anyway, i don't think we need to worry for Train 14:57:15 no too late for that tbh 14:57:30 just need some kind of plan for Unicorn 14:57:42 one thing we could do is change the fine naming _if_ .glanceclient is not present 14:58:00 so any new environment would not cause issue for us dropping it in the future 14:58:48 there is not unicorn release ... lets not go there ... mailing list has lovely thread about that whole mess 14:59:01 ok, i just wanted to surface it as something for Abhishek to worry about! 14:59:40 yeah ... lets see if we can squeeze in that naming change before we need to release final client, if not it will be U issue 15:00:15 but no need to worry about the download as we depend on the md5 way before we hit any of the download code 15:00:29 ok 15:00:31 and we're out of time 15:00:43 Thanks all! 15:00:47 bye! 15:00:51 #endmeeting