14:00:26 #startmeeting glance 14:00:27 Meeting started Thu Nov 8 14:00:26 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:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:30 The meeting name has been set to 'glance' 14:00:33 #topic roll-call 14:00:36 o/ 14:00:48 o/ 14:01:12 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:22 Morning rosmaita 14:01:33 good afternoon to you! 14:02:15 lets give couple of minutes to see who else is joining us 14:02:40 sounds good, full agenda, so we should have some more people soon 14:05:02 ok 14:05:07 #topic updates 14:05:28 So Berlin Summit is in next week, no meeting 14:05:38 ok 14:05:41 Spec deadline is 2 weeks after summit 14:05:56 so 3 weeks to go to get them specs in 14:06:26 jokke_: that reminds me, did you ever send out the operator survey about changing default image visibility? 14:06:41 FECK 14:06:48 It's going out today! 14:06:52 i was thinking that will require a spec lite 14:06:55 ok, cool 14:07:11 totally forgot that 14:07:27 yeah 14:07:30 also, procedural question 14:07:42 shoot 14:07:43 for deprecated config opts, do we need a spec-lite to remove them? 14:07:52 i'm thinking of owner_is_tenant 14:08:03 nah, if they are deprecated we clean them out and have reno for them 14:08:17 ok, that gives us some flexibility 14:08:53 nice, something else on this? 14:09:20 nope, other than maybe i'll take an action item to make a list of deprecated opts that haven't been removed 14:09:28 sounds good 14:09:31 could be some low-hanging fruit 14:09:42 #topic periodic jobs 14:09:48 #action rosmaita compile list of deprecated options 14:09:53 all green! 14:09:56 I see note on the etherpad that everything is green :) 14:10:04 except occasionally the keystone tips functional py35 14:10:13 http://zuul.openstack.org/builds?project=openstack%2Fglance&pipeline=periodic&job_name=glance-tox-functional-py35-keystone-tips 14:10:20 yah, have you had any eye on those what times out? 14:10:34 no, i haven't looked 14:10:38 kk 14:10:46 for a week it looked like abhishek's change had fixed it 14:10:51 and then it failed again yesterday 14:10:57 yeah 14:11:28 might be something us related, might be something test framework related, might be something infra related. Lets keep eye on them 14:11:33 yep 14:11:46 that's all on periodic jobs 14:11:59 we should wish Happy Diwali to everyone not here, though 14:11:59 #topic smuggling validation data on location add/replace 14:12:31 Soo I saw your review there and went ahead and merged the spec 14:12:40 great 14:12:49 it obviously hit merge conflict but I think it finally merged this morn 14:13:41 slightly off topic, the image_cache uses checksum for download validation 14:13:55 i don't know if we want to take a performance hit on that to use multihash? 14:14:18 I think we do 14:14:34 ok, i will file a bug 14:14:41 specially as it seems that the md5 is running away 14:14:54 well, that's not completely clear 14:15:00 it's ok for non-security uses 14:15:15 like making sure no bit flips during transfer 14:15:22 yeah, but I rather be prepared for the environments where it's not available 14:15:30 i am still trying to get a timeline on that 14:16:03 yeah, we should probably assume not available 14:16:12 cool ... so this is not our first priority issue, just something we want to keep track of and be ready to act if needed 14:16:36 #action rosmaita file glance bug about image cache does not use multihash to verify download 14:16:47 another good low hanging fruit for someone who suddenly has afternoon of free time :D 14:17:08 yeah, there's some example code in glanceclient 14:18:12 i'll try to carve out some time to test out imacdonn's patches, i have an S-1 devstack up 14:19:13 same here, I need to just reroll my containers running my devstacks 14:19:41 i need to get with the containers program, i am still using VMs 14:20:11 I just run lxc bare and simple :D 14:20:19 ok lets move on 14:20:30 #HTTP header encoding 14:20:36 #topic HTTP header encoding 14:20:44 i guess this is me 14:20:52 well, it's my fault, anyway 14:21:02 :o 14:22:10 we had that issue back in early rocky where some update to something broke something, and the glanceclient tests were breaking something, so the problem was sending unicode in headers which isn't strictly allowed, it's supposed to be 7bit ascii only 14:22:48 yes, I recall that 14:22:48 so i put up a change to use urlencoding to get unicode->7 bit ascii, and then sent that over in glanceclient headers 14:23:14 problem is, urlencoding may be a bit too much 14:23:36 it encodes some chars c where ord(c) < 128, which you don't need to do 14:23:50 ok 14:23:50 but the standards are a bit vague on how this should be done 14:24:05 anyway, we are gradually finding a case here or there that this change breaks 14:24:26 i think wxy found sometimes the token was getting corrupted and fixed that 14:24:39 I'm pretty sure, we're not the only ones dealing with this. Is there any safe-decode libs to just handle it? 14:24:48 and ian found that the hostname part of urls are being hosed 14:24:57 i haven't found anything 14:25:09 the lib we are using allows you to specify a set of safe chars 14:25:17 that's what wxy and ian do 14:25:27 but i don;'t know of a list anywhere 14:25:33 anyway, here is the actual point 14:25:52 i was holding off on ian's patch until we figure out a thorough way to fix this 14:26:00 but no one seems to have time ATM to tackle that 14:26:18 so i have +2'd his patch to at least get this particular case he's running into fixed 14:26:44 can we just tell the lib "do not touch anything ord(c) < 128? 14:26:57 s/?/"// 14:27:04 2? 14:27:07 "? 14:27:09 i think we could, by passing it a list of 127 chars! 14:27:09 :P 14:27:16 ohhh :| 14:27:39 yeah, but my idea was to scan the string first to see if any chars are out of range before doing anything 14:27:45 probably the same complexity 14:28:17 problem is, we still don't know what to do when we have a string with out-fo-range chars 14:28:52 Is there any reason why we shouldn't just reject it? 14:29:10 yeah, we need to support unicode 14:30:11 it's glancelient that had the tests that were using unicode, so i figured it was important to us at some point 14:30:44 i think i should take an action item to write up a new bug for this and be clear about exactly what the problem is 14:30:50 Well it WAS at least with v1 14:31:01 that's true 14:31:04 where all tag and property stuff happened over headers 14:32:21 so i think we should either (a) find a library that handles this properly (there must be one if it's a real problem) or (b) take your string-rejection strategy 14:32:25 now we are getting back to the same problem again 14:32:38 the codec gives a nice exception if the string is out of range 14:32:47 as for example the store IDs for where the image will be stored goes over headers again 14:32:53 so we wont' need to scan or anything 14:33:01 oh yeah 14:33:11 that is still experimental 14:33:20 we could require store IDs to be 7bit ascii 14:33:27 the descriptions can be unicode 14:33:56 yeah, that's a bit of bandaid but I guess so 14:34:15 I think we need to keep this hard on mind before dumping any more crap to the headers 14:34:29 and start being more strict that the stuff needs to happen before 14:34:40 and use the json based calls 14:34:56 #action rosmaita propose patch to multi-backend config opts saying store ID must be 7-bit ASCII 14:35:16 yeah, problem is that it makes the actions extremely un-atomic 14:35:39 i guess we could do multipart uploads 14:35:45 json+data 14:36:10 jayy for HTTP based APIs ;) 14:36:49 I see only Imperial fecktons of ways that would go so badly wrong :D 14:36:59 yeah, no kidding 14:38:58 o/ 14:40:13 ok moving on 14:40:27 #topic list --include-stores 14:40:30 anyway, back to the point, are you ok with imacdonn's quick-fix patch? 14:40:46 oops, sorry about the slow typing 14:40:58 #undo 14:40:59 Removing item from minutes: #topic list --include-stores 14:41:14 I will need to review the patch 14:41:29 sounds good, just wanted to verify you are not opposed in principle 14:41:30 I'll put it on my list to do before heading to berlin 14:41:36 ty 14:41:40 i'm done 14:41:44 #topic list --include-stores 14:41:51 there we go 14:41:58 hi Jokke 14:42:01 The spec was also merged this morn 14:42:25 my turn now?:) 14:42:28 this is also on my list to test out 14:43:40 sorry LiangFang, the floor is yours 14:43:49 OK.. 14:43:51 sorry 14:44:00 no my fault, i interrupted 14:44:54 my English is not good, now is my topic? 14:45:01 LiangFang: yes 14:45:08 OK.. 14:45:16 that's what we are talking about 14:45:33 sorry today I joined late 14:45:43 I have implemented the code 14:46:07 #link https://review.openstack.org/#/c/605014/ 14:46:19 someone gave comment to add UT, and I have added 14:46:53 hope you can help to take a look about this 14:47:18 another thing is that, I have about 10 patch to submit 14:47:38 so in the following days, I will submit one by one 14:47:44 sorry to bother you 14:48:06 no bother, but remember that next week is the summit, so things may be a bit slow 14:48:30 Ok 14:48:47 some colleague will join summit there 14:49:15 but the network team 14:49:24 I'm the storage team 14:49:59 so you are doing cinder and glance? 14:50:05 yes 14:50:13 starlingx glance and cinder 14:51:30 ok 14:51:36 so I also have lots of cinder patches to submit 14:52:41 ok lets continue on open discussion 14:52:47 #topic open discussion 14:52:56 Anything else we run out of time? 14:53:04 *before 14:53:31 yeah, just want to mention that gorka has a cinder patch up about greenthread starvation caused by the image-signature-verification code in cinder's image utils 14:54:04 i suspect we may be subject to a similar situation with the glance_store code 14:54:06 oh, how did that happen? 14:54:27 glance support image cache, right? 14:54:41 well, it depends on how much stuff you have running on the node 14:54:58 cinder uses rabbitmq for the scheduler and volume service interactions 14:55:06 LiangFang: yes we have caching that can be enabled on the API nodes 14:55:27 that's what was detecting starvation as service being down 14:55:50 so we probably don't see that, but could see it in hyperconverged edge nodes 14:56:15 found the link 14:56:23 #link https://review.openstack.org/#/c/615934/ 14:56:40 rosmaita: iirc our greenpool is by default 8000 per process ... I'd be surprised if that is the bottle neck 14:56:43 gorka has an interesting comment in there about greenthread and native thread interactions 14:57:27 yeah, i wonder why they're seeing this and we're not 14:57:35 jokke_: thanks 14:59:29 rosmaita: likely because we do stream the data through all our validation rather than cache it and run it through the validators and what not 14:59:55 yeah, that makes sense 15:01:42 like only place I really see us hitting heavily with these issue would be using fs store (which we fortunately do not support) with caching and loads of concurrent imports all going at the same time 15:02:35 ok, well that's a relief 15:03:09 yeah, we rarely do blocking io 15:04:16 most of our stuff is throttled by line speeds and buffers rather than having myriads of blocking interrupts 15:04:34 hooray for glance! 15:04:37 ok, sorry, we're out of time 15:04:48 #endmeeting