15:01:21 #startmeeting glare 15:01:22 Meeting started Tue May 9 15:01:21 2017 UTC and is due to finish in 60 minutes. The chair is mfedosin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:25 The meeting name has been set to 'glare' 15:02:18 #topic agenda 15:02:32 #link https://etherpad.openstack.org/p/glare-meeting-agenda 15:03:16 inarotzk: Idan, is it you? :) 15:03:28 yep, hello :) 15:03:35 hi! 15:03:43 let's begin then 15:03:52 #topic Updates 15:04:11 let me quickly describe my latest updates 15:04:32 inarotzk and then we can talk about yours :) 15:04:56 Great 15:05:10 so, 2 documentation units were merged yesterday 15:05:28 basic architecture and client setup 15:05:42 then I implemented several new tests 15:06:00 we will discuss it in next topic 15:06:17 also I updated glare docker image 15:06:36 and now you can inject your code inside the container 15:06:51 #link https://github.com/Fedosin/docker-glare 15:07:15 and image in docker hub is called "mfedosin/openstack-glare" 15:07:37 finally I implemented a small feature yesterday... 15:07:53 it was kinda a technical debt from my side 15:08:20 it is 'in' operator for 'version' filtering 15:08:50 Can you elaborate? 15:08:54 sure 15:09:11 for version we support all possible operators 15:10:02 for instance, if you want to get all artifacts with version greater than 2, then you provide filter: version=gt:2 15:10:29 the same story for lt, eq, neq and so on 15:10:46 but 'in' operator led to 500 error :( 15:11:42 if you want to send request like "give me all artifacts with version 1 *or* 2", then you send it as: version=in:1,2 15:12:09 nice ! 15:12:45 coercing works for this filter too 15:13:12 version=in:1.0.0,2.0.0 and version=in:1,2 are the same 15:13:37 probably that's all from my side 15:13:38 That's the meaning of coercing? (your example above) 15:14:26 yes, canonical format for version is "a.b.c-meta" 15:14:47 where a, b and c some numbers 15:15:09 but user can omit them if they are zeros 15:15:27 I understand 15:15:37 so, 2-rc1 will be converted to 2.0.0-rc1 on server side 15:15:57 and user doesn't need to bother about it 15:16:35 inarotzk: do you have any questions? 15:17:06 not on this topic :) 15:17:15 all right :) 15:17:25 should i update? 15:17:30 do you have any updates then? 15:17:36 yes, you're welcome 15:18:13 Yes, I wrote unit tests for sorting - https://review.openstack.org/463564 15:18:45 amazing! I'll review them today 15:19:01 While i did not, few question popped up 15:19:30 *while i did so 15:20:03 probably we will be able to discuss them during next topic... 15:20:16 do you have any other updates? 15:20:32 no 15:21:04 okay 15:21:17 #topic Unit tests and coverage 15:21:48 let me provide quick information about our status... 15:22:04 and then we will discuss your questions 15:22:27 cool 15:22:52 so, as I mentioned at last meeting we have a good coverage by functional tests 15:23:07 but it's hard to measure this coverage 15:23:32 and so we decided to begin this initiative 15:23:42 and implement a lot of unit tests 15:24:46 current coverage is near 69% which is not really bad, but definitely we can do better 15:25:17 it's after the exclusion of glare.tests folder 15:25:27 Can you remind me, how can we check the coverage? some command with tox? 15:25:50 if we include it in the coverage then results will be much higher, over 80% 15:26:08 yes, the simplest way is tox 15:26:18 command is: tox -e cover 15:26:42 it will generate a detailed report and place it in cover folder 15:27:10 since it's html you can view it in a webbrowser 15:28:01 my ideal plan is to make the coverage about 90% 15:28:10 which is hard but doable 15:29:10 we have 2 big items without unit tests now: upload/download and common utils 15:29:26 I'll be glad to take it 15:29:28 if we add tests for them we will get more then 80 15:30:01 *than 15:30:28 inarotzk: you can take common utils 15:30:37 and I'll do upload/download 15:30:50 I'll give you several examples on the matter 15:30:58 after this meeting 15:31:39 cool 15:31:52 but generally speaking I'm talking about this functions: https://github.com/openstack/glare/blob/master/glare/common/utils.py 15:32:30 if you build the report you will see big amount of red lines in this file 15:33:16 okay, so we have an action for Idan: 15:33:55 #action (inarotzk): implement unit tests for common utils 15:34:02 and an action for me 15:34:29 #action (mfedosin): implement unit tests for upload/download of blobs 15:34:56 and of course a global action: 15:35:26 #action increase test coverage up to 90% from the existing 69% 15:35:49 inarotzk: you wanted to ask questions... 15:36:42 yep , but they aren't really related to unit tests. Is it good time? 15:37:39 What do they related to? 15:38:14 Sorting operation and glare schema 15:38:30 no, it's fine to discuss it here 15:38:39 since you wrote unit tests for them 15:38:42 shoot :) 15:39:21 :) Sorting: Do we support 'secondary' sorting? 15:39:38 yes 15:40:06 sort=name:asc,version:desc,id:desc 15:40:07 and also for third, fourth etc ? 15:40:13 yes 15:40:49 it's comma separated list of artifact fields with optional sorting order 15:41:01 default one is desc 15:41:14 Ok, So maybe i should unit tests add for those scenarios :) 15:41:17 so, sort=name and sort=name:desc are the same 15:41:39 indeed! it will be awesome to have those tests 15:42:20 In glare schema: visibility has 2 options , as i understood. In ns_packages for example, 15:42:48 in the column available_values, i didn 15:43:15 what do you mean? 15:43:16 i didn't see those 2 options for visibility, and i think it might be good to add those 15:43:36 yes, visibility has two possible options now 15:43:44 'private' and 'public' 15:44:05 but afaiu it's included in the schema 15:44:15 let me check quickly 15:45:01 If i do glare schema ns_packages, i would expect to see in the row of visibility in the column of available_values: {'private', 'public'} but it's empty 15:45:11 inarotzk: you are right 15:45:20 it's not 15:46:06 let's include it then! it will be good 15:46:24 It might be a good opportunity for me to do it, and learn more by doing so 15:46:24 but, schemas are generated automatically 15:46:56 you just need to add appropriate validator to 'visibility' field in Base artifact type 15:47:27 okay, I'll help you on this 15:47:36 Thank you 15:48:02 #action (inarotzk) define available values for 'visibility' field 15:48:26 inarotzk: anything else? 15:48:44 No, thanks 15:49:17 okay, just a quick update from my side: 15:49:34 I've implemented a lot of tests for wsgi 15:49:48 #link https://review.openstack.org/#/c/463380/ 15:49:54 I know, it's hard to review 15:50:21 but please, if you have time :) 15:51:04 Yes :) 15:51:19 also I found unused file we can remove without consequences 15:51:26 https://review.openstack.org/#/c/463381/ 15:51:48 Have we ever used it? 15:51:49 probably that's all 15:52:04 let's discuss the documentation 15:52:11 #topic Documentation 15:52:39 I'm still writing the documentation related to artifact type framework 15:53:11 I wanted to finish it yesterday, but wsgi tests took a lot of time 15:53:23 and I gave up and postponed it 15:53:48 but I do think it will be done tomorrow or on Thursday 15:54:04 definitely this week :) 15:54:46 inarotzk: thank you for merging those two files! 15:55:08 #topic Open Discussion 15:56:03 Probably we should think how we can involve more people in glare community... 15:56:10 inarotzk: any ideas? 15:57:20 I think openstack mailing list is a good start 15:57:43 To write there about the project? 15:58:00 yes 15:58:29 show activity I would say 15:58:44 I'll take care about it :) 15:58:57 :) 15:59:01 also I found a bug in stackalytics 15:59:17 What is stackalytics ? 15:59:29 all glare commits from late March until May went to deb-glare 15:59:37 http://stackalytics.com/ 16:00:01 all OpenStack statistics 16:00:12 you can play with it 16:00:22 start with finding your stats :) 16:00:34 okay, we're out of time 16:00:43 inarotzk: thank you for coming 16:00:48 Thank you Mike 16:00:52 #endmeeting